yikuang / wave-protocol

Automatically exported from code.google.com/p/wave-protocol
0 stars 0 forks source link

Client cannot rejoin wave after Wave Server restart #34

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Join a wave, have a conversation
2. Restart your Wave Server
3. Have other participant continue to send information to existing wave

What is the expected output? What do you see instead?

What I believe should be happening is that the client should be seeing the
incoming delta, recognise that it doesn't have an entry in the index.wave
and then request the full history.

What instead is happening is that it seems to be baulking at the delta
because there isn't an entry in the index.wave. This means that the client
is unable to rejoin the existing wave.

What version of the product are you using? On what operating system?

latest hg pull on linux(Fedora)

Original issue reported on code.google.com by JamesRPu...@gmail.com on 13 Aug 2009 at 11:09

GoogleCodeExporter commented 9 years ago
If this is still a problem, could you give more details?  E.g. log output, more 
detailed scenario (where the wavelet is hosted, etc).

Original comment by btkalman@gmail.com on 27 Aug 2009 at 8:30

GoogleCodeExporter commented 9 years ago

Original comment by btkalman@gmail.com on 27 Aug 2009 at 8:33

GoogleCodeExporter commented 9 years ago
Tests seem to indicate it depends where the wave is hosted. If the wave is 
hosted on
another server, then the entire wave gets copied again (when updated) to remove
servers, and works again as normal. As long as somebody updates the wave 
remotely,
there is no problem.

The the wave is hosted on the local server that is restarted, then the wave 
becomes
dead on remote servers, and it is not possible to update it any more.

During a test, the following messages were logged at my end, the server that 
hosted
the wave and was restarted:

29/08/2009 9:47:31 AM
org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent 
processPacket
INFO: received XMPP packet:

<iq from="wave.wave.collaborynth.com.au" to="wave.microcomaustralia.com.au"
type="set" id="3069-24">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="signer">
      <item>
        <signature xmlns="http://waveprotocol.org/protocol/0.2/waveserver"
domain="wave.collaborynth.com.au" algorithm="SHA256">

<certificate>MIIEKDCCA5GgAwIBAgIJAMLC6TX0uJMKMA0GCSqGSIb3DQEBBQUAMIG/MQswCQYDVQQ
GEwJBVTEYMBYGA1UECBMPTmV3IFNvdXRoIFdhbGVzMQ4wDAYDVQQHEwVEYXB0bzEVMBMGA1UEChMMQ29
sbGFib3J5bnRoMSIwIAYDVQQLExlXYXZlIERldmVsb3BtZW50IFNlcnZpY2VzMSEwHwYDVQQDExh3YXZ
lLmNvbGxhYm9yeW50aC5jb20uYXUxKDAmBgkqhkiG9w0BCQEWGWphbWVzQGNvbGxhYm9yeW50aC5jb20
uYXUwHhcNMDkwODI4MjMyMTI0WhcNMTAwODI4MjMyMTI0WjCBvzELMAkGA1UEBhMCQVUxGDAWBgNVBAg
TD05ldyBTb3V0aCBXYWxlczEOMAwGA1UEBxMFRGFwdG8xFTATBgNVBAoTDENvbGxhYm9yeW50aDEiMCA
GA1UECxMZV2F2ZSBEZXZlbG9wbWVudCBTZXJ2aWNlczEhMB8GA1UEAxMYd2F2ZS5jb2xsYWJvcnludGg
uY29tLmF1MSgwJgYJKoZIhvcNAQkBFhlqYW1lc0Bjb2xsYWJvcnludGguY29tLmF1MIGfMA0GCSqGSIb
3DQEBAQUAA4GNADCBiQKBgQD2pjz7Oqpd1Voh+mtb0K8OVtw6b6k5638Do2Oig0FkTN8jmLDpxx+kkVr
WEpqmmDy3f6PTwJn6DF24Hx1Abs8NJRuZ0Nfo/5BXtS8dqCvXfBZfk8KcxYsum/6YPBvPXIiJGu/+e5Z
b27l+Kh5NUPhoeTpvQsC7rEjK291jfJ8lZQIDAQABo4IBKDCCASQwHQYDVR0OBBYEFDVcud4g4LkN9WZ
rLnsCGeQ4W2jaMIH0BgNVHSMEgewwgemAFDVcud4g4LkN9WZrLnsCGeQ4W2jaoYHFpIHCMIG/MQswCQY
DVQQGEwJBVTEYMBYGA1UECBMPTmV3IFNvdXRoIFdhbGVzMQ4wDAYDVQQHEwVEYXB0bzEVMBMGA1UEChM
MQ29sbGFib3J5bnRoMSIwIAYDVQQLExlXYXZlIERldmVsb3BtZW50IFNlcnZpY2VzMSEwHwYDVQQDExh
3YXZlLmNvbGxhYm9yeW50aC5jb20uYXUxKDAmBgkqhkiG9w0BCQEWGWphbWVzQGNvbGxhYm9yeW50aC5
jb20uYXWCCQDCwuk19LiTCjAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBACziQNUvzMZFwub
w0NhEylkvREDHVPV8B77w2FqLR0ZBvt5ELjrBvnfFhYvWSJ/bmxntxBxn4lGHDe0Mg07JvE5ZsEcHT/t
rZJdYg/hwxeLrX8W1lYoqQmkF0mwbsWReIIOV9a7iuL045/jy4bIriYtbBs80OpVlZp8Uko2eaM5g</c
ertificate>
        </signature>
      </item>
    </publish>
  </pubsub>
