About getGroups method (GroupManager)

Openfire Openfire Support
1

I have a Wildfire 2.5.1 and a Oracle database, with /-1500 potencial users (/-100 logged simultaneously) distributed in about +/-200 shared groups.

As the number of logged users grows, I noticed that Wildfire’‘s access to Oracle database increased a lot. Analyzing Oracle’'s logs there are 3 queries being executed thousands of times every day:

  • SELECT description FROM jiveGroup WHERE groupName=:1

  • SELECT name, propValue FROM jiveGroupProp WHERE groupName=:1

  • SELECT username FROM jiveGroupUser WHERE administrator=0 AND groupName=:1

Looking at Wildfire code, it seems that the getGroup methods at GroupManager never uses the group cache… Is that correct?

2

This is correct. For Wildfire 2.6.0 which will be released soon, this will be “fixed” and groups will be cached. This code is already up in the nightly builds, so if you are intrested in checking it out in your Testing environment, make sure everything works as expected. We would very much appreciate it as it looks like your’'s is the exact problem we were attempting to solve by implementing this code!

Cheers,

Alex

3

Hi, Alex

I just downloaded last nightly build, and I’'ll let you know if it worked as son as I finish testing it…

[]’'s,

Francis

4

Hi again, Alex

I had to make two little adjustments to make it run:

  • added an update (and a commit, of course ) on resources\database\upgrade\7\wildfire_oracle.sql[/i], in order to set database version to 7;

  • 128 bytes is not enough to cache my shared groups. So I changed ‘‘cache.group.size’’ and ‘‘cache.userGroup.size’’ to 256 bytes. Nothing happened. So I changed CacheManager.java[/i] (line 73) from

size = JiveGlobals.getIntProperty(“cache.” + name + “.size”, size);

/code

to

size = JiveGlobals.getIntProperty(“cache.” + propertiesName + “.size”, size);

/code

Also, when server starts, generates a error when inserting a null nodeID into tables PUBSUBNODE, PUBSUBAFFILIATION and PUBSUBSUBSCRIPTION. I hav no idea why. Here’'s the log:

2006.03.30 16:24:36 [org.jivesoftware.wildfire.pubsub.PubSubPersistenceManager.createNode(PubSubPer sistenceManager.java:210)

]

java.sql.SQLException: ORA-01400: cannot insert NULL into (“JIVE”.“PUBSUBNODE”.“NODEID”)

at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)

at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)

at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)

at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)

at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)

at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.jav a:955)

at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:11 68)

at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatem ent.java:3285)

at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatemen t.java:3368)

at org.jivesoftware.wildfire.pubsub.PubSubPersistenceManager.createNode(PubSubPers istenceManager.java:207)

at org.jivesoftware.wildfire.pubsub.Node.saveToDB(Node.java:1558)

at org.jivesoftware.wildfire.pubsub.PubSubModule.initialize(PubSubModule.java:400)

at org.jivesoftware.wildfire.XMPPServer.initModules(XMPPServer.java:442)

at org.jivesoftware.wildfire.XMPPServer.start(XMPPServer.java:343)

at org.jivesoftware.wildfire.XMPPServer.(XMPPServer.java:136)

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.wildfire.starter.ServerStarter.start(ServerStarter.java:88)

at org.jivesoftware.wildfire.starter.ServerStarter.main(ServerStarter.java:49)

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)

/code

Anyway, now it’'s running and doing ok, so far…

[]’'s

Francis

5

Hey Francis,

Thanks for the detailed bug report and bug fixes. BTW, how did you fix the problem when inserting a null nodeID in pubsub tables? I don’'t see in the code (mine is newer) how could that happen. Many important bug fixes (that affect 2.5.1 and nightly build versions) where checked in today so you may want to install the next nightly build.

Regards,

– Gato

6

Actually, I didn’'t, just ignored it.

I installed te last nightly build (march, 31), with the same behaviour. Debugging it, I noticed that nodeID[/i] is set to a empty string when the xmpp.pubsub.root.nodeID[/i] property does not exist, wich is my case. Is seems that setString()[/i] method treats empty string and null values the same way, setting to NULL. But this is only a guess. I don’‘t know if this is a JDBC or an Oracle’'s issue.

Btw, as pubsub is a new feature, maybe the upgrade database scripts should set default values for it…

[]’'s

Francis

7

Actually oracle considers an empty string null. Its not a bug, its a feature

Alex