Do we have a feature, like auto-update for services in 24/7 environments (without load balancing) ? Currently, when I need to update the service binaries and service goes down, client programs use automatically an emergency service URL, but I have problems with clients using sessions. Any better approach ?
Stephen Brannan:
I’ve been kind of looking for something similar. I did happen to run across one company offering such a product. It might help your situation. I’m still investigating it and haven’t had a chance to try it out yet. http://wyday.com/wybuild/
Stefan Tsalapatis:
+Stephen Brannan thanks, I don’t know if such “silent update” can save the service state with clients. My best thought is that if we have not a ServiceStack auto-update, then to implement a service ( it will be called from the emergency service). This special service will put all services in the AppHost(selfhost) in a drain down mode and somehow to transfer all sessions to the emergency service.
For the moment, I don’t know how to do it and if it is the best approach.
Stephen Brannan:
Who holds the client session state? ServiceStack or a separate client state on the client side? If it’s the session state in ServiceStack then one solution is to use redis as a ServiceStack cache. ServiceStack cache calls into the ICacheClient and when your service for service stack goes down the redis cache will remain active.
Stefan Tsalapatis:
+Stephen Brannan maybe the redis cache as you say is the solution for the sessions. I don’t use redis till now, I keep the sessions in memory, probably I should do.
Stephen Brannan:
Ahh gotcha. Yeah redis would solve this. It’s what I use; or more specifically redis cache in Azure as I have two instances running my site and thus must share the session.
Note: any of the distributed caching providers persists users session in an external data store which would survive AppDomain restarts:
https://github.com/ServiceStack/ServiceStack/wiki/Caching
The only CacheClient that doesn’t is the MemoryCacheClient (as expected). If preferred you can use the OrmLiteCacheClient to re-use your RDBMS so you don’t need to add an extra infrastructure dependency.
Stefan Tsalapatis:
+Demis Bellot
thx,. I tested it. It creates the CacheEntry table in SQL Server. If we use server events also, (now we test it in memory), we will need the redis, in any case ?
+Stefan Tsalapatis What’s the question? whether you need Redis if you switch to Redis ServerEvents provider?
Stefan Tsalapatis:
+Demis Bellot
No, my question is that if I need to save the state of server events also, it seems that I should use redis (for the sessions and the server events), instead my DBMS. I would not prefer the dependency on redis , but it seems unavoidable.
No the ServerEvents state doesn’t get saved, when the website goes down all ServerEvent connections to that website goes down with it, whether you use redis or not. Although the Server Event clients will try to auto-reconnect with website after it comes back up.
Stefan Tsalapatis:
+Demis Bellot
understood. I think to use a separate process for the server events, which will make the most simple, to publish only messages from other services (using a service endpoint), so it will need changes, very seldom. All our services are selfhost.