Is it possible the socket gets destroyed even though the queue is not empty
and then it tries to flush it? To me this looks like a race condition thus
hard to spot.
It's still early and I hadn't coffee nor a look at the code. ;-)
___
zeromq-dev mailing l
On 2013?11?05? 21:01, Manuel Irribarra wrote:
Hi everyone,
I wrote a simple web application:
Context context = ZMQ.context(workers);
Socket backend = context.socket(ZMQ.DEALER);
backend.bind(Constants.SOCKET);
Worker worker = null;
for (int i = 0; i < workers; i++) {
worker = new Worker
I vaguely remember this was reported a long time ago. I spent some
time but never found anything suspicious. Will look at it. - Martin
On Tue, Nov 5, 2013 at 4:10 PM, Pieter Hintjens wrote:
> Hi MinRK,
>
> I'll try to reproduce it tomorrow. Any suggestion to the kind of test
> case I could make?
Hi MinRK,
I'll try to reproduce it tomorrow. Any suggestion to the kind of test
case I could make?
-Pieter
On Tue, Nov 5, 2013 at 11:44 PM, MinRK wrote:
> Once in a while, when running either the IPython or PyZMQ test suite, I
> still get this error:
>
> Bad file descriptor (kqueue.cpp:77)
Once in a while, when running either the IPython or PyZMQ test suite, I
still get this error:
Bad file descriptor (kqueue.cpp:77)
or
Bad file descriptor (epoll.cpp:81)
Stack trace suggests that this happens when destroying a context:
Thread 0:
1 libzmq.3.dylib 0x00
Hi everyone,
I wrote a simple web application:
Context context = ZMQ.context(workers);
Socket backend = context.socket(ZMQ.DEALER);
backend.bind(Constants.SOCKET);
Worker worker = null;
for (int i = 0; i < workers; i++) {
worker = new Worker(
This is very interesting. I'd thought of ZRE as aimed at dynamic
clusters, typically mobile devices over WiFi, yet you could be right
that there's a nice mapping of the protocol onto TIPC instead of TCP
for the interconnects.
On Tue, Nov 5, 2013 at 12:52 PM, Erik Hugne wrote:
> On Tue, Nov 05, 20
On Tue, Nov 05, 2013 at 10:21:06AM +0100, Arnaud Loonstra wrote:
> Wow that's a great addition! I didn't know about TIPC yet. It has some
> characteristics like ZRE, it seems. Would it be an interesting transport
> for ZRE?
>
I've only read some brief info on ZRE, but i think adding a protocol
Awesome!
On Tue, Nov 5, 2013 at 1:21 AM, Arnaud Loonstra wrote:
> On 11/04/2013 04:13 PM, Pieter Hintjens wrote:
> > Hi all,
> >
> > Just to let everyone know that libzmq master now supports the tipc://
> > transport, which wraps the TIPC clustering protocol. This makes it
> > rather easier to
On 11/04/2013 04:13 PM, Pieter Hintjens wrote:
> Hi all,
>
> Just to let everyone know that libzmq master now supports the tipc://
> transport, which wraps the TIPC clustering protocol. This makes it
> rather easier to do failover and load-balancing.
>
> I've written an article that explains how th
10 matches
Mail list logo
