Questions about JRuby memcached client


#1

Hi,

So in light of recent discussions about bugs in the JRuby memcached
client
uncovered during load on the Glassfish app server (
http://tinyurl.com/apv6sk) I had a couple questions:

  1. I assume that these bugs would probably up in any JRuby installation
    on a
    app server, including JBoss?

  2. Are there success stories out there with JRuby and memcached, perhaps
    a
    particular combo of client and versions that works well.

At Adobe we would not have a very high request load, perhaps 20 req/sec
max. We were hoping to use memcached with JRuby on JBoss however to
save
tme on some of our longer database queries.

Thanks,

John


#2

Hi John,

To answer your question:

  1. I couldn’t tell you if the issues would appear, but I suspect that
    they
    will since they seem to be related to the way that the Ruby MemCache
    client
    is written. My guess about why these issues don’t appear more often in
    Mongrel and MRI is that users either wrap requests with a Timeout or
    Mongrel
    times the request out after a certain amount of time. I couldn’t figure
    out
    how to time out a request in Glassfish. Maybe there is some way to do it
    in
    JBoss?

  2. We have been running the version of the client on GitHub in
    production
    for some time now, and things are looking stable. We haven’t had a
    single
    incidence of the IO problem. I’ll have to update that README to say that
    we
    are using it in production.

I think that you should consider using the client (and contribute!).
What we
found at LinkedIn was that high load exposes the issue, but the amount
of
load itself does not seem to cause the problem. I’ve heard that folks at
Oracle are using the regular Ruby MemCache client for an application
with
fairly low load and they have never seen the issue. We use MemCache
pretty
excessively in our application: we cache the to_json method for some
Objects, we cache entire Objects in MemCache, using INCR and DECR on
rapidly
changing values and flush write to persistent store, and to minimize the
hit
to the database for data that we frequently read but very frequently
write.

Ikai