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

          Attachments

            Activity

            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.
            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?

              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: