A stack trace of the process when zmq_msg_send() blocks could already be
telling. It sounds like it's getting stuck in either pipe::terminate() or
dealer::xrecv()...
Cheers,
Christian
Pieter Hintjens wrote:
>Hi Björn,
>
>The best thing when it comes to specific functionalities like this is
>a
Tnx for info, and quick response.
On Mon, Nov 18, 2013 at 11:10 PM, Pieter Hintjens wrote:
> If you are developing new apps, then you should use 4.0.x, the latest
> stable build. Let us know if you have any questions or problems!
>
> On Mon, Nov 18, 2013 at 10:43 PM, Nikola wrote:
> > Will do
If you are developing new apps, then you should use 4.0.x, the latest
stable build. Let us know if you have any questions or problems!
On Mon, Nov 18, 2013 at 10:43 PM, Nikola wrote:
> Will do that, tnx for help.
>
>
> On Mon, Nov 18, 2013 at 10:35 PM, Pieter Hintjens wrote:
>>
>> OK, this is a
Will do that, tnx for help.
On Mon, Nov 18, 2013 at 10:35 PM, Pieter Hintjens wrote:
> OK, this is a really old version of 0MQ and has a lot of known issues.
> You should upgrade to 3.2 at least.
>
> On Mon, Nov 18, 2013 at 10:20 PM, Nikola wrote:
> >
> > 2.1.11 on ubuntu 12.0.4
> >
> > N.
> >
OK, this is a really old version of 0MQ and has a lot of known issues.
You should upgrade to 3.2 at least.
On Mon, Nov 18, 2013 at 10:20 PM, Nikola wrote:
>
> 2.1.11 on ubuntu 12.0.4
>
> N.
>
>
>
> On Mon, Nov 18, 2013 at 9:57 PM, Pieter Hintjens wrote:
>>
>> Server shouldn't core dump. What ver
Assertion failed !inpipe & !outpipe (pair.cpp:49).
On Mon, Nov 18, 2013 at 10:20 PM, Nikola wrote:
>
> 2.1.11 on ubuntu 12.0.4
>
> N.
>
>
>
> On Mon, Nov 18, 2013 at 9:57 PM, Pieter Hintjens wrote:
>
>> Server shouldn't core dump. What version of 0MQ are you using?
>>
>> On Mon, Nov 18, 2013
2.1.11 on ubuntu 12.0.4
N.
On Mon, Nov 18, 2013 at 9:57 PM, Pieter Hintjens wrote:
> Server shouldn't core dump. What version of 0MQ are you using?
>
> On Mon, Nov 18, 2013 at 9:33 PM, Nikola wrote:
> > Hi,
> >
> > following tutorial on
> >
> >
> https://learning-0mq-with-pyzmq.readthedocs.o
Server shouldn't core dump. What version of 0MQ are you using?
On Mon, Nov 18, 2013 at 9:33 PM, Nikola wrote:
> Hi,
>
> following tutorial on
>
> https://learning-0mq-with-pyzmq.readthedocs.org/en/latest/pyzmq/patterns/pair.html
>
>
> I got puzzled how to handle clients that die.
>
> 1) Start ser
Hi,
following tutorial on
https://learning-0mq-with-pyzmq.readthedocs.org/en/latest/pyzmq/patterns/pair.html
I got puzzled how to handle clients that die.
1) Start server
2) Start client
3) Kill client
4) Server core dumps
How do you handle disconnects?
N.
___
On 11/18/2013 06:21 PM, Luke Gracie wrote:
> If I run the code as root - no issue, but if I run the following code as a
> user; I the following error:
> ./zeromq.test.pl
> Can't locate loadable object for module ZMQ::LibZMQ3 in @INC (@INC contains:
> /usr/local/lib64/perl5 /usr/local/share/perl5
Well, I have mucked around such APIs with JNI a couple of times, and what I
would do is something like this:
In java:
public class DropsJNI
{
public native long drops_new(String directory);
public native void drops_destroy(long self);
}
What this is doing is providing a really shallow JNI i
On Mon, Nov 18, 2013 at 2:45 PM, shancat wrote:
> struct drops_t {
> void *pipe;
> zctx_t *ctx;
> };
>
> drops_t * drops_new (const char *directory);
> void drops_destroy (drops_t **self_p);
>
> The main problem is that I don't know the proper way to manage the drops_t
> struct
If you wan
struct drops_t {
void *pipe;
zctx_t *ctx;
};
drops_t * drops_new (const char *directory);
void drops_destroy (drops_t **self_p);
The main problem is that I don't know the proper way to manage the drops_t
struct
On Nov 19, 2013 5:38 AM, "gonzalo diethelm" wrote:
> Hi Shannen,
>
>
>
> If
Hi Shannen,
If you can post here a brief overview of the C API, I can give you a couple of
hints.
Regards,
--
Gonzalo Diethelm
DCV Chile
From: zeromq-dev-boun...@lists.zeromq.org
[mailto:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of shancat
Sent: Monday, November 18, 2013 3:32 PM
To: Zero
I'm working with Pieter on a ZeroMQ related free-software project and
could use some help. We need to wrap up the (simple) C API in JNI.
The project can be viewed at https://github.com/edgenet/drops
I don't "know" JNI so I'm getting quite stuck and any help is
appreciated :)
- Shannen
__
If I run the code as root - no issue, but if I run the following code as a
user; I the following error:
./zeromq.test.pl
Can't locate loadable object for module ZMQ::LibZMQ3 in @INC (@INC contains:
/usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor
On Mon, Nov 18, 2013 at 12:16 AM, Michael Haberler wrote:
>
> re keyboard interrupt: I solved this by testing for
> zpoller.terminated(poller) in the inner loop which I prefer anyway since
> it's synchronous delivery.
>
>
Nice.
> I think what warrants some thought longer term: if errors from py
And yet none of these fixes covers all the error possibilities.
Em 18/11/2013 11:49, KIU Shueng Chuan escreveu:
There were in fact 3 fixes addressing win32 issues in signaler.cpp
between 3.2.2 and 3.2.4.
https://raw.github.com/zeromq/zeromq3-x/master/NEWS
__
On Mon, Nov 18, 2013 at 3:10 AM, Brian Knox wrote:
> Hey neat - I hadn't really noticed pyczmq before! If you don't mind, I'd
> like to fork it this week just to play with adding support for the zproxy
> class I added to czmq (it's not in a stable release yet).
>
I don't mind at all, forking is
It's great to see such activity in the Python stack. It's very useful
to retest design concepts like zbeacon in other languages. Maybe also
the zauth model and then certificates, one day. In C we pushed as much
reusable code as possible down into CZMQ, which now has ~500 methods.
JZMQ and JeroMQ ex
On 11/17/2013 08:58 PM, Michael Haberler wrote:
> Hi Michel,
>
> just rewrote a protobuf/pyzmq Python application to use pyczmq (because I'm
> interested in beacon and securitiy support)
>
[snip]
If you mean zbeacon also note that it's available in Pyre using native
python: https://github.com/ze
There were in fact 3 fixes addressing win32 issues in signaler.cpp between
3.2.2 and 3.2.4.
https://raw.github.com/zeromq/zeromq3-x/master/NEWS
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Sorry: Windows 7.
Em 18/11/2013 10:58, Felipe Farinon escreveu:
Windows 8, ZeroMQ 3.2.2. I think that the problem is that the
application is running in a test environment that doesn't close it
graceously, instead it just terminates the application which leaves
the possibility for that event to
Windows 8, ZeroMQ 3.2.2. I think that the problem is that the
application is running in a test environment that doesn't close it
graceously, instead it just terminates the application which leaves the
possibility for that event to hang around. I have not tested with libzmq
master, I have just f
In threading module, the __init__() method is executed by the parent
thread. Only the run() method executes in the newly spawned thread.
So you should create the context in the run() method.
Since multiprocessing module follows the threading module interface, I
suppose the same thing applies.
On
Hey neat - I hadn't really noticed pyczmq before! If you don't mind, I'd
like to fork it this week just to play with adding support for the zproxy
class I added to czmq (it's not in a stable release yet). I haven't played
with CFFI before and would enjoy the opportunity to play with it and bother
Hi Björn,
The best thing when it comes to specific functionalities like this is
a minimal test case that shows the problem.
-Pieter
On Mon, Nov 18, 2013 at 9:09 AM, Björn Kuhlbrodt
wrote:
> Hello
>
> I' trying to use the new (4.0.1) ZMQ_REQ_RELAXED in C++ with VS2010 (and the
> standard C-Bind
Hi Michel,
Am 18.11.2013 um 04:52 schrieb Michel Pelletier :
> This uses ctypes.Structure.from_buffer to copy objects to and from an mmaped
> file with no serialization, in theory the only serializing happens "out of
> process" by the kernel to and from the mapped file. Maybe some ideas here
Hello
I' trying to use the new (4.0.1) ZMQ_REQ_RELAXED in C++ with VS2010 (and the
standard C-Binding from the 0MQ main site), but keep failing.
What I have:
One context with two ZMQ_REQ sockets in two different threads, one binds and
answers to REQs, one connects and sends REQs. This runs fine
29 matches
Mail list logo
