[
https://issues.apache.org/jira/browse/WAVE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995452#comment-15995452
]
ASF GitHub Bot commented on WAVE-446:
-------------------------------------
Github user vjrj commented on the issue:
https://github.com/apache/incubator-wave/pull/24
Thanks indeed Pablo for taking care of this important bug.
> Client gets stuck during concurrent editing, no error is shown in console
> -------------------------------------------------------------------------
>
> Key: WAVE-446
> URL: https://issues.apache.org/jira/browse/WAVE-446
> Project: Wave
> Issue Type: Bug
> Components: Protocol, Server, Web Client
> Affects Versions: 0.4.0
> Reporter: Pablo Ojanguren
> Assignee: Pablo Ojanguren
> Priority: Blocker
>
> 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()
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
