1. 01 Jun, 2012 1 commit
    • Ian Barber's avatar
      After speaking with Ben Gray and the discussion on the mailing list, this is an… · fe3fb419
      Ian Barber authored
      After speaking with Ben Gray and the discussion on the mailing list, this is an attempt to create a sockopt to allow connecting pipes to not immediately be available for traffic. The problem is in a PUSH to many PULL situation, where there is a connect to a PULL which is not there. This connect will immediately create a pipe (unlike bind), and traffic will be load balanced to that pipe. This means if there is a persistently unavailable end point then the traffic will queue until HWM is hit, and older messages will be lost.
      
      This patch adds a sockopt ZMQ_DELAY_ATTACH_ON_CONNECT, which if set to 1 will attempt to preempt this behavior. It does this by extending the use of the session_base to include in the outbound as well as the inbound pipe, and only associates the pipe with the socket once it receives the connected callback via a process_attach message. This works, and a test has been added to show so, but may introduce unexpected complications. The shutdown logic in this class has become marginally more awkward because of this, requiring the session to serve as the sink for both pipes if shutdown occurs with a still-connecting pipe in place. It is also possible there could be issues around flushing the messages, but as I could not directly think how to create such an issue I have not written any code with regards to that.
      
      The documentation has been updated to reflect the change, but please do check over the code and test and review.
      fe3fb419
  2. 04 May, 2012 1 commit
  3. 21 Apr, 2012 1 commit
  4. 18 Feb, 2012 1 commit
  5. 17 Feb, 2012 1 commit
  6. 16 Feb, 2012 1 commit
  7. 04 Feb, 2012 1 commit
  8. 21 Nov, 2011 1 commit
  9. 06 Nov, 2011 1 commit
  10. 01 Nov, 2011 1 commit
  11. 13 Sep, 2011 1 commit
  12. 11 Jul, 2011 1 commit
  13. 23 Jun, 2011 1 commit
    • Martin Sustrik's avatar
      Outstanding requests dropped when requester dies (issue 190) · d1373792
      Martin Sustrik authored
      So far the requests in req/rep pattern were delivered to and processed
      by worker even though the original requester was dead. Thus,
      the worker processing replies with noone to deliver results to.
      This optimisation drops requests in two situations:
      
      1. Queued inbound requests in XREP socket when peer disconnects.
      2. Queued outbound requests in XREQ when socket is closed.
      Signed-off-by: 's avatarMartin Sustrik <sustrik@250bpm.com>
      d1373792
  14. 22 Jun, 2011 1 commit
  15. 20 Jun, 2011 1 commit
  16. 17 Jun, 2011 1 commit
  17. 30 Jan, 2011 1 commit
  18. 20 Jan, 2011 1 commit
  19. 17 Nov, 2010 1 commit
  20. 01 Oct, 2010 1 commit
  21. 28 Aug, 2010 1 commit
  22. 27 Aug, 2010 2 commits