Hi Tim, I had a look at the code and fixed it already ;) Please give latest head a try.
You will need to alter the column type of Message.content to the right one for your SQLServertype. For example for MYSQL: ALTER COLUMN Message.content TYPE LONGBLOB; Thx, Norman 2010/3/2 Norman Maurer <[email protected]>: > Hi Tim, > > please fill two jira issues: > > https://issues.apache.org/jira/browse/IMAP > > I will need to look at the source to understand whats going on here.. > > Thx, > Norman > > > 2010/3/2 Tim-Christian Mundt <[email protected]>: >> Hi, >> >> with certain mails I get this exception in HEAD: >> >> Exception in thread "Thread-18" <openjpa-1.2.1-r752877:753278 nonfatal user >> error> org.apache.openjpa.persistence.InvalidStateException: Can only >> perform operation while a transaction is active. >> at >> org.apache.openjpa.kernel.BrokerImpl.assertTransactionOperation(BrokerImpl.java:4389) >> at org.apache.openjpa.kernel.BrokerImpl.rollback(BrokerImpl.java:1367) >> at >> org.apache.openjpa.kernel.DelegatingBroker.rollback(DelegatingBroker.java:885) >> at >> org.apache.openjpa.persistence.EntityManagerImpl.rollback(EntityManagerImpl.java:528) >> at >> org.apache.james.imap.jpa.mail.JPATransactionalMapper.rollback(JPATransactionalMapper.java:69) >> at >> org.apache.james.imap.store.mail.AbstractTransactionalMapper.execute(AbstractTransactionalMapper.java:42) >> at >> org.apache.james.imap.store.StoreMailbox.appendMessage(StoreMailbox.java:203) >> at >> org.apache.james.imap.processor.AppendProcessor.appendToMailbox(AppendProcessor.java:116) >> at >> org.apache.james.imap.processor.AppendProcessor.doProcess(AppendProcessor.java:71) >> at >> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:123) >> at >> org.apache.james.imap.processor.AbstractMailboxProcessor.process(AbstractMailboxProcessor.java:80) >> at >> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:73) >> at >> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:44) >> at >> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:46) >> ... >> at >> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:46) >> at >> org.apache.james.imap.main.ImapRequestHandler.doProcessRequest(ImapRequestHandler.java:171) >> at >> org.apache.james.imap.main.ImapRequestHandler.handleRequest(ImapRequestHandler.java:102) >> at >> org.apache.james.imapserver.mina.ImapIoHandler$1.run(ImapIoHandler.java:97) >> at java.lang.Thread.run(Unknown Source) >> >> >> The problem here is that OpenJPA automatically rolled back during commit, >> hence, there is no transaction any more: >> >> >> org.apache.james.imap.mailbox.StorageException: failed. Transaction commit >> failed.; >> nested exception is: >> <openjpa-1.2.1-r752877:753278 fatal store error> >> org.apache.openjpa.persistence.RollbackException: The transaction has been >> rolled back. See the nested exceptions for details on the errors that >> occurred. >> at >> org.apache.james.imap.jpa.mail.JPATransactionalMapper.commit(JPATransactionalMapper.java:60) >> at >> org.apache.james.imap.store.mail.AbstractTransactionalMapper.execute(AbstractTransactionalMapper.java:40) >> at >> org.apache.james.imap.store.StoreMailbox.appendMessage(StoreMailbox.java:203) >> at de.cowimas.mail.CowiMailbox.appendMessage(CowiMailbox.java:31) >> at >> org.apache.james.imap.processor.AppendProcessor.appendToMailbox(AppendProcessor.java:116) >> at >> org.apache.james.imap.processor.AppendProcessor.doProcess(AppendProcessor.java:71) >> at >> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:123) >> at >> org.apache.james.imap.processor.AbstractMailboxProcessor.process(AbstractMailboxProcessor.java:80) >> at >> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:73) >> at >> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:44) >> ... >> >> >> How can that be checked so that rollback() is only executed if OpenJPA >> hasn't done so before? >> >> Second: there's obviously a reason for OpenJPA to roll back: >> >> >> Caused by: <openjpa-1.2.1-r752877:753278 nonfatal general error> >> org.apache.openjpa.persistence.PersistenceException: Data truncation: Data >> too long for column 'content' at row 1 {prepstmnt 23802890 INSERT INTO >> Message (id, bodyStartOctet, content, contentOctets, mediaType, subType, >> textualLineCount) VALUES (?, ?, ?, ?, ?, ?, ?) [params=(long) 2501, (int) >> 786, (InputStream) java.io.bytearrayinputstr...@125bbd3, (long) 396202, >> (String) multipart, (String) mixed, (null) null]} [code=1406, state=22001] >> FailedObject: org.apache.james.imap.jpa.mail.model.jpamess...@1126d91 >> at >> org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4232) >> at >> org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4197) >> at >> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:102) >> at >> org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:72) >> at >> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:131) >> at >> org.apache.openjpa.jdbc.kernel.BatchingPreparedStatementManagerImpl.flushAndUpdate(BatchingPreparedStatementManagerImpl.java:82) >> at >> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:89) >> at >> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:72) >> at >> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:543) >> at >> org.apache.openjpa.jdbc.kernel.ConstraintUpdateManager.flush(ConstraintUpdateManager.java:105) >> at >> org.apache.openjpa.jdbc.kernel.BatchingConstraintUpdateManager.flush(BatchingConstraintUpdateManager.java:59) >> at >> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:89) >> at >> org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:72) >> at >> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:717) >> at >> org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:130) >> ... 31 more >> Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Data >> truncation: Data too long for column 'content' at row 1 {prepstmnt 23802890 >> INSERT INTO Message (id, bodyStartOctet, content, contentOctets, mediaType, >> subType, textualLineCount) VALUES (?, ?, ?, ?, ?, ?, ?) [params=(long) 2501, >> (int) 786, (InputStream) java.io.bytearrayinputstr...@125bbd3, (long) >> 396202, (String) multipart, (String) mixed, (null) null]} [code=1406, >> state=22001] >> at >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:192) >> at >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$700(LoggingConnectionDecorator.java:57) >> at >> org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:866) >> at >> org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:269) >> at >> org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1586) >> at >> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:151) >> at >> org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:120) >> ... 41 more >> >> >> "Data too long for column 'content'" sounds as if the email was gigantic, >> but it isn't (< 300kB) and I don't know about any restrictions concerning >> size. The kind of mails causing the problem have the Content-Type: >> multipart/related; or mails containing such mails as attachments. At least >> that's the pattern we found here. Maybe, the input stream fed into the >> "content" field is not correct but there is some endless recursion or so. >> >> I'd be glad to help on that but will need your advice. Should I file one or >> two jira issues for that? >> >> Regards >> Tim >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
