[
https://issues.apache.org/jira/browse/JAMES-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188449#comment-13188449
]
Michael Herrmann commented on JAMES-1317:
-----------------------------------------
No problem, you (Norman in particular) have been so helpful that it's nice for
me to try to give some useful insights back.
There are some news from our side: Setting openjpa.jdbc.SchemaFactory=dynamic
prevented a new connection from being borrowed from the pool in one case
(LazySchemaFactory), however there is at least one more case in which OpenJPA
tries to borrow an additional connection from the pool: When generating Ids
using OpenJPA's Sequence / generators functionality for the very first time,
OpenJPA creates a helper table with a new connection. Setting
<!--type=2 means org.apache.openjpa.kernel.Seq.TYPE_TRANSACTIONAL. In some
circumstances, this avoids an additional connection from being opened. -->
<property name="openjpa.Sequence" value="table(type=2)"/>
in persistence.xml fixes this, however then there is another instance in
org.apache.openjpa.jdbc.kernel.TableJDBCSeq where OpenJPA tries to obtain a new
connection. Changing openjpa.ConnectionRetainMode also does not help.
At this point, we see two options: The first is to add full-fledged JTA support
to James, hoping that then OpenJPA would always use the same connection for
side-tasks in the processing of a transaction. The second is to increase our
connection pool size to a value large enough so it does not run out of
connections. In theory, 21 should be enough: There are 20 spooler threads, each
requiring 1 connection when processing a mail, and OpenJPA should never need
more than 1 additional connection for its side tasks. To be on the safe side
however, I think we will set the maximum connection pool size to 50 and
configure the pool in such a way that connections that have not been returned
to the pool in a long time are removed (see
http://commons.apache.org/dbcp/configuration.html, "removeAbandoned"). I will
try this next.
> 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
