When Does Asp.Net Remove Expired Cache Items? - asp.net

When you add an item to the System.Web.Caching.Cache with an absolute expiration date, as in the following example, how does Asp.Net behave? Does it:
Simply mark the item as expired, then execute the CacheItemRemovedCallback on the next access attempt?
Remove the item from the cache and execute the CacheItemRemovedCallback immediately?
HttpRuntime.Cache.Insert(key,
new object(),
null,
DateTime.Now.AddSeconds(seconds),
Cache.NoSlidingExpiration,
CacheItemPriority.NotRemovable,
OnCacheRemove);
MSDN appears to indicate that it happens immediately. For example, the "Expiration" section of the "ASP.NET Caching Overview" says "ASP.NET automatically removes items from the cache when they expire." Similarly, the example from the topic "How to: Notify an Application When an Item Is Removed from the Cache" says "If more than 15 seconds elapses between calls to GetReport [a method in the example], ASP.NET removes the report from the cache."
Still, neither of these is unambiguous. They don't say "the callback is executed immediately" and I could conceive of how their writers might have thought option 1 above counts as 'removing' an item. So I did a quick and dirty test, and lo, it appears to be executing immediately - I get regular sixty-second callbacks even when no one is accessing my site.
Nonetheless, my test was quick and dirty, and in the comments to my answer to Is there a way to run a process every day in a .Net web application without writing a windows service or SQL server jobs, someone has suggested that Asp.Net actually defers removal and execution of the callback until something tries to access the cache again.
Can anyone settle this authoritatively or is this just considered an implementation detail?

