[zeromq-dev] problem running two 0mq applications on one host side-by-side

Sergey Malov smalov at mdialog.com
Fri Apr 13 19:28:50 CEST 2012


How can we prevent sender from freeing memory too soon ?

Thanks,
Sergey

On 2012-04-13, at 11:38 AM, Pieter Hintjens wrote:

> Corruption in messages usually means that the sender is freeing memory too soon, before the message gets sent.
> 
> -Pieter
> 
> On Apr 13, 2012 5:10 PM, "Sergey Malov" <smalov at mdialog.com> wrote:
> We are running two 0mq applications (both written in Scala) on one host talking to each other throw PUSH/PULL. They exchange information through protocol buffer messages.  Application "A" sends messages over PUSH socket uses 0mq Scala binding, application B receives message over PULL socket uses 0mq Java binding, pulled from a repo about a month ago.
> 
> Problem that lots of messages on receiving end come corrupted and can't be parsed. I don't think though that we are hitting a bug with protocol buffer library, or with 0mq  (except Scala binding which I am not so sure). Rather I think we are missing something in the way how communication is set up.
> 
> On receiving end the way how message is read is (below is semi-pseudo code):
> 
> class Reader {
>        private val socket = context.socket(ZMQ.PULL)
>        socket.setLinger(100)
>        socket.setReceiveTimeOut(2000)
>        private val poller = context.poller
>        poller.setTimeout(700)
>        poller.register
>        socket.bind(address)
> 
>        val goAhead = true;
>        while(goAhead) {
>                poller.poll
>                if(poller.pollin(0)) {
>                        val message = socket.recv(ZMQ.NOBLOCK)
>                        // try to parse message
>                        …..
>                }
>        }
> }
> 
> Our first attempt to remedy it was to use ICP sockets instead of TCP, since apps reside on the same machine, and it didn't help.
> Anything else we can try to fix it?
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> Sergey
> 
> 
> 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120413/004e7b70/attachment.htm>


More information about the zeromq-dev mailing list