Hi Ashish, after thinkin more about the whole stuff I wonder if the exception handling in SMTP could sometimes be an endless loop. In the handler we write a message back to the client on exception. But what happens if this throw a new exception ? Could it so loop forever ?
http://svn.apache.org/viewvc/james/server/trunk/smtpserver/src/main/java/org/apache/james/smtpserver/mina/SMTPIoHandler.java?revision=930014&view=markup Maybe we should just close the connection.. Bye Norman 2010/4/9 Eric Charles <eric.char...@u-mangate.com>: > Hi Ashish, > > I am the user who has many OOM with the trunk and feed Norman with my issues > :) > > 1. > Indeed, you have the dump with CircularQueue from mina 2.0.0-RC1. This is > the release we normally use in james and give the issue after a certain > period of time. I mean, the server can stay working correctly 2 days or > crash after 2 hours (see http://apache.u-mangate.com/james/oom/oom.png) due > to a peak in memory usage. T > To further investigate, we tried with mina trunk 2.0.0-RC2-SNAPSHOT : There, > we see a direct crash. I've uploaded such a dump on > http://apache.u-mangate.com/james/oom/index.html (click on shift-f5 to force > refresh, I setup the web server in a hurry). You will see there recursive > ConcurrentLinkedQueue. > > 2. > As shown on http://apache.u-mangate.com/james/oom/oom.png, the system works > while the line is flat (mail are received, spooled, delivered,...). On a few > seconds, it peaks and of course, nothing works anymore. So, the messages > don't remain in the spool. I made tests with quite huge messages, and they > are delivered very fast as soon as they arrive in James. > > Don't hesitate to ask more questions or propose additional tests. > > Many tks in advance, > > Eric > > > On 04/09/2010 12:40 PM, Ashish wrote: >> >> Norman, >> >> Couple of more queries >> >> 1. The heap dump uses circularqueue class, so seem to be taken for an >> earlier trunk snapshot. Is my take correct? >> >> 2. What's the state of the System? are the clients receiving the >> messages. The queue seems to be holding a very large number of >> objects. >> Essentially what I want to know is, if the clients are receiving the >> messages or the Server is holding them up. >> >> Will spend more time with the issue and see what I can figure out. >> >> thanks >> ashish >> >> On Thu, Apr 8, 2010 at 2:03 PM, Norman Maurer >> <norman.mau...@googlemail.com> wrote: >> >>> >>> Maybe Eric can do, cause he is the one who see it very freqently.. >>> >>> So Eric...;) ? >>> >>> Thx, >>> Norman >>> >>> >>> 2010/4/8 Ashish<paliwalash...@gmail.com>: >>> >>>> >>>> Can you provide the heapdump for this OOM? >>>> >>>> thanks >>>> ashish >>>> >>>> On Thu, Apr 8, 2010 at 1:40 PM, Ashish<paliwalash...@gmail.com> wrote: >>>> >>>>> >>>>> On Thu, Apr 8, 2010 at 1:28 PM, Norman Maurer >>>>> <norman.mau...@googlemail.com> wrote: >>>>> >>>>>> >>>>>> Hi Ashish, >>>>>> >>>>>> I think we tracked down the source of the problem a bit more.. The OOM >>>>>> seems to be related to IMAP. Our IMAP server component is using the >>>>>> StreamIoHandler (its the only one of our components who use this >>>>>> handler). So I suspect there is the problem. >>>>>> >>>>>> So there are two possible problems: >>>>>> 1) Bug in StreamIoHandler >>>>>> 2) Wrong usage of StreamIoHandler. Our implementations is here: >>>>>> >>>>>> http://svn.apache.org/viewvc/james/server/trunk/imapserver/src/main/java/org/apache/james/imapserver/mina/ImapIoHandler.java?view=markup >>>>>> >>>>>> Thx, >>>>>> Norman >>>>>> >>>>> >>>>> Sorry, haven't been able to look at this so far :( >>>>> earliest I can give it a shot will be on Sunday. >>>>> >>>>> thanks >>>>> ashish >>>>> >>>> >>>> >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > >
