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 at https://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.
