AddressAlreadyInUseException with TCP Event configuration

henriknystrom

Vote:

Hi all,

Having some troubles with getting TCP event communication going properly. Well, it works good, but every time the application needs to restart, for example when the web.config is saved I get the dreaded:

System.ServiceModel.AddressAlreadyInUseException: The TransportManager failed to listen on the supplied URI using the NetTcpPortSharing service: the URI is already registered with the service.

It only last for between 20-60 sec, but that is enough for it to be an issue in production.

Portsharing is turned on and I have disabled overlapping application pool recycling.

The following is the service model config:

  <system.serviceModel>
    <services>
      <service name="TodayNetwork/EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding"
          bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13000/RemoteEventService"/>
      </service>
      <service name="TripleMNetwork/EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding"
          bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13001/RemoteEventService"/>
      </service>
      <service name="Dirt/EPiServer.Events.Remote.EventReplication">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding"
          bindingConfiguration="RemoteEventsBinding" address="net.tcp://localhost:13002/RemoteEventService"/>
      </service>
    </services>
    <client>
      <endpoint name="TodayNetwork.PI" address="net.tcp://172.22.240.45:13000/RemoteEventService" binding="netTcpBinding"
        bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
      <endpoint name="TripleMNetwork.PI" address="net.tcp://172.22.240.45:13001/RemoteEventService" binding="netTcpBinding"
        bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
      <endpoint name="Dirt.PI" address="net.tcp://172.22.240.45:13002/RemoteEventService" binding="netTcpBinding" bindingConfiguration="RemoteEventsBinding"
        contract="EPiServer.Events.ServiceModel.IEventReplication"/>
      <endpoint name="TodayNetwork.PD1" address="net.tcp://172.22.240.44:13000/RemoteEventService" binding="netTcpBinding"
        bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
      <endpoint name="TripleMNetwork.PD1" address="net.tcp://172.22.240.44:13001/RemoteEventService" binding="netTcpBinding"
        bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication"/>
      <endpoint name="Dirt.PD1" address="net.tcp://172.22.240.44:13002/RemoteEventService" binding="netTcpBinding" bindingConfiguration="RemoteEventsBinding"
        contract="EPiServer.Events.ServiceModel.IEventReplication"/>
    </client>
    <bindings>
      <netTcpBinding>
        <binding name="RemoteEventsBinding" portSharingEnabled="true">
          <security mode="None" />
        </binding>
      </netTcpBinding>
    </bindings>
    <behaviors>
      <serviceBehaviors>
        <behavior name="DebugServiceBehaviour">
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
  </system.serviceModel>

#61235

Sep 12, 2012 14:16

Magnus Claesson

Vote:

Did you ever solve this, I have the exact same problem as you! Portsharing enable, disable overlapping recycle, and the sites working fine but goes down when restart, very annoying!

#61924

Oct 05, 2012 16:49

Erik Zetterstedt

Vote:

We had our fair share of that problem, the solution for us was to do the automatic site mapping manually. Kind of backward, but it is what it is..

This is an example of the config that should be in EPiServerFramework.config

<episerver.framework>
<automaticSiteMapping>
<add key="/LM/W3SVC/18100/ROOT:THEMACHINENAME" siteId="MySite" />
<add key="/LM/W3SVC/18400/ROOT:THEMACHINENAME" siteId="MyOtherSite" />
</automaticSiteMapping>
</episerver.framework>

18100 and 18400 is the IIS site id, you also need to replace THEMACHINENAME with the name of the actual machine.

Hope that works out.

#62196

Oct 16, 2012 15:28

Tore Lervik

Vote:

Any permanent fixes to this? We see the same problem in production on our site.

#66015

Feb 18, 2013 14:30

Frederik Vig

Vote:

Tore, I think EPiServer Support has a hotfix for it.

Frederik

#66021

Feb 18, 2013 16:32

Paul Middleton

Vote:

Hi,

Can anyone point me in the right direction regarding this issue please? Were currently experiencing this on our production environment.

Thanks

#86365

May 20, 2014 12:54

Tore Lervik

Vote:

We fixed this by recycling the application pool right before we deploy. After might also work.

Best case is if you turn the app pool off, deploy and then turn it back on.

#86366

May 20, 2014 12:59

roxana.todoran

Vote:

Hi,

We are seeing this issue after around 4h after the net.tcp configuration changes are deployed. Client is having 2 servers: 1 public web server for the webste and 1 admin server for doing CMS updates. Exception occurs on the public web server.

I've already tried setting disable overlapped recycling to true, stopping the application pool and restating it after the deploy, recycling the application pool, and nothing seems to work. If we recycle the application pool for the web server, website is still down. If we recycle the application pool for both servers, public website becomes functional for ~ 30 min.

Any idea?

Thank you,

Roxana

#144964

Feb 23, 2016 12:22

Henrik Fransas

Vote:

We also had this problem a lot when using TCP but not UDP so if it is possible to change to UDP it could be a solution.

For us we did a IIS Reset after each deploy since the site was pretty much the only thing on that server and that solved it, but it was not a good solution.

#144966

Feb 23, 2016 12:40

roxana.todoran

Vote:

Hi Henrik,

Unfortunatelly, UDP is not an option since the web server is in a DMZ and the firewall prevents the CMS server updates to propagate to the web server via UDP.

I didn't try IIS Reset. I know we exprienced this issue before on another project and stopping and restarting the app pool on every deploy seemed to do the trick. However, here it doesn't seem to work.

Appreciate your help.

Roxana

#144970

Edited, Feb 23, 2016 13:10

Henrik Fransas

Vote:

The problem is that the IIS are a little "slow" to relase the existing connections and when you doing a IIS reset you force IIS to relase everyhing.

Propably you can only restart the site and not the whole server. We also tried only application pool but didn't get it to work.

I reported it as a bug to Epi but I think the response was that they are doing what can be done but I do not remember exactly.

I was trying out to use a service bus (azure nuget package) to get rid of the tcp but at that time there were some problem with that implementation.

I will try that out and write a blog post on it, since it should be the best solution I think

#144971

Feb 23, 2016 13:15

roxana.todoran

Vote:

Thank you for the details. I will let you know as soon as I get to try the IIS reset.

#144977

Feb 23, 2016 14:10

Björn Olsson

Vote:

I'm having the same problems, I am not able to use UDP, so I have to use TCP. It worked when i stopped and restarted the app-pool, a recycle did not resolve the issue. This seems to be very shaky, which is far from optimal in a loaded balanced environment. Any updates from EPiServer yet?

#147005

Apr 03, 2016 21:28

Saasen

Vote:

We are also experiencing this issue, and TBH, we've had this issue several times. We've also tried contacting support, but no luck there as they say it's not an issue.

I'm always having this issue when using TCP, even when disabling overlapped recycling, TCP Port Sharing ON and correct configuration.

#160701

Oct 03, 2016 21:42

Andreas Ljung

Vote:

We are currently experiencing this issue as well, would really appreciate some input about what we can try.

Running an old CMS 6 R2 site

#173930

Jan 13, 2017 8:27