Hi Daniel,

That sounds a lot like an issue with remote events between the edit node and the public facing nodes. It sounds like the change is being made but the event isn't reaching the web frontends and hence the cache is only refreshing when it expires (or the app pool recycles). How are your remote events configured? UDP? Do you have the same issue with CMS content or is it just commerce?

Second what Paul said, sounds like a problem with remote cache invalidation. Are you on Azure/DXP? If yes you should have your ServiceBus endpoint configuration checked. 

Hi guys! Thanks for your quick replies. We are not in the cloud. I will look into if CMS content is coming over, and get back with my findings.

We do not experience the same problem with the CMS syncronization as far as we know.

If it is on premise you might also want to ask your IT to look into firewall settings.

What puzzles me is that you said it might take a day for content to appear. That does not sound right (the default cache time out is about 10m)

this is how our confguration looks like: 

    <client>
      <!-- Remote Events --> 
      <endpoint name="RemoteEventServiceClientEndPoint" xdt:Locator="Match(name)" xdt:Transform="Remove" />
      <endpoint name="mysite.se-10.X.X.X" address="net.tcp://10..X.X.X:Y/RemoteEventService" bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding" xdt:Transform="Insert" />
      <endpoint name="mysite.se-10.X.X.X" address="net.tcp://10..X.X.X:Y/RemoteEventService" bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding" xdt:Transform="Insert" />
      <endpoint name="mysite.se-10.X.X.X" address="net.tcp://10..X.X.X:Y/RemoteEventService" bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding" xdt:Transform="Insert" />
      <endpoint name="mysite.se-10.X.X.X" address="net.tcp://10..X.X.X:Y/RemoteEventService" bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication" binding="netTcpBinding" xdt:Transform="Insert" />
    </client>

Where is the caching for the syncronization to be found? 

I think also this is relvant. looks like communication on UDP.

    <services>
      <service name="EPiServer.Events.Remote.EventReplication" xdt:Locator="Match(name)" xdt:Transform="Replace">
        <endpoint name="RemoteEventServiceEndPoint" contract="EPiServer.Events.ServiceModel.IEventReplication" bindingConfiguration="RemoteEventsBinding" address="soap.udp://X.X.X.X:5000/RemoteEventService" binding="customBinding" />
      </service>
    </services>
    <client>
      <endpoint name="RemoteEventServiceClientEndPoint" address="soap.udp://X.X.X.X:5000/RemoteEventService" binding="customBinding" bindingConfiguration="RemoteEventsBinding" contract="EPiServer.Events.ServiceModel.IEventReplication" xdt:Locator="Match(name)" xdt:Transform="Replace" />
    </client>
    <bindings>
      <netTcpBinding xdt:Transform="Remove" />
    </bindings>

I haven't found any loggins for this remote event update. Should there be any?

I found this in the logs:

Error creating/opening service host for event replication class System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint X.X.X.X:5000. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations

that sounds suspicious, if you have access to the server, run netstat -aon | findstr '[port_number]' command to see which program is using that port

As is today, I still experience the same problem. If I restart one of the web fronts that doesn't show the product in IIS it starts working again. So this has to do with the caching right?

Yes it is most likely it. It seems that instance had some issues which prevents it from receiving or processing the cache invalidation messages. Now you restart it (the cure for any problem!) it started working again

Problem is, it happens every now and then. So it is not a single incident. We cannot obviously restart the site everytime we update a product.

I'd agree rrestarting IIS after each publish isn't the most practical of approaches, even if it does seem to work.

It certainly sounds like it's an issue with the cache not invalidating when it should, probably due to an issue with remote events. From your posts above, it's not clear what mechanism you're using for remote events. In one snippet you show remote events configured using TCP and in another it's using UDP. First of all, are all servers (both front-end and CMS) set up to use the same mechanism? If so, are all servers in the same network with no devices such as firewalls which would block traffic between the CMS and the front-end servers? UDP can be particularly fiddly to set up and debug as it tends to be blocked on networks plus, being UDP, there are no guarantees of delivery.

It might be worth temporarily installing the Episerver developer tools add on as I believe that has tools for testing remote events. That said, it may be of limited use if you can't access the tool on each of the boxes.

It may also be worth considering switching the remote events mechanism to one of the alternatives, even if it's just temporarily to test whether it resolves the issue. Probably the easiest to set up is Azure service bus which works even if your servers aren't in Azure.