During a job meeting.I have heard that Thread Local is absolutely an anti pattern because new Application servers uses new Thread technologies called new IO.In fact,they told me that the problem with ThreadLocal is that a complete thread must wait for the database query to return a response and that's absolutely a waste of resources(memory as well as CPU).
New developed Thread strategy uses a pool of threads so when a thread is not needed any more it will return to pool.What i have heard is that this new Technology is implemented in new AS such us Jboss,Websphere...(i'm not sure).
Can i use it locally with Apache tomcat for example?(if it's possible documentation on that fact)
ThreadLocal is a side character in your story. What you have heard about is asynchronous request processing, which is helped, among other things, by the NIO library.
In this programming paradigm, you don't get a simple method like
Response processRequest(Request req)
Instead you get
void requestReceived(Request req, Response resp)
and within this method you will usually just start the processing by preparing the back-end request and calling its method which will look like
execute(Query q, ResultCallback cb)
and the framework will call your ResultCallback's method resultReady(Result res) which will contain the query result.
The main point here is that the method requestReceived will return immediately, and will not occupy the thread while the back-end request is being processed at the back-end subsystem.
BTW another name for this style of programming is continuation-passing style or CPS. It is because when you call a function, you don't wait for its return value, but rather pass a callback into it which will be called with the function's result, and which implements the continuation of the total request processing.
How ThreadLocal fits into this
If you have followed what I have said above, it should already be clear to you that in this style of request processing, ThreadLocals are a useless concept because the request processing freely jumps from thread to thread, and in a way which is completely outside of your control.
ThreadLocal has basically nothing to do with databases or ThreadPools/ExecutorServices. ThreadLocal just means that the value stored in it is just visible to the Thread how set it. This doesn't cause any blocking. You must confuse some things there.
ThreadLocal: Stores variable per Thread.
"new IO": They most likely meant the java.nio package. It about reading/writing data without blocking.
Threadpools/Executorservice: Bunch of Threads where you can submit Runnables to. You can use ExecutorServices in any Java application, because they are part of the standard library.
For accessing the database you normally use a dedicated system like C3P0, which manages Threads and database connections
I think that i misunderstand the subject.
Well,i will explain in detail what i have heard.
When using ThreadLocal.If we have for example a query to DataBase or JMS call .The thread must be alive for the response to return (suppose that takes 15 minute for example).The thread will be in a waiting situation waiting for Db to return response.so it's a waste for CPU as well as memory.
New Thread management technology uses a pool of threads.In fact during the waiting time.The thread will be used to server another client.
That's what i have heard.
To Marko Topolnik:What you have exposed is asynchronous calls and it does nothing to do with Threads.
ThreadLocals, thread pools, and new IO can cooperate quite well. All you need is to define thread factory when creating a threadpool so that each new thread would get correct threadlocal value at the moment of creation. This value, for example, can keep a reference to java.nio.channels.Selector singleton. Another thread local variable can hold reference to the thread pool itself, so submitting new tasks to the thread pool can be simplified.
Asynchronous framework https://github.com/rfqu/df4j uses thread locals intensively this way.
Related
I want to build a process flow. I have multiple requests to process in a queue. One thread (call it T1) takes the first request start processing it and then passes it to some other thread (from a pool of threads lets call it T2) at a point when it has to do some blocking database access. T1 should get free now to process another request from queue. The blocking database access is done by a thread from T2 pool. Then after the database operation is completed, thread from T2 passes it to a thread T3 which return the processed result of the request and after that gets free to return another result processed by T2.
I want to do this to avoid one thread for one request model as it would bring a lot of context switching overheads and all threads will eventually block on database access and CPU resources will be wasted at that time. The T1 and T3 threads can be considered as thread pools of size of limited size depending on the cores in the CPU.
I thought about above approach after getting to know about async servelet as after getting the request it does not block the thread and instead a different thread does the job and returns the response later.
Let me know if the process flow I need to build is feasible in java and some resources on how can it be achieved.
Splitting a single request seems like a nice idea, but to optimize use of resources, I would look for using semaphores and have each request be handled by a different thread.
Try limiting the number of requests with semaphores, and limit the access to resources that can be accessed only one at a time also with semaphores.
Splitting a single request can be a good idea, but I think it is a good idea mostly in the case scenario that you want to save the data inside some files, to lower the memory usage of the threads.
I will try adding some Java code later if I can find my old projects...
Java Docs says CompletableFuture:supplyAsync(Supplier<U> supplier) runs the task in the ForkJoinPool#commonPool() whereas the CompletableFuture:suppleAsync(supplier, executor) runs it in the given executor.
I'm trying to figure out which one to use. So my questions are:
What is the ForkJoinPool#commonPool()?
When should I use supplyAsync(supplier) vs supplyAsync(supplier, executor)?
ForkJoinPool#commonPool() is the common pool of threads that Java API provides. If you ever used stream API, then the parallel operations are also done in this thread pool.
The advantage of using the common thread pool is that Java API would manage that for you - from creation to destruction. The disadvantage is that you would expect a lot of classes to share the usage of this pool.
If you used an executor, then it is like owning a private pool, so nothing is going to fight with you over the usage. You make to create the executor yourself, and pass it into CompletableFuture. However, do note that, eventually the actual performance would still depend on what is being done in the threads, and by your hardware.
Generally, I find it fine to use the common thread pool for doing more computationally intensive stuff, while executor would be better for doing things that would have to wait for things (like IO). When you "sleep" in common thread pool thread, it is like using a cubicle in a public washroom to play games on your mobile phone - someone else could be waiting for the cubicle.
I am trying to use both InheritableThreadLocal and a ThreadPoolExecutor.
This breaks down because ThreadPoolExecutor reuses threads for each pool (it is a pool, after all), meaning the InheritableThreadLocal doesn't work as expected. Now the problem seems obvious to me, but it was particularly snarly to track down.
I use InheritableThreadLocal so that each of several top-level processes has its own database connection for itself and any sub-processes it spawns. I don't just use one shared connection pool because each top-level process will do a lot of multi-step work with its connection before committing to the database and/or preparing a lot of PreparedStatements that are used over and over.
I use a shared ThreadPoolExecutor between these top-level processes because there are certain behaviors that need to be gated. e.g. Even though I might have 4 top-level processes running, I can only have any one process writing to the database at a time (or the system needs to gate on some other shared resource). So I'll have the top-level process create a Runnable and send it to the shared ThreadPoolExecutor to make sure that no more than one (or two or three as the case may be) are running at the same time across the entire system.
The problem is that because the ThreadPoolExecutor reuses its threads for the pools, the InheritableThreadLocal is picking up the original value that was run in that pool rather than the value that was in the top-level process which sent the Runnable to the ThreadPoolExecutor.
Is there any way to force the worker pool in the ThreadPoolExecutor to use the InheritableThreadLocal value that was in the context of the process which created the Runnable rather than in the context of the reused thread pool?
Alternatively, is there any implementation of ThreadPoolExecutor that creates a new thread each time it starts a new Runnable? For my purposes I only care about gating the number of simultaneously running threads to a fixed size.
Is there any other solution or suggestion people have for me to accomplish what I've described above?
(While I realize I could solve the problem by passing around the database connection from class to class to subthread to subthread like some kind of community bicycle, I'd like to avoid this.)
There is a previous question on StackOverflow, InheritableThreadLocal and thread pools, that addresses this issue as well. However, the solution to that problem seems to be that it's a poor use case for InheritableThreadLocal, which I do not think applies to my situation.
Thanks for any ideas.
using InheritedThreadLocal is almost surely wrong. Probably you'd have not asked the question if you can fit that bizarre tool.
First and foremost it's horribly leak-prone and often the value(s) escapes in some totally strange threads.
As for the Runnable being associate w/ a context.
Override publicvoid execute(Runnable command) of the ExecutorPool and wrap the Runnable withing some context carrying the value you want in the first place from the InheritedThreadLocal.
The wrapping class shall look something like
class WrappedRunnable extends Runnable{
static final ThreadLocal<Ctx> context=new ThreadLocal<Ctx>();
final Runnable target;
final Ctx context;
WrappedRunnable(Ctx context, Runnable target){...}
public void run(){
ctx.set(context);
try{
target.run();
}finally{
ctx.set(null);//or ctx.remove()
}
}
}
Alternatively, is there any implementation of ThreadPoolExecutor that creates a new >thread each time it starts a new Runnable? For my purposes I only care about gating the >number of simultaneously running threads to a fixed size.
While truly bad from performance point of view, you can implement your own, basically you need only execute(Runnable task) method for the Executor that spawns new thread and starts it.
Instead of using a ThreadPoolExecutor to protect shared resources, why not use a java.util.concurrent.Semaphore? The sub tasks you create would run to completion in their own threads, but only after having acquired a permit from the semaphore, and of course releasing the permit when done.
We had the same issue earlier and we solved this issue by writing ThreadLocalContextMigrator which basically copies the thread local context to the task that will be executed using a thread from the pool. The Task, while executing will collect more context info and upon completion of the task we copy it back.
Why not just pass the current connection on to any sub-tasks spawned by the main task? maybe some sort of shared Context object?
This question already has answers here:
Is ExecutorService (specifically ThreadPoolExecutor) thread safe?
(6 answers)
Closed 4 years ago.
I was working on a Java EE app that took in user requests from a UI and then keyed off a lon workflow asynchronously for each of these requests using ExecutorService (SinglethreadExecutor). Now since i was using a SinglethreadExecutor and because there was genuine need for the requests to be served one at a time, i did not feel the need for thread safety.
Is my understanding correct ?
Recently i had asked a question Issue when executing asynchronous tasks using ExecutorService and the solution to this question was that i make my code thread safe.
I'm looking if any shared resources that I'm using in my code is causing the need for this thread safety but would just like to be sure that my understanding of
the scenario is correct.
FYI, I have implemented my ExecutorService in a servlet as mentioned in Running a background Java program in Tomcat
Your requests will be passed to a different thread to be executed. Even if this thread doesn't access shared data structures, the passing of the request to the thread and the returning of the result need to be properly synchronized.
If you use one of the submit or invoke methods which use a Future object for returning the results, you can assume that the appropriate synchronization is performed. The javadoc for ExecutorService says this:
Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken by that task, which in turn happen-before the result is retrieved via Future.get().
In short, if the requests / tasks don't use shared data structures and you use the interface methods provided, then you should be OK.
There are two things that you need to consider when you need to make something "thread safe": When does a thread make data visible to anyone else? When does a thread try to read shared data?
Imagine this situation: Thread A gets the request. It works a bit on it. Then it calls a method foo() that gets the request as a parameter. foo() starts a new thread. The thread puts the reference to the request as a private, non-final field.
In hardware, thread A has copied the request into the L1 cache of the CPU core on which it runs. Since there is no synchronization between the two threads, A has no idea that some other thread might want to read the modified request, so it never flushes the cache (or it does it too late).
This means that thread B will get a stale request object. It won't see any changes made by thread A. As you can imagine, this usually works: If A doesn't change the request, B works. It breaks as soon as you change the code of A and you have a "but it worked yesterday!" situation.
To fix this, you must tell A to flush its caches even if the current version of your code works without it. There are several ways to do it; Stephen C described one. Two other ways:
You can synchronize foo() - A thread must flush when it enters a synchronized block.
Make the request a final field of B - Object graphs referenced via final fields must be completely flushed at the time the type construction has completed (where type == the class which contains the final field).
So I have a long running process that I want to encapsulate as a Runnable and dispatch it in a thread. To be more specific, I have a POST web service that creates a file in the file system but the creation of the file can take a very long time.
In the resource method of my web service, I want to be able to dispatch a thread to do the file creation and return the status 200. I don't think I can just do Thread.join because this would mean that the current thread would have to wait for the file creation thread to finish. Instead, I want to join the file creation thread to the main thread. Question is, how do I get the main thread in java?
I am not sure whether I get you right. Here is what I understood:
You want to preform a possibly long running operation (file creation)
you do not want you service method to block while that task is exectued
you want the task executed in a thread that exists outside the boundary/lifetime of the single request.
Am I right so far?
If sou really recommend you look into the newer concepts in java.util.concurrent. The concepts described there should give you enogh information tackkle this
Basic credo: Don't think in threads, think in tasks.
General Book recommendation: Java Concurrency in Practice by Brian Goetz
You will need to process the request asynchronously. A separate thread will be created for doing the heavy work and the request receiving thread will be free to process other requests. Please checkout following articles.
Asynchronous processing in Servlet 3.0
Asynchronous support in Servlet 3.0 spec
Asynchronous Support in Servlet 3.0
When you spawn the file-creation thread, you need to pass it some kind of reference to the parent thread, so it can communicate back (i.e. you provide something to enable a callback).
This could be the actual Thread object (obtained using Thread.currentThread, as someone said in a comment) or some other object that you use to signal when the file-creation thread is done.