> On 14 Okt., 10:31, dormando <dorma...@rydia.net> wrote: > > > Yeah, right. :-) Restarting all memd instances is not an option. Can > > > you explain, why it is not possible? > > > > Because we've programmed the commands with the full intent to be atomic. > > If it's not, there's a bug... there's an issue with incr/decr that's been > > fixed upstream but we've never had a reported issue with add. > > > > I'm not sure what you want to hear. "They're supposed to be atomic, yes." > > - that much is in the wiki too. > > I sure thought, that you designed memd to behave exactly the same with > 1 or many threads and it's good to hear, that there is no pending bug > concerning > atomicity of add() on multiple threads. The reason why someone posts > such a think on the mailinglist is to hear, what the opinion of a dev > is who has all the insight. :-) > So please understand my obstinately behaviour. > We are planning to run some tests concerning this behaviour, maybe I > can provide more detail in the future. But it will be hard to find > proof for a bug in this scenario. For that we have to build > a test scenario, with multiple instances trying to make an add() on > the same key on the exact same time on a consistent hashing cluster.
Can you give more info about exactly what the app is doing? What version you're on as well? I can squint at it again and see if there's some minute case. Need to know exactly what you're doing though. How long the key tends to live, how many processes are hammering the same key, what you're setting the timeout to, etc. Your behavior's only obstinate because you keep asking if we're sure if it's atomic. Yes it's supposed to be atomic, if you think you've found a bug lets talk about bug hunting :P
