After a discussion with Te-Wei about how to solve this bug, we decide to use this ticket to test the option to use named notifiers. We realized that this option considers too many changes in the code, and we don't want this. I created the ticket DM-40302 in phase 2 to implement Te-Wei's idea using a Factory pattern to let users instantiate multiple Tcpserver classes.

Good test is done in this ticket. The phase 2 ticket should resolve the issue. Great job done!

The suspicion of root cause in this ticket is the restriction of occurrence in LabVIEW, and therefore, the use of notifier is proposed. If multiple instances of TcpServer class are required, the multiple different notifiers would be required as well. However, NI uses the singleton for the notifier and the memory replication for multiple instances are not allowed. Therefore, for each different TcpServer instance, it will need to hold different notifier object, which is identified by the name, compared with other TcpServer instances.

In this case, if we want to have two instances of TcpServer, we need to have two different notifiers with the name of: name_1, name_2, ..., etc. The original proposal is that the user need to actively label the TcpServer with different names such as A, B, ..., etc. However, the user might label the names of TcpServer incorrectly to have the same names. If this happens, when one of TcpServer objects issues the notifier, the other TcpServer will be affected if it has the same labeled names.

Therefore, we propose to have a Factory class to let user to create the new TcpServer object. The detail of labelling is hidden in the create() method to make sure each new instance of TcpServer class will have a unique label name. By hiding such kind of implementation details, the developer can add more similar details in this new create() method in the future when needed and the user will not notice this. The other benefit is to minimize the affection of current running applications because the user only needs to modify the way how he/she instantiates a new object of TcpServer.

Another implementation detail is that the TcpServer class should hold the object of notifier instead of its name. By doing this, the developer can minimize the affection of singleton property of notifier. The read of notifier can avoid the overhead of "obtain notifier.vi" as well to improve the performance.