Resolution:
The following is specified in an rtserver.cm file

setopt multi_threaded_mode true
setopt server_threads    1
setopt client_threads    2
setopt server_connection_names    /conn_*, /smartsockets/...


The RTserver is launched and an RTclient connects to the RTServer. The RTserver trace_file shows that the RTclient with a unique_subject of “conn_1” first gets a client connection:

TAL-SS-10032-I RTclient {'RTclient', 'conn_1', '_node', pid, user, platform, 78} UP.
TAL-SS-10113-I SVC UP Handler: Placing SVC on &ltClient> thread pool.

If the client gets disconnected from RTserver and then reconnects the RTserver trace_file shows that the RTclient now gets a server connection.

TAL-SS-10032-I RTclient {'RTclient', 'conn_1', '_node', pid, user, platform, 78} UP.
TAL-SS-10113-I SVC UP Handler: Placing SVC on &ltServer> thread pool.

Why is this?

Briefly:
This problem is caused by the fact that the server is checking the unique_subject setting before it has been updated with the default subject prefix. The reconnect then has the default_subject_prefix on the unique_subject and the match is now different. This issue will be addressed in a CFIX for SmartSockets 6.8 .

Detail and work around:
When an RTprocess (client or server) connects to an RTserver for the first time, if the process does not specify the default subject prefix in front of its unique_subject setting (usually /), then the first time the RTprocess connects the RTserver will check it without the prefix. RTserver then passes an updated unique_subject back to the RTprocess when the connect succeeds, so now a / is prepended  to the processes unique_subject. When the RTprocess gets disconnected, and then reconnects, it passes the updated unique_subject because now it has the / in its unqiue_subject so the RTprocess's unique_subject will match the server_connection_names StringList .


The work around is to have each subject set listed twice; once with, and once without, a leading '/'?

Example:

setopt server_connection_names /smartsockets/…,smartsockets/…

OR in your RTclient set the following making sure to use the default subject prefix when defining the unique_subject:

TutCommandParseStr(“setopt unique_subject /smartsockets/RTclient_Foo");

RTclient is supposed to get a Server connection to RTserver but gets a Client connection instead.