[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