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 Mon, 11 Jun 2007 14:53:46 GMT
I'll work on some examples to illustrate what I mean,
It will be much clearer


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:

View raw message