Uploaded image for project: 'Wave'
  1. Wave
  2. WAVE-446

Client gets stuck during concurrent editing, no error is shown in console

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Blocker
    • Resolution: Unresolved
    • 0.4.0
    • None
    • Protocol, Server, Web Client
    • None

    Description

      This issue has been detected in Wave's fork, SwellRT but it is expected to be found in Wave and Kune also because it impacts client/server protocol implementation.

      Steps to reproduce:

      It "appears" during concurrent editing of the same blip. Easier to reproduce having 3 or more users editing concurrently the same blip, it might take some time to happen.

      Summary:

      This bug is caused by a subtle implementation detail of the client/server protocol. In particular when the server sends more than one delta in a ProtocolWaveletUpdate message, in particular when these deltas' versions are not contiguous.

      Description:

      SERVER SIDE:

      A WaveViewSubscription for a particular user has a pending submit request (1). During the waiting period until the submit response (from the WaveletProvider) more than one delta update is queued (2). When the submit response is ready (3), queued update deltas are filtered to avoid sending the transformed delta generated by the client itself (4).

      1) <WaveViewSubscription>.submitRequest() → state.hasOutstandingSubmit = true
      2) <WaveViewSubscription>.onUpdate()
      3) <WaveViewSubscription>.submitResponse()
      4) <WaveViewSubscription>.filterOwnDeltas(state.heldBackDeltas, state);

      A real trace of this follows...

      submitRequest for ch4 last version sent @38060
      onUpdate HELD for ch4 @38060 -> @38061
      onUpdate HELD for ch4 @38061 -> @38062
      onUpdate HELD for ch4 @38062 -> @38063
      submitResponse for ch4 applied to @38060 -> resulting @38062
      filtering deltas
      TO SEND deltas: (@38060 -> @38061) (@38062 -> @38063)
      EXCLUDED deltas: (@38061 -> @38062)

      CLIENT SIDE:

      The ProtocolWaveletUpdate message is received (5) and deserialized (6) in order to deliver to the View Channel (7).
      During deserialization, deltas versions are mistaken in the following method, RemoteWaveViewService.deserialize(). A detailed trace of the buggy loop from this method follows:

      Having as input,

      end ← @38063
      deltas ← (@38060 -> @38061) (@38062 -> @38063)

      the result of deserialization is the following list of deltas with wrong versions:
      (@38061 -> @38062) (@38062 -> @38063)

      Then, deserialized deltas are delivered to the delta channel which gets stuck processing delta’s queue (8):

      lastServerVersion ← @38060
      queue ←
      ack(@38061 → @38062)
      delta(@38061 -> @38062) // this should be delta (@38060 -> @38061)
      delta(@38062 -> @38063)

      deltas are removed from the queue every time lastServerVersion is equal to start version of queue's head delta. In this situation, due to the missing delta (@38060 -> @38061), the delta channel will not send and receive more deltas from/to the wave’s operation channel.

      5) <RemoteWaveViewService>.onUpdate(ProtocolWaveletUpdate update)
      6) <RemoteWaveViewService>.deserialize(ProtocolWaveletUpdate)
      7) <ViewChannelImpl>.onUpdate()
      8) <WaveletDeltaChannelImpl>.flushServerMessages()

      Attachments

        Issue Links

          Activity

            People

              pablojan Pablo Ojanguren
              pablojan Pablo Ojanguren
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated: