JInterface exception handling problem

Alexis Lê-Quôc alexis@REDACTED
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
AbstractConnection:doConnect().

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".

Cheers,

Alexis
----- Original Message -----
From: "Gordon Beaton" <not.for.email@REDACTED>
To: <erlang-questions@REDACTED>
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
node,
> > and I managed to track it down; I attached a small patch which correct
an
> > exception handling problem. In order to avoid others spending hours on
the
> > 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
> > n1@REDACTED The erlang emulator has been started with the
> > flag -sname n1 on the machine called n1@REDACTED Thus the node
> > will be known by erlang as n1@REDACTED 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
connection
> > between the two nodes, a new OtpCookedConnection will be created and
added
> > to the connection pool (of the OtpNode) with the name n1@REDACTED instead
of
> > n1@REDACTED 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
reply.
> > Nice side effect :-)
> >
> > Thus we end up having the 'connections' member of OtpNode have
{'n1@REDACTED':
> > ...}. And subsequent calls to mbox.send(n1@REDACTED, ...) will
fail
> > because it'll lookup for the full name and not notice that there is
already
> > 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
the
> > 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