MySQL Bugs: #52566: ndbinfo.transporters vs. docs when remote_node

Bug #52566	ndbinfo.transporters vs. docs when remote_node_id is not connected
Submitted:	2 Apr 2010 23:34	Modified:	4 May 2014 6:45
Reporter:	John David Duncan	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Cluster: Documentation	Severity:	S3 (Non-critical)
Version:	mysql-5.1-telco-7.1	OS:	Any (Mac OS X 10.5, Linux)
Assigned to:	Jon Stephens	CPU Architecture:	Any
Tags:	7.1.3, ndbinfo

Description:
The documentation at http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbinfo-transporters.html reads "Connections to API and management nodes which are configured but not currently connected to the cluster are shown with status DISCONNECTED." 

In fact, however, if nodes 5, 6, etc. are not connected, we actually see CONNECTING rather than DISCONNECTED: 

mysql> select * from transporters ;
+---------+----------------+--------------+
| node_id | remote_node_id | status       |
+---------+----------------+--------------+
|       2 |              1 | CONNECTED    |
|       2 |              2 | DISCONNECTED |
|       2 |              3 | CONNECTED    |
|       2 |              4 | CONNECTED    |
|       2 |              5 | CONNECTING   |
|       2 |              6 | CONNECTING   |
 ...

(only the connection from 2 to 2 is "DISCONNECTED," which is kind of weird.  And I see this on my machine even though the example in the manual definitely shows CONNECTED here).

Here are some possibilities:

(1) The transporter is actually listening for a new connection, CONNECTING is the correct state, and the docs are wrong.
(2) TransporterRegistry.cpp has a bug where it's setting its state to CONNECTING even though the remote node does not exist. 
(3) ndbinfo.transporters already filters on node_id for nodes that do not exist, but it should also filter on remote_node_id. (I think this is debatable...) 

How to repeat:
Create a cluster.
Create more nodes in config.ini than actually connect.
> select * from ndbinfo.transporters ;

Thank you for the report.

Verified as described.

Posted by developer:
 
This bug is regarding the state of transporter connections vs how those are documented in the manual.

> (1) The transporter is actually listening for a new connection, CONNECTING is
> the correct state, and the docs are wrong.

^ Yes, the transporters will always go back to state CONNECTING as soon as the disconnect of the old node has completed.

Solution: The documentation should be updated to reflect that CONNECTING is the normal state for connections to node which are not started.

Note! The output also shows(peculiar) connection to own node, i.e 1<->1 or 2<->2 which is always DISCONNECTED. If that is annoying please file new bug asking for own node connections to be removed from the output. Should be filtered inside the ndbd.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".