Uploaded image for project: 'libzmq'
  1. libzmq
  2. LIBZMQ-307

When one subscriber socket is closed, another subscriber socket fails to function properly

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 3.0.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Linux

      Description

      I have attached a python program that demonstrates this bug. Basically, at one point in the program, both subscribers are receiving messages just fine (the sleep allows the socket time to setup, on my system). After closing subscriber1 socket, we publish another message and subscriber2 cannot receive it, it just hangs. This is not a late subscriber problem because we do receive a message earlier in the program.

      Also, I ran this test script on 2.1.11 and it works fine.

        Gliffy Diagrams

          Activity

          gmcgraw Garret McGraw created issue -
          Hide
          cdevries Calvin de Vries added a comment - - edited

          I'm fairly certain that I'm seeing this bug in production (I'm using 3.0.2 as well). I have no issues with upgrading to 3.1, especially since Pieter is talking about do a stable release. Before that, though, I think we need to be certain that this isn't happening in 3.1.

          Show
          cdevries Calvin de Vries added a comment - - edited I'm fairly certain that I'm seeing this bug in production (I'm using 3.0.2 as well). I have no issues with upgrading to 3.1, especially since Pieter is talking about do a stable release. Before that, though, I think we need to be certain that this isn't happening in 3.1.
          cremes Chuck Remes made changes -
          Field Original Value New Value
          Priority Major [ 3 ] Critical [ 2 ]
          Hide
          rcxdude Douglas Young added a comment -

          This still occurs on the latest version in git

          What appears to happen is the first part of the second multi-part message is dropped and never sent (as seen by strace). sending more messages works successfully. The order to the socket opening and closing appears to matter. The first socket continues to work as expected after closing the second socket, but not vice-versa. The affected socket always appears to be the last one to be opened which is connected to the pub socket (not necessarily the last one to connect to the socket). the tcp transport is equally affected as the ipc.

          Show
          rcxdude Douglas Young added a comment - This still occurs on the latest version in git What appears to happen is the first part of the second multi-part message is dropped and never sent (as seen by strace). sending more messages works successfully. The order to the socket opening and closing appears to matter. The first socket continues to work as expected after closing the second socket, but not vice-versa. The affected socket always appears to be the last one to be opened which is connected to the pub socket (not necessarily the last one to connect to the socket). the tcp transport is equally affected as the ipc.
          Hide
          rcxdude Douglas Young added a comment -
          Show
          rcxdude Douglas Young added a comment - pull request for fix: https://github.com/zeromq/libzmq/pull/291
          Hide
          hurtonm Martin Hurton added a comment -

          Commit 4c93fc25879213824c4fb4c9545f895ed7f43b95 seems to fix this. Can we close/resolve this issue?

          Show
          hurtonm Martin Hurton added a comment - Commit 4c93fc25879213824c4fb4c9545f895ed7f43b95 seems to fix this. Can we close/resolve this issue?
          pieterh Pieter Hintjens made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]

            People

            • Assignee:
              sustrik Martin Sustrik
              Reporter:
              gmcgraw Garret McGraw
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: