Re: Question about connecting to a node and proposed patch

Hi Matthias,

Matthias Radestock <[email protected]> writes:

> Bill Clementson <[email protected]> writes:
>
>> One of the things that tends to bug me a bit is that, when I connect
>> to a node for the first time, the distel modules aren't loaded into
>> that node until you actually attempt to communicate with the node
>> (e.g. - display processes with "C-c C-d l" or reload a module with
>> "C-c C-d L"). At that point, the distel modules are loaded into the
>> node and you get a message stating "(Successfully uploaded backend
>> modules into node)". However, the action that you attempted (e.g. - if
>> you pressed "C-c C-d l" to display processes) is not actually executed
>> because the distel modules hadn't been previously loaded. Obviously,
>> this issue has bugged a number of other people in the past too as
>> there are a couple of similar messages on the mailing list and an
>> enhancement request on the google code distel web site
>> (http://code.google.com/p/distel/issues/list).
>
> I do not experience this problem - C-c C-d C-l and others work first
> time round for me, every time.

For me, every time I switch to a new node, I have to do the first
"distel action" twice - once to load the distel modules and once to
actually perform the action. However, see below.

> Do you have distel in your erlang load path, e.g. did you add it to
> ~/.erlang? I do, but there is a recent enhancement where that supposedly
> is no longer necessary. Perhaps you are using that new feature. However,
> it doesn't work for me at all - I just get a "badrpc" error all the
> time - so I have continued using the established way.

Aha! This is the problem and the explanation for why you and I get
such different behavior for the same test cases. I've only been using
distel for a few weeks, and one of the first things that I did was
read through the changelog to see what things had changed from the
documentation (the actual user manual is pretty up-to-date; however
Luke's EUC paper and the reference manual haven't been updated). When
I saw this 2007-02-27 entry:

	* elisp/erl-service.el (erl-check-backend, &erl-load-backend):
	If the Erlang node does not have the Distel modules available in
	the code path then patch them in directly as binaries using RPC.
	Now you don't have to bother adding Distel to the code path and
	should be able to connect to any Erlang node (e.g. on a target
	system).

then I removed the distel path statement from my .erlang
file. Everything appeared to work the same at the time. Over time, I
noticed the problem with distel modules not being loaded until I did
some other operation but thought (incorrectly) that it was behaviour
that had existed previously as well.

I've just added the distel path to my .erlang file and tried
connecting to a new node and things work fine now (e.g. - I no longer
have to initially do the first operation twice). Also, debugging works
fine with interpreted being toggled properly. 

So this accounts for the differences in behaviour that we were
experiencing.

>> Is there some reason why the uploading of distel modules to a node
>> shouldn't occur when you first connect to a node?
>
> That is what is supposed to happen, and it works for me.
>
>> I couldn't think of any good reasons not to, so I've made a patch to
>> erl-choose-nodename.
>
> erl-choose-nodename is not meant to connect to the node, so this is the
> wrong place to fix this problem.

Although adding the distel path to the .erlang file eliminates the
problems I was encountering, I think the patch (or something similar
that only does the erl-spawn operation in erl-choose-nodename when the
node is a remote node) might still be appropriate since having the
distel path in the .erlang file will only solve the problem when
you're connecting to a local node. 

If you try the test cases that I outlined in my previous messages with
a remote node, you should see the same behaviour that I was seeing
locally (before I added the path to my .erlang file). Therefore, there
is probably still a case for doing the initial erl-spawn in
erl-choose-nodename.

> Looking at the code, I believe the distel module loading happens via the
> following hook:
>    (add-hook 'erl-nodeup-hook 'erl-check-backend)
> I wonder whether there is a race condition which results in this hook
> being invoked too late when you first connect.

In stepping through the code, I noticed that the hook was only being
called when the first communication occured with the node (not as a
result of erl-choose-nodename). I added the erl-spawn to
erl-choose-nodename so that this would occur. Is there any reason why
this code shouldn't be in erl-choose-nodename (perhaps with a
modification to just execute the code for remote nodes)? Also, is
there any standard way to test whether a node is local or remote (or
do people normally just compare the values after the "@")? 

--
Bill Clementson


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/