[MAGNOLIA-1981] Unable to update item due to mysqlDataTruncation exception Created: 28/Dec/07  Updated: 02/Jan/08  Resolved: 28/Dec/07

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: 3.0.5
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Edgar Vonk Assignee: Boris Kraft
Resolution: Not an issue Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux Centos 5, tomcat 5.5, jdk1.5.0_09, apache 2, mod_jk, MySQL 5


Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

If we enter too much (textual) content on a certain page we get the following exception:

ERROR  info.magnolia.module.admininterface.SaveHandlerImpl 19.12.2007 12:30:17 -- /: unable to update item.: failed to write property state: 55c1ea2e-ed07-4e20-b7f5-b05c720da66b/{}content
javax.jcr.RepositoryException: /: unable to update item.: failed to write property state: 55c1ea2e-ed07-4e20-b7f5-b05c720da66b/{}content: failed to write property state: 55c1ea2e-ed07-4e20-b7f5-b05c720da66b/{}content
        at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1197)
        at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:805)
        at info.magnolia.cms.core.HierarchyManager.save(HierarchyManager.java:525)
        at info.magnolia.module.admininterface.SaveHandlerImpl.save(SaveHandlerImpl.java:212)
        at info.magnolia.module.admininterface.DialogMVCHandler.onSave(DialogMVCHandler.java:284)
        at info.magnolia.module.admininterface.DialogMVCHandler.save(DialogMVCHandler.java:181)
        at sun.reflect.GeneratedMethodAccessor156.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at info.magnolia.cms.servlets.MVCServletHandlerImpl.execute(MVCServletHandlerImpl.java:96)
        at info.magnolia.cms.servlets.MVCServlet.doPost(MVCServlet.java:111)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
 
 
 
CAUSED by:
 
mysqlDataTruncation: Data truncation: Data too long for column 'PROP_DATA' at row 1
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3374)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3308)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1837)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1961)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2543)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1737)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2022)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1940)
        at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1925)

It seems there is a limit in the datamodel for the storage of this content? Or maybe it is a setting in our MySQL that we need to tweak? Any help is greatly appreciated.



 Comments   
Comment by David Smith [ 28/Dec/07 ]

You might want to look at the MySQL docs to fix this one. Specifically:
http://dev.mysql.com/doc/refman/5.0/en/set-option.html
for the syntax of the set command and
http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#option_mysqld_max_allowed_packet
for the specific property to change. I believe the show commnad will give you the current setting for your database.

Comment by David Smith [ 28/Dec/07 ]

It should be mentioned issues like this having to do with the configuration and implementation of magnolia should be posted on the magnolia-user list instead.

Comment by Magnolia International [ 28/Dec/07 ]

this is not a Magnolia issue - mysql configuration (or jackrabbit)
Thanks David.

Comment by Edgar Vonk [ 02/Jan/08 ]

ok. thanks guys. next time I will first post the issue to the mailing list. The thing is: I did not know that it was a MySQL issue (in fact: I still don't know for sure); I thought it was a bug in Magnolia. To be honest: I think it actually is a bug. Magnolia should really do a rollback of the database transaction (updating the node) I would think? Now what happens is that the node in question becomes corrupt.

Comment by David Smith [ 02/Jan/08 ]

Magnolia only uses Jackrabbit to store data. If there is a bug here, it's with Jackrabbit as Jackrabbit is responsible for all data storage including defining the db schema on first initialization. The advantage of using Jackrabbit is Magnolia doesn't have to know anything about the underlying data store.

Comment by Edgar Vonk [ 02/Jan/08 ]

Ah yes, of course. Forgot about that for a minute. Thanks!

Generated at Mon Feb 12 03:32:13 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.