On Nov 5, 2007, at 2:35 AM, Robert Varga wrote:
> Hi Scott,
> still have some questions :-)
>>> 3. What happens if I call CometController.wake() while another
>>> thread is executing on a CometServlet with the same CometController
>>> instance? Will resume() be called once again after the resume/
>>> service currently executing returned true?
>> Yes. The second wake() is queued. I'll need to check to see if we
>> have a test case for that.
> And if two or more wake()-s were queued before the service()/resume
> () completed,
> will resume() be invoked once or as many times as wake()-s were
> In other words should we attempt to minimize the number of
> redundant calls to wake()
> or would it be optimally handled by Resin?
It's a flag that's tested and cleared at the beginning of the service
() call. So if a wake() occurs while you're processing the request,
Resin will automatically start a new service().
The assumption is that application has some kind of queue with data.
The service will drain the queue, but it's possible that a new
request occurs right before the service exists.
The idea is that Resin will handle the timing issues for you. You
just need to drain the queue in the service() call. And your
producer can call wake() after it submits data. So there should be a
minimum of application code dealing with this.
> Another question: is there a "no timeout due to idleness" value to
I'm thinking of making the following changes to the API based on the
1) change isActive() to isClosed()
2) wake the controller after a timeout occurs to allow for cleanup of
the output. Either add an isTimeout() or set isClosed() after
timeout. (This does not guarantee a resume() call if the socket is
dropped, only for timeout.)
3) Make the CometController.getAttribute be in a different scope than
the request. I'm concerned that request-scoped thread-unsafe objects
will be accessible from the CometController.
4) Remove the return value from wake()
> Thanks and best regards,
> resin-interest mailing list
resin-interest mailing list