[ome-devel] OME install woes: upload file through omeis
august
august at develop.ment.org
Thu Jun 1 17:03:52 BST 2006
> There were some recent commits to CVS for the image server.
> The original problem was an attempted work-around for a race
> condition in Berkeley DB, which apparently held for the versions that
> were tested, and failed miserably for others - especially when first
> populating a new OMEIS repository.
>
> Berkely DB still has a race condition in several of its versions, but
> the latest CVS commits work around them with a much more robust
> technique (by managing our own DB locking by using our own separate
> lock file). Whereas the original fix still resulted in a handful of
> failures (2-5 out of 64,000 "concurrent" writes from 64 processes),
> requiring a hack to "try it 25 times before giving up". The current
> fix had no failures that triggered the "try it again" code (which was
> left in place anyway). Testing was running the 64,000 concurrent-
> write script (t/test-concurrent-write in src/C/omeis) multiple times
> on new and populated repositories on FC1-4 and OS X using single and
> multiple CPUs (this included 32-bit and 64-bit architectures).
>
> Anyway, long story short: It would be helpful to try this again to
> see if this was related to the recent OMEIS/Berkeley DB fix.
>
> Also, I can report that finding and programming around other people's
> race conditions is no fun.
Ilya,
thanks for the report. Unfortunately, I have a working installtion
right now with lots of data and I don't want to muck with it. As soon
as I make a new install attempt (which should be soon) I will report any
oddities. [Or, is there a way to check the install withough having to
dump the DB?]
-august.
More information about the ome-devel
mailing list