we are facing an issue where the RemoteEventServiceEndpoint net.tcp ports stops listening and do not start unless we recycle IIS app pool. CMS is hosted in IIS6. Here are the configurations for your reference:
Everytime publishers try to publish, content does not go live and we have to recycle app pools to bring up the listening ports and ask them again to publish.
May you please help what could we do to resolve this?
Does it work at all?
If not, firewalls are the main suspects...
Restarting iis will also clear cache so then you will always get the latest content
Many thanks for your reply.
Yes, it works always when the front-end server's net.tcp RemoteEventServiceEndpoint port is listening on the server. But due to some reason, the listening ports e.g. 13078 & 13089 as mentioned in my earlier post, stops listening on the server itself (so no firewall problem I guess).
Then to bring these ports up, we have to recycle app pools for the sites and ask the publishers to publish new content again. Caching is not a problem, but random stoppage of these net.tcp ports at front end nodes is.
May you kindly comment on any such known behaviour with net.tcp and how we can get around this issue in EpiServer, so that the ports always keep listening instead of us admins going in the system and recycling the app pools again and again.
Thanks and Regards,
What version of Episerver are you on if you are running on IIS 6. Some old version I guess?
Haven't seen a similar bug myself I'm afraid.
The EPIServer CMS version we are using is 6.1.
If this is a bug or default net.tcp behaviour, I am not sure.
Sounds like a bug.
Could be this one
My advice would be to upgrade to latest cms 6R2 and hopefully this and a few hundred more bugs are solved. If not, contact Episerver and add a support ticket for it.
It seems like that automatic IIS app pool recycles that have been configured on front end nodes, bring down the service ports. Reason, upon recycle, W3SVC is not able to release the older worker process, within default time of 120 seconds, meanwhile, the new app pool process (ASP.Net code in it) which gets created, tries to bind service port mentioned in my post above which fails as the ports are already held by the older process. So I get an AddressAlreadyInUse .Net exception.
A subsequent recycle however, brings the ports up again. So I will have to figure out a way to initiate recycle on AddressAlreadyInUse exception for respective ports.
Have you seen any of the users implementing any better solution to this?