Go Back
1 Vote

synxfpng Utility Should Be Enhanced to Attempt To Invoke xfpl.dbr


Closed

The context of this ask is Case #99811 wherein an incorrect configuration on a test machine (missing the xfSeries feature on the 32bit installer) caused the following error when attempting to perform any xfServerPlus call: 

System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at Synergex.xfnlnet.XFProtocol.sendLaunchRequest()
   at Synergex.xfnlnet.XFProtocol.requestLaunch(String host, Int32 port, Int32 minport, Int32 maxport)
   at Synergex.xfnlnet.XFProtocol.startup(String host, Int32 port, Int32 scl)
   at Synergex.xfnlnet.XFConnect.connect(String host, Int32 port, Int32 scl)
   at Synergex.xfnlnet.XFNet.loconnect()
   at Synergex.xfnlnet.XFNet.connect(String hostIP, Int32 hostPort)

The root cause of this was tracked down to the xfSeries feature not being installed on the 32-bit Synergy Installer. It was however installed on the 64bit installer.

This caused confusion in CU's deployment, this is because we run in a mixed mode environment. Modern versions of Windows Server only ship in 64bit, therefore you need to have the xfServerPlus Service installed by the Synergy 64bit runtime in order to have xfServerPlus run as a service. HOWEVER CU then hacks XFPL_DBR=1 and DBLDIR to tell the xfServerPlus service to use the 32bit runtime.

One of the first things the rsynd process will do upon successful connection is attempt to open up xfpl.dbr to host up Traditional Synergy Code. However when you do not have the xfSeries feature installed for the 32bit runtime this dbr WILL NOT exist, which causes the application to immediately exit returning this error.

HOWEVER the Synergex supplied test program (synxfpng) DOES NOT attempt to run TRADITIONAL SYNERGY code. Instead all it does is attempt to validate that rsynd is responding rather than check for the above misconfiguration.

CU has fixed its configuration issue, but to assist in debugging it would be helpful if synxfpng was enhanced to attempt to run traditional code, kicking out the missing xfpl.dbr

3 Comments | Posted by Ace Olszowka to xfServerPlus on 4/15/2020 9:29 PM
Steve Ives
While we consider your actual request, this might be an alternative. Assuming you leave the standard "xfTest" methods in your method catalog, you could use one of the specific xfServerPlus test programs to verify the ability to run Synergy code:

D:\>dbs dbldir:xfnlstst localhost 2356
DBL/MS-WINDOWS Version 11.1.1c
Running xfServer connection tests for:
Machine: localhost
Port: 2356

Test 1. xfpl_tst1.
Test 1 successful!
Test 2. xfpl_tst2.
Test 2 successful!
Test 3. xfpl_tst3.
Test 3 successful!
Test 4. xfpl_tst4.
Test 4 successful!
Test 5. xfpl_tst5.
Test 5 successful!
Test 6. xfpl_tst6.
Test 6 successful!
Test 7. xfpl_tst7.
Test 7 successful!
Server: DBL/MS-WINDOWS Version 11.1.1c

If xfpl.dbr is missing then you will see this:

D:\>dbs dbldir:xfnlstst localhost 2356
DBL/MS-WINDOWS Version 11.1.1c
Running xfServer connection tests for:
Machine: localhost
Port: 2356

Could not start remote session.
status = 10054.
 

4/16/2020 4:30 PM   0  
Steve Ives
In speaking with a colleague on this, I was reminded that the synxfpng utility is essentially just an IP socket test that is doing little more than looking for a response from a socket. It doesn't have any knowledge of the xfNetLink protocol. As mentioned in my earlier response, there are other tools specifically for testing the actual operation of an xfServerPlus environment, including starting a DBR process, executing various methods, and validating the responses from those methods. There are two such utilities:
  • xfnlstst.dbr
  • xfspltst.dbr
Both of these are used as shown in my earlier response and produce similar results. The difference between the two is that the xfnlstst program uses xfNetLink Synergy to interact with the server, whereas xfspltst uses the socket API to do the same thing.

Using one of these two utilities is the recommended way to verify that an xfServerPlus instance is working, but it still does not verify that YOUR ENVIRONMENT is configured and working. You might want to consider writing and shipping your own xfServerPlus test program and have it actually call into some of your ELB's, open, interact with some of your data, etc. That would be the best possible way to actually validate the operation of your full environment.

4/16/2020 5:14 PM   0  
Ace Olszowka
> You might want to consider writing and shipping your own xfServerPlus test program and have it actually call into some of your ELB's, open, interact with some of your data, etc.

We wrote that tool; that is what kicked this out.

Unfortunately we got this as the error back from xfServerPlus (this is the stack trace above): 
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

This error is less than useless; because the error would indicate several other possible errors:
  1. The service is not running
  2. There is a Firewall Blocking the Service
  3. There is a TLS Mismatch (ie TLS 1.2 usage)

Nothing indicates that this is a configuration issue of the xfServerPlus instance because you die in (what I have named) the Synergex Provided xfServerPlus bootstrapping process (which does not appear to be documented*) which occurs prior to even touching customer code.

synxfpng is a useful utility in that it rules out the 3 above as an issue. Normally you would think this means that it is customer code; unfortunately that is not the case.
 

*Because this process is not documented that is the meaning of this section:

One of the first things the rsynd process will do upon successful connection is attempt to open up xfpl.dbr to host up Traditional Synergy Code. However when you do not have the xfSeries feature installed for the 32bit runtime this dbr WILL NOT exist, which causes the application to immediately exit returning this error.
I will put forth another idea to get this documented, it is only alluded to in various documents.

We need something that tests the Synergex Provided xfServerPlus bootstrapping process, that is the ask here, not for you to test our code, but for some way for us to test YOURS. The suggestion is to improve synxfpng to cover this, but it does not need to be that tool.

> Assuming you leave the standard "xfTest" methods in your method catalog
This gets closer, but unfortunately I do not believe that we would have this in. Rather, in my opinion, based on the available information it seems like xfpl.dbr should be enhanced to have these endpoints to be tested in the way you describe.

4/16/2020 5:41 PM   0  
Please log in to comment on this idea.