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