Hi Anthony, I see three serious problems here:
a) Resubmitting a delta does not always work IMHO because there are no IDs or Sequence numbers. We touched this topic already when discussing error recovery. The conclusion was that comparing deltas is Google's suggested approach to detecting duplicates (i.e. resubmissions), but it is not 100% safe and cumbersome. I assume this is a lost battle, but the approach is systematically flawed for no good reason. I propose to send a tuple of epoch&sequence-number with each submit to reliably and easily detect resubmissions by remote wave servers and by clients. b) Imagine the following scenario: '->' means 'sent to': S->R->C, where C is a client, S a wave server and R a remote wave server. Let's assume that S sent a wavelet update but no commit-notice. R has already forwarded the wavelet update to C. After a timeout, R concludes that S has crashed. Now it has to tell C that the uncommitted wavelet update must be revoked. This tremendously increases the complexity of wave clients and wave servers. Is it worth the pain? The only thing commit-notice is optimizing for is "delay". At the same time bandwidth is reduced (commit notice must be sent). c) The current C/S protocol is not able to handle deltas that have been sent to the client and are revoked later (see previous example). We really need the new C/S protocol. Greetings Torben 2010/2/22 Anthony Baxter <[email protected]> > We have the concept of a commit notice in both the server-server and > client-server protocol. > > In order to optimize latency the wavesandbox wave server relays > operations between clients immediately after they are validated and > applied to the in-memory wavelet state on the wave server before they > are persisted to disk. Later, when the operations are persisted, a > follow-up commit notice is sent to inform all clients that the wavelet > state is guaranteed to be persisted up to that version of the wavelet. > If there is an outage anywhere in the data center, there's a risk that > the wave server's in-memory state is lost, so clients can only rely on > operations to "stick" once they receive a subsequent commit notice. > > FedOne works differently than the wavesandbox wave server because > FedOne doesn't persist its state. We have decided to treat FedOne's > memory as its "most persistent" wavelet state and let FedOne send a > commit notice immediately when it applies operations to communicate > that it has persisted them to the best of its ability. > > The wavesandbox web client maintains a queue of operations it has sent > to the wave server which the wave server has applied but not yet > committed. If an outage in a data center happens and uncommitted data > on the wave server is lost then, after the service is reestablished > and the client reconnects to the wave server, the client resends its > queued operations and, when all goes well, the outage goes unnoticed > by the user. > > For servers, a remote server should not persist wave state until it > receives the commit notice from the hosting server. This ensures that > both servers have a common view of the state of the wave. It's > arguable that if you don't see a commit notice after submitting a > change after a certain period of time, you should re-send the submit > request. The current implementation doesn't do this yet. > > On Sat, Feb 20, 2010 at 17:09, antwatkins <[email protected]> wrote: > > Hi, > > > > I am still trying to figure out the purpose of the commit-notice as it > > is used within the code as part of the wavelet-update process. I was > > going back over the spec and it states the commit-notice can be added > > as part of the wavelet-update message. There is the private method > > XmppFederationHostForDomain.waveletUpdate() that would allow this, > > however, there are no public methods available that allow a wavelet- > > update to be sent to a Federation Remote with the optional commit (the > > public methods available allow you either to commit or send deltas, > > but not both). When persistence is added as part of the wavelet- > > update process, is it the intent to supply the commit-notice as part > > of the update and remove the separate call in > > WaveServerImpl.submitDelta()? > > > > Thanks, > > > > Anthony > > > > On Feb 16, 1:01 pm, Torben Weis <[email protected]> wrote: > >> Hi, > >> > >> thanks for the code walk. This helps explaining which part of the code > is > >> doing this. Let's hope that Google tells us why :-) > >> > >> > So my question isn't much different than Torben's. Why are we sending > >> > a commit-notice and what does that have to do with the fact that we > >> > don't have persistence yet since the comment in > >> > fedone.waveserver.WaveServerImpl.submitDelta() says: > >> > >> > // TODO: if persistence is added, don't send commit notice > >> > >> Perhaps the meaning of the comment is to send the commit notice later > (i.e. > >> after data has been persisted)? Currently the commit notice is sent > >> automatically without waiting for any commit (just guessing). > >> > >> Torben > >> > >> > >> > >> > Thanks, > >> > >> > Anthony > > > > -- > > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > > > > > > -- > Anthony Baxter, [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
