JInterface exception handling problem

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JInterface exception handling problem

Alexis Le-Quoc
Hello,

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 The erlang emulator has been started with the
flag -sname n1 on the machine called n1 Thus the node
will be known by erlang as n1 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 instead of
n1 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':
...}. And subsequent calls to mbox.send(n1, ...) 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.

-- Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Exception.diff
Type: application/octet-stream
Size: 608 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20010302/480c4539/attachment.obj>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JInterface exception handling problem

Gordon Beaton
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 The erlang emulator has been started with the
> flag -sname n1 on the machine called n1 Thus the node
> will be known by erlang as n1 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 instead of
> n1 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':
> ...}. And subsequent calls to mbox.send(n1, ...) 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JInterface exception handling problem

Alexis Le-Quoc
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>
To: <erlang-questions>
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 The erlang emulator has been started with the
> > flag -sname n1 on the machine called n1 Thus the node
> > will be known by erlang as n1 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 instead
of
> > n1 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':
> > ...}. And subsequent calls to mbox.send(n1, ...) 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
>



Loading...