upgraded to 3.6.0a - same problem.
I’ll have to revert to one week old backup of 3.5.2
Look at my post from last night few comments down from this one (especially if you’re using SQL Server…). I had essentially the same problem with 3.6.0a as with 3.6.0, but was able to complete the install a with manual patch.
Ville
I understand that the admin console will only show 3.6.0, but should Openfire keep IM’ing my Admin account daily that 3.6.0a is available? It’s annoying, but only every 24 hours or so.
jaysonben wrote:
I ran the upgrade from 3.5.2 to 3.6.0a and everything went smoothly until I tried to log into the admin console. All admin passwords had been erases. I went into the conf\openfire.xml and modified it so I could rerun the setup. Did that and then set myself up as an admin again. I tried logging in a little later and my password had been deleted again. The really funny thing is, I could still log into Spark and chat. I have Openfire running in a Windows domain envrionment.
do you see anything in the error logs when you try to log in? it most certainly should not “lose” your admin user list. One thing you can check is under system properties there will be a property called ‘admin.authorizedJIDs’, make sure that that has the proper list of users in it.
Nulani wrote:
Here’s error.log. Seems the problem is caused by JiveUsersFlag.
It seems it might be the database version number that’s bugged and that it indeed is v19 ( or what Openfire 3.5.2 uses. I’ll manually bump it while checking if the upgrades have already been made. )
Solved: The database was version 16. I manually bumped the version numbering.
You -just- bumped the version number? Without running the upgrade scripts? If you didn’t run the upgrade scripts corresponding with where you were to where the db is expected to be now, nothing is going to work right. =)
wroot wrote:
Just FYI, clean 3.5.2 (not touched, embedded-db) upgrade to 3.6.0a. All fine. Just Admin Console shows that there is 3.6.0a available
Upgraded IM Gateway - fine too.
Now i’ll digg the changelog and check out all the changes and new features. Btw, about backups. I dont like to do them, or i never do them before upgrade. Because i have setup them (backup scripts) to do this automatically for me
laugh Well that’s good that you do regular backups, and IMO is just as good in this scenario as long as you don’t mind losing the data from “right before upgrade” to “last backup”. =)
scottr wrote:
Well, as I said, it’s MySQL 4.1.22 (technically 4.1.22rc) running on a stock Mac OS X Server 10.4.11 machine.
Thanks for the workaround on creating the index; I’m sure that will do nicely. I hadn’t had time to look it up yet – this was on a home server and I was actually supposed to be working at the time. And yes, I ran the rest of the SQL scripts, it’s just that index that was still broken.
Finally, if I create a new column in a new table in a new database as “varchar(1024)” it automagically gets turned into “text”.
Are you kidding me? What the #%$# kinda database changes table column types out from under you? I’d far rather it reject and say “no, not going to do a varchar of that size” than auto-change. =(
mhterres wrote:
Hi.
I downloaded and installed version 3.6.0a (using .tar.gz). Now when I log in admin console the version still appears as 3.6.0 and the message to upgrade to version 3.6.0a is still there.
I did it 3 times in 2 different servers with the same results. What could be wrong ?
Regards,
Marcelo Terres
Hi I mentioned that in the release announcement =P It will show as 3.6.0 'cause frankly, there’s no way to make it be 3.6.0 officially in the code. So 3.6.0a is really just a “replacement bugfix” for 3.6.0. So basically, no need to be concerned over that!
tnt wrote:
same problem with 3.6.0a
Seeing anything in your error logs? Thre should be some exceptions indicating why it’s doing that.
sab0900 wrote:
Links to download the update still don’t work. But after looking at this thread, I would say the links not working is a good thing for now. It appears that testing on 4 systems doesn’t equate to a proper beta test. This is why most software companies beta test on 10’s or 100’s of systems before an official stable release.
This reminds me of this programmer I once worked with. His most common response to an inquiry as to why his “stable release” apps didn’t work was, “Well it works on my laptop.”
laugh I think you read too much into that. I tested it live on 4 servers that I run. I tested it locally on 8 separate installs with different data. Then another 12 iterations.
wroot wrote:
Oh, i just agree with Daryl and others, that this release (3.6.0) should be released as Beta first. As this is a community driven software (should be), so beta test could be done by 100’s completely different systems.
I agree. Things got away from us and messed up our release procedure. Doesn’t really matter what the reasons are though, should have gotten one out. I apologize for that.
jcorreia wrote:
just to add some feedback.
Clean install in Centos5 is working ok.
Although I had an error on intall with the .rpm version : "JAVA_HOME not found "(or something like that) error . It´s odd, but I fixed it putting “JAVA_HOME=/opt/openfire/jre” in /etc/sysconfig/openfire.
Thanks
Interesting, have you had this happen before? It’s supposed to automatically find that embedded jre.
blink I wonder why it thought you were at 18?? Any chance you had attempted the upgrade before and had it fail? I wonder if it found ofVersion from a previous attempt and was reading from there? Either way I’m glad you got running and sorry for the trouble!
Ville wrote:
Ok, upgrade complete… but it wasn’t a totally smooth upgrade.
Firstly, for some reason my database was using version 14 (I was upgrading from 3.5.2), so I had to manually apply update scripts from 15 onward. Everything went fine until script 19 where I got lots of errors:
Found old database version 18 for openfire. Upgrading to version 20…
Database setup or configuration error: Please verify your database settings and check the logs/error.log file for detailed error messages.
java.lang.IllegalArgumentException: java.sql.SQLException: Invalid object name ‘ofID’.
at org.jivesoftware.openfire.XMPPServer.verifyDataSource(XMPPServer.java:710)
at org.jivesoftware.openfire.XMPPServer.start(XMPPServer.java:427)
at org.jivesoftware.openfire.XMPPServer.(XMPPServer.java:161)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.jivesoftware.openfire.starter.ServerStarter.start(ServerStarter.java:106)
at org.jivesoftware.openfire.starter.ServerStarter.main(ServerStarter.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
at com.exe4j.runtime.WinLauncher.main(Unknown Source)
Caused by: java.sql.SQLException: Invalid object name ‘ofID’.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:368)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2816)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2254)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:631)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:477)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatem ent.java:777)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.logicalcobwebs.proxool.ProxyStatement.invoke(ProxyStatement.java:100)
at org.logicalcobwebs.proxool.ProxyStatement.intercept(ProxyStatement.java:57)
at $java.sql.Statement$$EnhancerByProxool$$67135b2b.executeQuery()
at org.jivesoftware.openfire.XMPPServer.verifyDataSource(XMPPServer.java:700)
… 16 more
Error starting the server. Please check the log files for more information.
Server halted
Even though it said “Found old database version 18 for openfire.”, the 3.5.2 database was version 14 (i.e. changes from script 14 were present, but not those from script 15). Perhaps it was supposed to be that way, and perhaps the Openfire upgrade process had upgraded the database from 14 to 18, and since script 19 had failed, it had stopped there.
The problem with the script 18 was number of “Incorrect syntax near ‘sp_rename’.” errors and nothing got done. Looking on the web I found this page where it was suggested that “exec” could be added in front of sp_rename commands. I did so, and the script 19 (and then subsequently the script 20) completed (i.e. the table renames were done). With the script 19 I did still get lots of warnings, but perhaps they can be safely ignored:
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Warning! The maximum key length is 900 bytes. The index ‘ofRoster_jid_idx’ has maximum length of 2048 bytes. For some combination of large values, the insert/update operation will fail.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Warning! The maximum key length is 900 bytes. The index ‘ofSASLAuthorized_pk’ has maximum length of 4128 bytes. For some combination of large values, the insert/update operation will fail.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Caution: Changing any part of an object name could break scripts and stored procedures.
Query OK, -1 rows affected (515 ms)
As far as I can tell, Openfire 3.6.0 is now working ok on my server.
This is small LAN server running a Windows 2003 Standard edition with SQL Server 2005.
Thanks for the new version!
Ville
majorsl wrote:
I understand that the admin console will only show 3.6.0, but should Openfire keep IM’ing my Admin account daily that 3.6.0a is available? It’s annoying, but only every 24 hours or so.
I must admit I don’t know why it’s doing that — except that it’s confused between what can be locally represented and what the package is called. Sigh. Try going into system properties and setting this to false: update.notify-admins
That’ll shut up the notifications!
Is your server called “office”? What does it say in the admin console? Does it say office there? What appears to be happening is it’s trying a server to server connection for what is probably supposed to be itself, which is clearly wrong behavior, but I want to get the whole scenario first.
VeNT wrote:
I’m now getting a really annoying issue
no-ones showing as online!
all my users can login but non can send messages!
logs showing these messages but I don’t know what they mean!
line
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:253)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:144)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:239)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2008.09.01 13:26:47 [org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSes sion(LocalOutgoingServerSession.java:258)
] Error trying to connect to remote server: office(DNS lookup: office:5269)
java.net.UnknownHostException: office
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:253)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:144)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:239)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2008.09.01 13:26:58 [org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSes sion(LocalOutgoingServerSession.java:258)
] Error trying to connect to remote server: office(DNS lookup: office:5269)
java.net.UnknownHostException: office
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:253)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:144)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:239)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2008.09.01 13:27:37 [org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSes sion(LocalOutgoingServerSession.java:258)
] Error trying to connect to remote server: office(DNS lookup: office:5269)
java.net.UnknownHostException: office
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.createOutgoingSess ion(LocalOutgoingServerSession.java:253)
at org.jivesoftware.openfire.session.LocalOutgoingServerSession.authenticateDomain (LocalOutgoingServerSession.java:144)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.sendPa cket(OutgoingSessionPromise.java:239)
at org.jivesoftware.openfire.server.OutgoingSessionPromise$PacketsProcessor.run(Ou tgoingSessionPromise.java:216)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2008.09.01 13:29:13 [org.jivesoftware.util.log.util.CommonsLogFactory$1.error(CommonsLogFactory.jav a:88)
] Line=19 The content of element type “dwr” must match “(init?,allow?,signatures?)”.
ubulid00 wrote:
I’m running into the same issue on Linux x86_64 with mysql 4.1.20, what is the full sql syntax to correct the update 14 error:
ERROR 1170 (42000) at line 5: BLOB/TEXT column ‘jid’ used in key specification without a key length
Hrm. Edit the associated script in resources/database/upgrade/14/openfire_mysql.sql and change it to include a key length. Change it to something like:
ALTER TABLE jiveRoster CHANGE COLUMN jid jid varchar(1024) not null;
Not to this version. The restored database was 3.5.2, and it had never been attempted to be upgraded. Of course, it may have been that on the first start of Openfire 3.6.0 it correctly would’ve showed the level (14 or whatever) but since the 19th upgrade script didn’t work, it stalled there, and on the next try (when I paid attention to the version) it was then 18.
Do you think it might be a good idea to prefix the sp_rename commands with “exec” in the future?
It turns out this is documented behavior.
http://dev.mysql.com/doc/refman/4.1/en/silent-column-changes.html
“From MySQL 4.1.0 onward, a CHAR or VARCHAR column with a length specification greater than 255 is converted to the smallest TEXT type that can hold values of the given length. …”
Thanks, that worked. I also had to do a similar fix to mysql update 19, I think.
I had a quick and bad experience upgrading from 3.5.2 to 3.6.0a (Win2003, embedded db) :
-
unstable client connections
-
search plugin not working
-
random ldap authentication, my admin account and workstation IP becoming blacklisted because of too many bad connection attempts.
So I reverted the server to my 3.5.2 backup… which could not start anymore (main class not found).
I had to restart the 3.5.2 install executable and copy the backed-up conf and embedded db to make things work again.
Next time, please put a “beta” label on early releases.