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.
