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

[Martin Sustrik]

Hi Vladimir,

> 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.

Ok, clear. Understood.

> 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.

Moving jzmq to org.zeromq package makes sense. I've created a ticket for 
it (ZMQ-226). It'll get into the trunk only post 0.6 release though.

> I also explicitly
> loaded both libzmq and jzmq libraries since Windows does not always find the
> dependent libraries.

Hm. Have you seen it make any difference? libzmq is a standard DLL (not 
a Java one) so it should be found on system path.

Does doing it this way mean that the library is looked for on java 
classpath? And if so, is it a right thing to do?

> 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.

Ack. We'll add something like this to the API later on, however, I would 
prefer encapsulating each API thread into a separate object rather then 
passing ID to each method. It looks somehow more neat.

> 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.

As to be able to use your code you have to submit it under MIT license.

> 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

Nice :)

Martin