Separate Cache Host Process
Previously, the NCache service and all cache instances were confined within one single process. This meant that if the process crashed, the service along with the caches and their resource information (memory, addresses, ports) were lost.
NCache has now provided more reliability by dedicating a separate process to the service and a devoted process to each cache host.
Note
This feature is also available in NCache Professional.
Client Communication with the Cache
The initial communication of the client with a cache host is a 2-hop communication:
It first interacts with the service, which connects the client to the cache host using the port forwarding mechanism.
It then communicates with the cache using port forwarding. All future interactions for the client are made directly with the cache.
When a cache is started in its own separate process, it is assigned a Management Port on which the service will communicate with it. This port is dynamically generated from a range (default 8300 – 8400, configurable in service.exe.config).
Note
Note that in case of the Partition-Replica topology, two ports will be assigned.
Once the port has been forwarded, the client will send all cache requests to the cache, like adding items to the cache, or fetching or removing them from the cache.
In case one of the cache host processes stops, the ports being used by that cache for communication are added back to the pool of available ports. For example, if a Partition-Replica node was using ports 8301 and 8302 and the process terminates, the ports will become available for use by any other cache. Now when a process starts for a new cache, port 8301 can be reused for this cache.
Formerly, once a port was assigned to the cache, it was considered as utilized - regardless of the cache state. This meant the port range was narrowed down involuntarily.
Server Communication with the Cache
The server communicates with the cache host on the Management Port that is dynamically generated. All management operations are channeled through this pathway.
What if the service restarts?
In the case where the service restarts, the cache processes will not be lost but the need to rediscover their previous states will arise. This means that the service has to ensure which caches were running before it crashed, along with their credentials like Process ID, Port, and so on. This rediscovery, as a result, warrants that the cache processes are not in a zombie state.
There are two tools used for rediscovery:
Windows Management Instrumentation Service (WMI)
A standardized service to access, consolidate, and share management information of devices, applications, and servers in an enterprise environment. You can either run the winmgmt.exe tool or the command line tool wmic to get information regarding the service.
Example:
wmic PROCESS WHERE (Description=”Alachisoft.NCache.Service.exe”)
You can work with multiple other commands using the Windows Management Instrumentation Command Line Tool.
netstat tool
This command-line tool displays network connections for incoming and outgoing TCP communications, routing tables, and network protocol statistics. You can rediscover your lost information about the caches by viewing the active connections and ports being utilized. Any ports within the port range of service.exe.config will indicate the cache hosts using the ports.
Example:
netstat –o will display the local address, foreign address, state, and Process ID of each active connection.
More details regarding this tool can be obtained from Microsoft’s Technet page.
See Also
Graceful Node Down
Self Healing Dynamic Clustering
IP Binding with Multiple NICs
Split-Brain
