It whould be cool if you could run the test with the mysql connector 5.0 to see if this problems still there. I think its a "bug" in the mysql connector. And if i understand Stefano right he had same issues with other mysql connectiors then 5.x
bye Norman Am Sonntag, den 27.08.2006, 02:38 -0400 schrieb Noel J. Bergman: > > 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] > > !EXCUBATOR:1,44f13dfd45111774818736!
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
