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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
