The question
The software runs on one DELL server with Linux.
Language could be C++, JAVA or Python.
Both thread A and thread B assign tasks to the service thread. When receiving tasks, service thread will put the tasks on its own task queue. When thread is free, it will execute the tasks and return task results to thread A or thread B depending on who sent request.
Thread A has a higher priority than thread B.
My thoughts
It is very similar to server/client in socket programming. However, since this software runs on one same server, TCPIP does not seem a good solution to me.
Another thought is to use a common database for this, such as redis. But Redis runs also on TCPIP and I am not sure if this could be a good fit.
Someone also suggests using a service DLL and both Thread A and Thread B can invoke service DLL directly. However I do not have experiences building DLL simultaneously serving several threads. Is this possible?
My question is: how to achieve this in a suitable way?
Related
I am trying to test an application with Jmeter. The application uses a proprietary library that creates multiple threads. In JMeter I have created a AbstractJavaSamplerClient, which does not seem to wait for all the other threads that might be generated in the application. Instead it just runs its own default method and closes leaving the other threads running in the background - since I am connecting to a server in the application, I can see through the server logs that it is still connected. Since I don't have the references to the other threads as they are instantiated through the proprietary library, I can't use the common solutions of wait() or join().How can I get the main thread to wait for all the threads (none of which I have references too)?
Put all work with the library in a separate thread in a specially created thread group. The library will create new threads in that thread group and its descendants. List all threads of that group recursively with group.enumerate(new Thread[group.activeCount()*2],true). Then you can join() them all.
You can start with
Thread.getAllStackTraces().keySet();
which will give you a set of all running threads. This will include those you are interested in and all the other threads, including those internal to the JVM.
Hopefully you'll be able to filter out the ones you are interested in by name, and then you can join() them.
I have been poring over some research for multithreaded programming, such as this academic webpage, and have noticed that it is quite popular to create one Thread for each client that connects to a given server. In fact, I have found some sample client-server program that does just this. (I attempted to adopt the idea, but now, I am in doubt.) According to Java: How to Program, it is recommended that I use the ExecutorService to create and manage Threads since the programmer cannot predict when a Thread will actually be dispatched by the system, despite the order in which threads are created and started.
What I intend to do
As mentioned earlier, I am creating a server that creates a Thread for each client. The clients are to send data to me, and the Thread will fetch the data, store it in a file, and log the data.
My question
Would using the ExecutorService to create Threads (and manage them!) be effectively the same as giving each client a Thread , but more manageable? Also, would it eliminate the overhead caused by the famous "one-thread-per-client" idea?
Would using the ExecutorService to create Threads (and manage them!) be effectively the same as giving each client a Thread , but more manageable?
yes
Also, would it eliminate the overhead caused by the famous "one-thread-per-client" idea?
no. The overhead is usually in terms of the number of active threads which is not changed by using a thread pool.
I have a problem with a Tomcat server that is unable to shutdown gracefully. I have taken a thread dump after I issued the shutdown command, and it looks like this:
http://pastebin.com/7SW4wZN9
The thread which I believe is the "suspect" that does not allow the VM to shut down is the one named "pool-4-thread-1". The rest of them are either daemon threads or internal VM threads. While trying to find out what this thread is for, I noticed that there are other java programs out there that create threads with similar names (For example, JVisualVM creates such threads).
So I'm wondering if someone else knows what this thread is and how it can be created.
These threads are probably created by an ExecutorService that you created in your code somewhere (directly or indirectly through a library) and that needs to be shutdown (for example in a ServletContextListener).
I might have a problem with my application. There is a client running multiple threads which might execute rather time consuming calls to the server over Java RMI. Of course a time consuming call from one client should not block everyone else.
I tested it, and it works on my machine. So I created two Threads on the client and a dummy call on the server. On startup the clients both call the dummy method which just does a huge number of sysout. It can be seen that these calls are handled in parallel, without blocking.
I was very satisfied until a collegue indicated that the RMI spec does not necessarily guarantee that behavior.
And really a text on the hp of the university of Lancaster states that
“A method dispatched by the RMI runtime to a remote object
implementation (a server) may or may not execute in a separate thread.
Calls originating from different clients Virtual Machines will execute
in different threads. From the same client machine it is not
guaranteed that each method will run in a separate thread” [1]
What can I do about that? Is it possible that it just won't work in practice?
in theory, yes, you may have to worry about this. in reality, all mainstream rmi impls multi-thread all incoming calls, so unless you are running against some obscure jvm, you don't have anything to worry about.
What that wording means is that you can't assume it will all execute in the same thread. So you are responsible for any required synchronization.
Based on my testing on a Mac laptop, every single client request received in parallel seems to be executed on a separate thread (I tried upto a thousand threads without any issues. I don't know if there is an upper bound though. My guess is that the max no. of threads will be limited only by memory).
These threads then hang around for some time (a minute or two), in case they can service more clients. If they are unused for some time, they get GC'ed.
Note that I used Thread.sleep() on the server to hold up every request, hence none of the threads could finish the task and move on to another request.
The point is that, if required, the JVM can even allocate a separate thread for each client request. If work is done and threads are free, it could reuse existing threads without creating new ones.
I don't see a situation where any client request would be stuck waiting due to RMI constraints. No matter how many threads on the server are "busy" processing existing requests, new client requests will be received.
Abstract Question
What is the best way to load resources into memory that will be shared across servlets in a Java application server?
What I am actually doing
I want to create a daemon thread that monitors a queue. This queue could have objects added to it from servlet threads. The thread would wait until a set period of time and check the queue to see if it had items in it, if so then it would process them and remove them. This thread would need to be started somewhere at sometime. I was thinking that a servlet with only the init method implemented would work for this task or is there a better place to put startup code like this in an application server? Am I approaching the problem all wonky?
Updates
I found this question and the accepted answer was to use the LifeCycle Listener. Is this a portable way of doing things or is my code going to be tied to a single application server. A bit more investigation led me to a find a few posts on message boards saying that I could do this in a ServletContextListener implementation.
I usually start these kinds of worker threads indirectly from a Servlet using the method you describe (usually they exist inside some other object that does the queue extraction and controls the processing).
For pulling objects off the thread, you don't need to do it based on time, you could have your thread wait() on the queue object and when an object is put onto the queue by some other thread, that thread would call notify() on the queue to release the watching 'worker' thread.
Google 'java worker thread wait notify' for many examples.