Details
-
Bug
-
Status: Open
-
Blocker
-
Resolution: Unresolved
-
0.4.0
-
None
-
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
- links to
