Actually there are a couple of changes in the org.waveprotocol.wave.persistence classes as well. I have found the easiest way to merge is not through the patch, but creating a separate clone from https://awatkins03-mongodb.googlecode.com/hg/ and doing a sync. Also, I haven't updated the patch (will do as part of making fixes for the initial codereview).
R, Anthony On Mar 26, 5:19 am, 地狱男爵 <[email protected]> wrote: > I found only the modified restoreIndexWave(ParticipantId > participant ...) method. > > if (userVersionList.get(i).getVersion() > perWavelet.get( > > sourceWaveletName).getCurrentVersion().getVersion()) { > > perWavelet.get(sourceWaveletName).setCurrentVersion( > userVersionList.get(i)); > perWavelet.get(sourceWaveletName).digest = > digest.get(i); > } > > am i right? > > On 3月26日, 下午4时40分, 地狱男爵 <[email protected]> wrote: > > > > > Great, Thanks. > > > I have found that now there is no patch > > fromhttp://codereview.waveprotocol.org/44001/show > > > Which files you have modified? > > > On 3月26日, 上午12时56分, antwatkins <[email protected]> wrote: > > > > Thanks for your inquiry/testing. I was able to duplicate what you > > > noticed in that when the server is restarted, you no longer see the > > > titles on the console client. When you type in more information into > > > the restored wave, titles reappear. > > > > I have tracked this down to the perWavelet object in the > > > ClientFrontEndImpl. This object contains a digest field for the > > > indexWave that is stored in memory and computed when a wavelet is > > > updated. When the server is re-started and the deltas are requested, > > > this digest for the indexWave is not re-computed (I'm not saying it > > > should be btw). > > > > I need to therefore store the digest information for the indexWave and > > > restore it when I retrieve the indexWave for a participant. I have > > > made this update and pushed to the mongodb-clone > > > athttps://awatkins03-mongodb.googlecode.com/hg/. You should now see > > > the titles on the console client when you restart your wave server. > > > > Thanks for your input! > > > > R, > > > > Anthony > > > > On Mar 25, 6:23 am, 地狱男爵 <[email protected]> wrote: > > > > > After reboot, log back in the console. The title of console list is > > > > Empty. > > > > I have to re-enter the console after a new message. The title was > > > > displayed. > > > > > after reboot, why did not the title of the list ? > > > > > On 3月25日, 上午10时30分, antwatkins <[email protected]> wrote: > > > > > > I've updated the clone at > > > > > https://awatkins03-mongodb.googlecode.com/hg/ > > > > > . Please let me know how it works out for you. > > > > > > R, > > > > > > Anthony > > > > > > On Mar 24, 3:07 pm, antwatkins <[email protected]> wrote: > > > > > > > Thanks for your feedback! It was quite valuable. I honestly never > > > > > > restarted the mongodb database without having also restarted the > > > > > > server (most of my focus was just on shutting down FedOne). So I > > > > > > was > > > > > > able to duplicate your issue and it shed some light on a larger > > > > > > issue. > > > > > > > First, here is what was happening in your case. If mongodb is > > > > > > restarted without restarting the server or client, the in-memory > > > > > > objects maintained in WaveletContainerImpl are still present. The > > > > > > next time you try to commit a delta to the database, it fails due to > > > > > > the db connection being severed. The issue is I allow the commit > > > > > > procedure of WaveletContainerImpl to proceed and throw an error > > > > > > afterwards. This error, however, stops the rest of the processing > > > > > > such that the indexWave is not updated and the client does not > > > > > > update > > > > > > its delta version. Therefore the next time you submit the client > > > > > > attempts to apply its delta at say 12, but the in-memory object has > > > > > > 15 > > > > > > as the start version and you get the error you saw. > > > > > > > The larger issue is when I first developed the persistence solution > > > > > > I > > > > > > did not want errors in persisting data to affect the regular > > > > > > operation. This was faulty thinking. As was brought up in the > > > > > > initial codereview, if people believe information is being saved, > > > > > > then > > > > > > they need to be informed if an error occurs and the in-memory state > > > > > > needs to be consistent. > > > > > > > So I fixed this issue by not allowing the in-memory store to be > > > > > > updated unless the persistence was successful. I also made another > > > > > > adjustment dealing with the indexWave. In FedOne, there is > > > > > > currently > > > > > > no way to recover if your indexWave is out of sync with the > > > > > > endVersion > > > > > > of the deltas. This doesn't really present itself as a problem > > > > > > without persistence, because the perWavelet and perUser objects > > > > > > maintained in ClientFrontEndImpl store all version information for > > > > > > all > > > > > > participants on all sessions. The issue when you persist is that > > > > > > upon > > > > > > server startup you do not (and would not want to) load all > > > > > > indexWaves > > > > > > for all users that have ever hosted a wave on your server. I don't > > > > > > want to get into specifics here, but suffice to say you'll get > > > > > > another > > > > > > HashedVersion error under very common scenarios if your indexWave is > > > > > > out of sync. I initially solved this by ensuring the indexWaves of > > > > > > all participants for a specific wave were pulled into memory when > > > > > > updates were made so they be kept in sync. I just added an update > > > > > > which will not throw an error if the expectedVersion is less than > > > > > > the > > > > > > version being applied for a participant. Instead I request the > > > > > > difference in history and update the conversation accordingly. > > > > > > > This all seems to be working well. I just want to go through some > > > > > > more tests before I push to the clone. > > > > > > > Thanks again for reviewing. > > > > > > > R, > > > > > > > Anthony > > > > > > > On Mar 23, 2:52 pm, "W. Palsgraaf" <[email protected]> wrote: > > > > > > > > I cloned your folder and gave it another try: > > > > > > > > I started a new wave, did some textwriting, added another > > > > > > > participant, > > > > > > > closed the console-client, started it with the other participant, > > > > > > > closed the > > > > > > > client and the server. > > > > > > > > then I started the server again. everyting worked fine! > > > > > > > > I stopped the client, and server again, > > > > > > > the i stopped the mongodb server, started it, > > > > > > > > and I got the same problem: > > > > > > > > WARNING: Mismatched hashes: expected: > > > > > > > 12:2e37dcfe5bc0d665670623ad4c559f5f0dee3ffb got: > > > > > > > 15:6ccfc0eb11cecce1123c7fd33d800a69865064bb > > > > > > > > I dropped the database, and did the same test again. This time I > > > > > > > didnt > > > > > > > have any problems. > > > > > > > > Finaly, I did the test again: same problem. > > > > > > > > So i didnt get any problems with stopping and starting the run- > > > > > > > server.sh, but it went wrong when > > > > > > > I stopped and started the mongodb server. > > > > > > > > By the way, I am working with local users > > > > > > > > On Mar 23, 3:16 am, antwatkins <[email protected]> wrote: > > > > > > > > > In order to make testing easier and to ensure a common code > > > > > > > > base, I > > > > > > > > have created a clone of FedOne and uploaded the mongodb > > > > > > > > persistence > > > > > > > > mechanism to that version. It can be found > > > > > > > > athttps://code.google.com/r/awatkins03-mongodb/ > > > > > > > > . Just create a new folder and > > > > > > > > clonehttps://awatkins03-mongodb.googlecode.com/hg/ > > > > > > > > awatkins03-mongodb > > > > > > > > > You'll need to copy in your wave cert and run-* scripts. In > > > > > > > > run- > > > > > > > > server you'll need to add the flag -- > > > > > > > > waveserver_enable_persistence=true . Lastly, you need to > > > > > > > > install > > > > > > > > mongodb (takes about 5 mins, instructions > > > > > > > > here:http://www.mongodb.org/display/DOCS/Getting+Started) > > > > > > > > > R, > > > > > > > > > Anthony > > > > > > > > > On Mar 22, 8:20 am, James Purser <[email protected]> wrote: > > > > > > > > > > On Mon, 2010-03-22 at 02:52 -0700, W. Palsgraaf wrote: > > > > > > > > > > James, > > > > > > > > > > > Did you come any further with this? > > > > > > > > > > I have got the same problem. > > > > > > > > > > Unfortunately not. I haven't tested it against another fedone > > > > > > > > > instance, > > > > > > > > > so I can't tell if it's something peculiar with the > > > > > > > > > wavesandbox > > > > > > > > > federation foo. However I can confirm that a wave started on > > > > > > > > > fedone and > > > > > > > > > containing only local fedone accounts works perfectly. > > > > > > > > > > I can also confirm that I get the same issue with two local > > > > > > > > > and one > > > > > > > > > wavesandbox account. So it would appear that at some point, > > > > > > > > > the sandbox > > > > > > > > > is returning a wrong hash count or the fedone mondgodb foo is > > > > > > > > > storing > > > > > > > > > the wrong hashcount. > > > > > > > > > -- > > > > > > > > > James Purserhttp://wavingtheshiny.collaborynth.com.au > > > > > > > > > Wave Addresses: > > > > > > > > > [email protected] (wave.google.com) > > > > > > > > > [email protected] (wavesandbox.com) > > > > > > > > > [email protected] (collaborynth.com.au FedOne Server) > > > > > > > > > Skype: purserj1977 > > > > > > > > > GTalk: [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.
