memcached for win32, new java api

Gregory Block gblock at ctoforaday.com
Tue Nov 30 02:08:36 PST 2004


On 29 Nov 2004, at 23:12, Greg Whalin wrote:
> Here I am confused?  We don't make any assumption about this running 
> in a single thread.  Since we are pulling all sockets from a pool, 
> this method should be as easily parallelized as any other method in 
> the client.  Are you saying you have found a case where our client is 
> not thread safe?  If so, please, by all means let me know. I can say 
> that we run the client in a pretty heavily parallelized environment 
> with a single instance and have had no problems, but tracking 
> threading bugs can always be a bit tricky, so if you know something we 
> don't, share the love.  :)

Now I'm going to have to go back and review that assumption.  :)  I was 
sure it was one of those situations where using getMulti() could use up 
all available connections, but now that I'm sitting here thinking about 
it, that doesn't make a whole lot of sense, as you're right, the pool 
should go ahead and create additional connections for others.

Could have been.. Actually, am totally wrong on this.  Thanks for the 
heads up.  :)  You're right.

> A nice thing about using a connection pool and a parallelized 
> environment, is that there is much less of a benefit to using 
> getMulti()  (you save a bit in network bandwidth at the cost of more 
> parallelization).  This is of course, assuming no optimizations on the 
> server side to using getMulti(), which I honestly have to profess my 
> ignorance.  Anyhoo, this is a bit off topic.

Totally.  There should be a minor benefit to getMulti(), at least in 
the previous implementation, as it should push all of the requests onto 
the network before retrieval; assuming multiple servers are in use, 
getMulti() should reduce request latency.

(On the other hand, when you know some entries won't have contents in 
cache, you then have to do a bunch of processing to figure out which 
bits did and didn't have answers, and fetch real objects for the keys 
which returned no data from cache when requested.  The only good way 
I've found of doing that is to go with a key->id map, retrieve the 
key->value map via getMulti(), step through it looking for missing 
data, and look up the information you needed on the way in via the 
key->id map to construct; and at the moment, that's single-threaded 
(though I'm about to take a whack at JOMPing that code, methinks.)

> Again, we only ever have one instance of the client, which uses a pool 
> of sockets.  If you are only ever gonna have one connection open to 
> the server, then a pool of clients should work as well.
>

You're dead to rights on this.  I can now see no point in not switching 
away from our current pooled-client implementation (unless there are 
performance issues related to synchronization, which I gather from your 
usage is unlikely).



More information about the memcached mailing list