[
https://issues.apache.org/jira/browse/JAMES-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187707#comment-13187707
]
Michael Herrmann commented on JAMES-1317:
-----------------------------------------
After a lot of debugging I finally figured out what caused the problem in my
case: My code contains a few additional JPA entity classes that are saved to
James's Derby database with OpenJPA (Just like James itself does).
Additionally, I use Spring's @Transactional-support for transaction handling.
Now, Spring's @Transactional support obtains a database connection from the
connection pool before my actual code is called. My code then calls
entityManager.persist(oneOfMyObjects), where entityManager comes from OpenJPA.
In persistence.xml, OpenJPA has a property called openjpa.jdbc.SchemaFactory,
its value is native(ForeignKeys=true). As far as I've understood, this setting
tells OpenJPA to look up and verify constraints on/between entities in the
database. This is done automatically when my code calls
entityManager.persist(...). What it does, and this is the crucial point, is to
read the schema data using a new(!) connection from the pool. In this case,
processing a mail thus requires two connections: One for the Spring transaction
and my code, and another to read the metadata. The reading of metadata is done
the very first time after the server is started. If, immediately after server
start, n mails arrive at the server in parallel where n is the size of the
connection pool, at least n + 1 connections are required to process this
request (n for my code, 1 for reading the metadata). The problem is that the n
connections are obtained immediately and cannot be released until after the
metadata has been read from the database. But, unfortunately, another
connection is required to do so and so the server ends up in a deadlock.
The root cause of this problem is precisely described in
http://mail-archives.apache.org/mod_mbox/openjpa-users/200708.mbox/%3c7262f25e0708231808r3f34911bpe172f600f35dd...@mail.gmail.com%3E.
The workaround for us will be to use a separate persistence unit with
openjpa.jdbc.SchemaFactory=dynamic and a new datasource so James should never
run out of connections again.
> Mail spooled but not processed
> ------------------------------
>
> Key: JAMES-1317
> URL: https://issues.apache.org/jira/browse/JAMES-1317
> Project: JAMES Server
> Issue Type: Bug
> Components: SpoolManager & Processors
> Affects Versions: 3.0-M1, 3.0-M2, 3.0-beta3
> Reporter: Raju Buchi
> Priority: Critical
> Fix For: 3.0-beta4
>
> Attachments: Dump.txt, Dump2.txt,
> james-server-mailetcontainer-camel-3.0-beta4-SNAPSHOT.jar,
> james-server-mailetcontainer-camel-3.0-beta4-SNAPSHOT.jar, jstack.zip,
> logs.zip, logs.zip
>
>
> Mails sent to James server are spooled but they are not processed and sent
> out.
> The issue is similar to the one faced by Zach.
> The server seems to be working fine for a few hours or few days, but some
> time all the mails are spooled but they will not be processed and sent out.
> Restarted the server several times and some time a few of the mails will be
> processed and all the others are lost.
> As Norman suggested I have took a jstack trace.
> Please let me how we can resolve this issue
> Thanks
> - Raju
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
