JInterface exception handling problem

Alexis Lê-Quôc <>
Tue Mar 6 20:32:46 CET 2001

Please correct me if I'm wrong, but the exception messages are lost, if they
happen in AbstractConnection:recvStatus() since they are rethrown with the
generic message: "Cannot connect to peer node" in

The messages that are thus ignored are "Handshake protocol error", "Peer
replied with status... instead of ok" and "Handshake failed - not enough
data". Unless I'm missing something obvious, there is no way for the
application to get these messages instead of the less descriptive "Cannot
connect to peer node".


----- Original Message -----
From: "Gordon Beaton" <>
To: <>
Sent: Tuesday, March 06, 2001 1:39
Subject: Re: JInterface exception handling problem

> On 2 Mar 2001 23:18:35 GMT, Alexis Lê-Quôc wrote:
> > I ran into a problem using Jinterface to send a message to an erlang
> > and I managed to track it down; I attached a small patch which correct
> > exception handling problem. In order to avoid others spending hours on
> > same problem, here's the how and why:
> >
> > I'm using a J-node to send a message using a mailbox to a node called
> >  The erlang emulator has been started with the
> > flag -sname n1 on the machine called  Thus the node
> > will be known by erlang as  This does not look really harmful
of a
> > mismatch but it actually is and the syptoms are that only one message is
> > successfully transmitted to the erlang emulator.
> >
> > In OtpNode.getConnection(String node), since there is no initial
> > between the two nodes, a new OtpCookedConnection will be created and
> > to the connection pool (of the OtpNode) with the name  instead
> >  because in AbstractConnection.receiveChallenge(...)
> > overwrites the peer name which will be subsquently inserted into the
> > connection pool. The new name is extracted from the erlang emulator
> > Nice side effect :-)
> >
> > Thus we end up having the 'connections' member of OtpNode have
> > ...}. And subsequent calls to mbox.send(, ...) will
> > because it'll lookup for the full name and not notice that there is
> > a connection to the node.
> >
> > This is not quite a bug in JInterface, but detecting the problem is
> > particularly difficult because exceptions are black-holed... That's what
> > patch is for.
> Actually there is already a mechanism for notifying the application
> about this kind of exception, they aren't black-holed. See
> OtpNodeStatus.
> However through an unfortunate oversight, OtpNode.registerStatusHandler()
> was declared private so it was impossible to register the necessary
> callback object (this is now fixed). So a simpler patch would be to
> change "private" to "public" in the method declaration.
> /gordon
> --
> [ do not send me private copies of your followups ]
> g o r d o n . b e a t o n @ e r i c s s o n . c o m
> ericsson research
> stockholm, sweden

More information about the erlang-questions mailing list