Torben,

I'm going to point out where I think this occurs and then piggy-back
on your question.

If you go to fedone.waveserver.WaveServerImpl.submitDelta() you'll see
the comment:

//Broadcast results to the remote servers, but make sure they all have
our signatures.

Following this comment a call is made to host.waveletDeltaUpdate()
with a listener defined for the callback.  After this is done, you
see:

           // TODO: if persistence is added, don't send commit notice
            host.waveletCommitUpdate(waveletName, resultingVersion,
                new WaveletFederationListener.WaveletUpdateCallback()
{
                  @Override
                  public void onSuccess() {
                  }

                  @Override
                  public void onFailure(String errorMessage) {
                    LOG.warning("outgoing waveletCommitUpdate failure:
" + errorMessage);
                  }
            });

I believe you get the first response from the listener after the
update is successful and the second commit notice from the code
snippet above.  The message (if persistence was added) is indeed
committed when you get the first notice in response to the
waveletUpdate.

The path this occurs is fedone.waveserver.WaveServerImpl.submitDelta()
which has the following code:

      synchronized (wc) {
          submitResult = wc.submitRequest(waveletName, delta);

submitRequest() is then handled by
fedone.waveserver.LocalWaveletContainerImpl.submitRequest() which
calls
fedone.waveserver.LocalWaveletContainerImpl.transformAndApplyLocalDelta()
which has the following code:

      DeltaApplicationResult applicationResult =
commitAppliedDelta(appliedDelta,
        new WaveletDelta(deltaAndVersion.first.getAuthor(),
transformedOps));

This calls
fedone.waveserver.WaveletContainerImpl.commitAppliedDelta(), which
commits the delta to the wavelet container and returns the result.
Theoretically if persistence was added, it would occur here and return
the result all the way back up the chain to
fedone.waveserver.WaveServerImpl.submitDelta() (Google, please advise
if I am wrong).

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

Thanks,

Anthony

On Feb 16, 7:34 am, Torben Weis <[email protected]> wrote:
> Hi,
>
> during my wave-server-hacking-quest I started to wonder what the real
> purpose of commit-notice is. My Wireshark experiments showed that I can get
> a wavelet-update in one XMPP stanza and the commit-notice in the next one
> (without any reconnects in between). Thus, the wavelet-update I received is
> uncommitted for some short time?
> Here is an excerpt of the XMPP data:
>
> <message type="normal" from="wave.wave1.vs.uni-due.de" id="5571-2" to="
> wave.wave2.vs.uni-due.de">
>    <request xmlns="urn:xmpp:receipts"/>
>       <event xmlns="http://jabber.org/protocol/pubsub#event";>
>          <items>
>            <item><wavelet-update 
> xmlns="http://waveprotocol.org/protocol/0.2/waveserver"; wavelet-name="wave://
> wave1.vs.uni-due.de/w+286932502/conv+root
> "><applied-delta><![CDATA[CvkBCk0KGAgIEhQnq6X...tPLk5yQ=]]></applied-delta> 
> </wavelet-update>
>           </item>
>          </items>
>        </event>
> </message>
> <message type="normal" from="wave.wave1.vs.uni-due.de" id="9727-3" to="
> wave.wave2.vs.uni-due.de">
>  <request xmlns="urn:xmpp:receipts"/>
>   <event xmlns="http://jabber.org/protocol/pubsub#event";>
>     <items><item><wavelet-update 
> xmlns="http://waveprotocol.org/protocol/0.2/waveserver"; wavelet-name="wave://
> wave1.vs.uni-due.de/w+286932502/conv+root">
>        <commit-notice version="9"
> history-hash="D40bHaCz3fmoyKumEnWorK8vQVA="/></wavelet-update>
>      </item>
>   </items>
>  </event>
> </message>
>
> 1) If the wavelet update is really uncommitted for some time:
>
> Handing out data that is not yet committed seems like asking for trouble.
> The only reason for doing so is IMHO to gain speed (i.e. no need to
> synchronize with disk IO) and hope that it does not come back to bite us.
>
> What is a remote wave server expected to do with uncommitted data?
> a) It is holding data back until it is committed, then sends data to its
> clients -> most of the speed gain is gone -> the performance gain is perhaps
> not worth the effort
> b) It is sending uncommitted data to the client. What happens if no commit
> notice appears? How long should the server wait? If no commit notice
> arrives, what to do? The clients have already consumed uncommitted data ->
> the wave blows up in front of the users
>
> 2) If my reading is wrong and the update is committed before the update is
> sent:
>
> Then commit notice is only kind of a reminder that some wavelet has reached
> a certain version number. In this case the spec should state that all
> wavelet updates sent are committed. Furthermore, the above commit notice
> could be omitted.
>
> What is the intended purpose of commit-notice?
>
> Cheers
> Torben

-- 
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.

Reply via email to