You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Tim-Christian Mundt <mu...@tzi.de> on 2010/03/02 19:21:39 UTC
exceptions when saving mail
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
Re: exceptions when saving mail
Posted by Norman Maurer <no...@googlemail.com>.
Hi Tim,
2010/3/2 Tim-Christian Mundt <mu...@tzi.de>:
> Thanks Norman,
>
> that was really quick. And it seems to work... weird. Am I the first person
> to store an email with more than 300kb? :)
Seems so, or at least you are the first who saw the exception ;)
I'm mostly use my email for maillinglists which usual don't get to big
emails ...
> Your query for altering the table did not work for me. Following the manual
> there is no "alter column". This worked:
>
> ALTER TABLE message CHANGE content content LONGBLOB
You are right, that happens when you need more sleep and have to less coffee =D
I just checked and I used the following yesterday:
ALTER TABLE Message MODIFY content LONGBLOB;
Not sure why I wrote the other one down yesterday.
Thx again,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: exceptions when saving mail
Posted by Tim-Christian Mundt <mu...@tzi.de>.
Thanks Norman,
that was really quick. And it seems to work... weird. Am I the first
person to store an email with more than 300kb? :)
Your query for altering the table did not work for me. Following the
manual there is no "alter column". This worked:
ALTER TABLE message CHANGE content content LONGBLOB
Best
Tim
Norman Maurer schrieb:
> 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 <no...@googlemail.com>:
>
>> 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 <mu...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: exceptions when saving mail
Posted by Norman Maurer <no...@googlemail.com>.
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 <no...@googlemail.com>:
> 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 <mu...@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
Re: exceptions when saving mail
Posted by Norman Maurer <no...@googlemail.com>.
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 <mu...@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