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.
