ok, changes are in,
there is one inconsistency,
currently READ is a main type, while WRITE is a subtype of NOTIFY
thoughts on consolidate these? ie NOTIFY/READ or make WRITE a main type
by no means is this set in stone, and as we go along and discover
problems or semantics issues, we can make a
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
1. CometEvent.notify is a servlet calling container method,not a
callback from the container
The servlet calls the "notify" method, right ?
2. Introduce a new EventType -> NOTIFY
3. Keep the sub event type -> WRITE_COMPLETE, instead of hav
Filip Hanik - Dev Lists wrote:
1. CometEvent.notify is a servlet calling container method,not a
callback from the container
The servlet calls the "notify" method, right ?
2. Introduce a new EventType -> NOTIFY
3. Keep the sub event type -> WRITE_COMPLETE, instead of having to busy
poll Comet
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
oh crap, we are thinking way different :), I was thinking the other
way around
Here is one event chain
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(READ) -
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
oh crap, we are thinking way different :), I was thinking the other
way around
Here is one event chain
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(READ) -
Filip Hanik - Dev Lists wrote:
oh crap, we are thinking way different :), I was thinking the other way
around
Here is one event chain
1. CometProcessor.event(CometEvent.BEGIN/null)
2. Servlet calls CometEvent.setBlocking(false);
3. Servlet calls CometEvent.notify(READ) - the servlet wants to be
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
true. lets see how it pans out in actual code, that might change our
perspective.
I was toying around with an alternative idea too, disallow any read
or write all together unless it is done on a worker thread. gives us
complete control, ea
Filip Hanik - Dev Lists wrote:
true. lets see how it pans out in actual code, that might change our
perspective.
I was toying around with an alternative idea too, disallow any read or
write all together unless it is done on a worker thread. gives us
complete control, easier to implement.
pu
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
So it uses a poller automatically, and the WRITE event would be sent
when the socket is signaled by the poller, then. This is very
similar. The only problem is that it could cause sync is
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
So it uses a poller automatically, and the WRITE event would be sent
when the socket is signaled by the poller, then. This is very similar.
The only problem is that it could cause sync issues, since the servlet
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I agree, but I don't understand how you can know if you can write
without a write polling. If there are no events on read, I have the
impression writing could be suspended for an indefini
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I agree, but I don't understand how you can know if you can write
without a write polling. If there are no events on read, I have the
impression writing could be suspended for an indefinite amount of
time. So
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Here are some changes.
1. The background thread should not have to call notifyWrite, since
we provide READ event, we can also provide
an automatic event is thrown when a write completes
EventType=NOTIFY EventSubType=WRITE_COMPLETE, as soon
Filip Hanik - Dev Lists wrote:
Here are some changes.
1. The background thread should not have to call notifyWrite, since we
provide READ event, we can also provide
an automatic event is thrown when a write completes EventType=NOTIFY
EventSubType=WRITE_COMPLETE, as soon as the write does comp
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
That doesn't look like much of a problem to me. The user in that
case would be writing in a situation where canWrite is false (since
the data hasn't been written yet), which is an error.
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
That doesn't look like much of a problem to me. The user in that case
would be writing in a situation where canWrite is false (since the
data hasn't been written yet), which is an error. To resume writing
stuf
(repost, trouble with smtp)
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
That doesn't look like much of a problem to me. The user in that case
would be writing in a situation where canWrite is false (since the
data hasn't been written yet), which is an e
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
That's the easy part: the bytes are kept in the usual socket buffer,
which will be flushed when the connection comes back from the write
poller, just before invoking the write event.
not so easy, if the servlet invokes
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
That's the easy part: the bytes are kept in the usual socket buffer,
which will be flushed when the connection comes back from the write
poller, just before invoking the write event.
not so easy, if the servlet invokes write again, you have c
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I thought about the canWrite idea earlier, and there is a difficult
problem to get around. the steps are
1. canWrite - returns true
2. response.getOutputStream().write(8k byte array)
3. only 2k gets written during the non blocking write
so w
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I'm on GMT+1 time for the next 5 weeks.
Jean-Frédéric told me you were in Finland.
Close :), actually in Sweden, my country of origination.
Filip
Rémy
-
To unsubscribe,
Filip Hanik - Dev Lists wrote:
I'm on GMT+1 time for the next 5 weeks.
Jean-Frédéric told me you were in Finland.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Filip Hanik - Dev Lists wrote:
I thought about the canWrite idea earlier, and there is a difficult
problem to get around. the steps are
1. canWrite - returns true
2. response.getOutputStream().write(8k byte array)
3. only 2k gets written during the non blocking write
so what does one do? does i
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
ok, here we go, I have thought about this and have two different
proposals.
1. Add non blocking support to Coyote(In|Out)putStream
The servlet can cast request.getInputStream() to a CoyoteInputStream
Example:
//perform a non blocking r
Filip Hanik - Dev Lists wrote:
ok, here we go, I have thought about this and have two different proposals.
1. Add non blocking support to Coyote(In|Out)putStream
The servlet can cast request.getInputStream() to a CoyoteInputStream
Example:
//perform a non blocking read.
int read = ((Coyo
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
- EOF as a new ComentEvent.EventSubType, subtype of
CometEvent.EventType .END (will be called when the endpoint signals
a read); after getting this event, the CometAdapter could
automagically call CometEvent.disableReadPolling() to avoid pro
Filip Hanik - Dev Lists wrote:
- EOF as a new ComentEvent.EventSubType, subtype of
CometEvent.EventType .END (will be called when the endpoint signals a
read); after getting this event, the CometAdapter could automagically
call CometEvent.disableReadPolling() to avoid problems if the client
so
Remy Maucherat wrote:
Hi,
To summarize, I propose the following additions in the Comet
functionality for the next Tomcat 6.0 release (the various names are
proposals, I am not very good at names):
- per event timeout becomes mandatory
per event or per connection?
- small refactoring of the t
Hi,
Overall I haven't been very involved with Comet, and only used it in
testing / playing around, not in production. But that said, your
proposed changes make good sense to me.
On 5/6/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
To summarize, I propose the following additions in the Comet
fun
Hi,
To summarize, I propose the following additions in the Comet
functionality for the next Tomcat 6.0 release (the various names are
proposals, I am not very good at names):
- per event timeout becomes mandatory
- small refactoring of the timeout callback using an action code rather
than a r
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
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 con
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
enoug
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.
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
--
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 sam
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
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
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
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.
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
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
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
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
my proposal is a little delayed, had a slight Fedora Core meltdown,
still recovering
Soon, you're going to say it's all my fault.
that's implicit :)
I am away without email next week, and I'm coming back on friday (in
the evening).
enj
Filip Hanik - Dev Lists wrote:
my proposal is a little delayed, had a slight Fedora Core meltdown,
still recovering
Soon, you're going to say it's all my fault.
I am away without email next week, and I'm coming back on friday (in the
evening).
Rémy
-
my proposal is a little delayed, had a slight Fedora Core meltdown,
still recovering
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
what am I thinking, all connectors, so far only the connectors
supporting poll are valid candidates for comet :)
I don't k
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
what am I thinking, all connectors, so far only the connectors
supporting poll are valid candidates for comet :)
I don't know how to redo the advertisement part of comet support
without the special "org.apache.tomcat.comet.support" attribut
Filip Hanik - Dev Lists wrote:
what am I thinking, all connectors, so far only the connectors
supporting poll are valid candidates for comet :)
I don't know how to redo the advertisement part of comet support without
the special "org.apache.tomcat.comet.support" attribute, though.
Rémy
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to
send additional data after close is called, as that is a output
stream close method.
calling close, will/should eventual
Remy Maucherat wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to
send additional data after close is called, as that is a output
stream close method.
calling close, will/should eventually trigger event(END).
Ok, I w
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to send
additional data after close is called, as that is a output stream
close method.
calling close, will/should eventually trigger event(END).
Ok, I will make those changes.
Filip Hanik - Dev Lists wrote:
flush I can see, but close in a comet I can't, there is no way to send
additional data after close is called, as that is a output stream close
method.
calling close, will/should eventually trigger event(END).
Ok, I will make those changes.
Rémy
---
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
5. CometEvent
public class CometEvent {
public enum EventType {
READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR
//and anything else, we could also crea
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
5. CometEvent
public class CometEvent {
public enum EventType {
READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR
//and anything else, we could also create groups of types,
RE
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
5. CometEvent
public class CometEvent {
public enum EventType {
READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR
//and anything else, we could also create groups of types,
READ,ERROR,SHUTDOWN, with subtypes
Filip Hanik - Dev Lists wrote:
5. CometEvent
public class CometEvent {
public enum EventType {
READ,TIMEOUT,SOCKET_CLOSE,CONTAINER_SHUTDOWN,CONTEXT_SHUTDOWN,GENERIC_ERROR
//and anything else, we could also create groups of types,
READ,ERROR,SHUTDOWN, with subtypes
}
public HttpSer
On 8/11/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
3. public boolean read(HttpServletRequest request, HttpServletResponse
response)
Suggestion - change this method to
public boolean event(CometEvent event)
This will allow the container to implement notifications for
timeouts, s
Filip Hanik - Dev Lists wrote:
any feedback?
If you're talking about me, I'm on vacation, so ...
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
any feedback?
Filip
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I believe this would allow for more flexibility in the future and a
cleaner interface.
This doesn't look bad, although I don't have time to really think
about it right now.
Rémy
---
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I believe this would allow for more flexibility in the future and a
cleaner interface.
This doesn't look bad, although I don't have time to really think
about it right now.
no rush, instead enjoy your weekend, and we can elaborate next wee
Filip Hanik - Dev Lists wrote:
I believe this would allow for more flexibility in the future and a
cleaner interface.
This doesn't look bad, although I don't have time to really think about
it right now.
Rémy
-
To unsubscr
Gents,
I have a suggestion on a small refactor for the CometProcessor, mainly
to make it a little bit more flexible,
here are my suggestions
1. public void begin(HttpServletRequest request, HttpServletResponse
response)
Suggestion - remove this method, its never called from the container
anyw
63 matches
Mail list logo
