How can I gain access to the thread pool used in RMI?
I read that RMI manages thread creation for each remote call but I want a way in which I can manipulate the thread creation.
I need to limit the number of threads so that, for example, only two threads serve two clients, and if another client makes a call, it will wait for one of the two previously created threads to become available.
In other words, I want to implement a fixed-size thread pool in RMI. How can I do that?
How can I get access to thread pool used in RMI?
There is no thread pool used in RMI. At least not in the Sun/Oracle-built RMI.
I read that RMI manage the process of threads creation for each remote call
Certainly but not via a thread pool.
but I want a way in which I can manipulate in that process. I need to limit the number of threads so that only two thread -for example- are serve two clients, and if another client make a call, it will wait for one of this threads be available.
You don't state why, and it sounds like a terrible idea, or else a job for a counting semaphore, but you can't do this as described. The RMI Specification carefully makes no guarantees about the association of threads to clients.
In other words i want to implement a thread pool with fixed size in RMI.
How can I do that?
You can't.
Related
I read it is not possible to restart the same Thread. If it should be restarted, then you have to create a new Thread.
But the thing is, the threads are limited, you can not create 40,000 threads because the operating system can only create 15,000 threads. (This is just an example).
Is there another possibility?
But the thing is, the threads are limited, you can not create 40,000 threads because the operating system can only create 15,000 threads. (This is just an example).
Yes, that's confusing - but you're mixing terms.
A java java.lang.Thread object is not an OS-level thead.
You can make a million or so Thread objects. Go ahead, try it.
You would not be able to simultaneously start all 1 million of em, however - start() causes things to occur, eventually leading to an 'OS level thread' to be created.
Once a thread ends, the java.lang.Thread object will stick around, but the OS level thread won't. Hence, your central problem thesis, which I'll summarize as:
Restarting an existing java.lang.Thread object is better than creating a new java.lang.Thread object, because I read that you can only have 40k or so java.lang.Thread objects
Is just flat out wrong. There is zero benefit between a hypothetical re-use of a j.l.Thread object by 'restarting' it (which implies it has ended), vs. just making a new object instead once the 'old' one has ended.
What you'd have to do if you want to 'restart' a thread is to have a run() method (the one that the thread ends up running in a new thread) that is a frameworky thing: It checks a queue of jobs, pulls one queue off the top, runs it, and then goes back to checking the queue. This is tantamount to 'reusing a thread', though you're now just reinventing what ExecutorPool (baked into core java itself) and friends already do.
ExecutorPools are probably a good idea. However, they don't 'solve' your problem. Your problem isn't actually a problem.
Use an Executor or ExecutorService. Class Executors has some factory methods for those. By using one that uses a thread pool you can submit actions without threads necessarily being created for each separate action.
You can use a thread pool. Database connections are often managed in a thread pool, for example. After it has done its work (e.g., queried some data), the thread returns to the pool, and can be reused.
The other thing you may be missing is: while you cannot have e.g., 40,000 threads at a time, nothing prevents you from creating new threads after old ones have finished.
Our current course assignment specifies that we are supposed to create a manager for a thread pool using the "Object Pool Manager" design pattern which spawns a set amount of threads. The ownership of these threads shall be transferred to the client and then back to the pool after the client has finished using it. If no thread exists in the pool then the client has to wait.
My confusion comes from the fact that a thread is supposedly not reusable, which defeats the purpose of pooling them. Have I understood the assignment incorrectly?
Threads are reusable as long as they have not ended. A pool of threads generally involves threads that do work as it is given to them, and then wait for more work. Thus, they never end until explicitly told to do so. The trick is designing them in a way such that the work they are given ends, but the thread itself does not. Thread pools are useful because it is often relatively expensive to create/destroy threads.
#Kaliatech has already explained the concept behind re-use of threads. Also "The ownership of these threads shall be transferred to the client" is slightly misleading as the ownership of threads generally remain with the thread-pool/object-pool as it is the manager of this pool and the client should simply submits the task to the pool which can either complete successfully or fail. The thread continues to run ready to pick the next task submitted to the pool. As a design too the separation of task object ( Runnable/Callable) and the object representing thread execution (Thread) are designed to be different. Should the need arise the thread-pool is responsible for ramping up/down the number of threads as they are expensive to create and manage. Java ThreadPoolExecutor will be a good example to refer to how typically such a thread pool works.
When using a thread pool, is it beneficial to still use singular thread objects for a specific task. I'm wondering in terms of a server in Java, whether or not the thread which is listening for connections, should share its resources with any other threads which are then allocated from this one listening thread? I may also be missing the point as I'm not familiar with this concept.
Yes, singular tasks that have to run concurrently can have their own threads outside of the thread pool. Forcing every thread to be part of the pool might obscure your design because you need all kinds of machinery to make concurrent tasks look like worker threads.
I'd create two pools, one for listening and one for internal tasks. This way you're never putting your server at risk of not being able to listen for connections.
The pool for internal tasks can be small if it's only a thread now and then, but at least it's safely isolated.
Resource sharing might be necessary in cases where your server needs to maintain a global application state (e.g. using an AtomicLong for the number of requests served by your server etc.). Your main thread would typically wait, ready to accept incoming connections/requests. You then update the global state (like hit counter), create a new "job" based on the new request (typically a Runnable or Callable) and submit it to a thread pool (java.util.concurrent) provides them.
The purpose of a thread pool is just to help you manage your threads. In other words, a thread pool handles the creation and termination of threads for you as well as giving work to idle threads. Threads that are blocked or waiting will not receive new tasks.
Your connection listener will probably be in an infinite loop waiting for connections and thus never be idle (although it could be in a wait state). Since this is the case, the connection listener thread will never be able to receive new tasks so it wouldn't make sense to pool it with the other threads.
Connection listening and connection handling are also two different things. From that perspective the connection listener shouldn't be pooled with the connection handlers either.
SImilar to #larsman's comment, I would do what ever you feel is simpler and clearer. I have tended to use one thread pool for everything because it appeared to be easier to manage. You don't have to do it that way and the listening task can be its own thread.
I'm using a thread pool to execute tasks in the background of my application. However, some of my tasks are heavier than others. So I'd like to limit the heavy tasks to a certain subset of the thread pool, thereby leaving at least a few threads open for any lightweight tasks to execute.
Is there a simple way to do this?
The most simple way is to use separate thread pools for different "tasks weight".
Even you can create separate class which exposes separate methods for differents tasks.
As it was said, the cleanest way is to use a separate thread pool for heavy threads.
Another way is to use a Semaphore. Create a semaphore with a count of, for example, three. Heavy threads have to acquire() it first. Only three heavy ones would be able to do so. The rest will wait (or fail, if you use tryAcquire()).
Of course, the thread needs to "know" it is a "heavy" one. For third-party threads it doesn't work, so see "two pools" approach again. :-)
When writing a multithread internet server in java, the main-thread starts new
ones to serve incoming requests in parallel.
Is any problem if the main-thread does not wait ( with .join()) for them?
(It is obviously absurd create a new thread and then, wait for it).
I know that, in a practical situation, you should (or "you must"?) implement a pool
of threads to "re-use" them for new requests when they become idle.
But for small applications, should we use a pool of threads?
You don't need to wait for threads.
They can either complete running on their own (if they've been spawned to perform one particular task), or run indefinitely (e.g. in a server-type environment).
They should handle interrupts and respond to shutdown requests, however. See this article on how to do this correctly.
If you need a set of threads I would use a pool and executor methods since they'll look after thread resource management for you. If you're writing a multi-threaded network server then I would investigating using (say) a servlet container or a framework such as Mina.
The only problem in your approach is that it does not scale well beyond a certain request rate. If the requests are coming in faster than your server is able to handle them, the number of threads will rise continuously. As each thread adds some overhead and uses CPU time, the time for handling each request will get longer, so the problem will get worse (because the number of threads rises even faster). Eventually no request will be able to get handled anymore because all of the CPU time is wasted with overhead. Probably your application will crash.
The alternative is to use a ThreadPool with a fixed upper bound of threads (which depends on the power of the hardware). If there are more requests than the threads are able to handle, some requests will have to wait too long in the request queue, and will fail due to a timeout. But the application will still be able to handle the rest of the incoming requests.
Fortunately the Java API already provides a nice and flexible ThreadPool implementation, see ThreadPoolExecutor. Using this is probably even easier than implementing everything with your original approach, so no reason not to use it.
Thread.join() lets you wait for the Thread to end, which is mostly contrary to what you want when starting a new Thread. At all, you start the new thread to do stuff in parallel to the original Thread.
Only if you really need to wait for the spawned thread to finish, you should join() it.
You should wait for your threads if you need their results or need to do some cleanup which is only possible after all of them are dead, otherwise not.
For the Thread-Pool: I would use it whenever you have some non-fixed number of tasks to run, i.e. if the number depends on the input.
I would like to collect the main ideas of this interesting (for me) question.
I can't totally agree with "you
don't need to wait for threads".
Only in the sense that if you don't
join a thread (and don't have a
pointer to it) once the thread is
done, its resources are freed
(right? I'm not sure).
The use of a thread pool is only
necessary to avoid the overhead of
thread creation, because ...
You can limit the number of parallel
running threads by accounting, with shared variables (and without a thread pool), how many of then
were started but not yet finished.