Steve,
Personally, I don't mind having a watchdog to make sure that something
somewhere doesn't get hung. But DefaultTimeScheduler is not designed to be
reset on a fine grained basis. If we keep a watchdog (I understand that not
everyone thinks we need one), we want to keep track of a limited number of
things (basically just make sure that the thread doesn't hang), and we want
to be able to reset it for free.
Besides, I hadn't suggested (yet) removing the watchdog without having
something to back it up. But that doesn't mean we should not set the socket
timeout when we have a known implementation issue.
--- Noel
-----Original Message-----
From: Steve Short [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 11, 2002 21:22
To: James Developers List
Subject: RE: handling connection vs sheduler problem
Agreed, I think using the socket timeout option is the way to go. I don't
see any advantage in implementing a manual timeout solution. One less
moving part to go wrong and less overhead because we remove the
SchedulerNotifyInputStream.
Regards
Steve
> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 11, 2002 3:59 PM
> To: James Developers List
> Subject: RE: handling connection vs sheduler problem
>
>
> Andrei,
>
> What issue do you have with using socket timeout? Is it not
> reliable enough for you? In the case of his problem, calling
> it fixes a platform specific problem, and should be neutral
> for other platforms.
>
> I've looked at replacing the DefaultTimeScheduler with
> something more appropriate for James, but I haven't had time
> to do it yet.
>
> --- Noel
>
> -----Original Message-----
> From: Andrei Ivanov [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, August 11, 2002 18:10
> To: James Developers List
> Subject: handling connection vs sheduler problem
>
>
> Hi
> I don't think that setting socket timeout will help to solve
> scheduler problem. It is not possible to control connection
> by setting socket timeout. As it was several times mentioned
> before scheduler isn't designed to be used as in James
> servers. It is nice and elegant solution, I mean
> ShedulerNotifyînputStream, but it results in overhead we know
> about. The solution is in cornerstone connection classes
> which create connection handlers for James. My idea is to
> adapt (modify) cornerstone connection classes by adding
> connection control facilities.
>
> About cornerstone. I've been using different cornerstone
> blocks a lot for my project. I can say that cornerstone is
> well written and reliable library. On the other hand for
> complex and particular phoenix based applications (like
> James) cornerstone shall be considered more as guideline than
> ready to use solution. If we really want to improve James we
> shall adapt cornerstone for James (but not James for
> cornerstone as it is now)
>
> Andrei
>
> ----- Original Message -----
> From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> To: "James Users List" <[EMAIL PROTECTED]>
> Sent: Monday, August 12, 2002 12:04 AM
> Subject: RE: Admin problem
>
>
> > I have no problem with the socket.setSoTimeout(timeout) call. We
> > should start making more use of setSoTimeout elsewere, and wean
> > ourselves off of the scheduler.
> >
> > With respect to the logging, I think that only the one
> > where we echo the timeout is necessary, not the one
> > where we log it for each connection.
> >
> > Would you please submit a [PATCH] to James-Dev?
> >
> > --- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
