Indirect termination of child server ineffective

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a parent server.
2. Create a child server.
3. Start Admin, connect to parent server.  Terminate the child server.

What is the expected output? What do you see instead?
I would expect the child to go away, and it does at first.  Then its 
reconnection logic activates, and it reconnects to the parent.

The parent server should forward the termination command to the child.  It 
appears that at this time the server simply stops its local interface to 
the child.  Disconnecting the child should be a separate action.

Original issue reported on code.google.com by enfield....@gmail.com on 20 May 2009 at 3:10

[GoogleCodeExporter]

I confirmed this problem.

Note that we are talking here about terminating the *connection* between the 
parent
and child, not terminating the child server itself.  (In order to terminate the 
child
server, the user must connect Admin to the child and then select Terminate.)

Once the connection has been terminated, the child server is "overly aggressive"
about reconnecting to the parent server.  Thus, the connection is initially
terminated, but then the child server goes into a "reconnect" mode and starts 
the
connection up again with the parent.  This is desirable behavior for dealing 
with
unreliable networks, but not for when the user explicitly wants the connection 
severed.

The code in question is in com.rbnb.api.ParentServer, method lostRouting().

Original comment by john.wil...@erigo.com on 20 May 2009 at 4:09

[GoogleCodeExporter]

I reiterate that it is confusing to "Terminate" a server, when really you are 
just 
disconnecting it from routing.  I also fail to see why you should need a direct 
connection to a server in order to terminate it.  That certainly doesn't 
facilitate 
remote administration of distributed networks.  It may not even be possible 
with 
some network topologies.

Perhaps the simplest fix here is to relabel the command "Disconnect" when child 
servers are in question.

Original comment by enfield....@gmail.com on 20 May 2009 at 5:15