Community
Participate
Working Groups
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.
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
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!
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!
Any more info on this? For example, running it with the same jvm on your local machine as on the embedded device?
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
