Oops, no, the files are still there (only unkn...@known.com).
Eric
On 03/29/2010 10:16 PM, Eric Charles wrote:
Hi Norman,
I just deployed your new commit with the new camel DisposeProcess.
Good news : I don't see anymore the m64 file in tmp (well I see 1
file, on the second after, it is no more there, so the dispose works
as it should).
I keep you posted with our eventual future OOM.
Tks,
Eric
On 03/29/2010 09:18 PM, Eric Charles wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
