Plugin Upgrade Failure: logExceptions Row size too large

[Mark Symons]

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

[Andy Brook [Plugin People] · Accepted solution]

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!

[Mark Symons]

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.

[Nicholas Blew]

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.

[Langer]

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

[elibishop]

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.

[Daniel Urstöger]

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

[Daniel Urstöger]

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.

[Septa Cahyadiputra]

Hi Mark,

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

Cheers,
Septa Cahyadiputra

[Daniel Urstöger]

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.