Ignite Realtime: Ignite Realtime Blog: Openfire 3.5.0 Release Candidate 1 Now Available

Ignite Realtime Blog

Previous Next

Openfire 3.5.0 Release Candidate 1 Now Available

Posted by jadestorm Mar 11, 2008

We are pleased to announce the availability of Openfire 3.5.0 RC1 off of the beta downloads page, along with Openfire Enterprise 3.5.0 RC1 off of the beta plugins page. The official release is slated for late March or early April, depending on when the official release date of Clearspace 2.0 is. There are a number of new features and bug fixes in this release. A couple of the highlights are as follows:

New Security Features

3.5.0 includes two new improvements to the overall security of Openfire. One is a new lock out manager, which allows administrators to lock out (disable) accounts, thereby preventing them from logging in. This can be for a period of time, or "forever". Another new security feature is a new auditor for actions performed in the admin console. This will allow you to keep track of what has changed in your server's configuration, and who performed the change.

For more information, see: Big Brother In 3.5.0

Invisibility

3.5.0 includes the ability to connect without sending an available presence. This provides an easy means for being "invisible" to other XMPP users, and visible specifically to those you intend on speaking to. This support needs to be built into clients or programs that you might be using to be of direct use, but the capabilities are now available!

For more information, see: Playing Casper in 3.5.0

Clearspace Integration Improvements

Clearspace 2.0 and Openfire 3.5.0 can now work together harmoniously to share users, groups, vcards, presence, and various other functionality. Not only that, but Clearspace and Openfire will configure their integration in a semi-automatic mode, where you provide a minimal configuration of Openfire and Clearspace and they take care of the rest! You will see a new option during initial setup where you can choose Clearspace integration that will lead you through the steps. Please note that Clearspace 2.0 or higher is required for this integration to function properly!

For more information, see: Clearspace 2.0 Public Beta

Performance Improvements

A number of improvements have been made to the overall performance of Openfire in 3.5.0. An important index was added to one of the database tables that improves roster loading speed by a large degree. The networking framework used for external component connections has also been replaced with MINA, drastically improving the performance of external component connections.

Fixed Double-Byte Character Problems

3.5.0 includes fixes for double-byte characters not being handled correctly. This should solve a number of problems with messages that include chinese characters, or other double-byte character encodings.

SparkWeb Enhancements

SparkWeb 3.5.0 includes a number of reliability improvements, especially with http binding, and also improved support for MUC functionality, such as moderation controls (kick/ban/etc).

New Admin Console Look and Feel

3.5.0 sports a brand new look and feel for it's administrative console. Those who have used Clearspace before will be familiar with it, as it's mirrored in concept and general look after Clearspace's administrative console. The new menu layout is much less cluttered than before, and should involve a lot less scrolling down the page to find what you want. Warning: Due to changes in the CSS files, and browsers wanting to hold onto CSS files for dear life in their caches, you will likely need to hit shift-reload on your browser when visiting the new admin console.

And more!

You can view the full changelog here.
You can view the updated documentation (javadocs et al) here.
Plugin updates required for Openfire 3.5.0 are available on the betaplugins page.
The specific plugins that need to be updated are:

IM Gateway
User Search
Enterprise
MOTD
SIP

Happy testing and please let us know of any issues you run into by posting in the Openfire support forum!

Thanks!
-The Openfire Team

Tags: openfire, planetjabber, release

Mar 12, 2008 10:30 AM

Martyn

Hey Guys

This is excellent news ! However, when I had a look at Beta download page, there was nothing there !

Martyn

Mar 12, 2008 10:33 AM

jadestorm in response to: Martyn

Try a shift-reload? I can see something there. Anyone else not seeing anything?

Mar 12, 2008 10:47 AM

Martyn in response to: jadestorm

Sorry, you were right - I hate IE sometimes ! As a point of interest, I checked this morning around 08:00 UK time and I couldn't see it then and revisited just prior to adding my comment so it should only be cached second time.

Apologies !

Mar 12, 2008 3:32 PM

wroot

what should i do when installer stays on "Uninstalling previous version" forever? this is not the first time i face that problem. It seems that installer finishes uninstall after all, but it doesnt go further, so i have to kill it and run again.

New GUI.. looks fine:) Though will have to get used.

Mar 12, 2008 3:35 PM

jadestorm in response to: wroot

Hehe, no idea. I've never seen that. What OS? Windows?

Mar 13, 2008 7:20 AM

Martyn

Hey Guys

I may have found an anomoly when using an existing database with MySQL (version 5.0.22).

I installed 3.50 RC1 and when it attempted to upgrade the database to the latest version it crashed.

I think this is related to the V14 upgrade which is this:

'#' jiveRoster: Add new index
ALTER TABLE jiveRoster ADD INDEX jiveRoster_jid_idx (jid(1024));

UPDATE jiveVersion set version=14 where name = 'openfire';

I've tried to maually enter the SQL and it caused the MySQL server to restart. I'm not an expert on MySQL either, so I'm not sure what it is about the statement it doesn't like but will dig around the logs etc.

Martyn

Mar 13, 2008 8:00 AM

jadestorm in response to: Martyn

I hate to say it, but that sounds like a MySQL bug. Your database should not be crashing just because someone adds an index. The odd thing is, I'm also running 5.0.22 and that index didn't cause a crash. Anyone have any suggestions?

mysql> alter table jiveRoster drop index jiveRoster_jid_idx;
Query OK, 9035 rows affected (0.25 sec)
Records: 9035 Duplicates: 0 Warnings: 0

mysql> alter table jiveRoster add index jiveRoster_jid_idx (jid(1024));
Query OK, 9035 rows affected, 1 warning (0.20 sec)
Records: 9035 Duplicates: 0 Warnings: 0

No restart. =/ I'm running mine on OS X. If I were to make a guess, it's crashing when it generates the index, which is not good. =) Lets try an alternative way of creating that table for you. Peform these MySQL steps:

CREATE TABLE `jiveRoster2` (
`rosterID` bigint(20) NOT NULL,
`username` varchar(64) NOT NULL,
`jid` text NOT NULL,
`sub` tinyint(4) NOT NULL,
`ask` tinyint(4) NOT NULL,
`recv` tinyint(4) NOT NULL,
`nick` varchar(255) default NULL,
PRIMARY KEY (`rosterID`),
KEY `jiveRoster_unameid_idx` (`username`),
KEY `jiveRoster_jid_idx` (`jid`(1024))
);

INSERT INTO jiveRoster2 SELECT rosterID,username,jid,sub,ask,recv,nick FROM jiveRoster;

If that succeeds, perform the next two:

DROP TABLE jiveRoster;

RENAME TABLE jiveRoster2 TO jiveRoster;

If all this succeeds:

UPDATE jiveVersion SET version=14 WHERE name = 'openfire';

What will all this accomplish? If the problem is that it's crashing while trying to generate the new index, this will avoid that problem by starting you with a fresh table and fresh index as it fills the new table.

Mar 13, 2008 8:08 AM

Martyn in response to: jadestorm

OK, I tried the first part:

CREATE TABLE `jiveRoster2` (
`rosterID` bigint(20) NOT NULL,
`username` varchar(64) NOT NULL,
`jid` text NOT NULL,
`sub` tinyint(4) NOT NULL,
`ask` tinyint(4) NOT NULL,
`recv` tinyint(4) NOT NULL,
`nick` varchar(255) default NULL,
PRIMARY KEY (`rosterID`),
KEY `jiveRoster_unameid_idx` (`username`),
KEY `jiveRoster_jid_idx` (`jid`(1024))
);

And SQL Admin reports:

Specified key was too long; max key length is 1000 bytes

So it looks like a config error on my MySQL setup then - just though it odd it actually crashed MySQL in the first place

Mar 13, 2008 8:16 AM

Martyn in response to: Martyn

I perhaps should add here that this database started life with Jive Messenger 2.1 and went through the transition to Wildfire and then to Openfire.

I haven't always upgraded to very realeased version, but have noted that on all occasions on previous ugrades, database update successful has always been reported.

I'm running the InnoDB engine as well for the tables.

This is running on a reasonable server with 2Gb RAM and Xeon processor - I start the DB using mysqld_safe --user=**

Mar 13, 2008 8:32 AM

Martyn in response to: Martyn

Sorry, I should also have added that if I just created the schema from scratch (ie not import existing tables and data), the tables were created with no problem by OF.

Mar 13, 2008 8:55 AM

jadestorm in response to: Martyn

What? It's creating the same freakin' index!

Mar 13, 2008 8:55 AM

jadestorm in response to: Martyn

Try changing the 1024 to 1000. If that works, then maybe I should change the official index length to 1000. For folks that have already upgraded, won't matter, they'll just have a slightly larger index.

Mar 13, 2008 9:35 AM

Martyn in response to: jadestorm

Already tried with a smaller index, same problem, crashes the server.

Mar 13, 2008 9:37 AM

jadestorm in response to: Martyn

Hrm. I'm not sure what to tell you at this point. Most of us use MySQL for primary testing. Anyone else seeing this?

Mar 13, 2008 9:41 AM

Martyn in response to: jadestorm

I wonder if this has something to do with the existing data and tables - if I start with a completely blank schema ie no tables, OF goes away and creates them quite happily.

Mar 13, 2008 9:43 AM

jadestorm in response to: Martyn

Well I mean, I upgraded from a previous version of the table, a number of times. =) I'd almost say that that's more heavily tested than a fresh install.

Mar 13, 2008 9:51 AM

Martyn in response to: jadestorm

If this isn't affecting anyone else, I don't think it's worth worrying about too much, I'll try and find a work around and see what happens.

Is the new index used explicitly in the code ?

Mar 13, 2008 9:54 AM

jadestorm in response to: Martyn

The index singlehandedly increases the speed of roster loading by a significant degree. Leaving it out means your roster loading will be "just as slow as it is now". =) So... if you just run the jiveVersion update line, then the rest of the updates will proceed and skip over that one.

Mar 13, 2008 10:03 AM

Martyn in response to: jadestorm

OK, thanks for all your help with this, it's much appreciated. I think this just goes to show what a great community we have here !

I will play with exporting all the data from the live system and import into a newly created blank set of tables. This should get around the issue of creating the index on the existing table set.

Also, just to add that having got RC1 up (if a bit by the back door !) it does look really great - great work.

Mar 14, 2008 10:53 AM