Hi Eric, you said all the files are related to address-errors , could you show me your address error processor config? Does the Problem still exist when you enable the ValidRcptHandler in the smtpserver.xml file?
Thx Norman 2010/3/30, Eric Charles <eric.char...@u-mangate.com>: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
