I'm developing a WCF sercvice in Azure, in a web-role. I build an index in memmory, and use it to serve wcf request. My problem is that this index is gone from the memory after iis is recycling. Is there any way, to detect the recycling event, and copy the index to the memory again?
Thansk for your help.
Yes you can detect it in the Application_End event (in your Global.asax.cs).
The better solution would be not to put the index in memory. Since you're using a Web Role, you can use Windows Azure Caching (you won't need to pay extra for this). By using Windows Azure Caching you can store the index in memory, but not in the process of the application pool. It's still super-fast and it can survive application pool recycles.
Another advantage is that, when you store the index in Windows Azure Caching, all instances and roles in the same deployment will be able to use the same cache. This means they'll all use the same index you store in it.
Related
I am having a MVC API project which is using a server side cache. It is deployed to Azure App Service. I was wondering to make use of App Service Local Cache to overcome challenge of keeping the cache in sync across nodes.Is this the right approach ? If yes, how do i modify the cache from my code.
PS: I am not much interested in using the Redis Cache.
I was wondering to make use of App Service Local Cache to overcome challenge of keeping the cache in sync across nodes.
What does sync across nodes mean? Do multiple webapp applications share cache data?
HttpRuntime.Cache can only be used in a single webapp application and cannot be accessed by other webapps. Once each cache is created, it takes up server resources. So from this point we can say: it is not that the more cache, the better. The cache has a time limit. After the expiration time set by the server, it will be recycled by the server. The cache can store any object.
So if you want to share cache data across sites, it is impossible to achieve, which is why the redis cache appears.
If you really don't want to use redis cache, then you can store the required data in sql server. This can only be an alternative, not the best.
We have a web farm of 4 SharePoint 2010 server. As web1, web2, web3, web4 and its AAM is http://xxx.sharepoint.com. Now I am making a web part where some data is going to be cached by HttpContext.Current.Cache. Now as we know that ASP.NET cache is limited to server memory and it is not shared between other servers in the web farm, So I created a solution where I will go to each server and in web.config I will fill the server list in the farm with semicolon separated and whenever any thing add to the cache I will send data to the other server and sync the cache and do the same for cache items removed.
Now my problem is how I will call other server individually by its own name in the SharePoint farm.
For example (http://web1/)
Not a direct answer but you can use timer jobs on Sharepoint for implementing something on all servers. Note that Sharepoint timer service must be running on all servers and it does not happen real-time(it doesn't take long either).
I used memcache, which is working good :) as expected
Microsoft Velocity is perfect use case for your scenario. Velocity will provide you distributed and in-memory cache.
Link:
Build Better Data-Driven Apps With Distributed Caching
Intro
I am developing a web application using ASP.NET MVC 3, C#, targeting IIS 7.0+. We have a number of long-running async requests (utilizing AsyncController/Async action features). I also use HttpRuntime.Cache quite often (and in some non-standard way which doesn't really matter here).
Question
Can IIS application pool be suddenly recycled if there are active long-running requests present? I want to prevent that behavior if possible as I don't want to lose data from cache.
Do I really need to use some persistent storage (i.e. Database) to overcome possible issues?
Normally IIS won't recycle an application which has pending requests for it due to period of inactivity. But IIS could recycle your application if you hit memory or CPU tresholds. But this is something that you could configure in your IIS management console.
When a recycle is triggered there is a "shutdown time limit" that defaults to 90 seconds. That's how long processes have to finish before they will be shutdown forcibly. This is configurable through IIS, you likely want to increase this to a large value in addition to removing non-desired recycle triggers (memory, CPU, time, schedule, requests, etc.)
I'm developing an application to run in azure.
I'm making use of the azure cache, however when I run this locally I don't want to connect up to Azure to use the cache because it's a bit slow and tedious.
Can you run the cache locally?
[EDIT]
This is .Net C#
Unfortunately, you do need to connect to azure to test the windows azure cache service. Read this for more info: http://msdn.microsoft.com/en-us/library/windowsazure/gg278342.aspx
You can use Windows Server AppFabric Cache when local debug. It utilizes very similar configuration and program mode, which means almost all you need to change is the cache server IP and access token.
But I'd better to create a separated Cache layer to isolate the cache operations. For example introduces ICache interface with Add, Get, Remove, etc. methods. Then you can implement the Azure Cache, Memcached, In-Proc Cache, etc. in vary cases.
There's a good cache layer you might be interested in, check the ServiceStack project at GitHUB https://github.com/ServiceStack/ServiceStack/tree/master/src/ServiceStack.Interfaces/CacheAccess
It's not possible. To use the windows azure caching service locally, you'll always have to route your request to azure, which adds a serious delay on top of the request.
To property test your cache, you need to deploy your service in azure.
As others said, you can use Windows Server AppFabric caching locally, but be warned, there are some differences between the Windows Server AppFabric caching and the Windows Azure caching service, like for example the notifcation based invalidation on local cache items is not supported in azure. Make sure not to use any of these features while developing locally, or you might get surprised when deploying your service to the cloud.
Only the timeout based invalidation on local cache is supported for the windows azure caching service. Windows azure caching service is designed to be used for your cloud services, so it makes sense it's kinda crappy when using with on on-premise application.
Azure AppFabric caching uses a subset of the functionality of Windows Server AppFabric caching. If you're willing to setup a server in house with the cache installed you could probably get something comparable to using the Azure cache. I haven't tried this myself, so while I know that the code you'd need to write is more or less the same between the two, I'm not sure how different the configs need to be.
Chances are though that it's going to be a lot less time and effort to just use the Azure cache.
This article specifically talks about what you are trying to do. Create a caching "infrastructure" that switches between local and distributed cache based on configuration(s):
http://msdn.microsoft.com/en-us/magazine/hh708748.aspx
Now you can use azure in-role cache and try locally using emulator
For some reason, the session is abandoning unexpectantly, and wreaking havoc in our application. We've had the app setup to use Session and have been using it for several months with no problems. Now, as we add additional content and store additional info in it, the Session is dumping well before the 20 minute timeout than its supposed to. I'm at a loss for the reason why... could it be because we may be adding a lot of data in the Session (not sure of exact size)? This is my local machine after all (Win 7, using IIS, ASP.NET 4.0, 4 GB RAM).
Or could there be other reasons for this occurrence? Any thoughts?
Thanks.
ASP.Net sessions are stored in the cache. If you are running out of memory then it will be dumped. You need to store the session in a database or other storage to keep it. I'll try to find a relevant link. Sessions are not meant to store tons of data!
Here is a link explaining how to use out-of-process sessions. Basically the idea is that, by default, ASP.Net/IIS will use in-process sessions (which are fastest) but are also limited by the power/storage on the server running IIS. The alternatives are to use a session state farm or a SQL server to store sessions. These are a bit slower but offer more flexibility. You will need to take into account the ability to serialize sessions into your decision.
Here is an excerpt from a book I've been reading (Programming Microsoft ASP.NET 3.5 by Dino Esposito):
Why Does My Session State Sometimes Get Lost?
When the working mode is InProc, the session state is mapped in the memory space of the AppDomain in which the page request is being served. In light of this, the session state is subject to process recycling and AppDomain restarts. As we discussed in Chapter 2, the ASP.NET worker process is periodically restarted to maintain an average good performance; when this happens, the session state is lost. Process recycling depends on the percentage of memory consumption and maybe the number of requests served. Although the process is cyclic, no general consideration can be made regarding the interval of the cycle. Be aware of this when designing your session-based, in-process application. As a general rule, bear in mind that the session state might not be there when you try to access it. Use exception handling or recovery techniques as appropriate for your application.
In Knowledge Base article Q316148, Microsoft suggests that some antivirus software might be marking the web.config or global.asax file as modified, thus causing a new application to be started and subsequently causing the loss of the session state. This holds true also if you or your code modify the timestamp of those files. Also, any addition to or removal from the Bin directory causes the application to restart.
Note: What happens to the session state when a running page hits an error? Will the current dictionary be saved or is it just lost? The state of the session is not saved if, at the end of the request, the page results in an error—that is, the GetLastError method of the Server object returns an exception. However, if in your exception handler you reset the error state by calling Server.ClearError, the values of the session are saved regularly as if no error ever occurred.
I'm assuming you are using Session state in-proc. If this is the case then the most common reason of losing your Session is that the corresponding Application Pool recycles. Go check IIS settings on Application pool and set up Event log entries for such events. You'll find the settings in: "Advanced settings" of your app pool -> "Recycling" -> "Generate Recycle Event Log Entry". Set them all to true and see if it will give you the reason of your Session State loss.
Also if you change data on given sites a lot then it will eventually trigger app pool recycling.
More ideas on app pool recycling:
http://blogs.msdn.com/b/johan/archive/2007/05/16/common-reasons-why-your-application-pool-may-unexpectedly-recycle.aspx