Fixed issue #1695 (ZMQ_REQ_CORRELATE)

[FredTreg]

Problem: when using ZMQ_REQ_RELAXED + ZMQ_REQ_CORRELATE and two 'send' are executed in a row and no server is available at the time of the sends, then the internal request_id used to identify messages gets corrupted and the two messages end up with the same request_id. The correlation no longer works in that case and you may end up with the wrong message.

Solution: make a copy of the request_id instance member of the req_t class before sending it down the pipe.

Issues #1690 and #1695 are linked: I also updated documentation to reflect the changes (there is no longer a disconnection of the peer when two sends in a row are sent from a relaxed REQ socket).

It seems I am the first to use malloc() on the ZMQ project: I hope this is ok! (I could not see a way around it).

Thanks!

[hintjens]

Why did you close the pull request?

[FredTreg]

Hi Pieter,

I saw that tests were failing on your automated build system, specifically
test_req_relaxed.cpp and test_req_correlate.cpp which are the two options I
am trying to fix.

As I had only tested my patch against the official 4.1.4, I closed my pull
request. I then tested my patch with the HEAD of the master branch and
indeed the two tests are failing. I am not sure it is related to my patch,
but I would like to investigate more before submitting my patch again.

Sorry if it caught you in the middle of the code review.

Thanks,

2016-03-20 21:42 GMT+01:00 Pieter Hintjens notifications@github.com:

Why did you close the pull request?

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#1862 (comment)

[bluca]

Hi Fred,

Those two tests are marked as expected failures, as the feature is currently not working.
See #1730 for more details. Brownie points if you can get that issue fixed too :-) But don't hold back these changes because of that!

[FredTreg]

Ok, thanks for pointing this out. I'll submit my changes then and look into #1730.

On a personal note, I started investigating ZMQ_REQ_CORRELATE and ZMQ_REQ_RELAXED because I wanted to use these options in my workflow. But since I looked into it more deeply I came to believe that these options are of very little use : in most scenario if you need to make two 'send' in a row on a REQ socket, closing it and reopen it before the second send will do the job : it is simple and effective. So maybe the suggestion in #1730 to drop these options in a future release of libzmq makes sense. Just a thought...

[coveralls]

Coverage decreased (-0.1%) to 74.39% when pulling e45dfe3 on FredTreg:master into 98ab7f4 on zeromq:master.