Ok, I think I can confirm the bug in JDBCSpoolRepository :-(
I opened an issue:
http://issues.apache.org/jira/browse/JAMES-603
Imho this is a blocker.
And maybe some of the reporting we had in past about james using 100%
CPU for a while after a restart (after a period of stopped activity)
could be related to this issue.
As soon as I reduce the number of the "old" error messages under 1000
the processing starts again and the CPU return to the normal values.
Stefano
Stefano Bagnara wrote:
Stefano Bagnara wrote:
Noel J. Bergman wrote:
Stefano: That sounds a lot like issues I saw last week with 1.4.2_12 and
1.5.0_08, and which I am not seeing with 1.4.2_09.
Update:
The autoReconnect change didn't fix it
(but I will remove it from the jdbc url anyway)
I just downgraded to 1.4.2_09 and restarted... now I don't have much
mails anymore, but we'll see if it happens later.
It happened again. Everyone is waiting for this thread to unlock the
spoolrepository:
"Remote delivery thread (31)" prio=1 tid=0x09201aa8 nid=0x7c03 runnable
[a306d000..a306e238]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at
com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:113)
at
com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:160)
at
com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:188)
- locked <0xa94ff950> (a com.mysql.jdbc.util.ReadAheadInputStream)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1910)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2304)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2803)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
at
com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1160)
- locked <0xa94ffdb0> (a java.lang.Object)
at
com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:685)
at
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1253)
- locked <0xa94ffdb0> (a java.lang.Object)
at
org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:92)
at
org.apache.james.mailrepository.JDBCSpoolRepository.loadPendingMessages(JDBCSpoolRepository.java:276)
- locked <0xa67453a8> (a java.util.LinkedList)
at
org.apache.james.mailrepository.JDBCSpoolRepository.getNextPendingMessage(JDBCSpoolRepository.java:248)
- locked <0xa67453a8> (a java.util.LinkedList)
at
org.apache.james.mailrepository.JDBCSpoolRepository.accept(JDBCSpoolRepository.java:192)
- locked <0xa6743620> (a
org.apache.james.mailrepository.JDBCSpoolRepository)
at
org.apache.james.transport.mailets.RemoteDeliveryVoid.run(RemoteDeliveryVoid.java:1269)
at java.lang.Thread.run(Thread.java:534)
Note that RemoteDeliveryVoid is almost equals to RemoteDelivery (from
current 2.3) and JDBCSpoolRepository is the one from the current 2.3.
Requesting the dump 10 minutes later I still see the same identical dump
with that thread runnable and with the same stack.
Looking at musql I see that the pending messages query last 2-7 seconds
and is repeated in a infinite (or very long) loop.
I don't understand why it does not exit from this loop, I'm investigating..
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
