libzmq
  1. libzmq
  2. LIBZMQ-307

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical 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.

        Activity

        Hide
        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
        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.
        Hide
        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
        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
        Douglas Young added a comment -
        Show
        Douglas Young added a comment - pull request for fix: https://github.com/zeromq/libzmq/pull/291
        Hide
        Martin Hurton added a comment -

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

        Show
        Martin Hurton added a comment - Commit 4c93fc25879213824c4fb4c9545f895ed7f43b95 seems to fix this. Can we close/resolve this issue?

          People

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

            Dates

            • Created:
              Updated:
              Resolved: