[zeromq-dev] Java API is not notifed of C++ assert failures.

Martin Sustrik sustrik at fastmq.com
Fri Mar 20 11:26:58 CET 2009


Vladimir & Mihaela wrote:
> Martin,
> 
> I have two processes - a dispatcher and a worker. The dispatcher creates a
> global queue and a global exchange. The worker creates a local queue and a
> local exchange, and binds each of them to the opposite object in the
> dispatcher. The dispatcher listens to the worker request and replies right
> away (in the same thread). The worker sends 10 messages to the dispatcher
> and goes on doing work. On a different thread, the worker listens to the
> dispatcher responses.
> 
> I tried to run this test using the Java API. Here is the worker log:
> 
> 17:33:20,551  INFO Process:87 - Sending: sim 169.254.25.129:default 0
> 17:33:20,561  INFO Process:106 - Received: dispatcher echo: sim
> 169.254.25.129:default 0
> 17:33:22,564  INFO Process:87 - Sending: sim 169.254.25.129:default 1
> 17:33:24,567  INFO Process:87 - Sending: sim 169.254.25.129:default 2
> 17:33:26,570  INFO Process:87 - Sending: sim 169.254.25.129:default 3
> 17:33:28,572  INFO Process:87 - Sending: sim 169.254.25.129:default 4
> 
> As you can see, the worker thread receives only the first reply; the rest
> are lost.
> 
> I then re-read the 0MQ documentation on the Java API: "Java extension
> creates single I/O thread that can be accessed from a single application
> thread. ... it is our intent to expose full 0MQ API via Java in the future."
> Any ETA on this?

We are not a Java shop here so adding functionality to Java API is 
rather painful. If you want to help with this it's actually pretty 
straightforward - except for the Java bit :). Constructor has to take 
"number of threads" parameter and return N "API" objects instead of a 
single one. In C++ you it is done this way:

//  Say we want 3 client threads.
dispatcher_t dispatcher (4); //  3 client threads + one I/O thread
locator_t locator (hostname);

//  Create the I/O thread.
i_thread *io = io_thread::create (&dispatcher);

//  Create client threads.
api_thread_t api1 = api_thread_t::create (&dispatcher, &locator);
api_thread_t api2 = api_thread_t::create (&dispatcher, &locator);
api_thread_t api3 = api_thread_t::create (&dispatcher, &locator);

//  Each API object exposes whole set of 0MQ functions.
api1->create_exchange (...);
api1->bind (...);
api1->send (...);

> Also, your explanation regarding how would the dispatcher detect when a
> worker thread disconnects is still not clear to me.
> 
> From an application perspective, the dispatcher (HA pair, when available)
> responds to the "join the collective" message sent by an unknown number of
> worker processes. If a worker disconnects gracefully, it can send a "leave
> the collective" message to the dispatcher. I would like to be able to detect
> when a worker has crashed (for example) and is no longer available. My tests
> show that when that happens the dispatcher does not crash (as I was fearing
> your reply implied).

Maybe I am misunderstanding what you are trying to achieve. The basic 
design principle of queueing systems is that the applications are 
decoupled, i.e. they application doesn't know whether the other 
application is online, offline, crashed or whatever.

So you have a symbolic endpoint (either a queue or an exchange) and you 
don't care about what's going on behind it. Queueing system (0MQ) should 
take care of that.

Martin





More information about the zeromq-dev mailing list