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
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
> 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
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
> - Are the request parameters obtainable in resume(), too, or
> only in
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
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().
> 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
>> There's a sketch of an example at
>> Javadocs are at
>> 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
> MessageLabs to scan all Incoming and Outgoing mail for viruses.
resin-interest mailing list