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
* max bytes to write to buffer.
* If len is smaller than the incoming message size,
* the message will be truncated.
* @param flags
* the flags to apply to the receive operation.
* @return the number of bytes read, -1 on error
*/
public native int recv (byte[] buffer, int offset, int len, int flags);
Have no more questions :)
2013/10/3 Artem Vysochyn <artem.vysoc...@gmail.com>:
> 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 construction, but my question is
> -- what we win here? I.e. one still has to make a call to jzmq':
> byte[] buf = socket.recv(flag). So, we do jni call .recv() and get
> copy of byte[] from native code. Then we copy that byte[] into DBB.
> I'm not judging, but just trying to figure out for myself, what one
> could win with DBB for receiving operation?
>
>
> Thanks in advance.
> -artemv
>
> 2013/10/2 Trevor Bernard <trevor.bern...@gmail.com>:
>> 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 the LMAX Disruptor in conjunction with zeromq. I
>> preallocate the RingBuffer with off-heap ByteBuffers to reduce GC and
>> to create a pool. This also is more efficient since it had one less
>> copy and you are reusing the ByteBuffers.
>>
>> Something like this:
>>
>> public final static EventFactory<ByteBuffer> EVENT_FACTORY = new
>> EventFactory<ByteBuffer>() {
>> public ByteBuffer newInstance() {
>> return ByteBuffer.allocateDirect(4096);
>> }
>> };
>>
>> On Wed, Oct 2, 2013 at 12:30 PM, Artem Vysochyn
>> <artem.vysoc...@gmail.com> wrote:
>>> hi Trevor,
>>>
>>> Can you past example(s) of how you use DirectByteBuffer in jzmq? pls.
>>>
>>> 2013/10/2 Trevor Bernard <trevor.bern...@gmail.com>:
>>>> 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 too much garbage and generates too much GC
>>>> pressure.
>>>>
>>>> On Tue, Oct 1, 2013 at 9:33 PM, Radu Braniste <rbrani...@gmail.com> wrote:
>>>>> Personally I'm using the direct buffer as a memory arena (I preallocate a
>>>>> pool) and I avoid one allocation like:
>>>>>
>>>>>> zmq_msg_t msg;
>>>>>> zmq_msg_init (&msg);
>>>>>> zmq_recvmsg ((void *) socket, &msg, flags);
>>>>>> int size = zmq_msg_size (&msg);
>>>>>
>>>>> //might check for out of bounds and return false
>>>>>
>>>>> memcpy(GetDirectBufferAccess(arena+used), zmq_msg_data (&msg), size);
>>>>>
>>>>> used += size;
>>>>>> zmq_msg_close(&msg);
>>>>>> return used;
>>>>>
>>>>> the best would be of course to use this technique with a possible
>>>>> "zmq_msg_init_data" as Peter suggested and completely avoid he extra
>>>>> memcpy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> zeromq-dev mailing list
>>>>> zeromq-dev@lists.zeromq.org
>>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>>
>>>> _______________________________________________
>>>> zeromq-dev mailing list
>>>> zeromq-dev@lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
