Confluence User-installed Plugins Screen Slow After Server Migration
Asked by Jonathan Martin:

We've just migrated Confluence to a new server. I'm attempting to re-install all of our plugins/add-ons. However, For some reason when accessing the "Manage add-ons" screen the "User-installed" add-ons is taking 10 mins or so to load. We never had an issue in our previous environment.

Here's some background on what I've done/researched:

**Background**

1. No errors in the logs.
2. Able to access System plugins on the "Manage add-ons" screen without delay.
3. Able to still upload plugins after waiting 10 mins for the "User-installed add-ons" section to load.
4. Disabled UPM using the JVM arg: -Dupm.pac.disable=true.
5. Able to access legacy Confluence plugin screen using this URL:
   1. https://\<confluence-root\>/admin/viewplugins.action
   2. I can upload JAR packaged plugins here but not OBR's. Also, this screen responds normally.

Here are our specs. The new environment is the same except for the database which we've migrated from MySQL to Oracle:

**Specs**

* Windows O/S
* Confluence v5.4.4
* UPM v2.14.0

Just a few thoughts on what it could be or how to proceed:

* We successfully migrated the data, could it be due to old plugin data from the previous environment?
* Is there a way for me to enable debug logging for UPM or profile the UPM page?
* Thought about upgrading the UPM plugin.

Any help would be greatly appreciated.


Answers:
author: JenniferC
body: I am pretty much experiencing exactly the same problem using the almost exact version numbers (mine is Confluence 5.4.1), except that in my case the database was migrated from HSQL to Microsoft SQL Server.

Did you ever find the answer to this?


author: Jonathan Martin
body: Hey thanks. These KB articles sound very familiar to what we're running into. I'll give safe mode a shot... then attempt upgrading.

comments: author: Jonathan Martin
body: Running in safe mode didn't fix the issue. I see this in the logs... Could it be related to my cache size?Will try upgrading UPM too. However, I'd like to find the root cause first.


author: Jonathan Martin
body: Forgot to add the logs:WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf key type: java.lang.Long WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf key: 13928065 WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf value type: net.sf.ehcache.Element WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf value: \[ key = 13928065, value=Item{version=null,freshTimestamp=5799399801057280,value type=\[Ljava.io.Serializable;}, version=1, hitCount=0, CreationTime = 1415869092055, LastAccessTime = 1415869092055 \] WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf container: net.sf.ehcache.store.chm.SelectableConcurrentHashMap$HashEntry@31887c WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf The configured limit of 100 object references was reached while attempting to calculate the size of the object graph. This can be avoided by adding stop points with @IgnoreSizeOf annotations. Since the CacheManger or Cache \<sizeOfPolicy\> elements maxDepthExceededBehavior is set to "abort", the sizing operation has stopped and the reported cache size is not accurate. If performance degradation is NOT an issue at the configured limit, raise the limit value using the CacheManager or Cache \<sizeOfPolicy\> elements maxDepth attribute. For more information, see the Ehcache configuration documentation. WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf key type: java.lang.Long WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf key: 13928065 WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf value type: net.sf.ehcache.Element WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf value: \[ key = 13928065, value=Item{version=null,freshTimestamp=5799399801057280,value type=\[Ljava.io.Serializable;}, version=1, hitCount=0, CreationTime = 1415869092055, LastAccessTime = 1415869092055 \] WARN \[pool-1-thread-1\] \[ehcache.pool.impl.DefaultSizeOfEngine\] sizeOf container: net.sf.ehcache.store.chm.SelectableConcurrentHashMap$HashEntry@28874e


author: abhalla
body: I missed the part in your question where you said you moved from MySQL to Oracle. This is now out of my league. You might want to raise a ticket at <https://support.atlassian.com/>.


author: abhalla
body: You might try upgrading to the latest version of UPM (available from <https://marketplace.atlassian.com/plugins/com.atlassian.upm.atlassian-universal-plugin-manager-plugin>). Some performance improvements were made in 2.14.2, but the latest version (2.18.1) has other fixes and improvements.

It doesn't sound like these KB articles are relevant, but I'll list them here anyway:

* SharePoint Connector: <https://confluence.atlassian.com/display/CONFKB/Updating+or+installing+plugins+takes+a+very+long+time+because+of+SharePoint+Connector>
* Spreadd: <https://confluence.atlassian.com/display/CONFKB/Updating+or+installing+plugins+takes+a+very+long+time+because+of+Spreadd+for+Confluence+Plugin>


author: Jonathan Martin
body: Some more info... We've got Service Rocket's Visibility and Redirect plugin installed. I'm beginning to think it may have something to do with these plugins and Oracle based on this:<https://community.servicerocket.com/servicerocket/topics/problem_installing_reporting_plugin_4_3_2_on_confluence_5_4_4>


Tags: confluence-administration

confluence-app

servicerocket

universal-plugin-manager