Re: [zeromq-dev] pyzmq pubsub: Address already in use

[Mazzaroth M.]

Thanks! This worked.

On Sat, Jun 11, 2016 at 9:26 PM, Douglas Petican  wrote:

> This is what I am currently using in my req-rep application.  Its
> generalized so that a number of different processes can use the same code:
>
> http://pastebin.com/HSYqsxRn
>
> If I am exiting normally I just call clean_up with an exit level of 0 and
> no error message
>
> <-Douglas Petican->
>
> On 2016-06-11 7:14 PM, Mazzaroth M. wrote:
>
> I'm making a pyzmq app which uses the publisher-subscribe pattern and when
> I setup a zeromq device in a controller class, I'm not able to cleanup the
> port and on next run I get the `Address already in use` error on
> startup(and I will need to reboot to release the port).
>
> I believe that I'm not able to cleanup the device when I quit the
> controller. It may be quite simple:
> 
> https://bitbucket.org/sidha/twitpub/commits/c9d047f5eca4d03fe30f8d844bd367c0894fa47d#chg-twitpub/controller.py
>
> How do I cleanup the Device object on a keyboard interrupt? I initiate the
> app from a run script:
> 
> https://bitbucket.org/sidha/twitpub/src/c9d047f5eca4d03fe30f8d844bd367c0894fa47d/twitpub/run?fileviewer=file-view-default
>
> I was thinking of overriding __del__ but it never gets called on ctrl-c
>
> regards,
> Michael
>
>
> ___
> zeromq-dev mailing 
> listzeromq-dev@lists.zeromq.orghttp://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] [CZMQ/git latest] make check failing ubuntu 14.04 LTS

[Frittum Johannes]

Hi!

Just noticed that make check for czmq is failing fom git latest in test zsock:

$ valgrind -v ./czmq_selftest -v -t zsock

