Hello, Some more information about NotYetConnectedException. I've appended a previous message as a postscript for context.
Here is a stack trace from the Throwable which is caught near line 152 in jade/core/messaging/MessageManager.java. The warning message is printed at that point. java.nio.channels.NotYetConnectedException at gnu.java.nio.SocketChannelImpl.write(SocketChannelImpl.java:258) at gnu.java.net.PlainSocketImpl$SocketOutputStream.write(PlainSocketImpl.java:668) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:109) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:186) at java.io.FilterOutputStream.write(FilterOutputStream.java:126) at jade.mtp.http.HTTPIO.writeAll(HTTPIO.java:114) at jade.mtp.http.KeepAlive$KAConnection.send(KeepAlive.java:143) at jade.mtp.http.KeepAlive.send(KeepAlive.java:298) at jade.mtp.http.MessageTransportProtocol.deliver(MessageTransportProtocol.java:325) at jade.core.messaging.RoutingTable$OutViaMTP.route(RoutingTable.java:109) at jade.core.messaging.MessagingService$ServiceComponent.routeOut(MessagingService.java:1112) at jade.core.messaging.MessagingService$ServiceComponent.access$2800(MessagingService.java:1002) at jade.core.messaging.MessagingService.forwardMessage(MessagingService.java:1364) at jade.core.messaging.MessagingService.deliverNow(MessagingService.java:1188) at jade.core.messaging.MessageManager$Deliverer.run(MessageManager.java:152) at java.lang.Thread.run(Thread.java:743) Sep 27, 2007 9:41:16 AM <unknown> <unknown> WARNING: MessageManager cannot deliver message (INFORM sender: (agent-identifier :name [EMAIL PROTECTED]:1099/JADE :addresses (sequence http://192.168.0.27:7778/acc)) conversation-id: mumble) to agent [EMAIL PROTECTED]:1099/JADE. java.nio.channels.NotYetConnectedException So it appears that gnu.java.nio.SocketChannelImpl.write fails. According to SocketChannelImpl.java that is due to SocketChannelImpl.isConnected returns false. However, that only happens after running for several hours. Before that, it appears that SocketChannelImpl.write succeeds many times. So I guess the question is what might have changed to cause SocketChannelImpl.write to fail after succeeding many times. Someone else has let me know via email that he has encountered NotYetConnectedException while running Classpath + Azureus Bittorrent client. He wrote, "I don't see this with IcedTea (OpenJDK codebase) so I guess it is Classpath NIO specific." Any further information is very welcome. Robert Dodier Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>: > I am running JADE-LEAP 3.5 on JamVM 1.4.5 + Classpath 0.95 + Linux 2.6.21 > + Xscale cpu (an ARM-architecture cpu) on the hosts which encounter > the NotYetConnectedException. These hosts are trying to send messages > to PC's which are running JADE-LEAP 3.5 + Sun JVM 1.5.0 + Linux 2.6.something > + i686 cpu. On every host there is an ordinary container (no split > containers). > > The exceptions seem to be thrown only after an ARM host has > been running for a while (maybe 1 hour to several hours). > Restarting the JVM seems to make the problem go away. > I say "seem" because it's not clear to me what are the > circumstances in which the exceptions are thrown. > > Probing into the Classpath source code, it appears that the > NotYetConnectedException originates from gnu.java.nio.SocketChannelImpl. > (The exception is never thrown from JADE, to the best of my > knowledge; grepping for NotYetConnectedException in the JADE > source code turns up nothing.) In SocketChannelImpl, > the exception is thrown if the method isConnected returns false. > Here is the definition of isConnected: > > public boolean isConnected() > { > // Wait until finishConnect is called before transitioning to > // connected. > if (connectionPending) > return false; > try > { > InetSocketAddress remote = channel.getPeerAddress(); > return remote != null; > } > catch (IOException ioe) > { > ioe.printStackTrace(System.out); > return false; > } > } > > I do not know whether the false return value comes from > the "return false" or "return remote != null". > I guess I'll keep digging. If anyone has any comments > about this I would appreciate it a lot. > > All the best & thanks for your help, > > Robert Dodier
