On Oct 1, 2007, at 11:12 AM, Robbie Varga wrote:

> Hi Scott,
> I would have a few questions regarding this implementation:
> 1. Are Filters applied before the service/resume calls are
>    invoked?

Only on the initial service, currently.

The plan would be to add a CometFilter interface with a resume() call  
matching the CometServlet resume.  If a filter implemented  
CometFilter, Resin would call resume() on the filter.

I didn't add the CometFilter to the current snapshot, but it's a  
straightforward change.

> If they are applied to both, then is it possible to specify if a  
> filter is to be applied only to resume() or only to service()?

That's basically why Resin currently skips the filter on the resume  
and only calls it on the service().  It would be too much of a  
surprise to call a non-comet-aware filter multiple times on the same  

> 2. What is the state of the request scope (attributes and parameters)
>    at the start of the resume() call?

Exactly the same as at the end of the service() or the last resume 
().  It happens to be the same request object, but might have a  
different Thread.

The attributes might have changed if your service calls  
CometController.setAttribute.  The CometController does not establish  
a new scope, it just provides a thread-safe way of setting the  
request attributes.

>    - Are the request parameters obtainable in resume(), too, or  
> only in
> service()?

Yes, everything's available.

>    - What is the state of the request attributes present at the
>      start of the resume() call?
>      a. The same as at the end of the preceeding resume/service  
> method?

Yep, with the possible exception again of any calls to  

>      b. Empty?
>      c. The same as at the end of the service method?
>      d. The same as at the start of the service method?
>      e. Undetermined?
> 3. Is the resume() call carried out on the same thread as the wake()
>    call triggering it, or is it carried out on a separate thread?

It's a different thread.  The resume() thread would be allocated from  
the same thread pool as the initial request and basically runs  
through the same call-chain as the service().  The wake() thread  
could be anything, really.

Specifically, the wake() does not block.  It's like Object.notify().

-- Scott

> Thanks in advance and best regards,
> Robert Varga
> On Thu, 20 Sep 2007 11:24:42 -0700, Scott Ferguson wrote:
>> The 3.1.3 snapshot includes a new implementation of Comet for Resin
>> servlets.
>> There's a sketch of an example at
>>    http://caucho.com/resin-3.1/examples/servlet-comet/index.xtp
>> Javadocs are at
>>     http://caucho.com/resin-javadoc/com/caucho/servlets/comet/
>> package-summary.html
>> The basic model is similar to the normal servlet, except there's a
>> new service() and a resume() call in the AbstractCometServlet.
>> The CometController is the main object that's passed from the servlet
>> to your application comet code.  Its main methods are wake(), close
>> (), and setAttribute()/getAttribute().
>> The CometController is thread-safe.  As always, the ServletRequest
>> and ServletResponse and the PrintWriter/ServletOutputStream are *not*
>> thread-safe.  You must not store the request/response or output in
>> object or pass them to other threads.  The only way other threads in
>> your application can talk to the Comet request is through the
>> CometController.  Data is passed through get/setAttribute (which sets
>> request.setAttribute in a thread-safe manner) and the servlet is
>> resumed with wake().
>> We'll cleanup the example in a bit to make a bit more sense.
>> The 3.1.3 release has been delayed another week (due primarily to
>> Quercus issues), so we're now aiming for the week of October 5.
>> -- Scott
> ______________________________________________________________________ 
> __
> In order to protect our email recipients, Betfair Group use SkyScan  
> from
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
> ______________________________________________________________________ 
> __

resin-interest mailing list

Reply via email to