Hello all,
On 14/11/2012 16:10, Pieter Hintjens wrote:
> Yes, these should be compatible. But it's worth checking.
>
> -Pieter
As advised by Pieter, I have made further checking on this point.
My conclusion is that it does not work!
If both pub/sub processes uses 3.1.0, it works
If both pub/sub
On Thu, Nov 15, 2012 at 9:50 AM, Emmanuel TAUREL wrote:
>
> From previous Pieter answer, I understood that the 4 cases should work
> (I hope so).
> Do I have to create a Jira bug entry for the coming 3.2.1 (stable)?
>
Definitely raise this, there's nothing that changed that should make them
inc
My test case still fails, I think #471 didn't addressed this issue, see
Adrien last comment at https://zeromq.jira.com/browse/LIBZMQ-450
b.
On Wed, Nov 14, 2012 at 4:08 PM, Pieter Hintjens wrote:
> 450 is also fixed afaics; at least the test case didn't pass before
> and does pass now. But bes
So the 3.1 release is problematic, it uses the old wire protocol but does
subscription upstreaming. The strategy we're using now can't recognize this
mix. If anyone wants to take a look at the protocol and see if there's a
solution...
I think we may have to consider 3.1 as an incompatible version.
Can you reopen the issue, please? Thanks...
On Nov 15, 2012 7:23 PM, "Balázs Varga" wrote:
> My test case still fails, I think #471 didn't addressed this issue, see
> Adrien last comment at https://zeromq.jira.com/browse/LIBZMQ-450
>
> b.
>
>
> On Wed, Nov 14, 2012 at 4:08 PM, Pieter Hintjens wr
Hello,
On 15/11/2012 13:26, Pieter Hintjens wrote:
>
> So the 3.1 release is problematic, it uses the old wire protocol but
> does subscription upstreaming. The strategy we're using now can't
> recognize this mix. If anyone wants to take a look at the protocol and
> see if there's a solution...
We have exactly the same problem...
Tons of 3.1 pub/sub everywhere, and need to udpate to 3.2 => the whole
architecture has to be update at the same time. Enjoy.
Can't even build something more robust top of 0mq, since most of the time
the only internal error handling of 0mq is a rough assert.
O
I sense another French blog rant is coming soon. :)
(just kidding!!!)
cr
On Nov 15, 2012, at 7:55 AM, Aurélien Vallée wrote:
> We have exactly the same problem...
> Tons of 3.1 pub/sub everywhere, and need to udpate to 3.2 => the whole
> architecture has to be update at the same time. Enjoy.
Frankly speaking, this problem would deserve one :-)
N.
De : zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] De la part de Charles Remes
Envoyé : jeudi 15 novembre 2012 14:58
À : ZeroMQ development list
Objet : Re: [zeromq-dev] Compatibility 3.1 - 3.2.1-rc2
I sen
On Thu, Nov 15, 2012 at 09:26:59PM +0900, Pieter Hintjens wrote:
> I think we may have to consider 3.1 as an incompatible version. It
> should not have been released as stable with this incompatibility.
I am so confused about the release numbering and what is deemed
stable.
The only version numbe
On Thu, Nov 15, 2012 at 11:44 PM, AJ Lewis wrote:
> In my mind, the 3-x series has never been stable, because there's
> always been an alpha, beta, or rc in the source name.
Indeed.
Let me recap history (omitting the 3.0 and 4.0 alien hell spawn
versions we'd all rather forget):
* 2.2 was the
Hello,
On 15/11/2012 17:22, Pieter Hintjens wrote:
>
>
> Now, what are the expectations here? Recall that this is a free
> software package, built by a community, and funded by users who are
> decent enough to pay for support, or to submit patches.
>
> Are we happy to delay the 3.2 release so we c
On Fri, Nov 16, 2012 at 2:00 AM, Emmanuel TAUREL wrote:
> My vote is in favor of compatibility.
> If making 3.2 talk to 3.1 is "pretty simple", it could be added to 3.2
> even if it delays 3.2 by few days.
> But will it also solve the other way round: 3.1 talk to 3.2?
It's doable but who are yo
In open source it's usually the people who *need a feature* who end up
supplying the patch that adds it. Saying out loud on the mailing list that you
are willing to delay a release is fine and all, but someone still has to do the
work. Who is that person?
cr
On Nov 15, 2012, at 11:00 AM, Emman
Perhaps I have missed it, but as far as I can tell there is no up-to-date
reference for the Java zeromq bindings. But that's a minor issue as I can
RTFS...
This has been a source of annoyance:
public ZContext() {
context = null; // Don't create Context until create 1st 0MQ socket
The bindings have JavaDoc.
You can generate it with the maven build. I don't use the Z* objects. I
usually use the ZMQ.*
ZMQ.Context context = ZMQ.context(1);
etc...
Joshua
Peter Friend
Thursday,
November 15, 2012 5:13 PM
Perhaps I have missed it, but as far as I can te
On Fri, Nov 16, 2012 at 7:13 AM, Peter Friend wrote:
> I am not sure why the context is not created at this point, but it can cause
> problems
It's a workaround for 0MQ/2.x's API, where you have to specify the
iothreads when you create the context.
For 0MQ/3.2 and forward this workaround isn't
When I share the context between threads before creating a socket, I set the
actual context manually
ZContext ctx = new ZContext ();
ctx.setContext (ZMQ.context (1));
Thanks
Min
On Nov 16, 2012, at 10:11 AM, Pieter Hintjens wrote:
> On Fri, Nov 16, 2012 at 7:13 AM, Peter Frie
Thanks, I've started just using ZMQ.* now as well. Got the javadocs built via
maven as well.
Peter
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of Joshua Foster
Sent: Thursday, November 15, 2012 3:23 PM
To: ZeroMQ development list
Subject: Re:
hi, i use jzmq in my project, i use jzmq 2.10, zeromq 2.1.7, but i get a
problem: i get assertion error in zeromq. i get the core dump, and the
backstrace blows:
#0 0x003eb9a30265 in raise () from /lib64/libc.so.6
#1 0x003eb9a31d10 in abort () from /lib64/libc.so.6
#2 0x003eb9a296e6 in
Could you please show us the java code which you tested with ?
This might help to look into the problem.
Thanks
Min
On Nov 16, 2012, at 12:52 PM, 陈竞 wrote:
> hi, i use jzmq in my project, i use jzmq 2.10, zeromq 2.1.7, but i get a
> problem: i get assertion error in zeromq. i get the core
we use a distributed system called storm which use zeromq, and we use storm
run my job, but it always core, so we gdb the core, found it cores in jzmq,
so i cant give the code, i just wander if any one met the same problem, so
that we can locate the problem, it seems not to be zeromq bug according
Ok,
The exception occurs when the pointer of c++ bound socket is null. If we use
ZMQ.Socket after ZMQ.Socket.close is called, this exception could occur.
I know how it the storm works. The storm doesn't do complex stuffs with the
zeromq. So I don't think it misuse the zeromq.
Does the word co
23 matches
Mail list logo
