Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
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.
This is not practical.
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.
This does not make sense. They do not work the same way as regular
filters, as every event will be intercepted, so this does not
duplicate existing functionality. As for mapping, it can be done too
if needed, but I think it is not that useful.
The problem for example is for a JEE server, to restore the security
association for the thread which is processing the IO event. This
can't be done otherwise since each event is sent using a different
thread. So for example, the Comet servlet would not be able to access
an EJB, a transaction, etc.
1) Yes. Different IO style, "new" API. If they can write the servlet,
then that new filter is easier. How is that difficult ?
2) Because filters intercept the call to the "service" method, which
is not going to occur.
3) In that case, they will not be able to code the Comet servlet
either. Not my problem.
4) Ok. Well, it's about the same anyway. Valves (which have no
mapping) work fine too, and I think mapping can be added later on if
it turns out it was really needed (especially since mapping will be
done only once per connection, it seems very practical). Personally, I
would think the most realistic model (given it is not trivial) is to
have one servlet take care of whatever XML protocol has been chosen,
and then delegate to actual business logic somewhere else (= not in
the servlet). That's why I think one servlet makes some sense.
5) You said it already. It's still something compared with a non
existent interception model.
6) For starters, people would need to be told what they should do to
write filters that would not break with Comet, and then find out that
they're very limited (you can do access logging, though; oh, and
compression, but you need to be smart ;) ).
head is clearing up...how about...
since:
public class MyServlet implements HttpServlet, o.a.c.CometProcessor { ....
wouldn't it make sense for:
public class MyFilter implements Filter, o.a.c.CometFilter {....
and you'd declare it the same way, since we are piggy backing on the
servlet logic to create Comet servlets, wouldn't it be smart to piggy
back on the filter logic to create Comet filters?
the interface CometFilter would define the new application chain, ie
void "event(CometEvent,CometFilterChain)"
achieves the new filter chain, piggy backs on mapping logic.
Filip
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).
agreed.
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.
perfect.
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.
ok
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.
3) is done by a worker thread under the control of Tomcat, so will go
through filters. I don't see the point of doing 3 in other threads,
Tomcat gives the app an independent thread to do its stuff (in case it
needs to do more than just read the data). 4) is done by the
application on its own. As I said, it's likely for 4) the state is not
meaningful, or can be recreated when there's a failover (any state
change would be simply for caching, I think).
Adding both options is going to be needed: replication triggered by a
filter, as well as periodic replication.
I think the current API is clean enough, and it works. However, your
proposed API fits better a real filter model, so I am willing to agree
to doing both things, not just one, which would have little value.
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]
