Steve,
I didn't say that I don't like the setSoTimeout approach. What I said was
that from the look of the code, the author(s) appear to be using the timer
as a watchdog to protect not only against an I/O hang, but also a hang
elsewhere in the processing of the handler. If that is not necessary, then
go with setSoTimeout.
Perhaps Serge and/or other authors of the handler can provide some insight
into why they did it the way they did it.
--- Noel
-----Original Message-----
From: Steve Short [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2002 11:50
To: 'James Developers List'
Cc: Shilpa Dalmia
Subject: RE: SMTPHandler connection timeout
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]>