Hurray for Reflector!
Expired cache items are actually removed (and callbacks called) when either:
1) Something tries to access the cache item.
2) The ExpiresBucket.FlushExpiredItems method runs and gets to item. This method is hard-coded to execute every 20 seconds (the accepted answer to the StackOverflow question Changing frequency of ASP.NET cache item expiration corroborates my read of this code via Reflector). However, this has needs additional qualification (for which read on).
Asp.Net maintains one cache for each CPU on the server (I'm not sure if it these represent logical or physical CPUs); each of these maintains a CacheExpires instance that has a corresponding Timer that calls its FlushExpiredItems method every twenty seconds.
This method iterates over another collection of 'buckets' of cache expiration data (an array of ExpiresBucket instances) serially, calling each bucket's FlushExpiredItems method in turn.
This method (ExpiresBucket.FlushExpiredItems) first iterates all the cache items in the bucket and if an item is expired, marks it expired. Then (I'm grossly simplifying here) it iterates the items it has marked expired and removes them, executing the CacheItemRemovedCallback (actually, it calls CacheSingle.Remove, which calls CacheInternal.DoRemove, then CacheSingle.UpdateCache, then CacheEntry.Close, which actually calls the callback).
All of that happens serially, so there's a chance something could block the entire process and hold things up (and push the cache item's expiration back from its specified expiration time).
However, at this temporal resolution, with a minimum expiration interval of twenty seconds, the only part of the process that could block for a significant length of time is the execution of the CacheItemRemovedCallbacks. Any one of these could conceivably block a given Timer's FlushExpiredItems thread indefinitely. (Though twenty seconds later, the Timer would spawn another FlushExpiredItems thread.)
To summarize, Asp.Net does not guarantee that it will execute callbacks at the specified time, but it will do so under some conditions. As long as the expiration intervals are more than twenty seconds apart, and as long as the cache doesn't have to execute time-consuming CacheItemRemovedCallbacks (globally - any callbacks could potentially interfere with any others), it can execute expiration callbacks on schedule. That will be good enough for some applications, but fall short for others.

Expired items aren't immediately removed from the cache, they're just marked as expired. You don't get a callback until a cache miss. I ran into this back in the ASP.NET 1.1 days, and it hasn't changed.
There may be cases where expired items are removed immediately - such as if there's low memory and high CPU - but you can't count on it.
I usually use a timer that reloads the cache on a regular basis.

Related

How to control the number of threads when executing an Asynchronous Activity in WF 4

I am creating a workflow in WF 4, where I have a ParallelForeach activity that iterates over a collection of items. For each item in the collection, I execute a custom Asynchronous activity to processing multiple items in parallel.
The above solution works for me, but I am concerned about the number of threads used since each Asynchronous activity instance is executed on its own thread. Is there a way to configure/control the number of threads that get launched when executing the parallelForeach activity in the above described mechanism?
since each Asynchronous activity instance is getting executed on its own thread. Who says? Certainly not the docs.
ParallelForEach enumerates its values and schedules the Body for every value it enumerates on. It only schedules the Body. How the body executes depends on whether the Body goes idle.
If the Body does not go idle, it executes in a reverse order because the scheduled activities are handled as a stack, the last scheduled activity executes first.
For example, if you have a collection of {1,2,3,4}in ParallelForEach and use a WriteLine as the body to write the value out. You have 4, 3, 2, 1 printed out in the console. This is because WriteLine does not go idle so after 4 WriteLine activities got scheduled, they executed using a stack behavior (first in last out).
The Parallelism of execution occurs only when an Activity creates a bookmark and goes idle. Even then, two activities aren't actually executing at the same time--one or more have just stopped executing, allowing others to run in order. Understandably confusing, given the name, but that's it.
In any event, when you're relying on the framework to parallelize for you, don't worry about how many threads they're using. They probably have everything under control. Until you know they don't.
Will is correct, ParallelForEach does not require a new thread for each branch. If you are doing blocking I/O in code that should occur in an AsyncCodeActivity so that you aren't unecessarily blocking. If you want CPU-bound work to run in parallel to other activities you will either need to wrap it in an AsyncCodeActivity or use InvokeMethod { RunAsynchronously = true} in which case the framework will take care of running the work on a background thread.
The SynchronizationContext extensibility point is intended for cases where you have a particular existing threading model that you need WF to integrate with. Prime examples of this include ASP.NET's threading environment, and Windows Presentation Foundation/WinForms (e.g. if you wanted a activity to work correctly).

Servlet getParameter

I have a servlet program for counting numbers, I want to control it through an html interface.
by pressing the start button the program must start running and by pressing pause button the servlet program must be paused and by clicking on the restart button it must restart again. by the way i used thread. My problem is that each time I should click one button and send its value to the servlet, and when I'm getting the buttons values inside the servlet a NullPointerException is occur... any help ??
I wouldn't use a Thread for that purpose and in general is not usually a good idea to create threads in servlets.
Say we count one number per millisecond meaning: it will give me the time between one click and another in milliseconds.
One work around could be:
Click on start = save the start time in the session.
click on stop = to get the count we do currentTime-StartTime (saved in session)
Now if you really must use Threads be sure then to create it using another class.
One suggestion might be create a ThreadManager class and store it in the session (use a listener for this) and then start it in that session object.
Even better store the ThreadManager inside the servletContext and have a way to create your thread per session.
To create Threads favor the Executor classes instead of the Thread classes.
Also make sure you stop your threads since having threads created by us inside a web container may prevent it from stoping entirely.
If you provide some code I can help you further.
Good luck, have fun.

What is the minimum time required for a delay activity to cause a persist?

I am trying to force a workflow service to persist (for "recovery/restart" purposes) and need to know if there is a minimum delay required to force a persist of the workflow. In most cases, I would do a bit of testing and see if I could determine the minimum, but am in a crunch because it appears that an alternate method is not working for me. The service is configured to immediately persist by the following, which is in my web.config:
<workflowIdle timeToUnload="0"/>
So, if I do a delay of, say, one second, will this be enough to force a persist? Should I just add a Persist activity rather than the delay? Or must I just try values until it either works or I determine I have to move on to another method?
The workflowIdle behavior kicks in when a workflow enters the Idle state. This will occur even with a delay as short as 1ms.
However, based on your requirement it is better to use the Persist activity to force persistence.

What is the difference between Application("Something") and Session("Something")

While debugging a classic ASP application (and learning about classic ASP at the same time) I've encountered the following
Application("Something") = "some value"
and elsewhere in the code this value gets used thus:
someObj.Property = Session("Something")
How does the Application object relate to Session?
A Session variable is linked to a user. An Application variable is shared between all users.
Application is a handy vault for storing things you want to persist but you can't guarantee they'll always be there. So think low-end caching, short-term variable storage, etc.
In this context with these definitions, they have very little to do with each other except that getting and setting variables is roughly the same for each.
Note: there can be concurrency issues when using Application (because you could easily have more than one user hitting something that reads or writes to it) so I suggest you use Application.Lock before you write and Application.Unlock after you're done. This only really applies to writing.
Note 2: I'm not sure if it automatically unlocks after the request is done (that would be sensible) but I wouldn't trust it to. Make sure that any part of the application that could conceivable explode isn't within a lock otherwise you might face locking other users out.
Note 3: In that same vein, don't put things that take a long time to process inside a lock, only the bit where you write the data. If you do something that takes 10 seconds while in a lock, you lock everybody else out.

Practical value for concurrent-request-timeout parameter or options for avoiding concurrent access to conversation exception

In the Seam Reference Guide, one can find this paragraph:
We can set a sensible default for the concurrent request timeout (in ms) in components.xml:
<core:manager concurrent-request-timeout="500" />
However, we found that 500 ms is not nearly enough time for most of the cases we had to deal with, especially with the severe restriction seam places on conversation access.
In our application we have a combination of page scoped ajax requests (triggered by various user actions), some global scoped polling notification logic (part of the header, so included in every page) and regular links that invoke actions and/or navigate to other pages.
Therefore, we get the dreaded concurrent access to conversation exception way too often, even without any significant load on the site.
After researching the options for quite a bit, we ended up bumping this value to several seconds (we're debating whether to bump it up to 10s), as none of the recommended solutions seemed able to solve our issue completely (even forcing a global queue for all the ajax requests would still leave us exposed to a user deciding to click a link right when one of our polling calls was in progress). And we'd much rather have the users wait for a second or two instead of getting an error page just because they clicked a link at the wrong moment.
And now to the question: is there something obvious we're missing (like a way to allow concurrent access to conversations and taking care of the needed locking ourselves, for instance :)? How do people solve this problem (ajax requests mixed with user driven interaction) in seam? Disabling all the links on the page while ajax requests are in progress (as suggested by one blog page) is really not a viable option.
Any other suggestions?
TIA,
Andrei
We use 60000 or 120000 (1-2 minutes). Concurrent-request-timeout is designed to avoid deadlocks. Historically we have far more problems with timeouts than deadlocks. A better approach is to use a client-side queue (<a4j:ajaxQueue> if using RichFaces) to serialize and remove duplicate requests as much as possible, then set the timeout high enough to avoid any remaining problems.
There are many serious issues resulting from Seam's concurrent request timeouts:
The issue is the last request gets the ConcurrentRequestTimeoutException. If the user double-clicks or reloads the page, only the last request matters -- why should he get an error?
Usually the ConcurrentRequestTimeoutException is suppressed, and only secondary NullPointerExceptions and #In injection failures are shown, making debugging difficult.
Seam 2.2.1 has a severe problem where transactions, ThreadLocals, and locks may leak after a timeout occurs, especially when used with <spring:spring-transaction/>. Look at SeamPhaseListener.afterRestoreView: there's no finally block to clean up after restoreConversation fails!
In my opinion there are many poor aspects to this design, so it's best to use a much higher timeout and try to avoid the issues.
This is what we have and it works fine for us:
<core:manager concurrent-request-timeout="5000"
conversation-timeout="120000" conversation-id-parameter="cid"
parent-conversation-id-parameter="pid" />
We also use a much higher value for the concurrent-request-timeout.
At least for duplicate events you can use settings in the a4j components to filter and delay them with eventsQueue, requestDelay and ignoreDupResponses=”true”.
(Last point http://docs.jboss.org/seam/2.0.1.GA/reference/en/html/conversations.html )
Can you analyse which types of request are taking a long time? Is there a particular type which you could reduce the request time by doing the "work" asynchronously and getting the update back in your poll?
In my opinion, ajax requests should always complete fairly quickly, then you can calculate a max concurrent request time by (request time * max number of requests likely to be initiated)

Resources