ZMsg and Frame don’t involve JNI instances. So it should be GCed when they’re get out of scope.
‘destroy' was insert to have common semantics between czmq and jzmq. At the future, it could be removed or obsoleted to reduce misunderstanding. Thanks Min From: techbird [email protected] Reply: ZeroMQ development list [email protected] Date: April 21, 2014 at 11:37:17 AM To: ZeroMQ development list [email protected] Subject: Re: [zeromq-dev] Jyre Zyre On 21/04/14 18:38, Pieter Hintjens wrote: I don't think so. On Mon, Apr 21, 2014 at 4:40 PM, techbird <[email protected]> wrote: Is there any reason not to change Jyre's pom.xml to use: <dependency> <groupId>org.zeromq</groupId> <artifactId>jzmq4</artifactId> <version>4.0.0-SNAPSHOT</version> </dependency> rather than, the current, version 3? On 21/04/14 09:28, techbird wrote: I'll update the Java code base to use a java.util.UUID for the identity - thanks Pieter. On 20/04/14 23:05, Pieter Hintjens wrote: The correct representation is binary. On Sun, Apr 20, 2014 at 8:52 PM, techbird <[email protected]> wrote: Hello Pieter. Could you provide some direction. After making the protocol changes - Jyre and Zyre clients time out. I've work this through and discovered that... Jyre uses a string for the sender identity UUID, and Zyre uses a binary representation. This prevents the UUID from being un-marshalled correctly. And the peers timeout. Which is preferred binary or string representation for the peer's UUID? On 19/04/14 20:24, techbird wrote: Hiya Pieter. thank you - I've started taking a look, made a little progress updating the protocol. Problem is I've had to stop to make supper, fillet a large salmon, and now I have an hour back on the computer (with a glass of wine). Got the Jyre talking to Zyre now... sorted out the differences String vs lString etc. Zyre is timing out now, so I'll read further and see what's what! :) Thank you, by the way I do code 'C', Python and Java ... but it's nolonger my day job so I am not as quick as some. On 19/04/14 19:25, Pieter Hintjens wrote: techbird, if you make a start and come back with issues you hit, we'll help you. On Sat, Apr 19, 2014 at 4:10 PM, techbird <[email protected]> wrote: Hiya Pieter. Of course you're right. - better to work in the present. The other option is to write my consumer using Pyre, but my other components live in Camel/Karaf. So maybe it makes sense for me to stay in the world of Java. I guess a lack of knowledge and time makes me apprehensive. Pushing that aside - I'll start looking at the code. Thank you Pieter :) Like everyone else my problems are a lo On 19/04/14 13:18, Pieter Hintjens wrote: My advice would be to take the latest ZRE protocol spec (RFC 36) and upgrade Jyre to work with that. It'll teach you quite a lot about the details and it's easy to test against Zyre. Otherwise you check out an older version of Zyre from github, from the moment we forked off Jyre. The stacks are fun... I'm using Zyre in some projects and it does make life simple. -Pieter On Sat, Apr 19, 2014 at 1:08 PM, techbird <[email protected]> wrote: Thank you kindly for your support yesterday. "Jyre should talk to Zyre and implement the same functionality (it will need some updates since Zyre has evolved a little)" I gave it a go. Zyre protocols have evolved away from the trunk Jyre - but independently both C and Java implementations work. As the protocols, beacon ports etc are different Jyre clients do not communicate with trunk zyre and visa-vera. Is there a earlier version of Zyre I could use which is compatible with trunk Jyre? I would like to write a 'producer' in C, and competing consumer(s) in Java. As an aside - I am only 2 days into 0MQ, and - my jaw is dropping - this project is amazing. Thank you so much for so much wisdom translated into an incredible set of integration stacks. Kind regards. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev line 546 ZreMsg.java ... if (!content.sendAndDestroy (socket, 0)) { When sending (shouting) a message to a group of two or more peers, the code asserts - as the frame was destroyed in the first peer send. Therefore to fix, is it safe to change to: if (!content.send (socket, 0)) { then in ZreInterface.java after line 434 add the following to destroy the frame. msg.setContent (null); Is there a better way of detroying the content frame? For example will the frame be destoryed when local ZMsg request - goes out of scope. I am not happy that the calling code is destroying something that is owned by ZreMsg. Thoughts? _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
