Improve examples to properly close connections / sessions, even if intended action / transfer couldn't be performed

[ngblume]

It might be a good idea to change the examples to disconnect from the server, even if the intended action (like transfer via SCP) fails, so session are not left active and need to be cleaned up by the SSH server.

Issue encountered during debugging of issue #36...

[volks73]

@ngblume I just looked through all of the examples with respect to this issue. Each example uses the Session:Disconnect.vi, Session:Destroy.vi, and the SSH:Shutdown.vi in the appropriate manner. All of the Close, Destroy, and Shutdown VIs in the toolkit also execute regardless of an incoming/inbound error on the Error In input. For example, see the block diagram of the Session:Disconnect.vi:

The Merge Errors function is used so that the incoming Error bypasses the call to disconnect and ensures the disconnect function is called. All of the Close, Destroy, and Shutdown VIs follow this implementation pattern.

Could you elaborate some more on the issue you were having related to disconnecting and the examples?

I wonder if issue you are having with the examples is a byproduct of loading shared libraries in LabVIEW? LabVIEW will load a shared library and not release it until it is explicitly unloaded and/or the LabVIEW runtime/development environment is shutdown. LabVIEW places a lock on a shared library while it is loaded, which prevent other applications and even other VIs within a project from using the shared library. So, even if the SSH session is properly disconnected and shutdown, the lock on may still be active and the shared library still loaded in memory.

I have repeatedly attempted to explicitly unload a shared library within the SSH:Shutdown.vi implementation and have never been able to get it to work. I have run into this problem on other projects, outside of this toolkit and its related shared libraries, and I have never been able to explicitly unload a DLL/shared library and then reload it without restarting LabVIEW. I have tried the Functional Global Variable (FGV)/Action Engine implementation described in the How to Load and Unload a DLL Dynamically in LabVIEW but it never worked. I suspect that even wrapping the initial Call Library Function node in a FGV is not "the same Call Library Function" node that loaded the DLL. It literally must be the Call Library Function node at the very beginning, meaning it can only happen within a loop and some higher level implementation. Thus, a complete re-design of the Toolkit and API would be needed. I am open to alternatives and implementations that would allow this to happen. Note, I believe this is a Windows-only issue.

References

1. https://forums.ni.com/t5/LabVIEW/How-do-we-unload-a-DLL-with-multiple-different-CLFN/td-p/1221474?profile.language=en

[ngblume]

@volks73 I looked at my code and its effects on the server. When using the following flow, the session were started on the server, but not explicitly closd, but rather closed by timeout from the server side.

When changing the code as follows, this effect disappeared and the sessions were closed immediately, even if the action (in this case, start with SCP), didn't suceed.

That lead me to believe, without further checking in your module, that the non-wiring of the error stooped the unwanted behavior of not actively closing the session. My current SCP VI loks like this:

I'm not sure, if this might be a side-effect from my original SCP-issue...

Cheers Niels

[volks73]

@ngblume Has this also been resolved? It seems like the examples are properly shutting down and the original issue may have been a byproduct of the SCP issue. Can I close?

[ngblume]

@volks73 not really.... I still see a difference when wiring the error through and when not.. It is probably easier to close this issue and I reopen another one, when I have time to investigate what's happening here...