==25433== Memcheck, a memory error detector
==25433== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==25433== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==25433== Command: ./czmq_selftest -v -t zsock
==25433==
--25433-- Valgrind options:
--25433----suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--25433---v
--25433-- Contents of /proc/version:
--25433--   Linux version 3.13.0-88-generic (buildd@lcy01-36) (gcc version 
4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #135~precise1-Ubuntu SMP Thu Jun 9 
08:27:38 UTC 2016
--25433-- Arch and hwcaps: X86, x86-sse1-sse2
--25433-- Page sizes: currently 4096, max supported 4096

[...]

Running czmq test 'zsock'...
--25433-- REDIR: 0x419e3a0 (free) redirected to 0x402b000 (free)
 * zsock:
--25433-- REDIR: 0x419efc0 (calloc) redirected to 0x402a540 (calloc)
--25433-- REDIR: 0x41a2170 (__GI_strlen) redirected to 0x402c670 (__GI_strlen)
--25433-- REDIR: 0x440d6a0 (operator new(unsigned int, std::nothrow_t const&)) 
redirected to 0x402b790 (operator new(unsigned int, std::nothrow_t const&))
--25433-- REDIR: 0x419f8c0 (posix_memalign) redirected to 0x402a4a0 
(posix_memalign)
--25433-- REDIR: 0x419dec0 (malloc) redirected to 0x402be00 (malloc)
--25433-- REDIR: 0x440d600 (operator new(unsigned int)) redirected to 0x402b950 
(operator new(unsigned int))
--25433-- REDIR: 0x41a3190 (memmove) redirected to 0x40254a0 
(_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x425cb80 (__memmove_ssse3) redirected to 0x402e910 (memmove)
--25433-- REDIR: 0x440b500 (operator delete(void*)) redirected to 0x402ac90 
(operator delete(void*))
--25433-- REDIR: 0x41a1770 (index) redirected to 0x40254a0 (_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x41ba170 (__strchr_sse2_bsf) redirected to 0x402c280 (index)
--25433-- REDIR: 0x41a2120 (strlen) redirected to 0x40254a0 
(_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x41a90d0 (__strlen_sse2_bsf) redirected to 0x402c650 (strlen)
--25433-- REDIR: 0x4226f20 (__memcpy_chk) redirected to 0x40254a0 
(_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x425a270 (__memcpy_chk_ssse3) redirected to 0x402ef30 
(__memcpy_chk)
--25433-- REDIR: 0x41a2e60 (bcmp) redirected to 0x40254a0 (_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x426b760 (__memcmp_ssse3) redirected to 0x402e460 (bcmp)
--25433-- REDIR: 0x41a3910 (memcpy) redirected to 0x40254a0 
(_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x425a280 (__memcpy_ssse3) redirected to 0x402d930 (memcpy)
--25433-- REDIR: 0x41a2380 (rindex) redirected to 0x40254a0 
(_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x41ba280 (__strrchr_sse2_bsf) redirected to 0x402c170 (rindex)
--25433-- REDIR: 0x41a1aa0 (__GI_strcpy) redirected to 0x402c760 (__GI_strcpy)
--25433-- REDIR: 0x41a3250 (memset) redirected to 0x40254a0 
(_vgnU_ifunc_wrapper)
--25433-- REDIR: 0x4259170 (__memset_sse2) redirected to 0x402e880 (memset)
==25433== Invalid read of size 1
==25433==at 0x402C658: strlen (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==25433==by 0x40635A9: zmsg_addstr (zmsg.c:382)
==25433==by 0x40C3DA5: ??? (in /usr/local/lib/libczmq.so.3.0.0)
==25433==  Address 0x is not stack'd, malloc'd or (recently) free'd
==25433==
==25433==
==25433== Process terminating with default action of signal 11 (SIGSEGV)
==25433==  Access not within mapped region at address 0x
==25433==at 0x402C658: strlen (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==25433==by 0x40635A9: zmsg_addstr (zmsg.c:382)
==25433==by 0x40C3DA5: ??? (in /usr/local/lib/libczmq.so.3.0.0)
==25433==  If you believe this happened as a result of a stack
==25433==  overflow in your program's main thread (unlikely but
==25433==  possible), you can try to increase the size of the
==25433==  main thread stack using the --main-stacksize= flag.
==25433==  The main thread stack size used in this run was 8388608.
==25433==
==25433== HEAP SUMMARY:
==25433== in use at exit: 142,188 bytes in 179 blocks
==25433==   total heap usage: 583 allocs, 404 frees, 284,456 bytes allocated
==25433==
==25433== Searching for pointers to 179 not-freed blocks
==25433== Checked 16,968,408 bytes
==25433==
==25433== LEAK SUMMARY:
==25433==definitely lost: 0 bytes in 0 blocks
==25433==indirectly lost: 0 bytes in 0 blocks
==25433==  possibly lost: 1,347 bytes in 39 blocks
==25433==still reachable: 140,841 bytes in 140 blocks
==25433== suppressed: 0 bytes in 0 blocks
==25433== Rerun with --leak-check=full to see details of leaked memory
==25433==
==25433== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==25433==
==25433== 1 errors in context 1 of 1:
==25433== Invalid read of size 1
==25433==at 0x402C658: strlen (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==25433==by 0x40635A9: zmsg_addstr (zmsg.c:382)
==25433==by 0x40C3DA5: ??? (in /usr/local/lib/libczmq.so.3.0.0)
==25433==  

[zeromq-dev] Please un-deprecate MDP 0.1

[Dariusz Suchojad]

Hello,

I have just noticed that MDP 0.1 has been deprecated and I would like to
ask for this tag to be removed.

http://rfc.zeromq.org/spec:7/

Truth be told, it is possible that it has been the case for some time
though on the other hand, I could swear I did not see it a couple of
weeks ago.

The reason I'm asking for it is that there is nothing wrong with this
protocol - it is straightforward, works very well and pretty much the
only thing that I would change is adding responses to READY commands
instead of having workers assume that it succeeds unless a subsequent
command fails.

(I would also expose IP addresses of remote sockets in the public API
but that's another kettle of fish).

We are currently adding 0.1 to Zato:

https://zato.io/docs/

It's a Python-based SOA/API integration platform - we already have
support for ZeroMQ and in this context MDP will give our users nice
synchronous connectivity when HTTP adds too much overhead and raw TCP
sockets are not particularly palatable.

I understand that there is MDP 0.2 which we are going to add too:

http://rfc.zeromq.org/spec:18

But since 0.2 is backward-incompatible with 0.1, even though the changes
are small, the two protocols cannot be mixed up anyway thus it looks
there is no reason to deprecate 0.1, they are just different things.

And there is 0.3 planned ..

https://github.com/zeromq/majordomo/issues/34

.. which appears to be a specification unlike either of the previous MDP
versions.

One this ticket is closed I'm not entirely sure what will happen? Will
0.2 become deprecated then? But since 0.3 is a different protocol then
perhaps it should not be called MDP at this point?

I just don't want to give our users impression that we are supporting
deprecated protocols only because I do know that they are just fine,
both 0.1 and 0.2, even if they are not compatible.

At the same time I would like to foster their adoption - they are quite
convenient and definitely make sense, please do not deprecate them.

best regards,

-- 
Dariusz Suchojad

https://zato.io
ESB, SOA, REST, APIs and Cloud Integrations in Python

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] docker accounts

[Arnaud Loonstra]

Would it be possible to merge the two?

Rg,

Arnaud

On 2016-06-13 14:00, Kevin Sapper wrote:

@Trevor that would be great!

@Godefroid thanks!

2016-06-13 13:55 GMT+02:00 Godefroid Chapelle :


On 13/06/16 09:04, Kevin Sapper wrote:


Hello zeromqers,

Ive been recently looking at the docker images of zeromq that are
provided on docker hub. Therere two docker hub organizations Im
interested in particular "zeromq" and "zeromqorg". Does anybody
on this
mailinglist own them or knows who does?

//Kevin


I created the zeromqorg organization during the hackathon in
January.

I just added you to the owners team.

Regards

Godefroid


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] pyzmq and curve, as server

[Julien Kauffmann]

Hi,

I'm trying to use the CURVE mechanism with PYZMQ, following the code 
example at 
https://github.com/zeromq/pyzmq/blob/master/examples/security/stonehouse.py.


I created an authenticator, I generated key pairs (which work as a CURVE 
client), set the `curve_server` flag to `True`, and finally bound the 
socket.


However, when the REP socket tries to contact the REQ socket, a network 
dump shows that it actually sends the `as_server` flag as `False` and 
I'm lost as to understand why. For all intents and purpose, I'm 
following the exact sequence done in the ironhouse sample.


Any clue what I could be missing here ? Is there any facility that could 
help me debug this (additional logs for instance) ?


Thanks,

Julien.



smime.p7s
Description: Signature cryptographique S/MIME
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] docker accounts

[Kevin Sapper]

@Trevor that would be great!

@Godefroid thanks!

2016-06-13 13:55 GMT+02:00 Godefroid Chapelle :

> On 13/06/16 09:04, Kevin Sapper wrote:
>
>> Hello zeromqers,
>>
>> I've been recently looking at the docker images of zeromq that are
>> provided on docker hub. There're two docker hub organizations I'm
>> interested in particular "zeromq" and "zeromqorg". Does anybody on this
>> mailinglist own them or knows who does?
>>
>> //Kevin
>>
>
> I created the zeromqorg organization during the hackathon in January.
>
> I just added you to the owners team.
>
> Regards
>
> Godefroid
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] docker accounts

[Godefroid Chapelle]

On 13/06/16 09:04, Kevin Sapper wrote:

Hello zeromqers,

I've been recently looking at the docker images of zeromq that are
provided on docker hub. There're two docker hub organizations I'm
interested in particular "zeromq" and "zeromqorg". Does anybody on this
mailinglist own them or knows who does?

//Kevin


I created the zeromqorg organization during the hackathon in January.

I just added you to the owners team.

Regards

Godefroid


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] docker accounts

[Trevor Bernard]

Kevin,

I created the "zeromq" organization a while back. I can add you as a
collaborator.

Best,
Trev

On Mon, Jun 13, 2016 at 4:04 AM, Kevin Sapper  wrote:
> Hello zeromqers,
>
> I've been recently looking at the docker images of zeromq that are provided
> on docker hub. There're two docker hub organizations I'm interested in
> particular "zeromq" and "zeromqorg". Does anybody on this mailinglist own
> them or knows who does?
>
> //Kevin
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] docker accounts

[Kevin Sapper]

Hello zeromqers,

I've been recently looking at the docker images of zeromq that are provided
on docker hub. There're two docker hub organizations I'm interested in
particular "zeromq" and "zeromqorg". Does anybody on this mailinglist own
them or knows who does?

//Kevin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev