Hi,
The goal of this project is to simplify and make easy the development
of ØMQ bindings on the JVM. I attempt to do this by providing a very
simple static interface (mirrors api.zeromq.org) and packaging up the
shared library in the JAR itself.
I currently only include Linux-amd64 in my builds
Still curious. Does it mean that using DirectByteBuffer only makes
sense if one uses ZMQ+Disruptor?
Not at all. That's just one example of how I do it.
-- what we win here
There is no way (that I know of) to pass a Java byte array to the
underlying c/c++ function without a copy. What the
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
? 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
Hi guys,
I messing around with JNI and libzmq and I was wondering if there was
a way to avoid the memcpy?
JNIEXPORT
jobject JNICALL
Java_org_zeromq_jni_ZMQ_zmq_1recv__JI (JNIEnv *env, jclass c, jlong
socket, jint flags)
{
zmq_msg_t msg;
zmq_msg_init (msg);
zmq_recvmsg ((void *)
With the release of the zeromq4.x, I'll start working on adding
authentication support in JZMQ shortly.
On Wed, Sep 18, 2013 at 5:43 PM, Pieter Hintjens p...@imatix.com wrote:
Authentication is on libzmq master, soon to become 4.x.
3.x does not have authentication.
On Wed, Sep 18, 2013 at
Thanks for the test case. I will look at it in more detail later this
evening. Might I suggest allocating the direct bytebuffer outside the loop
and trying something like this..
...
while(true) {
try {
socket.recvZeroCopy(buffer, buffer.remaining(), ZMQ.DONTWAIT) ;
}
...@gmail.comwrote:
This is awesome! Thank you for taking it off my plate.
I have this on my most urgent...but not quite yet todo list. So I'll
probably start pinging you with issues/pull requests in about 2 weeks (OK,
that's optimistic).
Between you and Trevor Bernard, my life just got at least 100x
, but as an integral part of it.
** **
I would be happy to participate in this renovated jzmq idea. Best regards,
** **
--
Gonzalo Diethelm
DCV Chile
** **
*From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Trevor
Hello,
I'd like to announce the immediate availability of cljzmq-0.1.1 on maven
central.
https://github.com/zeromq/cljzmq
For sample usage, I've started porting the zguide examples here:
https://github.com/trevorbernard/cljzmq-examples
Pull requests welcome!
Warmest regards,
Trev
In your performance experiment ZeroMQ will always be slower than TCP. There
is a small overhead to using ZeroMQ but it's mitigated by other smart
things it does like smart batching to avoid redundant network stack
traversals. But if all you're doing is a synchronous PING/PONG, you lose
that speed
Hi all,
I'm starting to work on JZMQ-3.0 and would like poll for opinions on
features/bug fixes they would like to see included in the new JZMQ-3.0.
There is currently no release date.
The primary reason for the major release is to simplify the build process
and make it easier for people to get
it is able to send the msgs.
2013/5/23 Trevor Bernard trevor.bern...@gmail.com
I'm using libzmq 3.2.3
On Wed, May 22, 2013 at 12:05 PM, Trevor Bernard
trevor.bern...@gmail.com wrote:
What should the functionality be for the following scenario?
;; Conceptually, assume push and pull sockets
What should the functionality be for the following scenario?
;; Conceptually, assume push and pull sockets are different processes
(def ctx (zcontext 1))
(def ctx2 (zcontext 2))
(def push (- (socket ctx :push)
(connect tcp://localhost:12345)))
(send push (.getBytes msg1)) ;; true
I'm using libzmq 3.2.3
On Wed, May 22, 2013 at 12:05 PM, Trevor Bernard
trevor.bern...@gmail.comwrote:
What should the functionality be for the following scenario?
;; Conceptually, assume push and pull sockets are different processes
(def ctx (zcontext 1))
(def ctx2 (zcontext 2))
(def
What version of JZMQ are you using?
I ran your test program and received the correct results.
JZMQ - 018a38d414af4e689c93e29d4d7a59a1f51fe84e
libzmq 3.2.2
On Mon, May 20, 2013 at 1:45 AM, Mark Sutheran mark_suthe...@yahoo.com wrote:
Hi Pieter,
Thanks for the quick response - test case below.
that references the byte[] passed back by zeromq. When you allocate
direct, you’re unnecessarily copying this byte[] again.
** **
Parag
** **
*From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Trevor Bernard
*Sent:* Monday, May
What is the purpose of int recvByteBuffer(int flags) ?
Oops, typo. The return type should be ByteBuffer. You can create a
direct bytebuffer with NewDirectByteBuffer.
Will this be a true 0 copy implementation? Or will the buffer still be copied
within the send/receive call?
The buffer will
, May 14, 2013 at 8:35 AM, Trevor Bernard
trevor.bern...@gmail.com wrote:
What is the purpose of int recvByteBuffer(int flags) ?
Oops, typo. The return type should be ByteBuffer. You can create a
direct bytebuffer with NewDirectByteBuffer.
Will this be a true 0 copy implementation
Can someone provide their source? The JZMQ numbers seem off. Unless there
was a performance regression introduced since then. Also what version of
libzmq too.
-Trev
On Fri, May 3, 2013 at 5:28 AM, MinRK benjami...@gmail.com wrote:
I ran your tests on my Linux machine (amd64 Ubuntu 12.04, 12
zmq_disconnect does not sent unsubscribe messages
Contributors: Adrian Muraru, Ian Barber, KIU Shueng Chuan, Martin
Hurton, Mika Fische, Dongmin Yu, MinRK, Pieter Hintjens, Stefan
Radomski, Steven McCoy, Trevor Bernard, Victor Perron.
Enjoy!
-Pieter
I've back ported the fix here and submitted a pull request:
https://github.com/trevorbernard/zeromq3-x
Can you see if it works Victor?
-Trev
On Wed, May 1, 2013 at 10:17 AM, Steven McCoy steven.mc...@miru.hk wrote:
On 1 May 2013 08:46, Victor Perron vic...@iso3103.net wrote:
call fails
Does the shared library libjzmq.so match the version of jzmq.jar?
On Fri, Apr 12, 2013 at 10:46 AM, dennis dennis.d...@gmail.com wrote:
I deploy my program on two machine.
first machine run zeromq 2.2(open jdk 1.7)
second machine run zeromq 3.2 (open jdk 1.7)
the program is working fine
Did you try manually removing one of the $ in the the makefile?
On Thu, Mar 14, 2013 at 4:11 PM, Gonzalo Vasquez gvasq...@altiuz.cl wrote:
Environment: AIX 6.1 Power 7
Tried, both with a normal user and with root access, and with jzqm v2.1.2
and the also the latest from the master branch in
That worked liked a charm!
Awesome!
How being too clean would harm the context creation/termination process?
It seems there is something awry but someone more experienced with
libzmq would have to chime in.
In this new scenario the context will never be terminated as it'll linger
idle in
So aside, from a version number increase, and few changed comments, there
doesn't seem be any real software upgrade, i.e. no src files modified, am I
wrong?
There should have been a few files changed:. This is the diff from the
v2.1.2 tag with master:
at 10:59 PM, Trevor Bernard
trevor.bern...@gmail.com wrote:
So aside, from a version number increase, and few changed comments, there
doesn't seem be any real software upgrade, i.e. no src files modified, am I
wrong?
There should have been a few files changed:. This is the diff from
Hi Gonzalo,
Can you try building the latest from jzmq master? Not knowing what
2.1.2-SNAPSHOT you have, I can't be certain which fixes are included in
your version.
These issues might be contributing to your stability problems that have
since been resolved:
-
I'd advise against trying to use identities to make this failover work.
Okay.
You're going to be fighting 0MQ's autoreconnect. Instead, provide
authentication in the protocol itself and design the router app to do the
failover itself.
I don't understand what you mean when you say design
Hi,
I have a use case where I'd like to re-cycle DEALER identities when a
failover situation occurs. I have one service SV1 that creates a
DEALER connection to a ROUTER socket on SVn. SV1 has a hot standby and
uses the same identity in a failover situation. The first connect goes
as you would
Hi Min,
Thanks for the suggestion. I added ROUTER_MANDATORY to my ROUTER but
this didn't resolve my original problem however. The problem is after
I reconnect on a different DEALER socket with the same identity, it no
longer correctly routes the response.
I'm curious if there is a way to reuse
What are your thoughts on removing the option to install jzmq.so?
Either include it as a native dependency or package the .dll, .so,
.dylib in the same jar? Currently we have to worry about libzmq, jzmq,
and the java library jiving in order to get a functional install.
-Trev
I'd like to announce the immediate availability of JZMQ 2.1.1 on Maven Central
* Add zero copy API to send and recv
* Remove asserts from get_context JNI
* Add ZLoop support
* Poller rewrite
* No longer c assert when trying to write to a closed Socket
* Add a continuous integration support
Also you'll need to use ByteBuffer.allocateDirect(...) in order for it
to work. I explicitly didn't check GetDirectBufferAddress for perf
reasons.
For the JZMQ api, I used sendZeroCopy and recvZeroCopy for a lack of a
better/fancier name. ;)
-Trev
On Sat, Feb 16, 2013 at 4:26 PM, Trevor Bernard
Disregard my bug claims. I managed to figure this out.
https://gist.github.com/trevorbernard/4969705
I had a misunderstood has zmq_recv worked.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
There is a zero copy API for JZMQ with this commit:
https://github.com/zeromq/jzmq/commit/336a8a1d3269483ba67bb903c8dc0b1482079a33
Cheers
On Sat, Feb 16, 2013 at 5:47 PM, Trevor Bernard
trevor.bern...@gmail.com wrote:
@gonzalo Did you do anything special on the client side to read the
direct
I'm thinking of extending jzmq to optionally allow the zero-copy
technique using the concepts outlined by Martin Thompson here:
That's awesome
I'm not 100% sure I'll do it, I need some more experimentation first,
but is there any interest or words of advice if someone's tried this
already?
: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
boun...@lists.zeromq.org] On Behalf Of Trevor Bernard
Sent: Friday, February 15, 2013 2:02 PM
To: thecarro...@jiminger.com; ZeroMQ development list
Subject: Re: [zeromq-dev] Zero Copy in Java jzmq
I'm thinking of extending jzmq
I'd like to announce the immediate availability of JZMQ 2.1.0 on Maven Central.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
This has been merged into master and the branch no longer exists.
On Tue, Feb 12, 2013 at 6:29 PM, Trevor Bernard
trevor.bern...@gmail.com wrote:
I have a branch that I would appreciate if a few JZMQ users would help
me vet. I cleaned up the build process a bit to not modify files after
I use ZMQ 2.X with the JZMQ binding. I am trying to debug a typical “java:
Socket.cpp:561: void* get_socket(JNIEnv*, jobject, int): Assertion `s'
failed.” I am probably sending a message on a closed socket, but it is
difficult to correlate my application logs and the assert error. I would
I have a branch that I would appreciate if a few JZMQ users would help
me vet. I cleaned up the build process a bit to not modify files after
./autogen.sh; ./configure; make
If you could do a build from a clean state, it would be greatly appreciated.
For the best optimised multithread application within a process, the
concurrent package and disruptor would give better solution. But it would
not scale well.
What do you mean by would not scale well?
___
zeromq-dev mailing list
Any naming suggestions for the project?
On Tue, Feb 5, 2013 at 9:05 PM, Trevor Bernard trevor.bern...@gmail.com wrote:
If you guys define this new API, which I suppose will be implemented atop
jzmq, we could also add it as a separate package to jzmq itself. Or maybe it
should be a separate
I've been using distinct API names as well. I'll be releasing a rough version
of what John and I discussed on my GitHub probably later this evening called,
jzmq-api, with a basic wrapper around the existing jzmq. Keep on mind that's
its very much a work in progress and it's to facilitate
to be; it's what I _sort of
know_. Also I'd love to hear any suggestions or criticisms you may
have. At some point I'll also include a Clojure idiomatic wrapper as
well.
-Trev
On Wed, Feb 6, 2013 at 2:53 PM, Trevor Bernard trevor.bern...@gmail.com wrote:
I've been using distinct API names as well. I'll
Any one know why this hangs when you try to term the context.
https://gist.github.com/trevorbernard/4727863
But if I run the sockets on a different thread, the context terms fine.
https://gist.github.com/trevorbernard/4727870
I've seen a few mentions of this but I've yet to find a good
experiences will definitely be invaluable! :)
On Sun, Feb 3, 2013 at 12:29 PM, John Watson jkwat...@gmail.com wrote:
Sounds great, Trev. As soon as I have something roughed out, I'll send a
pull request to the main jeromq project for perusal.
On Sun, Feb 3, 2013 at 11:55 AM, Trevor
available on the irc channel? If so, let's coordinate off-list a time to
chat about this.
John
On Tue, Feb 5, 2013 at 6:53 AM, Trevor Bernard trevor.bern...@gmail.com
wrote:
Awesome work John! I didn't realize you had a pull request in flight.
We should have a chit chat at some point; I've also
My advice is to work in small cycles and using real code, e.g. the
Guide samples, as your target.
We use 0MQ internally for as our IPC mechanism. I'll likely first
fulfil our needs and use-cases first before targeting the guide.
CZMQ is of course for C; what is IMO a valuable aim is that we
If you guys define this new API, which I suppose will be implemented atop
jzmq, we could also add it as a separate package to jzmq itself. Or maybe it
should be a separate project on github. Anyway, I am open to anything we all
agree on.
I'm OK with either option. John has already made a
I am in favour of this idea as well. Also, releasing stable builds to
central would be a major plus. I'd be more than happy to donate my
time for this effort.
-Trev
On Sun, Feb 3, 2013 at 1:02 PM, John Watson jkwat...@gmail.com wrote:
On Sun, Feb 3, 2013 at 4:57 AM, Pieter Hintjens
On the following line:
https://github.com/zeromq/jzmq/blob/master/src/org/zeromq/ZContext.java#L109
Should setLinger be set to 0 to immediately purge pending messages on
the socket upon close? Or is the currently functionality correct?
Also in the same method, shouldn't the close and remove be
101 - 153 of 153 matches
Mail list logo
