You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Filip Hanik - Dev Lists <de...@hanik.com> on 2006/09/07 16:07:17 UTC
Re: Proposal - Comet changes
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
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
>> For some of these events, we could provide with Tomcat a set of
>> utility valves which would implement them, such as a connection
>> tracking valve (closes connections on reloads or when sessions expire).
> agreed
>
> got my hands full today, will sleep on it some more.
I thought about it a bit more too, and I think I can indeed implement
these two features using a valve (which would be able to generate and
send those events down the pipeline):
- expire connection(s?) when the associated session expires
- close all connections when the webapp is stopped
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Remy Maucherat wrote:
>> Filip Hanik - Dev Lists wrote:
>> That's a second step :) It's a good idea because at the moment
>> there's only a boolean, so it's not possible to do anything except
>> sending an ERROR or READ event.
>>
>> Right now, I'm doing all the changes in the servlet container (which
>> is enough to keep me busy for now, and is independent).
>
> Looking at the event types and subtypes:
> - BEGIN: ok, no problem
> - READ: ok, no problem either
> - END/WEBAPP_RELOAD: it's useful, but it will be expensive (and not
> easy) to track which connection is associated with which webapp, and
> to close them; there could be an option to do this sort of tracking
> for people who would like to redeploy in production; I think the
> tracking and cleanup would best be done by the servlet itself using a
> listener
yes, this is a tricky one, let me think about it for a bit.
> - END/SERVER_SHUTDOWN: already done, but as an error event; I think
> the name should be changed to STOP or something, however, since only
> the connector could be stopped
I'm ok with the name change.
> - END/SESSION_END: ?; does this mean when the HTTP session expires ?
> It's about the same as WEBAPP_RELOAD, then: useful, but expensive and
> not easy to do (= another option); note also that the servlet can do
> this sort of tracking by itself (it can have a map of the connection
> and associated session, and use a session listener)
can't remember what I was thinking on this one.
> - ERROR/TIMEOUT: no problem; there should be the possibility for the
> servlet to not terminate the connection for that one (the connection
> goes back to the poller with a brand new timeout value), however
> - ERROR/CLIENT_DISCONNECT: ok, except on Windows with APR (a READ
> event will be generated instead, and it will read an EOF); NIO may
> have the same issue
I believe you are correct
> - ERROR/IOEXCEPTION: I don't understand that one: I think people will
> get an exception when reading invalid data, as usual
it was intended as a global catch all subtype. ie, if there is a poller
error. if data is invalid, then yes, read will throw ServletException or
IOException.
>
> For some of these events, we could provide with Tomcat a set of
> utility valves which would implement them, such as a connection
> tracking valve (closes connections on reloads or when sessions expire).
agreed
got my hands full today, will sleep on it some more.
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
> That's a second step :) It's a good idea because at the moment there's
> only a boolean, so it's not possible to do anything except sending an
> ERROR or READ event.
>
> Right now, I'm doing all the changes in the servlet container (which is
> enough to keep me busy for now, and is independent).
Looking at the event types and subtypes:
- BEGIN: ok, no problem
- READ: ok, no problem either
- END/WEBAPP_RELOAD: it's useful, but it will be expensive (and not
easy) to track which connection is associated with which webapp, and to
close them; there could be an option to do this sort of tracking for
people who would like to redeploy in production; I think the tracking
and cleanup would best be done by the servlet itself using a listener
- END/SERVER_SHUTDOWN: already done, but as an error event; I think the
name should be changed to STOP or something, however, since only the
connector could be stopped
- END/SESSION_END: ?; does this mean when the HTTP session expires ?
It's about the same as WEBAPP_RELOAD, then: useful, but expensive and
not easy to do (= another option); note also that the servlet can do
this sort of tracking by itself (it can have a map of the connection and
associated session, and use a session listener)
- ERROR/TIMEOUT: no problem; there should be the possibility for the
servlet to not terminate the connection for that one (the connection
goes back to the poller with a brand new timeout value), however
- ERROR/CLIENT_DISCONNECT: ok, except on Windows with APR (a READ event
will be generated instead, and it will read an EOF); NIO may have the
same issue
- ERROR/IOEXCEPTION: I don't understand that one: I think people will
get an exception when reading invalid data, as usual
For some of these events, we could provide with Tomcat a set of utility
valves which would implement them, such as a connection tracking valve
(closes connections on reloads or when sessions expire).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> great, can we adjust processSocket(socket, boolean) (AprEndPoint and
> NioEndpoint) so that it can pass the correct data (timeout, shutdown etc)
> I can do all the schtuff in the NIO piece, its so similar to the APR
> piece that I can just see what you have done there.
That's a second step :) It's a good idea because at the moment there's
only a boolean, so it's not possible to do anything except sending an
ERROR or READ event.
Right now, I'm doing all the changes in the servlet container (which is
enough to keep me busy for now, and is independent).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
great, can we adjust processSocket(socket, boolean) (AprEndPoint and
NioEndpoint) so that it can pass the correct data (timeout, shutdown etc)
I can do all the schtuff in the NIO piece, its so similar to the APR
piece that I can just see what you have done there.
Filip
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> yes please get started, I want to spend some time in the clustering
>> code right now, so I'll chime in a bit later.
>
> Cool. Since I'll be reusing a lot of existing code, I think it'll be
> done quickly (maybe by tomorrow).
>
> 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
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> yes please get started, I want to spend some time in the clustering code
> right now, so I'll chime in a bit later.
Cool. Since I'll be reusing a lot of existing code, I think it'll be
done quickly (maybe by tomorrow).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> 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.
>
> Great ! Yes, mapping is easy to add, so since you like it, those
> "filters" can completely use the existing infrastructure. Are you ok
> if I start with adding your CometEvent interface to the main source
> tree ?
>
> On the other side of the container fence, I would need to make some
> mods to the "valve" type (since if I don't have any possibility to
> integrate with JEE, my boss will murder me). Most likely I would add a
> new "event" method to Valve and ValveBase (as a special case, the
> "begin" event would be handled by the regular invoke method), and the
> (very few) valves that need to do business per event would be able to
> do it. AFAIK, all current valves "invoke" methods support Comet
> without problems (they don't do any funky tricks, and provide
> functionality that is still going to be needed on the initial event:
> HTTP auth, error pages and reports, etc). I think we should also
> specify that the response will be considered committed after the
> initial event. This also means the event method in the servlet adapter
> will not directly call the servlet (which IMO is a good idea).
>
> I missed it, but I am ok with adding a "close" method on the event
> class, since it is more explicit (indeed, it is to be implemented by
> closing the output buffer).
yes please get started, I want to spend some time in the clustering code
right now, so I'll chime in a bit later.
>
> 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
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
Filip Hanik - Dev Lists wrote:
> 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.
Great ! Yes, mapping is easy to add, so since you like it, those
"filters" can completely use the existing infrastructure. Are you ok if
I start with adding your CometEvent interface to the main source tree ?
On the other side of the container fence, I would need to make some mods
to the "valve" type (since if I don't have any possibility to integrate
with JEE, my boss will murder me). Most likely I would add a new "event"
method to Valve and ValveBase (as a special case, the "begin" event
would be handled by the regular invoke method), and the (very few)
valves that need to do business per event would be able to do it. AFAIK,
all current valves "invoke" methods support Comet without problems (they
don't do any funky tricks, and provide functionality that is still going
to be needed on the initial event: HTTP auth, error pages and reports,
etc). I think we should also specify that the response will be
considered committed after the initial event. This also means the event
method in the servlet adapter will not directly call the servlet (which
IMO is a good idea).
I missed it, but I am ok with adding a "close" method on the event
class, since it is more explicit (indeed, it is to be implemented by
closing the output buffer).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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: 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
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
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 ;) ).
>>> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
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 &&
>> 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.
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).
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.
>
>> The interface can be viewed at
>> http://people.apache.org/~fhanik/CometEvent.java
>
> 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
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Proposal - Comet changes
Posted by Remy Maucherat <re...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org