Hi Norman,
The .m64 are all to "unkown user" but to "well known domain" (so for
<unkn...@known.com>).
They are from various size (with and without attachment).
They are well formed (I can open the downloaded file with thunderbird)
However, when I sent a mail to unkn...@known.com, I don't see it in the /tmp
Tks,
Eric
On 03/29/2010 08:43 PM, Norman Maurer wrote:
Hi Eric,
sure.. we have to find the OOM cause. What would be interesting, could
you check somehow if the .m64 files are files which are related to
successfully delivered mail ?
Thx,
Norman
2010/3/29 Eric Charles<eric.char...@u-mangate.com>:
Norman,
Done. Now, we have to wait...
I saw some created *.m64 that were removed.
But there are other ones that remains in /tmp.
I sometimes run a jmap (java memory map) to produce a heap dump and analyse
it.
At the beginning, everything seems ok, and often, when I come back, the OOM
has already occured.
I changed the -Xmx512m to -Xmx256m to have a quicker exception (if any,
let's hope not).
The *.m64 are a clue and we should ensure that they are removed in all
circumstances.
This may be the easy part, as we have some visible clues (the files).
We should also ensure after that there are no other causes to the leaks.
Tks,
Eric
On 03/29/2010 08:00 PM, Norman Maurer wrote:
Hi Eric,
I found the cause for the not deleted temporary files. Hopefully this
is the cause of the OOM. Could try to svn up and run again ?
Thx,
Norman
2010/3/29 Norman Maurer<norman.mau...@googlemail.com>:
Hi Eric,
thx for the report. I see exact the same problem today here.. (The
OOM). Didn't notice the files in the tmp folder, but I think thats a
good pointer. I will try to debug the problem later or tomorrow. But I
suspect you are right about the tmp files and jms producers.. Did you
run a kill -3 pid to see what threads are active etc ?
Thx,
Norman
Ps: Patches are welcome :)
2010/3/29 Eric Charles<eric.char...@u-mangate.com>:
Hi,
The last two weeks, I deployed various trunk snapshots.
After james running less than 1 day, I always ran into a OutOfMemory
Exception.
I analysed the logs (for example STACK TRACE 1 in annex), and always
found
Camel complaining when trying to deliver on JMS queue.
I tried to adapt the ActiveMQ configuration based on
http://activemq.apache.org/javalangoutofmemory.html but nothing helped.
I also analyzed various heap dump :sometimes, 65% was used by
org.apache.mina.transport.socket.nio.NioSocketSession, sometimes by a
activemq class,...
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
