Plugin Upgrade Failure: logExceptions Row size too large

I have recently migrated a Confluence Server (v5.5.6) from HSQL DB to MySQL v5.6.20. Since then a couple of plugin upgrades have failed. Once with Gliffy, and then today when upgrading to UPM 2.17.13. The plugins upgrade just fine on another Confluence v5.5.6 that is still running HSQL DB.

Has anyone else seen these errors...

  • logExceptions Row size too large (> 8126)
  • execute Could not synchronize database state with session

...or have thoughts on how to address them? I can find no reference in JAC and wanted to ask here before logging a support call.

2014-08-29 10:58:56,064 INFO [UpmAsynchronousTaskManager:thread-4] [atlassian.plugin.manager.DefaultPluginManager] disableDependentPlugins Found dependent enabled plugins for uninstalled plugin 'com.atlassian.upm.atlassian-universal-plugin-manager-selfupdate-plugin': [].  Disabling...
2014-08-29 10:58:56,069 INFO [UpmAsynchronousTaskManager:thread-4] [atlassian.plugin.manager.DefaultPluginManager] updatePlugin Updating plugin 'com.atlassian.upm.atlassian-universal-plugin-manager-selfupdate-plugin' to 'com.atlassian.upm.atlassian-universal-plugin-manager-selfupdate-plugin'
2014-08-29 10:58:56,075 INFO [UpmAsynchronousTaskManager:thread-4] [atlassian.plugin.manager.DefaultPluginManager] notifyPluginDisabled Disabling com.atlassian.upm.atlassian-universal-plugin-manager-selfupdate-plugin
2014-08-29 10:58:56,269 WARN [UpmAsynchronousTaskManager:thread-4] [atlassian.confluence.cache.TransactionalCacheFactory] warning Transactional cache update outside transaction. All updates to this cache should be performed from a thread with a valid transaction context.
 -- referer: http://foo.bar.com/plugins/servlet/upm | url: /rest/plugins/1.0/installed-marketplace | userName: user2
2014-08-29 10:58:56,278 WARN [UpmAsynchronousTaskManager:thread-4] [atlassian.confluence.cache.TransactionalCacheFactory] warning Transactional cache update outside transaction. All updates to this cache should be performed from a thread with a valid transaction context.
 -- referer: http://foo.bar.com/plugins/servlet/upm | url: /rest/plugins/1.0/installed-marketplace | userName: user2
2014-08-29 10:59:02,029 ERROR [pool-15-thread-1] [sf.hibernate.util.JDBCExceptionReporter] logExceptions Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
 -- referer: http://foo.bar.com/plugins/servlet/upm | url: /rest/plugins/self-update/1.0/ | userName: user1
2014-08-29 10:59:02,033 ERROR [pool-15-thread-1] [sf.hibernate.impl.SessionImpl] execute Could not synchronize database state with session
 -- referer: http://foo.bar.com/plugins/servlet/upm | url: /rest/plugins/self-update/1.0/ | userName: user1

6 answers

1 accepted

I hit a similar issue in JIRA (doesnt matter, its a db issue), but the mysql documentation on row size limits states there is 64Kb (data) limit, however, your log traffic is indicating something lower, so not sure where that comes from. Regardless its a limitation of your database that the developer of pluginX didn't consider, contact the company involved.

Postgresql is just ever so much better in this and other areas (IMO), so if you have a choice, go there, http://www.postgresql.org/about/to escape this and other problems that lay in wait with mysql!

I followed the advice given by Septa to increase MySQL maximum allowed packet size. As Daniel has found, it did not work.

Thus, I am going with Andy's suggestion that this is a limitation that the "developer of pluginX didn't consider". pluginX in this case happens to be the Universal Plugin Manager - so the developer is Atlassian!

Thus, I have logged UPM-4660.

Eli has the right idea here, I just edited the variable he mentioned, innodb_log_file_size and I was able to update the plugin. My original value on a fresh MySQL 5.6 install was 48M, I changed it to 500M. If Atlassian comes back with a better value to use, I will substitute that in instead, but the 500M value worked to restore plugin functionality.

I have met the same problem:Row size too large,The Answer is useful for me。

Hi Mark,

Please review our knowledge base article here. It might help you on this.

Cheers,
Septa Cahyadiputra

I run into this problem even though the max_allowed_packet is set to 512MB, so it is most likely something else.

The issue came up with our Confluence installation which runs on MySQL since the beginning and it just emerged with latest Gliffy and UPM updates, before that we didn t have that issue.

I run into this problem even though the max_allowed_packet is set to 512MB, so it is most likely something else.

The issue came up with our Confluence installation which runs on MySQL since the beginning and it just emerged with latest Gliffy and UPM updates, before that we didn t have that issue.

I dug a lot into this problem and currently have no solution for this, but I tried moving my innodb Storage files to Barracuda and type to "Dynamic" or "Compressed" which didn t change anything. Googeling around the error message brought up doing that might fix the problem. Anyhow, maybe it is related to the MySQL version one is running?

I have 5.6 from Percona. Which version do you run?

Here are some of the arcticles I found relevant:

http://dba.stackexchange.com/questions/45837/mysql-row-size-too-large-8126

http://www.silverstripe.org/general-questions/show/37158

http://serverfault.com/questions/326836/issue-with-maximum-row-size-in-mysql

http://stackoverflow.com/questions/15585602/change-limit-for-mysql-row-size-too-large

http://dba.stackexchange.com/questions/14246/innodb-file-format-barracuda

It looks like MySQL 5.6.20 has a known issue— described here under "InnoDB Notes"— that superficially resembles the error mentioned in the knowledge base article Septa linked to, but has a different cause and requires a change to innodb_log_file_size instead (or upgrading to MySQL 5.7.5). I have not tried to reproduce this in a live Confluence instance with MySQL, but based on the error description it sounds very likely. If so, we should update our KB article; I'll try to get in touch with a support engineer who knows more about MySQL than I do.

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
Kesha Thillainayagam
Posted Apr 13, 2018 in Confluence

We want to hear how your non-technical teams are using Confluence!

Hi Community! Kesha (kay-sha) from the Confluence marketing team here! Can you share stories with us on how your non-technical (think Marketing, Sales, HR, legal, etc.) teams are using Confluen...

345 views 20 10
Join discussion

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