On Thu, Nov 15, 2007 at 00:56:18 -0800, dormando wrote:
For posterity, fix is in r635 from chris (not christ!) and dustin.
I read it, played with it a bit, ran tests, ran it, looked okay.
Runs entirely inside a lock, logic appears sane.
Adds 8 bytes to the item struct.
Thanks for the good
On Thu, Nov 15, 2007 at 09:47:46 -0800, dormando wrote:
Sure, I guess it's a great way to OOM the machine (I'd be very impressed
if someone actually did this!) since iov bytes aren't presently limited
by anything, but it doesn't presently deadlock like you say it does.
Hmm, maybe I don't get
Hmm, maybe I don't get the code, but I think the server may switch
from conn_write to conn_read only on TRANSMIT_COMPLETE, i.e. it pushes
full responce before reading the next request. The test case could
tell, but lazy to write one.
I didn't map the whole thing out, but it'll just create a
You can implement streaming with select()/poll() magic, not using any
threads. All you have to do is to send commands and _simultaneously_
read the replies. But to implement this as a library, like Perl
module for instance, where there's one call per command, you'll have
to complicate the
This test against MAX_CAS_ID is not needed: C standard _guarantees_
that ++ for unsigned type will wraparound to zero automagically. And
this condition won't be ever met anyway, so the check is a bit of a
waste (unless you have some reasons not to use full 64 bit range that
I'm failing to see,
Hi!
My thought was use expiration and flags if the item is new (aka the
action creates an object). Otherwise toss the values (or better yet,
just make them optional to send).
Cheers,
-Brian
On Nov 13, 2007, at 11:51 PM, dormando wrote:
This issue is not addressed in the
On Nov 15, 2007, at 10:34 , Brian Aker wrote:
My thought was use expiration and flags if the item is new (aka the
action creates an object). Otherwise toss the values (or better yet,
just make them optional to send).
That's effectively what bin-incr will do (except for the optional
This is more related to the PHP library
(http://pecl.php.net/package/memcache) and Brad's Cache::Memcached
Perl module.
I've been looking at the ability to allow for the connection pools
that both support. Assuming equal connection weights (in Perl, and I
guess just adding servers regularly in
2) Any specific reason on why there is only a synchronous *get *but not
synchronous *multiget *( I found only async *multiget *in the API doc ) ?
There is both asyncGetBulk and getBulk.
Sorry, my bad.
Couple more questions that came up:
- Regarding binary protocol, are there any
On Thu, Nov 15, 2007 at 14:54:22 -0500, Troy Davisson wrote:
'get' requests going to a single cache server for a hit/miss seems
fine but distributing 'set' requests to all cache servers seems to
be more of a chore, especially if 'get' requests are going randomly
to single memcached servers and
On Nov 15, 2007, at 10:34 , Rakesh Rajan wrote:
1) How stable is the codebase? Currently I am running Greg's library
on the production site. Is Dustin's codebase stable enough to switch
in production ? ( I know that I need to do some testing at my end
before making the decision. But
On Nov 15, 2007, at 13:35 , Oliver Castle wrote:
My only question is weather it is better to implement the Memcahed
client as a singleton method which is created once and then used until
the application is reset or load the Memcached client on every single
request. Using a singleton makes the
If you want to play with it, I can help you get it up and running.
Yups, I would love to take a look at this. Could you point me to any
resource to set it up ?
- I really like the fact that the library tries to perform some
optimization on storing some native objects. Have you also looked
On Nov 15, 2007, at 14:33 , Rakesh Rajan wrote:
If you want to play with it, I can help you get it up and running.
Yups, I would love to take a look at this. Could you point me to any
resource to set it up ?
My latest tree is always here:
Dustin, thanks a ton for all your inputs!
It would be great if we could also add memcache server's roadmap in the
wiki, like features planned in each release, small descriptions/links,
people who are contribution/leading the effort, timeline etc.
thoughts ?
-Rakesh
On Nov 16, 2007 5:18 AM,
Hi Everyone,
I've been working towards getting the next meetup at the Yahoo campus
in Sunnyvale. It's going smooth now and I wanted to gage everyone's
interest ahead of time. I am looking at dates Dec 10 - 15. We are
going to have pizza, snacks, drinks, free swag (Ill get details on
Rakesh Rajan wrote:
Dustin, thanks a ton for all your inputs!
It would be great if we could also add memcache server's roadmap in the
wiki, like features planned in each release, small descriptions/links,
people who are contribution/leading the effort, timeline etc.
thoughts ?
-Rakesh
On Thu, Nov 15, 2007 at 10:29:04 -0800, dormando wrote:
Hmm, maybe I don't get the code, but I think the server may switch
from conn_write to conn_read only on TRANSMIT_COMPLETE, i.e. it pushes
full responce before reading the next request. The test case could
tell, but lazy to write one.
There is a problem with trunk's CAS ID allocation where it doesn't
allocate a new ID after a CAS.
This means that it would correctly validate the CAS ID on save, but
not create a new one, so the previous CAS ID could be replayed
indefinitely (which means that if n clients try an update
19 matches
Mail list logo