Plugin Upgrade Failure: logExceptions Row size too large
Asked by 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-plugin2014-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: user22014-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: user22014-08-29 10:59:02,029 ERROR [pool-15-thread-1] [sf.hibernate.util.JDBCExceptionReporter] logExceptions Row size too large (&gt; 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: user12014-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
```


Answers:
author: Andy Brook [Plugin People]
body: I hit a [similar issue](https://thepluginpeople.atlassian.net/wiki/display/JEMH/Common+Problems#CommonProblems-UpgradewithMysqlto1.5.77+:Rowsizetoolarge) in JIRA (doesnt matter, its a db issue), but the [mysql documentation on row size limits](http://dev.mysql.com/doc/refman/5.0/en/column-count-limit.html) 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/)<http://www.postgresql.org/about/>to escape this and other problems that lay in wait with mysql!

comments: author: Mark Symons
body: 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](https://ecosystem.atlassian.net/browse/UPM-4660).


author: Nicholas Blew
body: 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.

comments: author: Langer
body: I have met the same problem?Row size too large?The Answer is useful for me?


author: elibishop
body: It looks like MySQL 5.6.20 has a known issue--- described [here](http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html) 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.


author: Daniel Urst?ger
body: 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://dba.stackexchange.com/questions/45837/mysql-row-size-too-large-8126>

[](http://www.silverstripe.org/general-questions/show/37158)<http://www.silverstripe.org/general-questions/show/37158>

[](http://serverfault.com/questions/326836/issue-with-maximum-row-size-in-mysql)<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>


author: Daniel Urst?ger
body: 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.


author: Septa Cahyadiputra
body: Hi Mark,

Please review our knowledge base article [here](https://confluence.atlassian.com/display/CONFKB/MySQLSyntaxErrorException%3A+Row+size+too+large). It might help you on this.

Cheers,  
Septa Cahyadiputra

comments: author: Daniel Urst?ger
body: 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.


Tags: confluence-administration