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

Sat Mar 28 01:36:35 CET 2009

Hey Martin,

My spec can be summarized as follows. I have an iterative process; for each
iteration (1) distribute a large amount of computation amongst a set of
machies; (2) the computation has a small amount of dependencies, so I need a
more sophisticated load balancing algorithm than the round robin algorithm
in the butterfly example; (3) the number of machines can increase and
decrease at each iteration, and the load balancing algorithm should respond
to such events.

To achieve this, I want to use existing components as much as possible. I do
not have the resources to re-invent everything. On the other hand, I do not
expect to find all the features I need in one product, so I am willing to
build some functionality myself. I do not mind that 0MQ is designed to be a
queing system and I may not be using it in the conventional way.

Same thing for the JNI interace into 0MQ. I have modified a few of the
project files in the following way:

Jzmq.java - I moved this class from the default package to the org.zeromq
package; this entailed creating the org/zeromq directory structure in the
libjzmq directory and moving the file to that directory. I also explicitly
loaded both libzmq and jzmq libraries since Windows does not always find the
dependent libraries. Finally, I modified the signatures of all exposed
functions to match the modified signatures of the C++ wrapper (see below).

Jzmq.cpp - to allow execution of send and receive on different application
threads, I modified the context_t structure to contain an array of pointers
to an api_thread_t instead of one pointer to an api_thread_t. Now construct
takes one more argument - the number of application threads that is used to
allocate the memory for the array of thread proxies. To all other functions
I added the api_thread_id used to perform the operation on.

As a result of changing the directory structure I also needed to change the
libjzmq.vcproj file. I am attaching all modified files in case you want to
put them in SVN. You may wish to add comments, assertions, etc.

These changes seem to be consistent with your implementation philosophy (app
designer is in control). One has to be very careful which api thread ids one
uses when doing all these operations, but now I indeed get all replies:

17:48:21,069  INFO Process:89 - Sending: sim 169.254.25.129:default 0
17:48:21,069  INFO Process:114 - Received: dispatcher echo: sim
169.254.25.129:default 0
17:48:23,072  INFO Process:89 - Sending: sim 169.254.25.129:default 1
17:48:23,072  INFO Process:114 - Received: dispatcher echo: sim
169.254.25.129:default 1
17:48:25,085  INFO Process:89 - Sending: sim 169.254.25.129:default 2
17:48:25,085  INFO Process:114 - Received: dispatcher echo: sim
169.254.25.129:default 2
17:48:27,088  INFO Process:89 - Sending: sim 169.254.25.129:default 3
17:48:27,108  INFO Process:114 - Received: dispatcher echo: sim
169.254.25.129:default 3

Vladimir

-----Original Message-----
From: Martin Sustrik [mailto:sustrik at fastmq.com]
Sent: Friday, March 20, 2009 5:27 AM
To: Vladimir & Mihaela
Cc: zeromq-dev at lists.zeromq.org
Subject: Re: [zeromq-dev] Java API is not notifed of C++ assert
failures.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jzmq.cpp
Type: application/octet-stream
Size: 6542 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090327/c9cfeb59/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Jzmq.java
Type: application/octet-stream
Size: 1836 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090327/c9cfeb59/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libjzmq.vcproj
Type: application/octet-stream
Size: 4077 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090327/c9cfeb59/attachment-0002.obj>