views:

133

answers:

3

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?

A: 

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.

Matthew Murdoch
I don't mind if the processing of the objects completes in order but I do need them to begin processing in order. Meaning, if I submit 1, 2, 3 I want 1 to start processing before 3 but I do not need for 1 to complete processing before 3 starts.
JediPotPie
+1  A: 

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.

Jon Skeet
I should have mentioned that I declared the ThreadPoolExecutor object as static. So, shouldn't this be "shared" by all instances of the TP class?From Sun:Fields that have the static modifier in their declaration are called static fields or class variables. They are associated with the class, rather than with any object. Every instance of the class shares a class variable, which is in one fixed location in memory. Any object can change the value of a class variable, but class variables can also be manipulated without creating an instance of the class.
JediPotPie
They're shared within the same process (well, not quite necessarily, but we'll leave out classloaders for the moment). If you've got two different processes running, they're entirely separate.
Jon Skeet
Ah, I see. It would be in the case where I create two instances of the same class within the same executing process (main, etc..) but not two different processes. Makes sense.
JediPotPie
A: 

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.

Paul Morie
You are right, that's how I am running the tests. I guess I don't really need a daemon I just need to be able to add the objects to the same ThreadPoolExecutor pool. I thought that if I made the ThreadPoolExecutor object static that all instances of the TP class would use the same instance of ThreadPoolExecutor.
JediPotPie