Inconsistent Protocol Access?

[Brendan W. McAdams]

So, I'm even more confused.  Same results with Perl.  there are 6 servers in
our cluster.  It looks like PHP, using addServer adds it to a "pool".
I telnetted around the servers and found that 1 of the keys I'm looking for
is on server 1, and the other is on server 2.  PHP finds both; Perl and
Python only find the one on server 2.  If I move server 2 to the front of
the list, it finds the one on server 2 and not on server 1.  It seems like
Perl/Python aren't trying the other servers.

Can someone explain to me what's going on here?  I'd love to figure this out
so I can build some sane monitoring tools for data.

On 8/21/07, Brendan W. McAdams <bwmlists at evilmonkeylabs.com> wrote:
>
> I'm attempting to debug some issues in a production system; the system is
> on PHP 4.4 with the PECL Extension version 2.1.2.
>
> We are setting keys for customers of the type:
> statistic_<customer_id>_<sub_id> within our PHP application.
>
>
> In some cases a customer doesn't have a sub_id, and we set the key as
> statistic_<customer_id>_
>
>
> I am able to reliably access these numbers from PHP (They are just
> integers: they are incremented using the builtin incr method in memcache);
> however, when I try either of the Python libraries (pure Python and C
> binding implementations) in certain cases I can't get an object for
> statistic_ ; it seems to mostly be in cases when there's no sub id but I do
> see it sometimes when there is.
>
>
> It's my understanding that the access should be the same across all
> languages, and as we're seeing some issues where sometimes dumping the data
> in memcache out to the database is not always returning the full numbers,
> I'm wondering if there's a deeper issue.
>
>
> Anyone got any thoughts or guidance for me?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070822/88861108/attachment-0001.html