</iq>
29/08/2009 9:47:31 AM
org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent 
sendPacket
INFO: sent XMPP packet: 
<iq type="result" id="3069-24" from="wave.microcomaustralia.com.au"
to="wave.wave.collaborynth.com.au">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish>
      <item node="signer">
        <signature-response xmlns="http://waveprotocol.org/protocol/0.2/waveserver"/>
      </item>
    </publish>
  </pubsub>
</iq>
29/08/2009 9:47:31 AM
org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent 
processPacket
INFO: received XMPP packet:

<iq from="wave.wave.collaborynth.com.au" to="wave.microcomaustralia.com.au"
type="set" id="8457-25">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="wavelet">
      <item>
        <submit-request xmlns="http://waveprotocol.org/protocol/0.2/waveserver">
          <delta
wavelet-name="microcomaustralia.com.au/w+wxzvRfpHa2HL/conv+root">CqIBChgIBRIUIeV
zOT1S0yeQ1GqRJN8i0Pu/FEYSIHB1cnNlcmpAd2F2ZS5jb2xsYWJvcnludGguY29tLmF1GmQaYgoEbWF
pbhJaCgIoeQowGi4KBGxpbmUSJgoCYnkSIHB1cnNlcmpAd2F2ZS5jb2xsYWJvcnludGguY29tLmF1CgI
gAQoeEhxva2F5IGxldCdzIHNlZSBpZiB0aGlzIHdvcmtzEqcBCoABQPVR4qKOQsPuJysNuvVopT6xB/f
iea7af/rYb9gx9Jv5EFjjrZzB7Bc2s8Ch5suFa93jlgbPg0lW5x6ohS8So9DyaXBOdE1KUUvd6LuNLpL
6zNrX7EO3HeUZC1SAM4c7tzm63ErISsPVVrByPXB7HiG2CXMKNR8rHQz7DPyA+kQSIKmZUK9HhX8GS4Y
lLINQ7zIVBTPW9X4roJc/6hhs0PBdGAE=</delta>
        </submit-request>
      </item>
    </publish>
  </pubsub>
