[
https://issues.apache.org/jira/browse/WAVE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pablo Ojanguren updated WAVE-446:
---------------------------------
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()
> 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
> Environment: SwellRT/JetPad
> 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)
