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 && 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!
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.
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).
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.
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.
The interface can be viewed at
http://people.apache.org/~fhanik/CometEvent.java
I still think there are too many types.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
