memcached for win32, new java api

[Greg Whalin]

Gregory Block wrote:
> 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.

Good good!  Scared me a bit thinking we had some thread safety issue 
that we had not noticed.  I did not think this to be the case, but never 
hurts to have outside verification.


>> 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.)

I personally am not sure this belongs in the realm of responsibility of 
the client.  I would say this is the duties of the calling code to 
parrallelize the checking/repopulating of the data.  But yes, I agree, 
this is a potential slow area.

>> 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).

Yeah, only synchronized code is in the pool when getting a new 
connection.  Should not be a big slowdown IMO.