On 4/9/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
Elias Naur wrote:
> On 4/8/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
>> Elias Naur wrote:
>> > On 4/7/07, Rémy Maucherat <[EMAIL PROTECTED]> wrote:
>> >> On 4/6/07, Elias Naur <[EMAIL PROTECTED]> wrote:
>> >> > I'm aware that a correct implementation must empty the buffer on a
>> >> > READ event, but as I stated in the original post, a READ event is
>> >> > never received (not even when the client forces a disconnect), only
>> >> > the initial BEGIN event, so had I included a read on READ it
>> wouldn't
>> >> > matter and would only serve to clutter the test case. If I'm
>> supposed
>> >> > to read when receiving BEGIN, I'll admit my test is incorrect, but
>> >> > then the example at
>> http://tomcat.apache.org/tomcat-6.0-doc/aio.html
>> >> > needs to be corrected too.
>> >>
>> >> So you can also confirm APR and NIO do the same ? I don't see how
>> >> you're not going to get an error event in that particular case.
>> >> However, I can't test it personally, so maybe you can look into
>> this a
>> >> bit deeper (otherwise, most likely Filip will).
>> >>
>> >> Rémy
>> >>
>> >
>> > No. Compiling and enabling the APR connector instead of the NIO
>> > connector made the problem go away. There were still no ERROR events
>> > sent after the client disconnect (I guess the connection might timeout
>> > sometime later), but the original problem of 100% CPU usage is gone.
>> ok, lets put an end to this now, shall we :)
>> The problem is not with any of the connectors, it is with your code.
>>
>> On Windows Your Code does:
>> NIO: 100% CPU because you get issued READ after READ, and you are not
>> emptying the buffer
>> APR: 100% CPU because you get issued READ after READ, and you are not
>> emptying the buffer
>>
>> On Linux Your Code does:
>> NIO: 100% CPU because you get issued READ after READ, and you are not
>> emptying the buffer
>> APR:BEGIN event, followed by an ERROR event.
>>
>> As you might figure out by this point it's just how the different IO
>> apis work on different platforms.
>> This is still 100% fault of your own code, the Java NIO api doesn't
>> notify us of a connection close or hangup, it notifies us as if it was
>> an READ event
>> and you are not handling it.
>>
>> This has nothing to do with APR or NIO, had your code was correct, you'd
>> never have 100% CPU, here is your code corrected.
>>
>> public void event(CometEvent event) throws IOException,
>> ServletException {
>> System.out.println("event.getEventType() = " +
>> event.getEventType());
>> if ( event.getEventType() == CometEvent.EventType.READ ) {
>> if (event.getHttpServletRequest().getInputStream().read(new
>> byte[1024]) == -1) {
>> event.close();
>> }
>> }
>> }
>>
>
> Pretty please, with sugar on top, read my original posting. I'm
> watching the output of the test servlet, and _no_ READ event is ever
> received, only the single BEGIN when the connection is established. To
> be extra sure, I ran your modified test, and got the exact same
> result: 100% CPU usage after client disconnect. Have you tried my code
> on linux? It is entirely possible that my code is incorrect, but then
> the fault is elsewhere, not in the event handler.
tried it on Linux (Fedora 6)and Windows (XP), same results.
starts spitting out READ events as soon as the client disconnects and
the input stream is not emptied.
Filip
I'm guessing you're testing with the trunk? After seeing your response
I compiled the tomcat6 trunk and tested with that instead, and now I
get a torrent of READ events, as expected! I suppose there has been
NIO fixes in this area lately and they fixed my problem. Now, when is
6.0.11 due? ;)
- elias
