Signals need a way to propagate to other servers in a farm


A signal to expire a cache entry (triggered from a specific server in the farm because of a modification on an item for example) has in most cases vocation to be propagated to other servers in the farm which may otherwise continue to show obsolete information.


sebastienros wrote Sep 27, 2011 at 6:05 PM

Should be doable by implementing a distributed cache provider.

pszmyd wrote May 10, 2013 at 12:37 PM

This should be obsoleted as Orchard.Caching comes in in 1.7. The default (current) Orchard caching mechanism should not be used for caching data, but local in-app settings only.

rodpl wrote Jul 16, 2013 at 12:28 PM

I don't agree. There would be even problem with settings. Assume.

3 servers in load balance. Lets change settings which are cached in one of them. This server will update DB and will keep new settings cached. The other two servers will have old in-app settings

rdobson wrote Oct 15, 2013 at 3:46 PM

Hand rolled something for this using background webapi calls when using as an azure cloud service.

Otherwise making any settings changes will not be reflected on other instances. As well as with an new AzureSignals/ISignals) had to do this when shell settings are changed (added to AzureShellSettingsManager) as well as enabling and disabling features (created a new AzureShellDescriptorManager/IShellDescriptorManager).

sebastienros wrote Dec 4, 2013 at 7:41 PM

Could it be done using a dedicated sql table like SqlDependency is doing ?

Piedone wrote Dec 4, 2013 at 8:27 PM

Is there an actual reason we're keeping to ICacheManager? It's not only inflexible but the built-in implementation is also prone to memory overflow (because it stores everything in a dictionary) as opposed to ASP.NET cache for example that will start throwing entries away on memory pressure.

Why don't we change everything to ICacheService (and keep ICacheManager around for a few more version but just for backward compatibility)? "Monitoring" kind of functionality is also possible e.g. how I've done here: https://helpfullibraries.codeplex.com/SourceControl/latest#Libraries/Utilities/CacheServiceMonitor.cs

sebastienros wrote Dec 4, 2013 at 8:53 PM

ICacheManager doesn't free up memory BY DESIGN ;) This was one of the reasons to have it.

Piedone wrote Dec 4, 2013 at 9:21 PM

Really? Could please you tell the reasons?

sebastienros wrote Dec 4, 2013 at 10:17 PM

Because !

Piedone wrote Mar 11 at 10:52 PM

This is now solved with Distributed Events.