RE: [jade-develop] NotYetConnectedException

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 FOO@xxxxxxxxxxxx:1099/JADE  :addresses (sequence
http://192.168.0.27:7778/acc)) conversation-id: mumble) to agent
BAR@xxxxxxxxxxxx: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 "robert@xxxxxxxxxxxxxx" <robert@xxxxxxxxxxxxxx>:

> 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


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux