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.

Reply via email to