- This topic has 3 replies, 2 voices, and was last updated 10 years, 3 months ago by
.
-
Posts
-
Hi,
My application is build as the following:
* There are worker processes. Each worker process hosts a service accessible by a mean of communication.
* This is one master process that connects to each of the worker processes by that same mean. It is materialized by a class that abstracts the concept that the code is running on a remote domain by starting a worker process and communicating with it.Result: this mean of communication is completely seamless and abstract to my top level classes and to the main project that basically only composes the application parts.
When I used WCF, disposing my client connections was done internally by simply disposing the proxy classes. Now using NetworkComms I do something similar, I dispose the TCPConnection object which works fine… until I want to terminate my application! At that moment, my main project would need a reference to NetworkComms to call NetworkComms.Shutdown(). I went around this by creating an extra layer of abstraction by using a factory to create my proxy classes and then at disposal of that factory call the NetworkComms.Shutdown().
It’s all fine and not a blocking issue, but I’m wondering about the motivations behind this. Can you tell me more about it?
Best regards,
David
Heya David,
The motivation behind NetworkComms.Shutdown() was:
1. Ensure all open connections are gracefully closed.
2. Ensure all worker threads are shutdown.The background worker thread is the big one really. NetworkComms.Net can make use of either synchronous or asynchronous communication methods via NetworkComms.ConnectionListenModeUseSync. Other features such as NetworkComms.CurrentNetworkLoadIncoming may spawn background threads.
To ensure that regardless of what had taken place during the lifetime of an application, it could close correctly, we created a method that would do any necessary clean-up.
Hope that answers the question.
Kind Regards,
MarcHi Marc,
I was expecting that answer. But I’m wondering why I need to call it if I properly disposed all my connections? Why would NetworksComm expect anything incoming in that case?
Best regards,
David
Sorry I forgot to add that other core features involve background threads such as incoming connection handling (if listening), connection keep alives, and incoming packet thread pool etc. Looking at the source I don’t think it’s possible to get away without calling Shutdown() for version 2.3.1.
I do like the idea of under the majority of circumstances NetworkComms.Net, particularly if not listening, can shutdown without needing to call Shutdown though.
We are currently working heavily to get a Beta out of the next release and probably won’t get a chance to look at this before then but I will add a post to the feature request forum as a reminder.
Marc
- You must be logged in to reply to this topic.