.
The other option for us would be to modify the client side code to set
a timer and close the sockets that have been idle for n seconds, but
would like to avoid this as far as possible.
Thanks,
Prasad
overrunning the server buffer/ TCPIP buffer?
Regards,
Prasad
mention
is the socket revc buffer right?
Its just that the key number that the client is currently sending is
much higher than the one the server has processed.
So can't figure out why the disjoin. The iirc solution sounds seems
the right way to go to get around this.
Thanks,
Prasad
On Sep 29, 3:
small chunk
of multigets are reached inherently? Since I don't call the fetch till
I return from the mget API call.
Thanks,
Prasad
On Sep 29, 5:14 pm, Brian Aker wrote:
> Hi!
>
> On Sep 29, 2011, at 2:07 PM, dormando wrote:
>
> > Still, I thought this was fixed already.
characters.
Thanks,
Prasad
On Sep 29, 8:22 pm, Brian Aker wrote:
> Hi!
>
> On Sep 29, 2011, at 2:30 PM, Prasad wrote:
>
> > And so with this fix does the client call a fetch after a small chunk
> > of multigets are reached inherently? Since I don't call the fetch ti
me know if any other client is preferred over spymemcached
for handling failovers.
Regards,
Prasad
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
quot;
CACHESIZE="1"
OPTIONS="-S -v >> /var/log/memcached 2>&1"
Anyone have any idea why this might be happening?
Regards,
Prasad
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubs
]
Dec 30 16:01:02 ip-10-82-116-125 kernel: memcached[14329]: segfault at 10
ip 0037b4a0f89e sp 7fa7e6fb8b60 error 4 in
libsasl2.so.2.0.23[37b4a0+19000]
Looks like its memcache + sasl issue.
Regards,
Prasad
On Wed, Dec 30, 2015 at 4:43 PM, dormando wrote:
> Hi,
>
> Do you have a
