Connection issues with Perl API -- or is it just me?

[M Nielsen]

A little more info:

I lied about 5.8 (I thought I tested last night on 5.8.0, but it was 
5.6.1 too) -- I just tested on a machine running Red Hat 9 with 5.8 and 
it works as-is with the blocking code, the problem seems to be 
localized to some in the 5.6.x series.  In talking with some Perlmonks 
the idea was thrown around that it could be due to a known bug with 
signals and timers (like the perl API uses time::hires), though I'm not 
enough of a guru myself to know a lot about it.  It was also thought 
that the new SIGALRM support could be a culprit, but I don't think so.

Add't (old, but maybe still valid) discussion here:
http://perlmonks.org/index.pl?node_id=34188

On Monday, Dec 29, 2003, at 15:23 US/Mountain, Brad Fitzpatrick wrote:

> Avva,
>
> You added that blocking/nonblocking stuff.
>
> Any clue why this code works for us, but not for some people?
>
>
>
> On Mon, 29 Dec 2003, M Nielsen wrote:
>
>> Okay, so not 30 minutes after I posted this to the list, another
>> message
>> (http://lists.danga.com/pipermail/memcached/2003-December/000416.html)
>> popped up regarding FreeBSD 5.2.  After commenting-out the two lines 
>> in
>> question the script worked fine on the machine I'm testing on.
>>
>> This machine is by no means bleeding edge - Red Hat 7.2, stock kernel,
>> Perl 5.6.1.
>>
>>
>> On Monday, Dec 29, 2003, at 03:26 US/Mountain, M Nielsen wrote:
>>
>>> I'm having some connection problems with using the perl API.  I know
>>> less than jake about socket programming, so all I've been able to
>>> track down is that connect(), either on line 122  or 130 of the perl
>>> API is failing and calling it a dead server (both issuances return
>>> nothing even though the demon is up and running).
>>>
>>> The demon has been tried on two machines, Redhat 7.2 and 8 (stock UP
>>> kernels) with the latest versions of libevent and memcached (1.1.9)
>>> with poll as the method.  I've tried a simple client app from many
>>> other machines with the latest Perl API (on 5.6 and 5.8), both
>>> localhost and not, with the same result.  I can telnet and set/get
>>> everything by hand just fine so I don't believe the demon is the
>>> problem.  The test code used is simple, almost verbatim from the pod:
>>>
>>> use strict;
>>> use Cache::Memcached;
>>> my $memd = new Cache::Memcached {
>>>     'servers' => [ "127.0.0.1:11211" ],
>>> };
>>> die "set failed" unless ($memd->set("my_key", "Some value"));
>>> print "my_key = " . $memd->get ('my_key') . "\n";
>>>
>>> ...with the above in my tests the die() is triggered and the "stats"
>>> command on the demon via telnet shows no items have been stored.  The
>>> Debug option shows nothing additional. The demon is invoked with:
>>>
>>> memcached -m 10 -l 127.0.0.1 -p11211
>>>
>>> ...I have a sinking feeling it's me doing someone wrong here, but I
>>> can't figure out what.
>>>
>>
>>