Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <45002795.6020507@hanik.com>
Date: Thu, 07 Sep 2006 09:07:17 -0500
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Proposal - Comet changes
References: <44DCB252.8010204@hanik.com> <44E2E90C.8000504@apache.org>
 <44E320C4.2090105@hanik.com> <44E33033.9020202@apache.org>
 <44E33D6F.7000001@hanik.com> <44E397F9.1060905@apache.org>
 <44E39E23.90804@apache.org> <44E3CA98.3090505@hanik.com>
 <44E3CB9F.6030501@hanik.com> <44E440F7.9010205@apache.org>
 <44E47014.7090504@hanik.com> <44E5D542.20500@hanik.com>
 <44E77768.9050708@apache.org>
In-Reply-To: <44E77768.9050708@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

ok, I've had a chance to think about it, and let me try to summarize our 
ideas, my goal here is to simplify the implementation

1. CometEvent would be an interface, in such a way that we could reuse 
the objects in the backend, and also provide a facade to hide server 
details from the servlet

2. As suggested, if servlet instanceof CometProcessor && comet.support 
invoke servlet.event(CometEvent) instead of servlet.service(), otherwise 
invoke service()
   This is excellent, cause it will give the implementor a fall back 
option if comet support is not available, he can do the logic blocking, 
ala Future.waitForCompletion style
   This will guarantee that a comet servlet remains portable, nice thinking!

3. Servlet filters should be respected and used exact same way as a 
servlet, at the end CometEvent.getRequest/CometEvent.getResponse should 
return the same objects as the servlet would have received in its 
service method. Hence in the ApplicationFilterChain object will do the 
check for (isCometProcess && hasCometSupport).
   In a similar manner, this object would also make sure that 
CometEvent.getRequest delivers the wrapper to the servlet implementation 
if a wrapper has been added.
   I don't see a need to break away from the standard filters, or not 
use them.
   For example, a StandardCometEvent implementation would have
     getHttpRequest - returns the request for the servlet, could be a 
request wrapper, exposed through CometEvent
     getInternalRequest - returns the request object from the connector, 
not exposed through the interface

4. For interception, I think the existing valves and filters 
could/should remain untouched. Interception will/should only be done at 
the activation of the request
   Sequential event method (such as READ) would not go through the 
interceptors, just like it is today. This is essential as we can have 
filters/valves that modify both incoming and outgoing content.

5. StandardCometEvent could be a zero GC object if need be, if the 
SecurityManager is enabled, a non reusable facade should be used

6. CometServlet removal - good idea.

7. The servlet should have a way of gracefully ending the session, such 
as CometEvent.close() instead of just letting it timeout

8. Session timeouts/invalidations. An active comet session should not 
invalidate the HttpSession based on inactive time.
   getAccessCount() would return >0 if there is a comet session
   I am not fully kosher with this yet, still need to think about this 
some more. a possibility is to have CometEvent.releaseHttpSession(), 
will `--accessCount`

9. The similar problem will have to be worked out for last accessed time

10. Session replication, currently session replication is triggered 
through a valve at the end of each request,
    I will have to adjust clustering to support periodic replication or 
add some other mechanism to make this work.
    Still need to think this through.

The interface can be viewed at
http://people.apache.org/~fhanik/CometEvent.java


Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> my proposal is a little delayed, had a slight Fedora Core meltdown, 
>> still recovering
>
> I thought about it a bit, and I think we could do the following (with 
> an event method):
> - If the "servlet" implements CometProcessor and the connector 
> supports Comet, then don't call the service method, instead call a 
> begin event
> - Otherwise, do the normal processing (and a regular service method 
> remains in the servlet)
> - Remove CometServlet
> - An interception mechanism (similar to valves) could be a good idea 
> (not sure, though); I think the valves could maybe be extended a 
> little bit to do that
>
> So I'll be away next week. I think the biggest priority is that you 
> should come up and submit a real plan for adding clustering.
>
> R�my
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org