[ http://issues.apache.org/jira/browse/JAMES-134?page=comments#action_63407 ] OG commented on JAMES-134: --------------------------
Hi Stefano Bagnara, For my amusement I did the test that you have suggested: I opened Mozilla which takes about 30MB, and minimized it. To my amazement the 'Task Manager'(Processes TAB,'Mem Usage' column) did shrink to 3MB. I maximized and 'Mem Usage' got to 13MB, lower than it's previous value. I did the test again with James running in a command line while delivering the 40MB message, and I monitored it's 'Mem Usage'. Amazingly each time I minimized it the value shrunk to around 1MB, and started to rise again. I minimized and maximized several times during that mail transition, and the results were similar. Consequentially, I thought to myself that something is fishy about it. I opened windows help and looked to see why this 'Mem Usage' column doesn't behave as I expect. It turned out that 'Mem Usage' represent the current working set. I guess that W2K removes a minimized process from the current working set. Anyway I found out that what I was looking for, i.e. the real amount of memory that the process takes in Virtual Memory is under the column called 'VM Size'. The James 'VM size' was 339MB, this column was not affected by minimizations and maximizations, and when I attached the same 40MB file twice to a single message, the 'VM size' rose to 643MB. This rise is also reflected by the Performance TAB 'Mem Usage' which was then at 1,015,920. I restarted James with -Xmx1532M, and now I will try to crush it with a message that has many attachments of the 40MB file. Seven attachments did the trick and I have got the famous: ------------------------------------------------------------ Spool=org.apache.james.mailrepository.AvalonSpoolRepository 21/04/05 17:59:29 ERROR spoolmanager: Exception in processor <transport> java.lang.OutOfMemoryError 21/04/05 17:59:29 ERROR spoolmanager: An error occurred processing Mail1114097348464-7 through transport 21/04/05 17:59:29 ERROR spoolmanager: Result was error ------------------------------------------------------------- May I add that the computer responsiveness was degraded very much during, even with less attachments. It isn't right for any program to sit on such large amounts of unused memory, I thought to myself, and so I have written a small program to test your claim that memory isn't given back to the system by java. I attached that test file TestMemRec.java here. The test makes a big array, and then set it to null, and then call System.gc(). I ran this test with 'java -Xmx1000M'. That test showed that even though the resources were released the memory wasn't given back to the system. I couldn't believe it, so I searched google and found the post that suggested to use -Xincgc, which link I wrote below. I ran my test again now with -Xincgc, and now the memory was given back to the system. I ran the program with the command 'java -Xmx1000M -Xincgc -Xloggc:gc.txt TestMemRec' post link: http://groups-beta.google.com/group/comp.lang.java.programmer/browse_frm/thread/6d9e6ab8f027d31f/16017bc2833aa6d5?q=java+%22return+memory%22&rnum=3&hl=en#16017bc2833aa6d5 BTW - I read the link that you posted to see what you are trying to tell me, but I knew the stuff that was written there, because I have learned it many years ago. I don't know what your point was, sorry. BTW2- After changing to -Xincgc the mail server still had the same problem with big message delivery i.e. OurOfMemoryError. BTW3- For me James failed on 7x40=280MB and succeeded on 6x40=240MB. It isn't close to a 1GB message. People should be told that James can not transfer a 280MB message, instead of letting them find it out the hard way, when James fail, don't give any failure notice message, and quit delivering any more mail. People should also be told to use the -Xincgc in order to make the JVM return the unused memory to the system. > Large emails in the spool cause SpoolManager to throw OutOfMemoryError > ---------------------------------------------------------------------- > > Key: JAMES-134 > URL: http://issues.apache.org/jira/browse/JAMES-134 > Project: James > Type: Bug > Components: SpoolManager & Processors > Versions: 2.0a3, 2.1, 2.1.3, 2.2.0 > Environment: Operating System: MacOS X > Platform: Macintosh > Reporter: Matt Bishop > > Steps to repro: > 1. Send yourself a very large email (16 megs works for me) > 2. check the SpoolManager log and see this over and over: > ERROR spoolmanager: Exception in JamesSpoolManager.run null > java.lang.OutOfMemoryError > What makes this problem particularly bad is that the spoolmanager doesn't > move on to other > messages but keeps pegging the CPU trying to process this email. To fix it, > I have to shut down > james, delete the email files out of spool and restart. > EXPECTED: email should spool to the user as expected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
