Re: Question about connecting to a node and proposed patch

Hi Matthias,

Matthias Radestock <[email protected]> writes:

> Bill Clementson <[email protected]> writes:
>
>> So, how do you work with remote nodes? Do you manually load the distel
>> modules in them (or have a .erlang file or remote script set up on the
>> remote machine)?
>
> I have the distel code and a suitable .erlang file on the remote
> machines.
>
> I'd love to use the new distel code loading feature, but we have to make
> it work first.

Have you tried debugging the erl-check-backend call to determine why
it's failing to load the distel beam files on the target node or do
you have any clues as to why it's not working (other than the badrpc
messages)?

>> Why would you want to use "C-c C-d n" to select a node that hasn't
>> been started?
>
> I use "C-c C-d n" for its documented purpose - to select "the nodename
> to connect to in future.". So, for example, I often use the same node
> for a long time and frequently restart it, and don't want to have to
> think about / find out whether the node is up or down when typing "C-c
> C-d n".

But, since all "C-c C-d n" seems to do is change the current node that
distel deals with and update the node name in the mode line, I'm not
quite sure I understand the exact use case you're describing and why
you think my patch will prevent you from doing this. In any case, with
the patch that I sent in my last email, all that will happen if the
remote node isn't up is that you'll get a nodedown message in your
*Messages* buffer and another message in the *Messages* and minibuffer
with the Erlang error. For example, if I try to connect to "bc@xx" (a
non-existant node), I get the following messages:

nodedown: bc@xx
EXIT: <0.2.0> [emacs-error "(error \"xx/4369 No address associated with nodename\")"] 

But, these are just messages and the erl-nodename-cache variable and
erl-target-node function both still show "bc@xx" as the "active"
node. Therefore, functionally, my patch will not prevent you from
doing what you currently do when connecting to nodes. You can still
use "C-c C-d n" to connect to a node that is down, subsequently start
it, and interact with that node.

However, I agree that my patch doesn't deal with nodes that are
bumped/restarted. But, this is only an issue if you're using the
distel code loading functionality (which doesn't work for you). If
you've got the distel modules in your erlang code path, then you are
functionally no different from where you are today (except that, for
those of us who can use the distel code loading functionality, we do
get automatic loading of the distel modules in remote nodes without
having to setup the erlang path).

>> If it is a race condition, loading the distel modules into the node
>> when erl-choose-nodename is run will avoid this.
>
> Sure, but it's the wrong place because it a) changes the documented (and
> useful) semantics of erl-choose-nodename, b) requires that you use
> erl-choose-nodename to connect to nodes rather than connection happening
> as required when running some other command.

As I note above, it does not prevent you from connecting to a node
that is not "up". It just puts a message in the minibuffer and
*Messages* buffer. It does do the "ping" to see if the node exists
and, if the distel modules aren't loaded, it loads the distel
modules. In your case (since you load the modules in your remote
.erlang file), it would just display a message in the minibuffer that
it had successfully communicated with the node).

> The distel code should be loaded onto the node when the connection is
> initiated, which happens the first time you actually try to do something
> that requires the node to be present, e.g. toggle interpretation, set
> breakpoints, list processes. Also, overall the distel mode should be
> quite immune to node restarts - just as it is currently when the distel
> code is on the erlang load path - e.g. if I bounce a node and then
> toggle interpretation I expect it to work first time, and not have to
> toggle twice or use "C-c C-d n" to reselect the node.
>
> We should figure out what is causing these problems with distel code
> loading. 

I guess there are actually at least 2 (probably separate) issues:

1. Distel code loading is not working for you at all (although it 
   does work fine for me)
2. There appears to be something (possibly a race condition) that is
   preventing the first distel command from executing if distel 
   modules haven't been loaded into the node yet.

> As a stop-gap solution, may I suggest another key-bound command
> "erl-ping" which executes the erl-spawn call from your patch on
> (erl-target-node), i.e. it will work like most other distel commands by
> prompting for a node if none is currently selected and performing the
> action (in this case a call to erlang:node()) on it. 

I dislike having a separate "erl-ping" function as it is something
that one has to manually do (and know when to do it).

> Alternatively, you
> could just make erl-check-backend interactive and bind it to a key.

Making erl-check-backend interactive won't work as the fsm setup won't
have been done yet for the node. That's why I did the erl-spawn
instead as the fsm setup is done the first time there is a distel
communication with the node.

I'll see if I can figure out why issue #2 is occurring. If you (or
anyone else reading this) wants to look for it too, you can test it
easily enough by:

1. Remove the distel path from your local .erlang file
2. Connect to a local node with "C-c C-d n" 
3. Press "C-c C-d l" to diplay erlang processes 

Since in #3, the distel modules won't have been loaded into the node
yet (and they won't be in the code path for the node), they will be
loaded and the "C-c C-d l" action will not be executed. So, the race
condition or scheduling conflict or whatever is causing this problem
will be occuring at this point.

Hopefully, we'll be able to track this one down (although I've found
that race conditions can sometimes be pretty hard to debug, especially
if there are multiple languages).

- Bill


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