memcached for win32, new java api

[Gregory Block]

On 29 Nov 2004, at 17:20, Evan Martin wrote:
> I randomly stumbled across this:
>   http://www.ctoforaday.com/archives/000039.html
> which indicates they've almost got memcached building on win32 (why? 
> not
> sure...), as well as a "more adventurous" Java client that uses
> connection pools, worker threads, etc. for better performance.

Oh, yes.  I did quite a bit of work on it.  Then it got utterly stomped 
on, performance-wise, by the work done by meetup.

Mind you, I'm not using it as-is; the Meetup client has one of the same 
problems I had in the beginning, which is with the assumption that 
get-multi will only be used in a single-threaded manner.

However, the easiest way I've found of managing this is to actually 
just go ahead and create an object pool of memcached clients, and grab 
one out of the pool every time I need one in order to supply myself 
with the level of parallelism required.

For the most part, this works without a hitch.

> However, August 6th is the last time it's mentioned, so I'm CC'ing this
> mail to the memcached list to some guesses at the author that that blog
> post in hopes of attracting interest from lurkers on this list and
> getting him inspired to distribute/integrate his work.  :)


I did indeed to a truckload of work to get everything up and running 
under win32.  When used under cygwin, I was getting scary CPU lockups 
and random blue-screens out of the two folks using NT boxes at the 
time.

I've done a lot of work to get it to where it is, but quite frankly, it 
was just as easy to have one of those people instead point their dev 
servers at one of the other developers' unix boxen when testing their 
software; the live service is all based on linux anyways, and so we 
weren't looking for a solution we needed in production.

If someone wants to bear the mantle of managing that nightmare (I had 
to compile that blasted thing under VirtualPC on my mac.  Don't ask.) 
I'll very happily pass the torch.

The problem, as always, is libevent; it just isn't kept abreast with 
the libevent development; when I asked about a specific problem I was 
having with the author, he even handed me a patch - so it's clearly a 
known problem, it's just not well maintained on win32.

A bigger question would be to find out whether cygwin's behavior has 
improved, and whether those lockups have been solved.  If they have, 
cygwin is almost guaranteed to be a better environment, if for no other 
reason than not requiring the Win32 compiler suite.  :)