Re: [zeromq-dev] zmq_recvmsg jni

Ok, I see this: /** * Receive a message in to a specified buffer. * * @param buffer *byte[] to copy zmq message payload in to. * @param offset *offset in buffer to write data * @param len *

Re: [zeromq-dev] zmq_recvmsg jni

hi Trevor, Thanks for posting this. Very nice. Still curious. Does it mean that using DirectByteBuffer only makes sense if one uses ZMQ+Disruptor? Second question: >>... >> ByteBuffer bb = ByteBuffer.allocateDirect(4096); >> socket.recvByteBuffer(bb, 0); >>... I also had been thinking about such

Re: [zeromq-dev] zmq_recvmsg jni

It's fairly straightforward. ByteBuffer bb = ByteBuffer.allocateDirect(4096); serialize(bb, someObj); bb.flip(); socket.sendByteBuffer(bb, 0); ... ByteBuffer bb = ByteBuffer.allocateDirect(4096); socket.recvByteBuffer(bb, 0); bb.flip(); Object deserialized = deserialize(bb); In my use case, I use

Re: [zeromq-dev] Unsure of the best topology

Hi Kieran, >>>The way it's done currently means that if we add new functionality, it >>>has to be replicated at all points, rather than a ZMQ solution, where >>>just at the client and worker would be aware of the message format, >>>everything in between would just be for moving messages. I would

Re: [zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

Hi Christian, Thanks for catching this :-) -Pieter On Wed, Oct 2, 2013 at 2:09 PM, Christian Kamm wrote: > Interesting, thanks! Could you run the test_spec_rep test in a debugger and > send a stacktrace? > > Cheers, > Christian > > Jose Pedro Oliveira wrote: > >>Hi, >> >>ZeroMQ v4 fails 2 tes

Re: [zeromq-dev] Unsure of the best topology

Hi Kieran, > Is there a better way to do this? Can it even work (i.e. have I > understood correctly)? Since half the fun of ZeroMQ is discovering the best topologies yourself, it would be a shame to point you in any specific direction. What I'll say is that it's very fast to try different designs

Re: [zeromq-dev] zmq_recvmsg jni

hi Trevor, Can you past example(s) of how you use DirectByteBuffer in jzmq? pls. 2013/10/2 Trevor Bernard : > I do that very thing with a different method signature. > > https://github.com/trevorbernard/zmq-jni/blob/master/src/main/c%2B%2B/zmq.cpp#L169 > > I've had some success with preallocating

[zeromq-dev] montonic clock II

Hello Pieter & all References: * Theo de raadt on going longlong http://www.openbsd.org/papers/eurobsdcon_2013_time_t/ * monotonic clock & issues in python : http://www.python.org/dev/peps/pep-0418/ * An implementation of monotonic timer same as yours + comment pointing out MONOTONIC_CLOCK_RAW

Re: [zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

Christian, I attached a backtrace to a previous message: * http://lists.zeromq.org/pipermail/zeromq-dev/2013-October/023025.html Ping me if you need more information. Regards, jpo On 2013/10/02 13:09 , Christian Kamm wrote: > Interesting, thanks! Could you run the test_spec_rep test in a deb

[zeromq-dev] zmq_recvmsg jni

I'm using a slightly different approach, by using 2 jni calls only (one for allocation and a general purpose call) and 2 memory arenas (one input, one output) as registers all the logic is implemented strictly in c++ and the data passed via the arena is strictly java primitives (I have a generic v

[zeromq-dev] Unsure of the best topology

Hi, I'm fairly new to ZMQ, and I'm looking to use it for a specific project to replace an unweildy HTTP solution. Currently this is what we have: We have a presence inside a NAT'ed network, we have multiple clients, and one "proxy". We have a public endpoint, with multiple workers behind it.

Re: [zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

Interesting, thanks! Could you run the test_spec_rep test in a debugger and send a stacktrace? Cheers, Christian Jose Pedro Oliveira wrote: >Hi, > >ZeroMQ v4 fails 2 tests (1 XFAIL + 1 FAIL) in Fedora 19 x86_64. >The first test fails every time "make check" is executed but >the second doesn't.

Re: [zeromq-dev] zmq_recvmsg jni

I do that very thing with a different method signature. https://github.com/trevorbernard/zmq-jni/blob/master/src/main/c%2B%2B/zmq.cpp#L169 I've had some success with preallocating a bunch of DirectByteBuffers off heap. It definitely helps with performance and GC. If I use byte[], it generates far

Re: [zeromq-dev] big endian compatibility ?

NetMQ has fixed this since version 3.3.07, any older versions of NetMQ will not talk to a newer version, or to any other zmq implementation. On Wed, Oct 2, 2013 at 11:17 AM, Pieter Hintjens wrote: > 1. The nonce is not interpreted in any way by the receiver; it's > treated as a chunk of memory.

Re: [zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

I've no real clue why this test would fail randomly but I've disabled it on libzmq master and will backport that to 4-x until someone has time to debug it. -Pieter On Wed, Oct 2, 2013 at 11:44 AM, Jose Pedro Oliveira wrote: > > On 2013/10/02 10:15 , Pieter Hintjens wrote: >> Is there any way to

Re: [zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

On 2013/10/02 10:15 , Pieter Hintjens wrote: > Is there any way to get a backtrace for the test_spec_rep failure? I'm > unable to get a failure when running it, which makes diagnosing the > problem impossible. > Here it is: $ gdb tests/.libs/test_spec_rep core.12122 GNU gdb (GDB) Fedora 7.6.1-41.

Re: [zeromq-dev] my minimal crypto_box / crypto_box_open test fails

Yes, it can be painful when the open method fails and you get zero information about what the error was. My advice is to build and test in little steps, and package up the encrypt/decrypt as I did in libcurve. Then the only errors you can get are bad input data or bad keys, which are easier to spo

Re: [zeromq-dev] big endian compatibility ?

1. The nonce is not interpreted in any way by the receiver; it's treated as a chunk of memory. The encoding is irrelevant so long as the value is unique. 2. NetMQ got it wrong initially; I believe this was fixed. On Wed, Oct 2, 2013 at 10:27 AM, Laurent Alebarde wrote: > Hi Developpers, > > Is l

Re: [zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

Is there any way to get a backtrace for the test_spec_rep failure? I'm unable to get a failure when running it, which makes diagnosing the problem impossible. On Wed, Oct 2, 2013 at 11:01 AM, Jose Pedro Oliveira wrote: > Hi, > > ZeroMQ v4 fails 2 tests (1 XFAIL + 1 FAIL) in Fedora 19 x86_64. > Th

[zeromq-dev] zeromq4-x: test failures in Fedora 19 x86_64

Hi, ZeroMQ v4 fails 2 tests (1 XFAIL + 1 FAIL) in Fedora 19 x86_64. The first test fails every time "make check" is executed but the second doesn't. System * Intel i7, 8 GB of RAM * Fedora 19 x86_64 Kernel: 3.11.1-200.fc19.x86_64 Glibc: 2.17-18.fc19.x86_64 libsodium: 0.4.3 Steps

Re: [zeromq-dev] my minimal crypto_box / crypto_box_open test fails

I forgot to add the 16 authentication bytes in crypto_box :-[ Le 02/10/2013 10:37, Laurent Alebarde a écrit : I am trying to make working a minimal test of crypto_box / crypto_box_open, based on libzmq's curve_client.cpp : uint8_t k1_public [crypto_box_PUBLICKEYBYTES]; uint8_t k1_secre

Re: [zeromq-dev] duped sockets and fork

Hi, The only solution we could find to the leaking sockets problem is to destroy parent context before fork. Then, we re-initialize the parent context after fork. Sometimes the context initialization fails at the parent, somehow the router-dealer connections are not established. We are looking at

Re: [zeromq-dev] JeroMQ

Hi Pieter, Thanks a lot. Now I see. 2013/10/2 Pieter Hintjens : > On Tue, Oct 1, 2013 at 11:01 PM, Artem Vysochyn > wrote: > >> Still totaly confused... Why need to port something on something? Why >> then not create php-port or python-port? > > There is a .Net port. I've heard rumours there is

[zeromq-dev] my minimal crypto_box / crypto_box_open test fails

I am trying to make working a minimal test of crypto_box / crypto_box_open, based on libzmq's curve_client.cpp : uint8_t k1_public [crypto_box_PUBLICKEYBYTES]; uint8_t k1_secret [crypto_box_SECRETKEYBYTES]; int rc = crypto_box_keypair (k1_public, k1_secret); uint8_t k2_public [cr

[zeromq-dev] big endian compatibility ?

Hi Developpers, Is libzmq supposed to be big-endian compatible ? Or not ? In particular, is a big-endian box supposed to be able to talk with a little endian box ? I could find this which says it is compatible in the ma

Re: [zeromq-dev] Assertion failed: get_load () == 0 (poller_base.cpp:31)

Hi Renato, What version of the library are you using? The asserts in the library do not handle error conditions but impossible situations caused by remaining bugs in the code, or unknown states. In these situations there is no way to recover. If the process continued, the results could be data se

[zeromq-dev] Assertion failed: get_load () == 0 (poller_base.cpp:31)

Hi, While running an extensive test sending messages from PUB/SUB pattern, we had an assertion failure that caused a kill of a process. The message says: Assertion failed: get_load () == 0 (poller_base.cpp:31) This comes from a PUB process and after the socket was closed. Also, this ass

Re: [zeromq-dev] Certificate formats

So this may be a very stupid question, but what does a certificate have to hold that is so complex? We have one or two keys, some meta data... why would you'd be thinking of anything more complex than plain text? For a grid, yes, a certificate server seems the right model. I've not thought about C