james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: exceptions when saving mail
Date Tue, 02 Mar 2010 18:28:21 GMT
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 <mundt@tzi.de>:
> 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.ByteArrayInputStream@125bbd3, (long) 396202,
> (String) multipart, (String) mixed, (null) null]} [code=1406, state=22001]
> FailedObject: org.apache.james.imap.jpa.mail.model.JPAMessage@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.ByteArrayInputStream@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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message