Is it ever possible that your compute takes longer than your timeout?
no, the return value of memcache.delete(lock + x) is true.
On 10/17/10 6:07 AM, Tobias wrote:
Is it ever possible that your compute takes longer than your timeout?
no, the return value of memcache.delete(lock + x) is true.
But wouldn't that also be true if another process found the expired lock and set
a new one?
--
Les Mikesell
Thx for your replies so far. Failover is deactivated in our
configuration. This can not be the reason. I think I have to write a
little bit more
about the circumstances:
our 50+ consistent hashing cluster is very reliable on normal
operations, incr/decr, get, set, multiget, etc. is not a problem.
our 50+ consistent hashing cluster is very reliable on normal
operations, incr/decr, get, set, multiget, etc. is not a problem. If
we have a problem with keys on wrong servers in the continuum, we
should have more problems, which we currently have not.
The cluster is always under relatively
On 14 Okt., 10:00, dormando dorma...@rydia.net wrote:
our 50+ consistent hashing cluster is very reliable on normal
operations, incr/decr, get, set, multiget, etc. is not a problem. If
we have a problem with keys on wrong servers in the continuum, we
should have more problems, which we
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
Hi Diez,
On 14 Okt., 11:39, Dieter Schmidt flatl...@stresstiming.de wrote:
For me it sounds like a configuration problem on the webservers or an
availability/accessability issue.
If for example all machines are accessable the locking key resides on
maschine x. If one of the servers
On 14 Okt., 14:01, Dieter Schmidt flatl...@stresstiming.de wrote:
What happens if the add cmd failes because of an unlikely network error?
The situation is: two different clients are doing an add() with the
same key at the same time. Both are getting true (assuming that this
key has to be on
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
Yeah, we also have used this as a sort of crude locking mechanism on a site
under fairly heavy load and have never seen any sort of inconsistency-- as
dormando said, I'd make sure your configuration is correct. Debug and make
sure that they're both indeed setting it on the same server. Or, if
10 matches
Mail list logo
