tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: Proposed simplification of CometEvent
Date Wed, 13 Jun 2007 22:54:08 GMT
here we go, some examples

and the entire document has been updated to reflect most changes


Filip Hanik - Dev Lists wrote:
> 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 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. Originally 
>>> when we were talking non blocking writes, I was thinking along the 
>>> lines of non blocking to where the Comet developer had to do that 
>>> logic, just as he was writing a socket, possibly like (but not 
>>> suggested) a CometEvent.nonBlockWrite(ByteBuffer).
>>> 2. Do we need non blocking? with the methods of isWriteable and the 
>>> ability to register(OP_WRITE)->event(WRITE), if the number of bytes 
>>> you write is usually smaller than the socket buffer, chances are 
>>> that most writes will be non blocking. I would even argue a large 
>>> majority would be non blocking, and thus the implementation or the 
>>> complexity thereof would not be needed. And with the ability to do 
>>> async writes, means I can create my own thread pool/write queue to 
>>> perform these writes.
>> You are writing the opposite thing to the previous email, and we are 
>> back to "non blocking is useless". The problem is that I understand 
>> blocking IO as "write this data, and return when it's done". If the 
>> socket is in blocking mode, any write done by the servlet may block, 
>> regardless of what isWriteable says. Of course, it's very unlikely, 
>> which is why Comet in 6.0.x works.
>>> 3. isWriteable - simple method, but I don't like that the method in 
>>> itself performs actions like adding the socket to a poller etc.
>>>   Instead isWriteable==true means that you can write on the socket, 
>>> isWriteable==false you cannot. This method should be able to be 
>>> invoked as many times as its wanted, and is thread safe and doesn't 
>>> do anything funky underneath.
>> Ok, so you prefer a more complex API (if I follow "just in case it 
>> was useful"). I started with an API which would expose all 
>> operations, and looked into removing what was not explicitly useful.
>>> 4. isWriteable - I'm also reading in that you are also suggesting 
>>> that we use this method to declare if we want blocking or non 
>>> blocking writes.
>> No. The situation where write could (maybe) block is if the servlet 
>> writes in a Tomcat thread. Typically, this is the reply-later design, 
>> using the sleep/callback methods. The isWriteable method is not used, 
>> since the servlet merely wants (in that common design) to send a 
>> response as fast as possible, and typically this sort of response is 
>> not too large and unlikely to cause IO problems. This blocking 
>> behavior is allowed in that case to avoid forcing the user to put in 
>> more complex logic to deal with the partial write + event, and is set 
>> just for the amount of time it takes to perform the write (note that 
>> this ).
>>>   At this point this method is doing three things:
>>>   a) returns true/false if we can write data
>>>   b) delegates a socket to the poller to write data and generate a 
>>> event(WRITE) to the comet processor
>>>   c) configures a write to be blocking or non blocking
>>>   This is for sure not what I would expect of a "simple API", if 
>>> simple means less keystrokes than yes, but simple to me also means 
>>> intuitive and easily understood.
>> So you have plenty of methods to do the same thing.
>>> Given points 1-4, this is what is going to happen to every single 
>>> developer
>>>  I) They are going to use stream.write and event.isWriteable all the 
>>> time, not realizing what it actually does
>>> II) They are going to get confused when they receive an IOException 
>>> for trying to perform a write, cause they used isWriteable and the 
>>> socket went into non blocking mode
>> If that's what you want to believe ...
>>> At this point, this 'simple' API, obviously not so simple, instead 
>>> it becomes very complicated, as I would almost have to reverse 
>>> engineer the code to truly understand what it does.
>>> It may be simple to you and me, but that is because we are 
>>> implementing it.
>> I really don't see what is complex, especially when you look at the 
>> code the user would write for the simple cases, where you don't even 
>> have to use any API besides stream.write:
>> - reply later
>> - wait for read events, and write data in response to it
>> The complex case deals with handling incomplete async writes if you 
>> don't simply drop connection.
>>> so what does this mean to 'isReadable'? That I'm automatically 
>>> registering for a READ event if it returns false? Maybe I don't want 
>>> a READ event, I just want to see if any data has trickled in. so if 
>>> I call sleep(), should I then call isReadable() to reregister for 
>>> the read. how is this simpler than that register/unregister.
>> Read events always occur, unless you use sleep/callback. If this is 
>> not written clearly in the javadocs already, I need to change them.
>>> Where does that leave us, well:
>>> a) We are almost in sync on the implementation side of it
>> Not really, there's a big disconnect in the understanding of non 
>> blocking vs blocking, and according to you, non blocking is not 
>> useful (again).
>>> b) I believe your API is not intuitive, nor usable, as it simply 
>>> doesn't reflect what is going on and/or what a programmer wants done
>>> c) Your API doesn't become simpler just cause we merge three methods 
>>> into one -> configure(NON_BLOCK), write(byte[]), register(OP_WRITE)
>>> c) The API I propose, you think is overengineered, I think it just 
>>> makes things much clearer, the fact that it automatically allows for 
>>> future extension is a side effect rather than design decision
>> My API is simpler because the code the user has to write is more 
>> straightforward and easier to understand. Feel free to write small 
>> examples to see for yourself.
>>> So bottom line is, user will get the same implementation (or very 
>>> close to what we've talked about), question is what API are they 
>>> going to get?
>> Rémy
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message