Hi eric, thx for all your help, maybe smtp-source ( which is included in postfix ) can help you with stress testing.
Bye Norman 2010/3/31, Eric Charles <eric.char...@u-mangate.com>: > Hi Norman, > > There are not so much .m64 files, so even it it shows that a mail > processing didn't reach the end and may have cause a leak, I don't think > it would make crash my process so quick (between 10 and 24 hours). > > I quickly analysed a few dumps last week : there is always a class that > took 30/40% of the memory. Sometimes a activemq class, sometimes not > (don't remember the details). > Also notable, the stack trace (the place where the OOM gives problems) > varies. > Today stack was: > org.apache.camel.RuntimeCamelException: > org.apache.camel.CamelExchangeException: Error processing Exchange. > Exchange[JmsMessage: ActiveMQObjectMessage {commandId = 2102, > responseRequired = true, messageId = > ID:srv001-51032-1270011735798-2:0:24:1:214, originalDestination = null, > originalTransactionId = null, producerId = > ID:srv001-51032-1270011735798-2:0:24:1, destination = > queue://processor.root, transactionId = null, expiration = 0, timestamp > = 1270014325685, arrival = 0, brokerInTime = 1270014326893, > brokerOutTime = 1270014333023, correlationId = null, replyTo = null, > persistent = true, type = null, priority = 4, groupID = null, > groupSequence = 0, targetConsumerId = null, compressed = false, userID = > null, content = org.apache.activemq.util.byteseque...@69b568d0, > marshalledProperties = null, dataStructure = null, redeliveryCounter = > 0, size = 10718, properties = null, readOnlyProperties = true, > readOnlyBody = true, droppable = false}]. Caused by: > [java.lang.OutOfMemoryError - Java heap space] > at > org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1055) > at > org.apache.camel.spring.spi.TransactionErrorHandler$1.doInTransactionWithoutResult(TransactionErrorHandler.java:154) > ... > > > > I also think the tmp files are not the main cause. > > I have now james running in eclipse and I made already made a little > trip in the code. Quite impressive since last time I looked at it. > I will try to stress james with a small smtp/pop3 client (I used > postage, but a simple class with commons-net behind) may be easier and > see what happens (eventually with eclipse profiler). > > It will be for this weekend for me. > > Bye, > > Eric > > > On 03/31/2010 07:11 PM, Norman Maurer wrote: >> Hi Eric, >> >> thx for keeping us in the loop... I'm still not sure why the .m64 >> files are still in the tmp folder sometimes.. But I suspect the files >> are not the cause of the OOM. >> >> I didn't get a OOM since yesterday morning (the time I deployed >> current trunk version), but just found to new .m64 files.. >> >> So I'm still searching for the real cause. If nothing helps I will >> need to use a profiler to find th leak. >> >> Bye, >> Norman >> >> 2010/3/31 Eric Charles<eric.char...@u-mangate.com>: >> >>> Hi Norman, >>> >>> I had defined the Null mailet >>> >>> <mailet match="HostIsLocal" class="Null"> >>> <processor> local-address-error</processor> >>> <notice>550 - Requested action not taken: no such user here</notice> >>> </mailet> >>> >>> but now, I use the standard config >>> >>> <mailet match="HostIsLocal" class="ToProcessor"> >>> <processor> local-address-error</processor> >>> <notice>550 - Requested action not taken: no such user here</notice> >>> </mailet> >>> >>> I still have the OOM. >>> >>> I will now deploy a fresh svn with your last commits and enable the >>> ValidRcptHandler. >>> I keep you posted with the result, >>> >>> Tks, >>> Eric >>> >>> >>> On 03/30/2010 06:49 AM, Norman Maurer wrote: >>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org