You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2016/11/02 12:20:15 UTC
apr_redis
OK, so my plan is to start pulling the relevant bits out of Credis for
use in apr_redis. I was thinking initially about maybe just using the
library, but for parity w/ apr_memcache, that doesn't make sense.
Here's the rub: I'd prefer not having to do both the 1.6 and 2.0
"ports" at the same time; instead I'd like to implement 1st in 1.6
and then, once it gets the green light front-port it to 2.0. The
issue, of course, is that 1.6 still has apr and apr-util.
Any concerns about this approach? Or would people prefer it be
added 1st to 2.0/trunk and then folded into 1.6...
Re: apr_redis
Posted by Joshua Marantz <jm...@google.com>.
Hi Jim,
FWIW, mod_pagespeed has a redis interface in C++, and is based on hiredis
<https://github.com/redis/hiredis/tree/010756025e8cefd1bc66c6d4ed3b1648ef6f1f95>
.
It's all in
https://github.com/pagespeed/mod_pagespeed/tree/master/pagespeed/system .
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache.h
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache.cc
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_setup.cc
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_setup.h
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_setup_main.cc
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_cluster_test.cc
https://github.com/pagespeed/mod_pagespeed/blob/master/pagespeed/system/redis_cache_test.cc
Important questions about Redis strategy-- beyond which underlying API to
use -- arise with handling clustering or other mechanisms to have more than
one server. For mod_pagespeed we chose clustering, which is a little bit
more complicated than the apr_memcache equivalent, because it allows
configurations to dynamically update.
-Josh
On Wed, Nov 2, 2016 at 8:20 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> OK, so my plan is to start pulling the relevant bits out of Credis for
> use in apr_redis. I was thinking initially about maybe just using the
> library, but for parity w/ apr_memcache, that doesn't make sense.
>
> Here's the rub: I'd prefer not having to do both the 1.6 and 2.0
> "ports" at the same time; instead I'd like to implement 1st in 1.6
> and then, once it gets the green light front-port it to 2.0. The
> issue, of course, is that 1.6 still has apr and apr-util.
>
> Any concerns about this approach? Or would people prefer it be
> added 1st to 2.0/trunk and then folded into 1.6...
>
Re: apr_redis
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Nov 2, 2016, at 11:01 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>
> Also, unless people have an issue, I prefer using the "telnet"
> method for the client (ala Credis) rather than the more cumbersome
> method.
>
Skip that... Looks like the standard RESP way is quicker, so I'll
use that.
Re: apr_redis
Posted by Jim Jagielski <ji...@jaguNET.com>.
That's my thought as well... Due to the apr/apr-util combination
in 2.0, it's actually easier to add to 1.6 and then port to 2.0
(since apr_redis is in apr-util), then the reverse (and typical
method).
Any idea why we are using apr_socket_sendv() in apr_memcache?
Using apr_socket_send() would be easier but maybe for parity
I should continue w/ the vecs.
Also, unless people have an issue, I prefer using the "telnet"
method for the client (ala Credis) rather than the more cumbersome
method.
> On Nov 2, 2016, at 9:45 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
> On 02 Nov 2016, at 2:20 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> OK, so my plan is to start pulling the relevant bits out of Credis for
>> use in apr_redis. I was thinking initially about maybe just using the
>> library, but for parity w/ apr_memcache, that doesn't make sense.
>>
>> Here's the rub: I'd prefer not having to do both the 1.6 and 2.0
>> "ports" at the same time; instead I'd like to implement 1st in 1.6
>> and then, once it gets the green light front-port it to 2.0. The
>> issue, of course, is that 1.6 still has apr and apr-util.
>>
>> Any concerns about this approach? Or would people prefer it be
>> added 1st to 2.0/trunk and then folded into 1.6...
>
> I’m imagining that it’s easier to work with apr-util v1.6 + httpd than apr v2.0 + httpd? If so it makes sense. Can’t release v1.6.x until it’s also in v2.0 though, but that shouldn’t be too much of a problem.
>
> Regards,
> Graham
> —
>
Re: apr_redis
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Nov 2016, at 2:20 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> OK, so my plan is to start pulling the relevant bits out of Credis for
> use in apr_redis. I was thinking initially about maybe just using the
> library, but for parity w/ apr_memcache, that doesn't make sense.
>
> Here's the rub: I'd prefer not having to do both the 1.6 and 2.0
> "ports" at the same time; instead I'd like to implement 1st in 1.6
> and then, once it gets the green light front-port it to 2.0. The
> issue, of course, is that 1.6 still has apr and apr-util.
>
> Any concerns about this approach? Or would people prefer it be
> added 1st to 2.0/trunk and then folded into 1.6...
I’m imagining that it’s easier to work with apr-util v1.6 + httpd than apr v2.0 + httpd? If so it makes sense. Can’t release v1.6.x until it’s also in v2.0 though, but that shouldn’t be too much of a problem.
Regards,
Graham
—