memcache bugs on 64-bit platforms?

[Serhat Sakarya]

I'm trying to narrow down an issue with 1.1.13-pre2 that only occurs when
the store is done through a webserver that runs on the same node (lighttpd
1.1.14/fastcgi/PHP 5.1.4/APC-3.0.10/php memcache client 2.0.4); there is no
issue when the memcached runs on another server or I downgrade to 1.1.12.

Specifically, when I'm storing a large serialized array (300k+), the
subsequent get command results in the error "Failed to read, and not due to
blocking" on the memcached side. When I do a manual get through telnet, I
see that the data is successfully retrieved, but the final "END" is
missing... and it only happens for this value.

This seems symptomatic for an obscure bug... do you have any ideas about the
cause of this problem?

Regards,

Serhat


On 7/25/06, Steven Grimm <sgrimm at facebook.com> wrote:
>
> We are running exclusively on 64-bit machines. We had to modify the 1.1.12sources to support cache sizes of greater than 4GB, but
> 1.1.13-pre2 should have all our changes so you should be fine.
>
> The comment you're referring to is in code that implements a new binary
> protocol. None of the existing clients make use of that protocol so you
> should be safe.
>
> -Steve
>
>
>
> Serhat Sakarya wrote:
> > Does anyone have experience with running memcached on 64-bit
> > platforms? I'm using memcached on a dual-core opteron 170 with RHEL 4.3.
> >
> > I've noticed that 1.1.13-pre2 has protocol bugs that 1.1.12 doesn't
> > (or at least: they're not triggered by the same code). In the code,
> > there is a line "XXX NOT SAFE ON 64 BIT FOR PROTOCOL REASONS NEED TO
> > RECODE TO USE 4 byte INTS ONLY" that indicates that this is a known bug.
> >
> > Can it be safely assumed that 1.1.12 is stable for 64-bit?
> >
> > Regards,
> >
> > Serhat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20060726/34750082/attachment.html