> Traces 34780, 5954, 5960 and 24996 require explanation
> 1 9.69% 9.69% 4821600 294 139416400 8501 34780 [B
TRACE 34780:
org.gjt.mm.mysql.Buffer.<init>(<Unknown>:Unknown line)
org.gjt.mm.mysql.PreparedStatement.executeQuery(<Unknown>:Unknown line)
org.apache.james.mailrepository.JDBCSpoolRepository.loadPendingMessages(:2
76)
Ok, this is bothersome. There does not appear to be any reason for there to
be 294 outstanding buffers taking up 4.8MB of heap.
> 3 3.28% 21.42% 1631296 15245 31949344 298592 5954 [C
> 5 3.09% 27.66% 1539240 9525 30157792 186620 5960 [B
TRACE 5954:
java.lang.StringBuffer.expandCapacity(StringBuffer.java:202)
java.lang.StringBuffer.append(StringBuffer.java:401)
java.io.UnixFileSystem.resolve(UnixFileSystem.java:93)
java.io.File.<init>(File.java:227)
java.io.File.listFiles(File.java:998)
org.apache.avalon.excalibur.monitor.DirectoryResource.testModifiedAfter(Dir
ectoryResource.java:84)
org.apache.avalon.excalibur.monitor.impl.AbstractMonitor.scanAllResources(A
bstractMonitor.java:132)
org.apache.avalon.excalibur.monitor.impl.ActiveMonitor.run(ActiveMonitor.ja
va:102)
java.lang.Thread.run(Thread.java:534)
TRACE 5960:
java.lang.StringCoding$CharsetSE.encode(StringCoding.java:336)
java.lang.StringCoding.encode(StringCoding.java:380)
java.lang.StringCoding.encode(StringCoding.java:386)
java.lang.String.getBytes(String.java:590)
java.io.UnixFileSystem.getLastModifiedTime(UnixFileSystem.java:Native
method)
java.io.File.lastModified(File.java:773)
org.apache.avalon.excalibur.monitor.DirectoryResource.testModifiedAfter(Dir
ectoryResource.java:93)
org.apache.avalon.excalibur.monitor.impl.AbstractMonitor.scanAllResources(A
bstractMonitor.java:132)
org.apache.avalon.excalibur.monitor.impl.ActiveMonitor.run(ActiveMonitor.ja
va:102)
I'm going to increase the stack depth for the next test to see where these
are coming from. 3MB for what? And it isn't in our code as far as I can
see, so it must be some Avalon artifact.
> 8 2.52% 35.46% 1253616 882 36346336 25572 24996 [B
TRACE 24996:
org.gjt.mm.mysql.PreparedStatement.<init>(<Unknown>:Unknown line)
org.gjt.mm.mysql.jdbc2.PreparedStatement.<init>(<Unknown>:Unknown line)
org.gjt.mm.mysql.jdbc2.Connection.prepareStatement(<Unknown>:Unknown line)
org.gjt.mm.mysql.jdbc2.Connection.prepareStatement(<Unknown>:Unknown line)
org.apache.james.util.mordred.PoolConnEntry.prepareStatement(PoolConnEntry.
java:257)
org.apache.james.mailrepository.JDBCSpoolRepository.loadPendingMessages(JDB
CSpoolRepository.java:272)
org.apache.james.mailrepository.JDBCSpoolRepository.getNextPendingMessage(J
DBCSpoolRepository.java:248)
org.apache.james.mailrepository.JDBCSpoolRepository.accept(JDBCSpoolReposit
ory.java:192)
org.apache.james.mailrepository.JDBCSpoolRepository.accept(JDBCSpoolReposit
ory.java:122)
Disturbing on two accounts. First, why are there 882 outstanding
PreparedStatement objects left in memory, and secondly, why didn't I switch
to DBCP from Mordred? :-)
So there are two incidents of MySQL apparently leaking, but not on every
opportunity. And we do have explicit close calls for that allocation spot.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