</iq>
29/08/2009 9:47:31 AM 
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl
isLocalWavelet
INFO: ### WS is local?
[WaveId:microcomaustralia.com.au!w+wxzvRfpHa2HL]/[WaveletId:microcomaustralia.co
m.au!conv+root]
= true
29/08/2009 9:47:31 AM 
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl
isLocalWavelet
INFO: ### WS is local?
[WaveId:microcomaustralia.com.au!w+wxzvRfpHa2HL]/[WaveletId:microcomaustralia.co
m.au!conv+root]
= true
29/08/2009 9:47:31 AM 
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl
submitDelta
INFO: ## WS: Got submit:
[WaveId:microcomaustralia.com.au!w+wxzvRfpHa2HL]/[WaveletId:microcomaustralia.co
m.au!conv+root]
delta: ByteStringMessage: hashed_version {
  version: 5
  history_hash: "!\345s9=R\323\'\220\324j\221$\337\"\320\373\277\024F"
}
author: "purserj@wave.collaborynth.com.au"
operation {
  mutate_document {
    document_id: "main"
    document_operation {
      component {
        retain_item_count: 121
      }
      component {
        element_start {
          type: "line"
          attribute {
            key: "by"
            value: "purserj@wave.collaborynth.com.au"
          }
        }
      }
      component {
        element_end: true
      }
      component {
        characters: "okay let\'s see if this works"
      }
    }
  }
}

29/08/2009 9:47:31 AM 
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl
isLocalWavelet
INFO: ### WS is local?
[WaveId:microcomaustralia.com.au!w+wxzvRfpHa2HL]/[WaveletId:microcomaustralia.co
m.au!conv+root]
= true
29/08/2009 9:47:31 AM
org.waveprotocol.wave.examples.fedone.waveserver.WaveletContainerImpl
transformSubmittedDelta
WARNING: Got empty server set, but not sumbitting to head!
WaveletDelta(purserj@wave.collaborynth.com.au, 1 ops:
[WaveletDocumentOperation(main,__121; << line { by="by" }; >>; ++"okay let's 
see if
this works")])
29/08/2009 9:47:31 AM
org.waveprotocol.wave.examples.fedone.federation.xmpp.XmppFederationHost$SubmitR
esponsePacketListener
onFailure
WARNING: submit request to waveserver failed: Cannot submit to head

Original comment by penguin....@gmail.com on 28 Aug 2009 at 11:57

GoogleCodeExporter commented 9 years ago
Sorry, typos in first paragraph makes it confusing :-(

Tests seem to indicate it depends where the wave is hosted. If the wave is 
hosted on
a *remote* server, the *local* server is restarted, and the wave is updated
*remotely*, then the entire wave gets copied again to the *local* server, and 
works
again as normal. As long as somebody updates the wave *remotely*, there is no 
problem.

Original comment by penguin....@gmail.com on 29 Aug 2009 at 12:07

GoogleCodeExporter commented 9 years ago
This is expected.  If a server restarts then it loses the information about all
wavelets (no persistence).  If the server wasn't the host then it's fine, it 
will get
an update from the host, realise it's missing the history, then request it (and
persistence would allow the server to preemptively request the history).

However if the server was the host of the wavelet then the same thing can't 
happen,
there isn't a way for the host to request its own history from remote servers. 
Again, need persistence.

In any case, this doesn't actually seem to relate to the original reported 
client bug.

Original comment by btkalman@gmail.com on 29 Aug 2009 at 1:44

GoogleCodeExporter commented 9 years ago
In what way do my comments not relate to the original bug report? It looks the 
same
to me, even if it wasn't specified where the wave was kept.

This will be a problem even if the server supported persistence, e.g. hard disk
crashed, business closes, etc. It would be good if it was somehow possible to
resurrect/fork the wave based on the data that is stored on the other servers.

Brian May

Original comment by penguin....@gmail.com on 29 Aug 2009 at 6:28

GoogleCodeExporter commented 9 years ago
I say that they don't relate because the bug originally filed seems to indicate 
a bug
related to the *client*, but the hosting issue we've been talking about is 
entirely a
server issue.  However, as you say, it could just be that when this was filed 
it was
misinterpreted as a client bug.

Overall this isn't a bug -- the question of whether there should be a way for a 
host
to recover its wavelets is something that could be discussed properly on the
wave-protcol discussion, not here.  So, I will mark this as closed.

Original comment by btkalman@gmail.com on 29 Aug 2009 at 10:47

GoogleCodeExporter commented 9 years ago
For the record, this was discussed on wave-protocol here:
<http://groups.google.com/group/wave-protocol/browse_thread/thread/bd0f44facefdf
cf9/638e7d68ac0cd752?lnk=gst&q=restart#638e7d68ac0cd752>.

Original comment by penguin....@gmail.com on 31 Aug 2009 at 1:13