JInterface exception handling problem

Alexis Lê-Quôc alexis@REDACTED
Sat Mar 3 00:18:35 CET 2001


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

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


More information about the erlang-questions mailing list