Mongo experts - help need please

Ian Booth ian.booth at canonical.com
Fri Jul 25 05:37:26 UTC 2014


> 
> That said, the goal is of course not to make the developer's life
> miserable. All the driver wants is an acknowledgement that the error
> was perceived and taken care of. This is done trivially by calling:
> 
>     session.Refresh()
>

So in Juju now, we use session.Copy() which calls Refresh() under the hood. We
do this for each database interaction. It's not too onerous.


> Done. The driver will happily drop the error notice, and proceed with
> further operations, blocking if waiting for a re-election to take
> place is necessary.
> 
> 
> This feels very much like a concurrency or timing issue. You might
> also be misunderstanding what session.Copy does.. it's not so magic.
> If session.Copy truly prevented the watcher from working, it wouldn't
> work at all either way. Every independent process that connects to the
> database and does a change is monitored by watchers that live in
> different sessions.
> 
>> The tests are quite simple:
> 
> I'm not able to observe the test failure you mention after hacking it
> to use independent sessions:
> 
> http://paste.ubuntu.com/7852418/
> 

The tests passed for me every time also, with and without independent sessions.
If I loaded my machine to max out CPU usage to 100%, then the tests (different
ones each run) would fail intermittently but reproducibly every time with
session copy, but I could not induce even one failure without session copying.

Maybe the watcher implementation is indeed somehow involved. I'm not 100% across
any subtleties in the implementation as till a few days ago the code was new to
me. I am interested in being able to explain how session.Copy() does observably
affect the test results and relate that to a defect in the code so it can be
fixed. But I don't know how to explain that right now.



More information about the Juju-dev mailing list