We did some load testing on our customized confluence installation. We are using conveyor to override existing xwork actions (e.g. the alphalist implementation provided by atlassian fetches all page objects of a space, does some permission filtering in memory and finally identifies the portion to present to the user. In case of a high number of page objects, this might not be an appropriate solution). Our conveyor plug-ins are spread over several plug-in archives.

The confluence xwork object factory implementation responsible to create new xwork action instances delegates the class lookup task to the ConfluencePluginObjectFactory and the PluginsClassLoader. Actually the ConfluencePluginObjectFactory class cycles for every xwork action class resolution through all plug-in classloader and ask them for the class instance. Every time a class is not present as part of an plug-in a ClassNotFoundException is thrown and the next plug-in is asked. So quite a number of exception might be generated. In addition there is this synchronized loadClass(..) method in PluginsClassLoader. In case confluence is under heavy load and the xwork action to resolve is served in our test scenario by the 20th plug-in, we observed that the xwork class resolution was delayed in worst case about 1s!! The main reason is that several threads are waiting for the loadClass method monitor.

(I assume that this problem is also present in case of xwork plug-ins.)

Please find attached a patched ConfluencePluginObjectFactory which helped us to solve the problem. This patch is using a cache to identify the plug-in classloader which may serve the class resolution.

It would be very helpful when atlassian would incorporate this patch in the next release (or find a even better solution for this performance problem.)