I am finding it hard to find any detailed documentation on the use of StatelessWorkers.
I want to achieve something similar to this. As suggested in the document I need to use Stateless Workers in order to process some messages and activate the grains that will eventually hold the state.
I would like to have multiple instances of a dispatcher grain processing the "initialization" since this grain by no means handles any state and the messages do not need to be queued in order.
Do I need to mark this grain as Reentrant? or Will the StatelessWorker (attribute) be enough?
With regards to activation, it seems like I need to inherit from IGrainWithIntegerKey (or a similar interface). this means that I need to activate the grain as follows:
GrainClient.GrainFactory.GetGrain<IDispatcherActor>(0)
Since I am always using 0 as ID will multiple instances of the grain still be activated? or do I need to create different IDs. It seems like I cannot call the grain as follows:
GrainClient.GrainFactory.GetGrain<IDispatcherActor>()
even if I inherit from IGrain
Short Answer
You can create a stateless worker by inheriting IGrainWithIntegerKey and using a key 0.
Long Answer
Stateless workers are the same as normal grains with a couple of differences:
They are always activated locally (in the same silo as the caller).
Multiple activations can be created if the calls to a stateless worker activation build up.
They are subject to the same deactivation semantics.
It might be surprising that stateless workers have keys, but there are couple of reasons why keys might be useful:
Stateless worker activations may have different 'flavours', which could be related to their key.
A larger pool of stateless workers could be activated by addressing them with a range of keys.
But if these features aren't useful to you, the convention is to use a key of 0.
They can only be called from inside a silo.
StatelessWorker grains can be called from clients. That's actually one of the popular scenarios when calls from clients should be preprocessed before they can be routed to other grains for actual processing.
Related
I did some research on this topic, but I am unable to find the expected answer for this. In my application I have used
ThreadPool.QueueUserWorkItem
Like following way.
ThreadPool.QueueUserWorkItem(o => CaseBll.SendEmailNotificationForCaseUpdate(currentCase, caseUpdate));
My app in asp.net mvc & I have handled all background task which is not required to execute on user operation for faster execution & quick user response.
Now I wants to know that, Is there any bad side of using ThreadPool.QueueUserWorkItem When we have larger audience for application.
No, you should never use it. I can write a lot of reasons why but instead you should read this article from Scott Hansleman who is a genius IMHO
http://www.hanselman.com/blog/ChecklistWhatNOTToDoInASPNET.aspx
Under "Reliability and Performance":
Fire-and-Forget Work - Avoid using ThreadPool.QueueUserWorkItem as your app pool could disappear at any time. Move this work outside or use WebBackgrounder if you must.
So, as recommended, don't use ThreadPool.QueueUserWorkItem. An excellent alternative for this is at:
https://www.asp.net/aspnet/overview/web-development-best-practices/what-not-to-do-in-aspnet-and-what-to-do-instead#fire
Edit: As mentioned by #Scott-Chamberlain, here's a better link:
http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx
It really depends on what you are going to be doing but generally speaking, your likely concerns will be:
Persistence. Threads in the managed pool are background threads. They will die when the application recycles which is generally undesirable. In your case you want to send e-mails. Imagine if your process dies for some reason before the thread executes. Your e-mail will never be sent.
Local storage is shared, which means you need to make sure there are no leftovers from the last thread if using it. Applies to fields marked with ThreadStaticAttribute as well.
I would instead recommend that you implement a job scheme where you schedule the job somewhere and have some other component actually read from this list (e.g. database) and perform the job, then mark it as complete. That way it persists across application unload, there is no memory reuse and you can throttle the performance. You could implement the processing component inside your application or even as a Windows service if you prefer.
I was reading through the .NET API Guide and it is pretty good information but I'm a bit confused on how RabbitMQ manages threads. Under the Concurrency Consideration section it states that every IConnection is backed up by a single background thread. Then it continues with:
The one place where the nature of the threading model is visible to the application is in any callback the application registers with the library. Such callbacks include:
any IBasicConsumer method
the BasicReturn event on IModel
any of the various shutdown events on IConnection, IModel etc.
I'm a bit confused by this. Do they mean that every time HandleBasicDeliver is called a new thread is created? In that case there will be as many threads as messages are received and the concurrency is controlled by the prefetch count along with the number of consumers?
So if we consider a case where I have one IConnection and two channels (IModel) with prefetch count of one and one EventingBasicConsumer per channel, how many threads would we have running in the application?
I have done considerable amount of research on this topic since I first asked the question so I thought I would post it here in case someone finds this information useful.
Take this with a grain of salt. These are my understandings of how rabbit (C#) works.
IConnection is an actual socket connection. It will have a single thread polling it. According to suggestions I have read, use one connection per application unless you have a reason to use more.
Using more than one connection does not necessarily mean that you have better fault tolerance since if a connection fails, there usually is a problem that will result in all the connections to fail. Also, in many cases using one connection is enough to handle the traffic coming from the network and it is simply unnecessary to have more.
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-July/013771.html
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-May/019873.html
In C# channels are not considered thread safe so it is not a bad idea to have a channel per thread, otherwise one should make sure to use locking mechanism.
https://www.rabbitmq.com/dotnet-api-guide.html
As per my understanding of reading the source code, handleBasicDeliver (and I think all IModel calls) is ran in a Task. With that in mind, having multiple consumers does increase the concurrency of your software since if one consumer receives a message and is busy processing it, another consumer is free to pick up a message and execute it in a different thread. Also, each consumer must be on its own channel to maximize concurrency otherwise message order is preserved. However, if that kind of concurrency is not welcome consider using a single channel to ensure the messages are processed in the order they arrived.
NOTE: Point 3 may have changed in that channel order is no longer preserved. I haven't had time to explore the new changes so read through this and draw your own conclusion:
https://github.com/rabbitmq/rabbitmq-dotnet-client/issues/251
I have revised my answer and research that you did looks good.
I have created an application using Rabbitmq and in that I had a situation where I have to share the same IConnection(Connection) for number of IModel(channel). And that is the way we should use one connection as one connection is enough for serving multiple channels.
The problem I faced once was if I am creating one connection per client then the number of connections for that queue goes on increasing which results in termination of the application after a while.
So we should avoid having multiple connections unless its needed. If possible only one connection should be used for multiple channels.
Various shut down events on IConnection, IModel:
The IModel even if goes down the IConnection is still there. But if the IConnection is down then all the IModel under that connection will be shut down.
I'm really loving the TPL. Simply calling Task.Factory.StartNew() and not worrying about anything, is quite amazing.
But, is it possible to have multiple Factories running on the same thread?
Basically, I have would like to have two different queues, executing different types of tasks.
One queue handles tasks of type A while the second queue handles tasks of type B.
If queue A has nothing to do, it should ignore tasks in queue B and vice versa.
Is this possible to do, without making my own queues, or running multiple threads for the factories?
To clarify what I want to do.
I read data from a network device. I want to do two things with this data, totally independent from each other.
I want to log to a database.
I want to send to another device over network.
Sometimes the database log will take a while, and I don't want the network send to be delayed because of this.
If you use .NET 4.0:
LimitedConcurrencyLevelTaskScheduler (with concurrency level of 1; see here)
If you use .NET 4.5:
ConcurrentExclusiveSchedulerPair (take only the exclusive scheduler out of the pair; see here)
Create two schedulers and pass them to the appropriate StartNew. Or create two TaskFactories with these schdulers and use them to create and start the tasks.
You can define yourself a thread pool using a queue of threads
I added log4net to my application and can now see the thread Ids of user activities as they navigate through my website. Is there any specific algorithm to how threads assignment happens with IIS7, or is it just a random number assignment (I suspect it's not completely random because my low traffic site show threads mostly in the range 10-30)? Any maximum to the number of threads available? And I notice that my scheduler shows up with a weird threads id -- any reason for this? The scheduler is Quartz.net and the id shows as "Scheduler_Worker-10", and not just a number.
This explains all you need to know.
An Excerpt:
When ASP.NET is hosted on IIS 7.0 in
integrated mode, the use of threads is
a bit different. First of all, the
application-level queues are no more.
Their performance was always really
bad, there was no hope in fixing this,
and so we got rid of them. But perhaps
the biggest difference is that in IIS
6.0, or ISAPI mode, ASP.NET restricts the number of threads concurrently
executing requests, but in IIS 7.0
integrated mode, ASP.NET restricts the
number of concurrently executing
requests. The difference only matters
when the requests are asynchronous
(the request either has an
asynchronous handler or a module in
the pipeline completes
asynchronously). Obviously if the
reqeusts are synchronous, then the
number of concurrently executing
requests is the same as the number of
threads concurrently executing
requests, but if the requests are
asynchronous then these two numbers
can be quite different as you could
have far more reqeusts than threads.
So basically, if requests are synchronous, the same number of threads per request. See here for various parameters.
I've explained this is a blog post on my blog
ASP.NET Performance-Instantiating Business Layers
The title doesn't coincide with your question but I explain the way IIS handles Requests and I believe you'll have your answer.
A quote from the article
When IIS fields a request for your
application it hands it over to the
worker process. The worker process in
turn creates and instance of your
Global class (which is of type
HttpApplication). From that point on
the typical flow of an ASP.NET
application takes place (the ASP.NET
pipeline). However, what you need to
know and understand is that the worker
process (think of it as IIS really)
keeps the instance of your
HttpApplication (an instance of your
Global class) alive, in order to field
other requests. In fact it by default
it would create and cache up to 10
instances of your Global class, if
required (Lazy instantiation)
depending on load the number of
requests your website receives other
factors. In Figure1 above the
instances of your ASP.NET application
are shown as the red boxes. There
could be up to 10 of these cached by
the worker process. These are really
threads that the worker process has
created and cached and each thread has
its own instance of your Global class.
Note that each of these threads is in
the same App Domain. So any static
classes you may have in your
application are shared across each of
these threads or application
instances.
I suggest you read that article and I'll be happy to answer any questions you may have. Please note that I've intentional kept the article simple in that I don't talk about what happens in the kernel or go into details of the various components that participate. Keeping it simple helps people understand the concepts a lot better (I feel).
I'll answer some of your other questions here:
Is there any specific algorithm to how threads assignment happens with IIS7?
No, for all intents an purposes it's random. This is explain in the article I pointed to. The short answer is that if a cached thread is available then IIs will use it. If not, it will create a new thread, create and instance of your HttpApplication (Global) and assign all of the context to it. So in a site that's not busy, you may see the same threads handle requests. But there are no guarantees. If there is more than one free thread IIS will pick a thread at random to service that request. You should note here, that even in a not so busy site, if your requests take a long time, IIS will be forced to create new threads to service other incoming requests.
Any maximum to the number of threads available?
Yes (as explained in th article) typically 10 threads per worker process. This can be adjusted but I've worked on a number of extremely busy websites and I've never had to. The key is to make your applications respond as fast as possible. Mind you an application can have multiple worker process assigned to it (configured in your app pool) so in busy sites you actually want multiple worker processes for your application, however the implication is that you have the required hardware (CPU cores and memory).
The scheduler is Quartz.net and the id shows as "Scheduler_Worker-10", and not just a number
Threads can have names instead of Ids. If the thread has been assigned a name then you'll see that instead of an id. Of course for threads IIS creates you have no such control. Mind you, I've not used (nor know about Quartz) so I don't know about that but I'm guess that's the case.
I'm writing an app that will need to make use of Timers, but potentially very many of them. How scalable is the System.Threading.Timer class? The documentation merely say it's "lightweight", but doesn't explain further. Do these timers get sucked into a single thread (or very small threadpool) that processes all the callbacks on behalf of a Timer, or does each Timer have its own thread?
I guess another way to rephrase the question is: How is System.Threading.Timer implemented?
I say this in response to a lot of questions: Don't forget that the (managed) source code to the framework is available. You can use this tool to get it all: http://www.codeplex.com/NetMassDownloader
Unfortunately, in this specific case, a lot of the implementation is in native code, so you don't get to look at it...
They definitely use pool threads rather than a thread-per-timer, though.
The standard way to implement a big collection of timers (which is how the kernel does it internally, and I would suspect is indirectly how your big collection of Timers ends up) is to maintain the list sorted by time-until-expiry - so the system only ever has to worry about checking the next timer which is going to expire, not the whole list.
Roughly, this gives O(log n) for starting a timer and O(1) for processing running timers.
Edit: Just been looking in Jeff Richter's book. He says (of Threading.Timer) that it uses a single thread for all Timer objects, this thread knows when the next timer (i.e. as above) is due and calls ThreadPool.QueueUserWorkItem for the callbacks as appropriate. This has the effect that if you don't finish servicing one callback on a timer before the next is due, that your callback will reenter on another pool thread. So in summary I doubt you'll see a big problem with having lots of timers, but you might suffer thread pool exhaustion if large numbers of them are firing at the same timer and/or their callbacks are slow-running.
I think you might want to rethink your design (that is, if you have control over the design yourself). If you're using so many timers that this is actually a concern for you, there's clearly some potential for consolidation there.
Here's a good article from MSDN Magazine from a few years ago that compares the three available timer classes, and gives some insight into their implementations:
http://msdn.microsoft.com/en-us/magazine/cc164015.aspx
Consolidate them. Create a timer
service and ask that for the timers.
It will only need to keep 1 active
timer (for the next due call)...
For this to be an improvement over just creating lots of Threading.Timer objects, you have to assume that it isn't exactly what Threading.Timer is already doing internally. I'd be interested to know how you came to that conclusion (I haven't disassembled the native bits of the framework, so you could well be right).
^^ as DannySmurf says : Consolidate them. Create a timer service and ask that for the timers. It will only need to keep 1 active timer (for the next due call) and a history of all the timer requests and recalculate this on AddTimer() / RemoveTimer().