Event Log : Child Service calling Parent Service config

Question

There are two WCF services running on Microsoft Windows Server 2003 R2 (x86) named as:

1. Service A: It's the parent Service.

2. Service B :It's the child Service.

Now, using MCS configuration web we have configured both the services in such a way that A calls B when we have to infer some rules. We are tracing all the logs by enabling System diagnostic logging in configuration files of installed services. As a result we are getting "B.svclog "file for our analysis.

On analysis of this log file for Service B we are getting an exception stating :

 

Could not connect to http://1xx.2x.1xx.7x:9030/service A/config . TCP error code 10061: No connection could be made because the target machine actively refused it 1xx.2x.1xx.7x:9030 .

Please note here it seems that here child service (B)  trying to call parent Service (A) however they are not configured in a such a way by MCS config web that service B has to check the config of service A.

 

Here : 1xx.2x.1xx.7x is server IP on which services are running. 9030 is the port number which the service is using.

We aren't clear that why we are getting such exception where child service is calling parent service?

 

Please let me know if any other information is required.

 

Any help is deeply appreciated.

 

 

Answer 1

A couple of things.

1. When implementing configservices in both client app/service A (parent service) and host service B (child service called by parent service), and using configweb to wire together for load balancing, etc, what is actually happening is as follows:  Your client app/service A is 'subscribing' to a virtualized service host hosting service B.  Config Services provides the virtualization automtaically (meaning, allowing any number of nodes to be spun up on physical machines or VMs that thenparticipate in the virtualized cluster).  You parent app/service A is also virtualized in this manner.  Config Services takes care of all URI mapping between the various A and B nodes, including load/balancing failover when A makes a business service call to B (if a B node has crashed, this is detected before the call is made and request is routed to another B node, if one is available).   To make all this work automagically, when you use ConfigWeb to 'subscribe' A to B, B actually will communicate back to A when a new B node is either started or stopped.  The A nodes then automatically either add or substract that node from the list of available B nodes.  Of course, if a B node crashes (or can't communicate back to A client nodes when it closes), A nodes will keep gracefully failing over to other B nodes that are online, until (configurable) 12 consecutive failed requests to that specific B node, at which points A clients (individually, becuase there may be many virtualized A nodes) on their own remove that unavailable B node from their available list, and stop trying to make requests to it (up until/if it is brought online aain, then. that B node will tell all A nodes, it is available again).  So what you are likely seeing is a communication attempt from a new B node starting up, to tell A node it is available and start using it for requests (this hey I am here message goes to the A config service).  In most on-premise networks when there is no external load balancer, you should make sure this request goes through, so the A nodes can start using the new B node (in case of spinning up a new B node, or a B node network connection temporarily lost, or a B node crash/start again).  Its a non-fatal error if B nodes can't communicate to A nodes via config services, but in this case A nodes will remain completely unaware of new B nodes as they come online and never use them.  A nodes also tell B nodes when a new A node comes online, so that B nodes keep an up-to-date list of all subscribing hosts across virtualized client nodes.  Note that you can also use config services when hosts are 'virtualized' (eitehr A or B) using an external load balancer, like a hardware load balancer or in a cloud environment like Azure.  You use config web to indicate which specific endpoints are to be load balanced by such as externl mechanism, and the 'virtualized IP or DNS name and port to go against.  In all cases, their is also a NODE service (that is built in) that allows virtualized nodes to keep in sync among themselves, such as when a config update is applied.  The node service is separate from the config service, it a separate servicehost that is meant only for private node-to-node communication.

2.  So this is a long summary of some key highlights of how it works.  In a nutshell, you likely have an issue where child B cannot make a config service call back to parent A when B comes online.  You need to discover why you are getting this error, even though it is non-fatal.  If the node A is not online yet, this is to be expected.  When node A does come online, it will discover all available node Bs on its own (again, via config services)--even if this list of B nodes has completely changed since A went down. 

3.  If you set detailed logging=true (default) in the B and A node config repository (they are inherited config settings), and properly setup your event logs (specify the event source again via config setting managed by configweb), you will get rich tracing/logging information in your event log, and can see exactly when and why B is trying to call A's config service.  I *highly* recommend you get your event log sources setup, sot hat this automatic logging can be viewed.  In production, you cam simply set detailed logging to false, and then only exceptions get written (not informational messages).

 

-Greg

 

---

Greg Leake, Microsoft

Answer 2

Also, my note above is assuming A and B are *separate* processes, each with their own config service implementation and distinct sql config repositories.  If A and B are running in the *same* host process (not just same machine, but actually in same windows app), then their is only ONE config service, and it never tries to communicate with itself, only with other virtualized nodes (peer nodes) and that is via the node service.  But again, look at event logs to see all the tracing info.  If I am right pernote above, this is normal and by design, but you need to find out why B cannot find A, ideally, this communication should go through, although again, its non fatal and even expected that in many cases it will not go through (for example, A node(s) not running).

 

-Greg

---

Greg Leake, Microsoft

Answer 3

 In a nutshell, you likely have an issue where child B cannot make a config service call back to parent A when B comes online. Cheap Replica Watches,Replica Swiss Watches

Answer 4

Very good introduction, I will try. Thanks for sharing. The A nodes then automatically either add or substract that node from the list of available B nodes.  wholesale fashion jewelry by the dozen fake Coach diaper bag replica uhren Jaeger Lecoultre master eight days   Omega Replicas   Rolex 16233 fake

Answer 5

Hi Anuj,

In stocktrader application every parent node maintains a list of child nodes. as well as every child node maintain a list of its parent node. you can see it through your config web application.

so when child node crashesh father node removes it from its list after all failed retry attempts & try to balance all traffic to other available nodes as per recovery failure implementation. but when child node alive one more time it again try to reach to father as its list contain address of father.

This scene is only valid for TCP based services as in MSMQ we are not checking the service online status as as per stocktrader design we are just checking the MSMQ while balancing traffic in msmq based service 

---- Amit Saraf

 

 

Answer 6

Also, to be clear, load balancing on premise works for net.tcp; http/https; and also MSMQ.  Failover works for net.tcp and http/https if the host process crashes on any node (or machine dies, etc.).  For MSMQ, failover happens when the MSMQ NT Service is stopped for any reason, independent of whether the actual WCF host bound to MSMQ is active or not.  In this case, messages are persisted to the node's MSMQ store; and when host comes back online, it will begin processing these messages.

 

-Greg

---

Greg Leake, Microsoft

Answer 7

The node service is separate from the config service, it a separate servicehost that is meant only for private node-to-node communication.