tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Proposal - Comet changes
Date Fri, 08 Sep 2006 01:30:51 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> 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
> I agree to a significant extent, but I would like to go a bit further 
> and clean things up for interception.
>> 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
> Ok.
>> 2. As suggested, if servlet instanceof CometProcessor && 
>> 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!
> Ok.
>> 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
> No, I don't see how filters can work. It is possible that some filters 
> which would be wrapping the request would be ok, but most likely they 
> would do something when the call returns (and finish what they had to 
> do), so any attempt to use the wrapped objects would fail later on.
The same developer that does the comet servlet sets up the mapping for 
the filter, so I don't see a need to have to protect against this scenario.
>> 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.
> Actually, I would like to have a new type of filters (both for the 
> container side and the application side), because things like setting 
> up the security contexts, etc, are still likely going to be needed. 
> This would be something simpler than valves/filters, with no mapping 
> (since most likely, a single servlet is all that's needed to handle 
> all the Comet traffic of an application).
> The filter would have a filterEvent method, and the difference between 
> the application side and the container side is that the first gets the 
> facades, and the second the Request and Response objects (which allow 
> access to everything). Each request should be un/wrapping as a regular 
> filter on each invocation (of course, the wrappers can be stored in a 
> request attribute).
I see this as a duplicate effort, trying to recreate something that 
already exist, here are the cons
1. The developers would have to learn something new, tomcat specific to 
achieve the same thing that they could have done using filters
2. They would work the same way as filters, then why not use filters
3. They run into the same risk as you described above, ie, invalidating 
an object at request end, can happen here as well
4. Assuming that there would be only *one* comet servlet per application 
is not a safe assumption, I would never code it that way.
5. You lose the mapping feature, this is extremely useful, and could 
prove to be very useful for comet servlets as well
6. Everyone already knows how a filter works, and they are implementing 
a servlet, makes sense to just piggy back this functionality.

>> 5. StandardCometEvent could be a zero GC object if need be, if the 
>> SecurityManager is enabled, a non reusable facade should be used
> GC doesn't matter too much for the whole connection since it's quite 
> long running. These objects would be discarded when the Comet 
> connection  ends (but it would be a bit bad to start allocating too 
> many objects for each event).
>> 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
> The servlet can close the writer or OS, and the client could send the 
> appropriate end chunk, this should work.
that is how it is today, I think its cleaner to provide them with the 
CometEvent.close() method and let the container handle the logistics.
CometEvent.close may be implemented as  
"this.getInternalResponse().getInputStream().close()" if you wish.
>> 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`
> It should be ok when activity checking is enabled: endAccess will only 
> be called when recycling the request object.
>> 9. The similar problem will have to be worked out for last accessed time
> Bleh, -1. Normally, it's still the beginning of the session access, so 
> the beginning of the request.
>> 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.
> So this would be done in a container side Comet event filter ;) I 
> would not even bother with doing session replication when there's no 
> client activity (I think anything which goes to the session when 
> there's no client input comes from the server side, and thus can be 
> restored as is in case of a failover). Of course, you could have 
> periodic replication as well as an option.
Comet event filter will not work, has the same problem I described, the 
session can be modified async, ie a typical comet sequence is
1. receive data
2. add data to the queue
3. async thread reads data, processes it
4. async thread  writes response
In step 3. the session could very well be modified, as the server state 
would change.

>> The interface can be viewed at
> I still think there are too many types.
Not sure I understand what you mean, there are 4. You don't even have to 
look at the sub types, they are just additional information, that could 
help you decide what the next step should be. For example, webapp reload 
vs server shutdown are quite different, but both are of the type END


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message