ets:lookup and ets:update_counter return  although key/value is there
Tue Sep 13 10:22:17 CEST 2005
after upgrading to a more powerfull pentium IV
processor on an ets intensive application we have
experienced that ets:lookup and ets:update_counter
sometimes returns empty list although the key is
there. By doing another lookup/update_couter
immediatly after the failed one, the operation
succeeds (key and value are returned). We see that
this problem only affects a small set of keys (and the
same keys). That is, 2 or 3 keys (and the same ones)
out of about 1000 elements in a ets are having
problems every now and then.
There are parallell ets:update_counter/insert working
on the same keys from other processes, but no delete.
I know that ets should be deadly safe, but it is
strange that the second lookup/update_counter happens
immedialty after the failing one ALWAYS succeeds.
The fault is reproducable only on the machine we see
the problem and for the specific keys.
The test simply lookup a key that we have seen
failing. Doing 10000 ets:lookup's about 4 fails.
We have upgraded to R10B without any improvement.
My best clue: I know that the memory driver for erlang
has been changed to delete memory areas before
updating them - to reduce memory fragmentation. Could
it be that there is a time slice where the data is not
BR Knut Bakke.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
More information about the erlang-questions