Hi Jerry, We got some unit tests for multiple UID deletion on top of JPA...
See MessageMapperTest::deleteMessagesShouldModifyUnderlyingStorageWithRange One way of getting further would be to run these tests against Amazon RDS. Also some IMAP integration test exists. Check JpaExpungeTest. Again, running it against RDS might help diagnosing the issue. Regards, Benoit On 15/11/2019 01:03, Jerry Malcolm wrote: > Any ETA on this issue. I have clients with several hundred emails they > want to delete but cannot unless they want to do it one at a time, which > is not acceptable to them. Anything I can do to help? I suspect when > a problem gets into multi-thread locking it's going to be over my head. > But I' willing to take a look anyway if I can just get a couple of > pointers to get me into the zipcode of where the problem might be. > > Thanks. > > Jerry > > On 10/29/2019 1:19 PM, Jerry Malcolm wrote: >> I created JAMES-2942 <https://issues.apache.org/jira/browse/JAMES-2942>. >> >> The emails in question do not have any additional explicitly-added >> user flags. >> >> Jerry >> >> On 10/28/2019 6:05 AM, Tellier Benoit wrote: >>> Every time I try to trash more >>> than one mail item at a time (select a bunch of mails in TBird and hit >>> 'Delete') I get a failure. The logs have a huge dump which I can attach >>> if necessary. But the key lines are: >>> >>> Caused by: <openjpa-3.0.0-r422266:1833209 fatal store error> >>> org.apache.openjpa.persistence.RollbackException: Optimistic locking >>> errors were detected when flushing to the data store. The following >>> objects may have been concurrently modified in another transaction: >>> [org.apache.james.mailbox.jpa.mail.model.JPAUserFlag-1530940342] >>> >>> Caused by: <openjpa-3.0.0-r422266:1833209 nonfatal store error> >>> org.apache.openjpa.persistence.OptimisticLockException: An optimistic >>> lock violation was detected when flushing object instance >>> "org.apache.james.mailbox.jpa.mail.model.JPAUserFlag-1530940342" to the >>> data store. This indicates that the object was concurrently modified in >>> another transaction. >>> >>> I understand locking, etc. I googled 'optimistic lock' but I'd have to >>> dig deeper to understand how it's used in JPA. In any case, apparently >>> these locks are fighting with each other when more than one update is >>> attempted on a mailbox. >>> >>> This is very reproducible. So far, I have never been able to delete >>> more than one item at a time. >>> >>> I guess my current version is in the ballpark of 3.4+. It was a clone >>> of the master branch right after 3.4 went live. >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
