Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 364030

Summary:	NotYetConnectedException on first request to Jetty
Product:	[RT] Jetty	Reporter:	qquit27
Component:	websocket	Assignee:	Jan Bartel <janb>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3	CC:	janb, jetty-inbox
Version:	unspecified
Target Milestone:	7.5.x
Hardware:	Other
OS:	Linux
Whiteboard:

Description qquit27

2011-11-17 08:43:00 EST

Build Identifier: 7.5.4

On our relatively slow platform, occasionally NotYetConnectedExceptions are thrown on first request to jetty, see below. 

Cause: 
HttpOutput checks, isOpen() on its AbstractGenerator _generator before writing content. In isOpen() the AbstractGenerator checks, isOpen() on its ChannelEndpoint, which again checks isOpen() on its ByteChannel. This ByteChannel may be an instance of SocketChannel. According to Java SocketChannel Class Specification, "A newly-created socket channel is open but not yet connected. An attempt to invoke an I/O operation upon an unconnected channel will cause a NotYetConnectedException to be thrown.".  In order to avoid the described NotYetConnectedExceptions, the ChannelEndPoint should in addition check isConnected() for SocketChannels.  

Exception thrown: 

[qtp1086452480-34] WARN  HttpConnection - /
java.nio.channels.NotYetConnectedException
   at gnu.java.nio.SocketChannelImpl.write(SocketChannelImpl.java:240)
   at java.nio.channels.SocketChannel.write(SocketChannel.java:132)
   at org.eclipse.jetty.io.nio.ChannelEndPoint.gatheringFlush(ChannelEndPoint.java:354)
   at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:292)
   at org.eclipse.jetty.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.java:300)
   at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:848)
   at org.eclipse.jetty.http.AbstractGenerator.flush(AbstractGenerator.java:452)
   at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:94)
   at org.eclipse.jetty.server.HttpConnection$Output.flush(HttpConnection.java:1010)
   at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:173)
   at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:101)
   at org.eclipse.jetty.util.ByteArrayISO8859Writer.writeTo(ByteArrayISO8859Writer.java:102)
   at org.eclipse.jetty.server.handler.ErrorHandler.handle(ErrorHandler.java:60)
   at org.eclipse.jetty.servlet.ErrorPageErrorHandler.handle(ErrorPageErrorHandler.java:147)
   at org.eclipse.jetty.server.Response.sendError(Response.java:310)
   at org.eclipse.jetty.server.Response.sendError(Response.java:378)
   at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:128)
...


Reproducible: Sometimes

Steps to Reproduce:
1.Start Jetty on slow platform and immedeately submit http request
2.
3.

Comment 1 Jan Bartel

2011-11-17 22:35:02 EST

Could you explain the test scenario a little more? How are you able to receive a request on a channel that is not connected? 

thanks
Jan

Comment 2 qquit27

2011-11-18 05:04:06 EST

I only see the exceptions on our slow embedded device, running jamvm/ Java 1.5, roughly on every second/third startup, never on my local machine. Actually, I see them beeing thrown also in other lines of the ChannelEndPoint Class, where IO Operations are executed on _channel, however only in the first request right after starting jetty.  E.g. 

java.nio.channels.NotYetConnectedException
   at gnu.java.nio.SocketChannelImpl.read(SocketChannelImpl.java:217)
   at gnu.java.net.PlainSocketImpl$SocketInputStream.read(PlainSocketImpl.java:587)
   at java.io.DataInputStream.readFully(DataInputStream.java:286)
   at java.io.DataInputStream.readInt(DataInputStream.java:323)
   at ch.belimo.bd.admin.SessionHandler.run(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:679)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:704)
   at java.lang.Thread.run(Thread.java:745)

Might we run into race conditions on start up, because our device is so slow? Where is channel connect actually called? The exceptions sometimes result in jetty delivering incomplete documents on that first request, which on browser side results in quite unpredictable behavior. 
Thanks for your effort!

Comment 3 Jan Bartel

2011-11-21 22:14:57 EST

Can you run jetty on your local machine using the jamvm and see if the problem occurs? I still can't see how its possible for a read to succeed on a socket that is not connected, unless there is something funny going on with the jvm.

Jan


(In reply to comment #2)
> I only see the exceptions on our slow embedded device, running jamvm/ Java 1.5,
> roughly on every second/third startup, never on my local machine. Actually, I
> see them beeing thrown also in other lines of the ChannelEndPoint Class, where
> IO Operations are executed on _channel, however only in the first request right
> after starting jetty.  E.g. 
> 
> java.nio.channels.NotYetConnectedException
>    at gnu.java.nio.SocketChannelImpl.read(SocketChannelImpl.java:217)
>    at
> gnu.java.net.PlainSocketImpl$SocketInputStream.read(PlainSocketImpl.java:587)
>    at java.io.DataInputStream.readFully(DataInputStream.java:286)
>    at java.io.DataInputStream.readInt(DataInputStream.java:323)
>    at ch.belimo.bd.admin.SessionHandler.run(Unknown Source)
>    at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:679)
>    at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:704)
>    at java.lang.Thread.run(Thread.java:745)
> 
> Might we run into race conditions on start up, because our device is so slow?
> Where is channel connect actually called? The exceptions sometimes result in
> jetty delivering incomplete documents on that first request, which on browser
> side results in quite unpredictable behavior. 
> Thanks for your effort!

Comment 4 Jan Bartel

2012-01-11 23:22:27 EST

Any more info on this? For example, running it with the same jvm on your local machine as on the embedded device?

Comment 5 Jan Bartel

2012-07-30 00:10:07 EDT

Indications are that this is something strange with the particular jvm in use. As the poster has not provided any further details, I will close this issue for now. If more details are provided that point to a problem with the jetty code, then please reopen.

thanks
Jan