Reputation: 1068
I am writing a multi-threaded solution in Java to connect two systems, A & B. System A is completly serial, not threaded, and will supply data to send to system B. System B accepts data from multiple sources asynchronously all at the same time.
I am using ThreadPoolExecutor to manage the threads. I am using a static singleton instance of a class, TP, that wraps around ThreadPoolExecutor (which is also static) because system A cannot create new objects but it can make calls to static objects.
Here is where I am stuck. I am doing some very basic testing of the setup before I go all out. I created two classes for testing, T1 & T2. Each of these classes imports the class TP (where the static singleton is created). T1 adds some objects to the TP queue and then T2 adds some more.
Even though the TP object is declared as static, it looks like there are two versions running in parallell. The objects submitted to the queue by T2 are being executed before the object submitted by T1 have all been executed. Also, since neither T1 or T2 calls shutdown() on the ThreadPoolExector, they both hang and never terminate.
How can I create a daemon static instance of a tread that basically wakes up whenever I send something to be processed, even from different Java executables?
Upvotes: 0
Views: 375
Reputation: 15788
It sounds to me like you're running two different 'main' classes that each use this same static singleton class. In that case, there will be two instances of the singleton created -- one in each JVM.
I think what you want to do is have the thread pool encapsulated in another process that runs as a service and exposes some mechanism for IPC as Skeet has commented. A common way to do this would be to expose a JMS queue to receive requests from different producers and have the consumer (your daemon) dispatch the requests it receives to the thread pool for processing.
For running this service as a daemon, you could host it in a container or use something like the Java Service Wrapper if you're running on Windows.
Upvotes: 0
Reputation: 1502216
If you're running two separate processes, then you've got two separate types and two separate instances, regardless of whether it's a singleton.
If you want two different processes to talk to each other, you'll need to address that issue entirely separately. There are plenty of different IPC mechanisms available - networking, named pipes (tricky from Java IIRC), memory mapped files, a simple shared directory where one process places tasks for the other to process etc.
It's also not clear exactly what's hanging, or how your thread-pool is configured. If the problem really is the threading side (rather than the IPC side) then please post a short but complete program which demonstrates the problem.
Upvotes: 1
Reputation: 31463
If the size of the thread pool is greater than 1 then there is no guarantee that all the T1 objects will be processed first.
Upvotes: 0