Wave
  1. Wave
  2. WAVE-129

Re-opening a previously opened wave only lets one operation through before channel dies

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      <b>What steps will reproduce the problem?</b>
      1. Open a wave
      2. Open/create another wave
      3. Re-open the wave from step 1, and edit.

      <b>What is the expected output? What do you see instead?</b>

      Expected behaviour is editing works.
      Observed behaviour is that one operation succeeds, and subsequent operations do not, because the channel gets closed after that first operation.


      Issue imported from http://code.google.com/p/wave-protocol/issues/detail?id=128

      Owner: hearn...@google.com
      Cc: ano...@google.com
      Label: Type-Defect
      Label: Priority-High
      Stars: 2
      State: open
      Status: Accepted

        Activity

        Hide
        Ulrich Stärk added a comment -

        Comment 1 by hearn...@google.com:
        I suspect this may be because there is no control flow for closing a wave session / mux, so it may be that two muxs are competing over the same channel, and somehow conflicting?


        Comment 2 by hearn...@google.com:
        Problem found.

        Since there is no mechanism in the old protocol for a client to close a wave session, then after opening a wave for the second time, the server sends duplicate updates. One is an ack, one is an incoming delta. Since the client-side socket layer demultiplexes these messages based on wavelet name, then both messages go to the new mux, and the channel dies.

        Client-side solution seems possible: the updates are distinguishable by channel id. Updates that come in for closed channels can just be ignored by the client.


        Comment 3 by horst.an...@googlemail.com:
        Tried to notify David after I saw his related post here http://groups.google.com/group/wave-protocol-code-discuss/msg/7a68d3c6b378ddf5 that the described bug is most likely already reported here http://code.google.com/p/wave-protocol/issues/detail?id=100. Just in case nobody noticed.


        Comment 4 by hearn...@google.com:
        Issue 100 has been merged into this issue.


        Comment 5 by hearn...@google.com:
        Update: this issue has been patched over for now, with some client-side filtering.

        Once the new protocol is rolled out, the ability for the client to close wave streams should fix this issue properly. Leaving this issue open until then.

        Show
        Ulrich Stärk added a comment - Comment 1 by hearn...@google.com: I suspect this may be because there is no control flow for closing a wave session / mux, so it may be that two muxs are competing over the same channel, and somehow conflicting? — Comment 2 by hearn...@google.com: Problem found. Since there is no mechanism in the old protocol for a client to close a wave session, then after opening a wave for the second time, the server sends duplicate updates. One is an ack, one is an incoming delta. Since the client-side socket layer demultiplexes these messages based on wavelet name, then both messages go to the new mux, and the channel dies. Client-side solution seems possible: the updates are distinguishable by channel id. Updates that come in for closed channels can just be ignored by the client. — Comment 3 by horst.an...@googlemail.com: Tried to notify David after I saw his related post here http://groups.google.com/group/wave-protocol-code-discuss/msg/7a68d3c6b378ddf5 that the described bug is most likely already reported here http://code.google.com/p/wave-protocol/issues/detail?id=100 . Just in case nobody noticed. — Comment 4 by hearn...@google.com: Issue 100 has been merged into this issue. — Comment 5 by hearn...@google.com: Update: this issue has been patched over for now, with some client-side filtering. Once the new protocol is rolled out, the ability for the client to close wave streams should fix this issue properly. Leaving this issue open until then.
        Hide
        Ali Lown added a comment -

        The 'new' protocol was rolled out eons ago.
        This issue is definitely fixed. (I checked!)

        Show
        Ali Lown added a comment - The 'new' protocol was rolled out eons ago. This issue is definitely fixed. (I checked!)

          People

          • Assignee:
            Unassigned
            Reporter:
            Anonymous
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development