Openfire 3.5.0 Release Candidate 1 Now Available

Blogs Ignite Realtime Blogs
1

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

2

Hey Guys

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

Martyn

3

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

4

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 !

5

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.

6

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

7

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

8

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.

9

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

10

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=**

11

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.

12

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

13

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.

14

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

15

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

16

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.

17

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.

18

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 ?

19

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.

20

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.