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

Vladimir & Mihaela puiuvlad at optonline.net
Wed Apr 15 12:37:19 CEST 2009


I have not not forgotten about the PGM/multicast. At some point I will use
it, but before that I need to iron out my system architecture (which
includes regular messaging in addition to multicast).


(1) what is the limit in the number of exchange to queue bindings? I assume
it's related to the maximum number of sockets available on a machine. What
would that limit be? In the hundreds, thousands?

(2) is there an unbind function? If the number above is low then I am
thinking to close connections that are rarely used and reopen them when
needed. I could go with a different approach if an unbind is not available.

Martin, along the lines in Holger's message,

(3) here is a scenario that may run into trouble if bind asserts and kills
my process; it can be even used maliciously to bring down my system as well.

Process DIS creates a global queue and a global exchange. There are multiple
SIM processes that communicate with DIS via DIS' global objects. However, in
this case each SIM will receive messages targeted to other SIMs and will
have to filter out the ones that it is not interested in. An alternative is
to have each SIM create a global pair of objects for point to point
communication with DIS. In this case DIS will have to bind to each SIM's
global objects. So, a malicious strategy to bring down DIS would be to
connect to SIM, ask it to bind to SIM's newly created objects and
immediately exit. DIS will try to bind and will kill itself, bringing down
the entire system. Therefore the only viable architecture is the first one,
with its disadvantages - added traffic on the network, each process
filtering out what it does not need, etc.


-----Original Message-----
From: Tamara Kustarova [mailto:kustarova at fastmq.com]
Sent: Tuesday, April 14, 2009 6:52 AM
To: Vladimir & Mihaela
Cc: Martin Sustrik; zeromq-dev at lists.zeromq.org
Subject: Re: [zeromq-dev] Java API is not notifed of C++ assert


we have looked at the code you sent us, thank you for your
We are currently working on the java package structure, and will let you
know about the changes in few days.


On Mon, 2009-04-13 at 21:44 -0400, Vladimir & Mihaela wrote:
> Martin,
> Here is the modified Jzmq.java file. Nothing has changed in the C++ layer.
> have put the wrapper for the api_thread_t inside class Jzmq as inner class
> JApiThread. I hid the createQueue methods on the Jzmq object and exposed
> them in the JApiThread object.
> The usage is this:
>     _jzmq = new Jzmq(zmqHost, 2);
>     Jzmq.JApiThread api = _jzmq.getApiThreadProxy();
>     _xId = api.createExchange("E", Jzmq.SCOPE_LOCAL, host);
>     api.bind("E", "disQ");
> and in a different thread:
>     Jzmq.JApiThread api = _jzmq.getApiThreadProxy();
>     api.createQueue("Q", Jzmq.SCOPE_LOCAL, _host);
>     api.bind("disX", "Q");
>     byte[] msg = api.receive();
> Finally, "I release the code (C++ and Java) under MIT license."
> :-)
> Vladimir
> -----Original Message-----
> From: Vladimir & Mihaela [mailto:puiuvlad at optonline.net]
> Sent: Monday, April 13, 2009 6:44 AM
> To: Martin Sustrik
> Cc: zeromq-dev at lists.zeromq.org
> Subject: RE: [zeromq-dev] Java API is not notifed of C++ assert
> failures.
> Sorry, my mistake. I was delegating createExchange to createQueue and that
> caused my problem. Malo's suggestion helped (thanks, Malo). I will send
> final code tonight. Vladimir
> -----Original Message-----
> From: Martin Sustrik [mailto:sustrik at fastmq.com]
> Sent: Saturday, April 11, 2009 3:21 PM
> To: Vladimir & Mihaela
> Cc: zeromq-dev at lists.zeromq.org
> Subject: Re: [zeromq-dev] Java API is not notifed of C++ assert
> failures.
> Vladimir,
> > If I use the old Jzmq methods (with the thread id) then all's OK, but if
> > use the wrapper methods (which ultimately get translated into the same
> calls
> > to the old methods) the second process dies when trying to bind.
> IIRC you are working on Win32 and I assume the process dies without a
> diagnostic message.
> We've been looking into the problem last week and found out that
> standard Win32 assert macro misbehaves when used within JNI.
> It aborts the process, as it should, however, it doesn't print the
> message. It's completely incomprehensible why it is so, as printing to
> stdout works OK, printing to stderr works OK and CrtDbgReport works OK
> as well. assert internally calls undocumented _wassert function. There's
> no source available for that one afaics.
> To fix the problem I've replaced all 930 (sic!) asserts in
> libzmq/libjzmq code by proprietary zmq_assert. Developing for Windows
> can make even a strong man cry :(
> Anyway, if you get the trunk, you should get a meaningful message when
> the process fails. The message would help us to track the problem down.
> (Note that Java API have changed slightly since version 0.5, so when
> you'll switch to trunk you will have to adjust your code.)
> Let us know how it goes.
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list