So let's review the options:
- use java.net.Socket.setSoTimeout(timeout) - fix Avalon so that it removes redundant triggers when they are updated - fix Avalon so that it calls notify every time a trigger is reset - can we extend the Avalon scheduler/timer classes with a new timer that does what we need (sorry I don't have the code handy to check how feasibly this is myself)? - implement a new timer mechanism purely within James Noel, you stated that you didn't like the setSoTimeout approach, can you clarify why James need to protect parseCommand as well as socket IO? Cheers Steve -----Original Message----- From: Serge Knystautas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 6:30 AM To: James Developers List Cc: Shilpa Dalmia Subject: Re: SMTPHandler connection timeout Noel, Looks rather serious... like you said, perhaps building our own trigger mechanism is the way to go. More importantly, I just wanted to note that SchedulerNotifyInputStream will reset the trigger every 20,000 bytes, not every byte. So while bad, it's not the end of JVM's as we know it. :) Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ ----- Original Message ----- From: "Noel J. Bergman" <[EMAIL PROTECTED]> To: "James-Dev Mailing List" <[EMAIL PROTECTED]> Cc: "Shilpa Dalmia" <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 11:54 PM Subject: RE: SMTPHandler connection timeout > Shilpa, > > You've got me convinced. > > Having read the thread, more James code and the relevant portions of > Cornerstone, I believe that you are actually underestimating. If what > appears to be the case from my reading of the code, and what you and Peter > Donald say is happening, then you are underestimating the potential > magnitude of the problem by orders. Trace through the doDATA method. It > appears to be that SchedulerNotifyInputStream resets the trigger for EVERY > BYTE OF DATA in the message stream; SchedulerNotifyOutputStream does the > same when writing. If those are really resulting in a new queue entry for > each byte of data (which is what appears to be the case), that's brutal, and > really needs to be addressed either in Avalon or in James. > > As far as I can see, James is using this as a watchdog timer, which does not > appear to be the design point for Avalon's facility, based upon their own > comments, design and implementation. And even the workaround to Avalon of > adding another thread or doing the replacement during the reset would be > performance prohibitive given that the trigger is reset for each byte of > data read from the stream. I've done a grep of James to find all uses of > the trigger code, and it looks to be similar in all cases. Perhaps a more > efficient watchdog solution can be devised, maybe tied to the handler > instance. I'd sooner create a watchdog thread per handler than have 100s of > thousands (or millions) of events in the scheduler queue. > > Am I reading this correctly? Your throughts? > > --- Noel > > -----Original Message----- > From: Shilpa Dalmia [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 21, 2002 19:26 > To: '[EMAIL PROTECTED]' > Subject: FW: SMTPHandler connection timeout > > > You can look at the foll. avalon mailing list thread on this issue where > they have given an explanation for this. > http://www.mail-archive.com/[email protected]/msg08660.html > > I have a implemented a temporary solution for this issue, which fixes the > problem. > > Shilpa > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
