memcached for win32, new java api
gblock at ctoforaday.com
Mon Nov 29 14:23:52 PST 2004
On 29 Nov 2004, at 17:20, Evan Martin wrote:
> I randomly stumbled across this:
> which indicates they've almost got memcached building on win32 (why?
> 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
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. :)
More information about the memcached