Hi, Thank you very much for Stefano's advice. I follow the advice to change the spool from disk spool to be JDBC spool then it works very well. I still don' understand why disk spool will have problem. I had put hundreds of emails to /var/mail/spool and close SMTP&FETCH MAIL. It will take all the memory in a while, and NEVER release the memory even after the James had processed all the emails in the spool. At that time, I login to the remote manage UI, use memstat to see the JVM memory usage, the JVM still have plenty memory. It seems not the JVM take the memory, but some other program does. But, the TOP command shows it is the Java thread takes the memory. Is it a JVM bug? Or disk spool repository bug?
Fisher -----Original Message----- From: Stefano Bagnara [mailto:[EMAIL PROTECTED] Sent: Friday, August 10, 2007 9:27 PM To: James Users List Subject: Re: Out of memory error while fetch mail. Fisher ha scritto: > Hi, > > I got a very strange problem. I running James on a server which have 4G > memory total, and I allocated 768M memory to James. When I use fetch mail to > fetch email from remote server, the Java VM will take 95% memory (I saw this > with the TOP command), but while I login to RemoteConsole, use memstat to > print the memory usage by James, it shows that only around 800M memory > total, and around 500M free. > Can someone tell me what happened? Thanks. > > Fisher This is standard behavior of memory allocation between JVM and the undelying OS. If at a given moment the JVM uses a lot of temporary objects (like fetchmail does, as it creates many objects for every single incoming mail) then it's up to the garbage collector to remove them from memory. The garbage collector is only run at give times and if there is plenty of memory available then this decrease the probability that the GC will run and empty JVM memory. This means that the JVM will ask to the OS all of the memory you assigned with the Xmx parameter. The memory you see with MEMSTAT is the memory used by the JVM. Anyway, once the JVM asked the max memory to the OS it won't be freed anymore. The details depend on your OS, your kernel and you VM but most times the sentence above is true. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
