Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
nice ultimatum :)
let me go through both the proposals and look it over. after that I
suggest we simply have/agree on a majority vote without vetoes to be
able to move on properly.
in the vote announcement, I think we should simply outline t
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
nice ultimatum :)
let me go through both the proposals and look it over. after that I
suggest we simply have/agree on a majority vote without vetoes to be
able to move on properly.
in the vote announcement, I think we should simply outline t
Filip Hanik - Dev Lists wrote:
nice ultimatum :)
let me go through both the proposals and look it over. after that I
suggest we simply have/agree on a majority vote without vetoes to be
able to move on properly.
in the vote announcement, I think we should simply outline the
differences so that
Remy Maucherat wrote:
Remy Maucherat wrote:
Hi,
I've been working on additions to CometEvent to implement the
additional Comet functionality that was agreed upon before creating
the "trunk" branch. Although not functional at the moment, I consider
it to be developed enough from an algorithmi
Remy Maucherat wrote:
Hi,
I've been working on additions to CometEvent to implement the additional
Comet functionality that was agreed upon before creating the "trunk"
branch. Although not functional at the moment, I consider it to be
developed enough from an algorithmic standpoint to be prop
Filip Hanik - Dev Lists wrote:
Ok, one use case scenario would be AJAX requests with asynchronous
responses on the server, I can see this be extremely common,
I've tried to add in comments to make the example clear, and I don't see
this example as stupid, as there are a lot more AJAX client fram
Costin Manolache wrote:
On 6/15/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
correction, should read
I can implement inputstream.read() to return 0 on both blocking and non
blocking *Comet events*, (since sockets are always non blocking)
Ok, my mistake - what I really meant to sa
On 6/15/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
correction, should read
I can implement inputstream.read() to return 0 on both blocking and non
blocking *Comet events*, (since sockets are always non blocking)
Ok, my mistake - what I really meant to say is: I am only interest
Filip Hanik - Dev Lists wrote:
Costin Manolache wrote:
Ok, so let me double check: the low level socket in sandbox is
allways read
after a poll() / select(),
and never with a blocking read() ?
huh? :)
After the poll(): the Comet servlet, in a tomcat thread will be able
to call
read() in t
Ok, one use case scenario would be AJAX requests with asynchronous
responses on the server, I can see this be extremely common,
I've tried to add in comments to make the example clear, and I don't see
this example as stupid, as there are a lot more AJAX client frameworks
than Comet client framew
since we are getting pretty far off track here, I've started a Wiki page
on what comet is and isn't.
http://wiki.apache.org/tomcat/WhatIsComet
It will be helpful in the future, or we can assimilate this into our
docs eventually, but for now, I think it is a good drawing board to
clear out thin
Costin Manolache wrote:
Ok, so let me double check: the low level socket in sandbox is allways
read
after a poll() / select(),
and never with a blocking read() ?
huh? :)
After the poll(): the Comet servlet, in a tomcat thread will be able
to call
read() in the input
stream, and that will r
Ok, so let me double check: the low level socket in sandbox is allways read
after a poll() / select(),
and never with a blocking read() ?
After the poll(): the Comet servlet, in a tomcat thread will be able to call
read() in the input
stream, and that will return data or 0 if no more data is avai
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Please note, that neither Remy nor I have yet really talked about non
blocking reads, so you might think sandbox is non blocking, well it
is not.
It is buffering, but not non blocking. a true non blocking read,
would require a rewrite of all
Filip Hanik - Dev Lists wrote:
public class ExampleCometStockStreamer implements CometProcessor {
...
public class StockUpdater extends Thread {
public void run() {
...
StockUpdates[] updates = fetchUpdates();
Client[] clients = getClients(updates);
for (int i=0; i
Filip Hanik - Dev Lists wrote:
Please note, that neither Remy nor I have yet really talked about non
blocking reads, so you might think sandbox is non blocking, well it is not.
It is buffering, but not non blocking. a true non blocking read, would
require a rewrite of all the buffer filters to k
Costin Manolache wrote:
On 6/14/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
>> >
>> >
>> > Sounds better - but as Remy explained you would first need to
explain
>> > why blocking is needed in this context and how to deal with the
>> confusion
>> > of mixing
On 6/14/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
>> >
>> >
>> > Sounds better - but as Remy explained you would first need to explain
>> > why blocking is needed in this context and how to deal with the
>> confusion
>> > of mixing blocking and non-blocking f
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
here we go, some examples
http://people.apache.org/~fhanik/tomcat/aio.html#Example%20code%20snippets
and the entire document has been updated to reflect most changes
http://people.apache.org/~fhanik/tomcat/aio.html
Here is an alternativ
Costin Manolache wrote:
>
>
> Sounds better - but as Remy explained you would first need to explain
> why blocking is needed in this context and how to deal with the
confusion
> of mixing blocking and non-blocking for users, and the implementation
> complexities it adds.
trunk doesn't mix them. a
Filip Hanik - Dev Lists wrote:
here we go, some examples
http://people.apache.org/~fhanik/tomcat/aio.html#Example%20code%20snippets
and the entire document has been updated to reflect most changes
http://people.apache.org/~fhanik/tomcat/aio.html
Here is an alternative version of the examples
>
>
> Sounds better - but as Remy explained you would first need to explain
> why blocking is needed in this context and how to deal with the
confusion
> of mixing blocking and non-blocking for users, and the implementation
> complexities it adds.
trunk doesn't mix them. a comet connection is eith
here we go, some examples
http://people.apache.org/~fhanik/tomcat/aio.html#Example%20code%20snippets
and the entire document has been updated to reflect most changes
http://people.apache.org/~fhanik/tomcat/aio.html
Filip
Filip Hanik - Dev Lists wrote:
I'll work on some examples to illustrate
Costin Manolache wrote:
On 6/13/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
> For a separate opinion:
>
> In the trunk version:
> - the '...' and array return seem strange and generate GC ( not a big
> issue
> those days, but still inconsistent with the
> rest
On 6/13/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
>> setTimeout() is not optional (the javadoc is out of date, sorry), there
>> was an agreement on that earlier. Timeout sets the connection timeout,
>> which is most likely useful even if there are events. It's quite
>
On 6/13/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
> For a separate opinion:
>
> In the trunk version:
> - the '...' and array return seem strange and generate GC ( not a big
> issue
> those days, but still inconsistent with the
> rest of tomcat )
yes, its a n
Costin Manolache wrote:
For a separate opinion:
In the trunk version:
- the '...' and array return seem strange and generate GC ( not a big
issue
those days, but still inconsistent with the
rest of tomcat )
yes, its a new language feature, hence it wasn't available in previous
JDKs or Tomcat.
On Wed, 2007-06-13 at 12:04 +0200, Remy Maucherat wrote:
> Costin Manolache wrote:
> >> setTimeout() is not optional (the javadoc is out of date, sorry), there
> >> was an agreement on that earlier. Timeout sets the connection timeout,
> >> which is most likely useful even if there are events. It's
Costin Manolache wrote:
setTimeout() is not optional (the javadoc is out of date, sorry), there
was an agreement on that earlier. Timeout sets the connection timeout,
which is most likely useful even if there are events. It's quite
possible sleep could use a timeout argument (I think calling setT
On 6/12/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Costin Manolache wrote:
> In the sandbox version:
> - sleep() and setTimeout(int) -> why not sleep(int millis) ? I think
it's
> confusing to have both and the interactions between them, in
> particular setTimeout is marked optional ? It makes
Costin Manolache wrote:
In the sandbox version:
- sleep() and setTimeout(int) -> why not sleep(int millis) ? I think it's
confusing to have both and the interactions between them, in
particular setTimeout is marked optional ? It makes sense to have
setTimeout() as a general timeout.
setTimeout(
For a separate opinion:
In the trunk version:
- the '...' and array return seem strange and generate GC ( not a big issue
those days, but still inconsistent with the
rest of tomcat )
- the API seems a bit over-complex - for example, why
setConfiguration(COMMET_BLOCKING) instead of setBlocking()
I'll work on some examples to illustrate what I mean,
It will be much clearer
Filip
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Ok, let me see if I can summarize.
1. Whether you write out the stored buffer using the Poller thread,
or a Tomcat worker thread (flushed in Http11xxxProce
Filip Hanik - Dev Lists wrote:
Ok, let me see if I can summarize.
1. Whether you write out the stored buffer using the Poller thread, or a
Tomcat worker thread (flushed in Http11xxxProcessor) as described below
I originally thought of this as async write, as we are simply doing a
write with a
Ok, let me see if I can summarize.
1. Whether you write out the stored buffer using the Poller thread, or a
Tomcat worker thread (flushed in Http11xxxProcessor) as described below
I originally thought of this as async write, as we are simply doing a
write with another one of our threads. Origi
Filip Hanik - Dev Lists wrote:
I think I did present understandable explanations, so if you don't
bother reading (as usual ...), I suppose I should stop wasting my time.
throwing your hands in the air and saying you're not going to waste your
time, is in your personal interest only and you are o
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
In my personal opinion I am no longer sure a non blocking write is
needed.
Ok.
async -> using more than one thread to do stuff
and that is what you are proposing, to dispatch the write to the poller
thread.
non blocking -> a method call wh
Filip Hanik - Dev Lists wrote:
In my personal opinion I am no longer sure a non blocking write is needed.
Ok.
async -> using more than one thread to do stuff
non blocking -> a method call which returns immediately without, well,
blocking
I think I did present understandable explanations, so
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
If you don't care about this stuff, but still read the first line, do
our community a favor and get involved :)
I'm not sure I understand this. It could be interpreted in a
derogatory way.
if it is just you and I, then its your -1 against
Filip Hanik - Dev Lists wrote:
If you don't care about this stuff, but still read the first line, do
our community a favor and get involved :)
I'm not sure I understand this. It could be interpreted in a derogatory way.
The API's are pretty much identical,
Yes, they are pretty much function
If you don't care about this stuff, but still read the first line, do
our community a favor and get involved :)
The API's are pretty much identical,
Remy:
https://svn.apache.org/viewvc/tomcat/sandbox/comet/java/org/apache/catalina/CometEvent.java?view=markup
Filip:
https://svn.apache.org/view
Yoav Shapira wrote:
Hi,
On 6/7/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
fail-fast the connection using an IOException (the servlet would
effectively only handle clients which are "fast enough" if using the
Comet API like in Tomcat 6.0, which avoids a lot of issues)
This is an interesting
Hi,
On 6/7/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
fail-fast the connection using an IOException (the servlet would
effectively only handle clients which are "fast enough" if using the
Comet API like in Tomcat 6.0, which avoids a lot of issues)
This is an interesting assumption, but I th
43 matches
Mail list logo
