Sessions in OpenCPU: what are the specifics? - r

After reading this blog post on OpenCPU, I have questions about Sessions:
* when/how do sessions expire?
* can session expire time be configured on the server?
* can session expire time be changed at runtime?
* are sessions saved on-disk or in-memory?
* do sessions work with the nginx opencpu proxy?
Thanks in advance!

Probably better suited for the mailing list. Also have a look at the paper for some of these topics.
When/how do sessions expire?
The default expiration for temporary sessions in the server implementation is 24h.
Can session expire time be configured on the server?
You could edit the /usr/lib/opencpu/scripts/cleanocpu.sh script, which get triggered through /etc/cron.d/opencpu. But if you want persistence it is usually better to store things in a database (RMySQL, mongolite, etc) or in a package on the server, or in the client.
Can session expire time be changed at runtime?
No, expiration of resources is up to the server.
Are sessions saved on-disk or in-memory?
The current implementation saves on disk (with a bit of in-memory cache), but the API is agnostic.
Do sessions work with the nginx opencpu proxy?
Yes, they are no different than anything else on the server.

Related

How to handle stale reads in Riak for things like sessions in the face of network partition

If one is storing sessions in Riak, there is a possibility of a read being stale.
Isn't this bad? For example, session data. User logs out and then refreshes the page and they are still shown as logged in.
Also, if there is a network partition or something making a node unresponsive (excessive I/O or CPU usage), then the user could log out which destroys the session but if a subsequent read happens on the other side of the nodes they are still going to be logged in because on that side the session hasn't been destroyed. What is the answer?
With an eventually consistent datastore like Riak there is a risk of stale reads under some conditions however in most environments this is offset by Riak's availability profile (where stale reads are better than no reads or an inability to write).
Riak does have some features that can help you with session storage like expiry (when using BitCask or In Memory backends) and the Riak documents have some examples and links to real world session store use cases built on Riak that are worth a look: http://docs.basho.com/riak/latest/dev/data-modeling/.

How to synchronize server operation in multiple instances web application on Azure?

I have a client-server web application - the client is HTML/JS and the server is ASP.Net. web application hosted by Azure Web Role
In this application the client can save a document on the server by calling a web service method on the server side.
After calling the saving method, the client might save the document again while the server processes his previous save request. In this case I want the newly initiated saving to be queued until the previous saving operation is completed.
If I had a single web role instance, it would be easy for me to implement this by thread synchronization, but since the client request might be handled by different web role instances, the synchronization is problematic.
My question is - how can I implement such synchronization mechanism, or is there a better way to get the same result, that I'm not aware of.
Thanks.
I would consider combination of storage or service bus queues to queue up the requests to process the documents AND using BLOB leases to mark the work as in progress.
Queuing would be important since the requests might be delayed in processing if there is a previous request for the same job that's on going.
BLOB Leasing is a way to put a centralized lock in storage. Once you start processing of a request, you can put a blob with a lease on it and release the lease once you're done. Requests for the same work would check first if the lease is available before kicking off. Otherwise, they could just wait. More info on leases here: http://blog.smarx.com/posts/leasing-windows-azure-blobs-using-the-storage-client-library
Have you looked into using the Windows Azure Cache - Co-Located on your roles?
This is a shared caching layer that can use excess memory on your roles (Or have it's own worker role if your web roles are already close to capacity) to create a key / value store which can be accessed by any role on the same deployment.
You could use the cache to store a value indicating a document is currently being processed and block it until the document has finished uploaded. As it is a shared caching layer the value will be persisted across your instances (Though the cache will not persist during an upgrade deployment).
Here's a good introductary article to using Caching in Azure with configuration examples and sample code.

How do massively scalable sites like Facebook and Google implement sessions?

Does anyone have any insight into their system architecture? Do they use Memcache? Surely every time I click on Facebook my HTTP requests aren't being channeled to the same server where my session is in memory?
A basic solution would be to store the session identifier & associated state in a database (or equivalent). This allows any application node in a cluster to access the session.
In practice, such a solution is slow and read-through caching (e.g. with Memcache), session replication, etc. are used to improve performance.

What is database backed Cache and how does it work?

What is database backed Cache and how does it work ? Something similar in line of when the app server goes down and database is backed by cache there is no time wasted to repopulate an in memory cache
A database backed cache is a method of storing data that is costly (in resources or time) to generate or derive. You could see them implemented for such things as:
improving web server performance by caching dynamic pages in a db as static html so additional hits to the page do not incur the overhead of regenerating the page. Yes, this might be counter-intuitive as often database access is the bottleneck, though in some cases it is not.
Improving query time against a slow (or offsite) directory server or database.
If I understand your example correctly, I believe you might have it backwards. The database is backing some other primary location. For example, in an app server farm, if a security token is stored in a db backed cache and the app server you are currently interacting with goes down you could be routed to a different service instance. The token cache check it's in-memory cache which won't contain the token, so it will be retrieved from the database, deserialized and added to the (new) local cache. The benefits are minimized network transport and improved resilience to failures.
Hope this helps.

ASP.NET Session State Migration

I was hoping someone could validate my assumptions before I recommend that my client upgrade from a 30/mo to a 80/mo hosting package.
Site: the site is a custom ASP.NET ecommerce site. the shopping carts are stored in the inproc session.
Problem during busy seasons like we are having now, users are frequently losing their shopping carts and their FormsAuthentication Login information.
Solution I wanted to migrate the site to use a SQL Server Session state. My assumptions are that the customers are losing their shopping carts because the InProc sessions are recycling more frequently then their 20 minute timeout, due to load. Will moving the Session to SQL Server or a Session State Server allow customer to store their Shopping Cart Session without the recycle, If so, can once their will I have any issues if I increase the Session timeout to say 40 or 60 minutes
Using the SQL Session state means that sessions should survive a recycle of IIS, (but not a recycle of SQL Server if you use the default script which creates the session database in the tempdb).
There is a script available from the Microsoft website which creates a permanent session state db. I would recommend using that one instead (See here).
So, to basically answer your question. Yes, the SQL Session state will help. You might want to consider also using the out-of-proc state server to test your theory.
Also, as a co-worker has just reminded me, make sure anything you store in the session is marked as serializable before migrating, otherwise you will run into problems.
Could you just add some RAM to the box? That might help and would likely be cheaper and simpler than moving the session to SQL Server. Of course, it would only be a stopgap, but if it saved them $50/mo for a few years it's probably worthwhile.
You might also check the code to see if some other data is left in the session for much longer than necessary.
The assumptions sound reasonable to me. might also want to look at the settings on the AppPool and try to figure out why its recycling. Maybe all you need to do is change those (if you can).

Resources