I haven't used VoyageMongo, but just a general comment that maybe the testcase is best produced at your end, since you understand the symptoms and can cut down a slice of your application as a template. Publishing that to the mail list provides an explicit demonstration of the problem making it easier for someone to assist. Indeed, as an extension if all the steps to load up VoyageMongo and set up the environment are included, sometimes I'll even be inclined to investigate such things that are unknown to me as a form of goal-directed learning (although right I'm now tied up with some other things).
cheers -ben On Thu, Dec 3, 2015 at 10:02 PM, Holger Freyther <hol...@freyther.de> wrote: > >> On 03 Dec 2015, at 09:58, Holger Freyther <hol...@freyther.de> wrote: >> >> Hi guys, > > >> This is a write "heavy" workload but at no point in time more than a couple >> of objects will >> be in the cache. So somehow the VOMongoCache>>#compactIfNeeded check does not >> trigger and/or given the difference in the sizes of the dictionary it is >> possible that some of >> the dead objects are not removed from the timestamp cache. > > the keyword here is "delete" heavy. VOMongoCache>>#removeValue: is called by > the > VOMongoRepository>>#remove: but this leaves the timeStamp (pharo v3 version or > versions in newer) to have an entry for a OID that was removed. > > And as >>#performCompact will only remove "dead" keys from timeStamp/versions > it will > leave many delete entries in the timeStamp. > > The other thing is that I wonder why the self mutex critical lock is not > taken around the > removal of the object? > > Is there anyone willing to resolve this, create a testcase and make a > backport to Pharo3? > > holger
