Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Date: Thu, 03 May 2007 16:47:12 +0200
From: Filip Hanik - Dev Lists <devlists@hanik.com>
Subject: Re: Proposed new CometEvent.notify method
In-reply-to: <463945DC.9050606@apache.org>
To: Tomcat Developers List <dev@tomcat.apache.org>
Message-id: <4639F5F0.8030008@hanik.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
References: <4638B4DE.4090800@apache.org> <463945DC.9050606@apache.org>

Remy Maucherat wrote:
> Remy Maucherat wrote:
>> Hi,
>>
>> To more conveniently support some use cases, a new notify method 
>> could be added to the event. This would do an action callback and 
>> call a new method in the Poller class would add the socket to a 
>> structure like the socket add list. The comet poller thread will then 
>> check if there are sockets in that list, and call an event (as for 
>> the event type, it could be a regular timeout - it's very similar - 
>> or a new type which will behave the same as timeout - which would be 
>> significantly harder since modifications will have to be made to 
>> accommodate the new event type).
>>
>> I know how to make this fairly easily with the APR connector, and I'm 
>> not so sure about the NIO one (most likely it's very similar, 
>> however). The main thing which is annoying to implement is if the 
>> fact that there will not be any other concurrent event occurring has 
>> to be enforced and there are multiple pollers (I think the socket has 
>> to be removed "just in case" from each poller, which is quite annoying).
>
> Along with it, I think a semi dynamic option should be added to not 
> use read polling (which does funky stuff in certain cases, since when 
> using pipelining, there's data available but the data may actually not 
> belong to this request), but still check timeout. I think per 
> connection timeout should also be supported by APR. Having these in 
> addition to notify() would allow all possible usage scenarios without 
> running into funny corner cases.
Just to understand it right event.notify() will call back into the 
endpoint (through an actionhook) and this issues a 
XXXEndpoint.process(socket) so that they the comet servlet has a worker 
thread to piggy back on? (sort of simulate a read event), except the 
event type will be NOTIFY, or the sub type will be NOTIFY.
That sounds good to me, since there are use cases that are very hard to 
do if it is done asynchronously through an external thread.

Basically, to create an "async servlet" the code would simply look like this

a) make sure it is not registered for READ event
b) call event.close()
c) call event.notify() - yields a END or NOTIFY event

this would recycle the connection/req/resp, and voila, we have async 
servlet, AJAX style.
Let me know if I'm on the wrong path here

So in terms of code could we
1. Change "boolean comet =" to "int comet =" or to a list of enum, based 
on if you want to register for a read with the poller or to not have any 
poller interaction
   So reuse the same code we have, and at the end decide what list to 
add the connection too, the Poller.READ or Poller.NOOP (pardon my own 
names:)
   The CometProcessor could use the CometEvent to decide during the 
BEGIN event, whether to register for READ or not.
2. I'd like to expand on available, is it possible to at the very bottom 
InternalXXXInputBuffer.SocketInputBuffer, to issue a non block read, 
that would read data into the first buffer, to see if there even was any 
data. this would solve our non-blocking read issue. Basically the length 
would then have to be kept around so that when a read is issued, and 
there already is some data in the buffer, don't reissue it, and just 
return the length.
3. Still haven't come up with a good/clean idea for non block write, 
next week will open up much more time for this.
   For a while I was thinking of registering the connection for 
Poller.WRITE, to notify the servlet when a write is doable without 
blocking, however, this cause the same concurrency issues as the 
Poller.READ does, so I have put it on the back burner for now.

thoughts on these suggestions? more to come from this corner soon,

Filip


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org