It's not portable and currently the detection scheme use really easy to
break and report false positive. Try to rather launch services on
different ports.
Change-Id: I0739bea2f8fe42e1bba1c04e6ce5be14237dfbcb
Instead of raising raw psycopg2 errors/exceptions from the
postgresql driver we should make an attempt to translate
those errors/exceptions into a equivalent tooz exception to
make it so that users of tooz can handle the known driver
failure modes in a sane manner (users expecting to user tooz
as a pluggable abstraction will not be able to handle raw
psycopg2 errors/exceptions, especially if those users are
using different tooz backends at the same time).
Change-Id: Ic95e5fa21bb25096a31b5c5e38aa0b14afa05d87
Avoid the case where 'client3' doesn't leave the group before
we start to check for that removal in the main client by using
the get() operation on the 'client3' leave_group() operation.
Change-Id: I4f1cc3ea1088d0cd026023c72018ee6716b9bbc8
memcache does not clear group members when members expire.
run_watchers checks group value specifically rather than calling
get_members function which filters dead members. this patch makes
run_watchers call get_members.
Change-Id: Ic96116c40642e98ca4edff2bfdb217578e6cfb45
Closes-Bug: #1392800
When running watchers we scan over all the currently existing
groups, during this scan of groups and associated members we
can determine if the the member that the driver represents has
been kicked out of the group and clean out our '_joined_group'
set when this has been detected.
Change-Id: Ib17543f2401804d2d3573d9b8bdeb55cb2c9f606
When a group used to exist (or for some reason still exists
in the groups list) we should avoid failing when getting
members of that group in the running of watches function and
should instead handle that case specially and trigger all
watches (to notify those watches that everyone was removed).
Change-Id: I5484857e6ea58f1cdec5f9f8fac69a3571e053ed
To avoid having the redis driver connecting to a
very old redis we should try to be defensive and
raise an exception if we are connecting to a redis
version that will just not provide enough working
functionality for this driver to work correctly.
Change-Id: Ic16990805d8ac015f2c1f12f44e4115dba366135
In order to provide more accurate heartbeating expiry we should
try to use the PSETEX command when we can (which supports millisecond
resolution expiry instead of using the SETEX which only supports
second level expiry).
Change-Id: I4f6e6b20ec26d9da03caf508c8e6b4c54c156f93
Deletion of multiple keys in one call was added in 2.4.0 so
we should try to use it if we are in that version (or newer) to
avoid doing a loop that does the same (optimizing bandwidth
and call count and such).
Change-Id: I145e75327fa4f826fa0e93d3270952089da9784f
If we got kicked out of a group, or the group got removed
we don't need to log a warning when stopping and an error
related to the above occurs.
Change-Id: Iccadd6483b7e75d1b1ce3c4e6904a22380af7f1c
When a member has not heartbeated in a given amount of time
it should no longer be present in any of its associated groups,
to accomplish this we need to have a heartbeat key that each
member uses and have the group membership code fetch, check,
and clean members (if they are no longer alive).
Fixes bug 1386684
Change-Id: I89a8343ea9317c0522a6132ea065905b16b27b0d
Avoid using lua locks
The default redis library will try to be smart about using
or not using lua based locks, it seems to not correctly predict
this correctly and then fails with errors such as:
''unknown command 'EVALSHA''
Upstream issue filed:
https://github.com/andymccurdy/redis-py/issues/550
The 'traditional' locks require PEXPIRE used by the redis-py
library which requires redis 2.6+ to actually work. So when
we are using a server version that is not new enough
we should conditionally raise a not implemented error to
avoid it later failing (which it will).
This also fixes a bunch of encoding issues that the enabling
of the py33 system now exposed (damn encodings...)
Change-Id: Ied6045276c9a1398db710a68aa75fe92aac9b4bb