Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-37422

TCP/IP Module Can not Run Multiple Instances at the Same Time

    XMLWordPrintable

Details

    • Bug
    • Status: In Progress
    • Resolution: Unresolved
    • None
    • ts_main_telescope

    Description

      TCP/IP module can not run multiple instances at the same time. It will fail if I use the asynchronous call to run multiple instances of TcpServer.runServer.vi. At DM-37368, I tried to run two instances at the same time, one for SAL and the other one for GUI. However, only one of them can construct the TCP/IP connection successfully, which depends on which instance I run first.

      The following references are useful for this use case:
      1. Reentrancy: Allowing Simultaneous Calls to the Same SubVI
      2. Asynchronously Calling Multiple Instances of a VI for Parallel Execution
      3. Combining Option Flags into a Single Option Value

       

      My use case is to run two different TCP/IP servers (with SAL and GUI) clients at the same time. Therefore, another option might be allow to listen multiple ports at the same time. The client will need to add the field in the header to identify its role. But I felt this option might make the code complex. We could discuss first to have a good and easy solution if you like.

      Attachments

        Issue Links

          Activity

            I tried to reproduce the problem. After modifying the execution configuration on several VIs like TcpServerBase.runServer.vi and others, I realized this way will complex the code too much, so I need more time to debug and find a solution for this bug. I will prioritize other tickets before continuing with this ticket. I will leave some notes here for my acknowledgment only and future changes:

            I had to set the TcpServerBase.runServer.vi with Shared clone reentrant execution option selected, because reentrant VIs can only have dynamic dispatch terminals if they share clones between instances. After that, the run arrow broke, and the error message recommended to me: “you must either change the terminal in the connector pane to not be dynamic or edit VI Properties to modify the reentrancy behavior.” Then, when I set the Shared clone reentrant execution option, this message appeared: "You have changed priority, execution system, or reentrancy. These changes may break other implementations of this method in the hierarchy. Would you like to make all the implementations match the priority, execution system, and reentrancy of this VI?". I clicked yes. Now the arrow is solid.

            TcpServerCmd.runServer.vi and TcpServerTel.runServer.vi inherited this property, except TcpServer.runServer.vi.

            With this configuration, I can run two instances of TcpServer with different ports, and I can construct two connections from two TCP clients. However, I have problems with the GenRead user event sending generic user events when the connection is closed in any TCP Client. (End of my notes)

            pcortes Patricio Cortes added a comment - I tried to reproduce the problem. After modifying the execution configuration on several VIs like TcpServerBase.runServer.vi and others, I realized this way will complex the code too much, so I need more time to debug and find a solution for this bug. I will prioritize other tickets before continuing with this ticket. I will leave some notes here for my acknowledgment only and future changes: I had to set the TcpServerBase.runServer.vi with Shared clone reentrant execution option selected, because reentrant VIs can only have dynamic dispatch terminals if they share clones between instances. After that, the run arrow broke, and the error message recommended to me: “you must either change the terminal in the connector pane to not be dynamic or edit VI Properties to modify the reentrancy behavior.” Then, when I set the Shared clone reentrant execution option, this message appeared: "You have changed priority, execution system, or reentrancy. These changes may break other implementations of this method in the hierarchy. Would you like to make all the implementations match the priority, execution system, and reentrancy of this VI?". I clicked yes. Now the arrow is solid. TcpServerCmd.runServer.vi and TcpServerTel.runServer.vi inherited this property, except TcpServer.runServer.vi. With this configuration, I can run two instances of TcpServer with different ports, and I can construct two connections from two TCP clients. However, I have problems with the GenRead user event sending generic user events when the connection is closed in any TCP Client. (End of my notes)
            ttsai Te-Wei Tsai added a comment - - edited

            As the discussion, the TcpServer.runServer.vi and others should not be cloned because the user will do the clone at the higher level. Therefore, there should be something else wrong.

            ttsai Te-Wei Tsai added a comment - - edited As the discussion, the TcpServer.runServer.vi and others should not be cloned because the user will do the clone at the higher level. Therefore, there should be something else wrong.
            pcortes Patricio Cortes added a comment - - edited

            This week I’ve been working on this bug testing different configurations in the execution properties of TcpServer LabVIEW project. I found several forums and articles talking about reentrancy in LabVIEW classes. I found this forum on the lavag.org webpage, downloaded the code Test Shared Reentrancy.zip (attached in this ticket), and modified it. I found the followings: 

            • In this example (Test Shared Reentrancy.lvproj) there is a parent class with two child classes, similar to TcpServer project.
            • I created a new class to emulate the TcpServer class, and named it Class C.lvclass.
            • I configured the parent and child classes as non-reentrant execution.
            • I configured the Class C.Count.vi with shared clone reentrant execution.
            • I created the Main2.vi to call two instances of Class C.Count.vi and they work as clones using independent memory space, as expected.
            • Based on this, I only should configure the TcpServer.runServer.vi on TcpServer project with the shared clone reentrant execution, but this change is not enough according to my previous tests. I need to consider this Test Shared Reentrancy.lvproj is simpler than TcpServer code, and there is no shift register or similar if we compare it with the TcpServer code.
            • LabVIEW has unpredictable behavior when you use classes, reentrant VIs, and shift registers, as this article mentions. It says “Avoid combining stateful VI’s [the one that stores data within itself from one call to the next. This is done in LabVIEW using shift registers and feedback nodes] with shared clone dynamic dispatch methods. Store the data between calls using another mechanism such as the class private data itself.”
            • Te-Wei is right in suspecting the shift registers are causing the bug, even though those are initialized.
            • I will continue debugging the TcpServer code supporting me with Rolando's experience in LabVIEW classes and reentrancy. 
            pcortes Patricio Cortes added a comment - - edited This week I’ve been working on this bug testing different configurations in the execution properties of TcpServer LabVIEW project. I found several forums and articles talking about reentrancy in LabVIEW classes. I found this forum on the lavag.org webpage, downloaded the code Test Shared Reentrancy.zip (attached in this ticket), and modified it. I found the followings:  In this example (Test Shared Reentrancy.lvproj) there is a parent class with two child classes, similar to TcpServer project. I created a new class to emulate the TcpServer class, and named it Class C.lvclass . I configured the parent and child classes as non-reentrant execution. I configured the Class C.Count.vi with shared clone reentrant execution. I created the Main2.vi to call two instances of Class C.Count.vi and they work as clones using independent memory space, as expected. Based on this, I only should configure the TcpServer.runServer.vi  on TcpServer project with the shared clone reentrant execution, but this change is not enough according to my previous tests. I need to consider this Test Shared Reentrancy.lvproj is simpler than TcpServer code, and there is no shift register or similar if we compare it with the TcpServer code. LabVIEW has unpredictable behavior when you use classes, reentrant VIs, and shift registers, as this article mentions. It says “Avoid combining stateful VI’s [the one that stores data within itself from one call to the next. This is done in LabVIEW using shift registers and feedback nodes] with shared clone dynamic dispatch methods. Store the data between calls using another mechanism such as the class private data itself.” Te-Wei is right in suspecting the shift registers are causing the bug, even though those are initialized. I will continue debugging the TcpServer code supporting me with Rolando's experience in LabVIEW classes and reentrancy. 

            People

              pcortes Patricio Cortes
              ttsai Te-Wei Tsai
              Patricio Cortes, Te-Wei Tsai
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Jenkins

                  No builds found.