Confluence User-installed Plugins Screen Slow After Server Migration

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.

4 answers

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

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:

 

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

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.

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

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/.

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?

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Published 12 hours ago in Confluence

Think you know shares vs. @mentions in Confluence? Take this collab quiz.

To anyone who doubts that Atlassians are a little too obsessed with collaboration, and tools related thereto, let me describe a recent discussion we had (which took place on our internal Confluence, ...

95 views 2 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you