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
29 matches
Mail list logo
