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

[2 Apr 2010 23:34] John David Duncan
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 ;
[3 Apr 2010 9:37] Sveta Smirnova
Thank you for the report.

Verified as described.
[3 Apr 2014 12:24] Magnus BlÄudd
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.
[5 May 2014 1:00] Bugs System
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".