apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: Redis and mod_cache/mod_socache
Date Wed, 02 Nov 2016 18:11:03 GMT
On Mon, Oct 31, 2016 at 10:49 AM, Graham Leggett <minfrin@sharp.fm> wrote:

> On 31 Oct 2016, at 5:05 PM, Jim Jagielski <jim@jaguNET.com> wrote:
>
> > Moving to APR:
> >
> > Query: Think it would be worth my time to work on a Redis
> > implementation for APR-util? I am working on a minimal Redis
> > lib, related to work, which is basically a soft reboot of Credis
> > from GoogleCode, which could serve as the core functionality, which is
> > what got me thinking about it.
>
> +1.
>

Agreed, if this is done as yet another loadable provider...

To the point about memcache not being a loadable component, keep in mind
it is a self-contained, lightweight component. It -could- be abstracted
into a
loadable module, but with no library dependencies a switchable framework
was never a priority to a developer. As long as the ABI to apr_memcache is
maintained, it could become loadable with a 1.6 revision bump and the
broader API touch any of these stores.

With a modular interface, then the question of redis vs credis vs other
implementations is a no-brainer, we can support multiple implementations.


> You have a point, there is nothing stopping us creating an
> apr-util-cache-redis package with a lifecycle of it’s own.
>

What's the win on this? I think we discussed this at length in the APR 0.9
graduation to 1.0 and decided monolithic had plenty of advantages. It was
further simplified with 2.0. It can certainly be revisited but this served
us well
for 15 years and gave distributors the ability to break out the many
lib/apr-util-1
subcomponents based on library inter-dependencies.

Right now in apr-2, our *hard* lib dependencies look like;

$ ldd .libs/libapr-2.so
linux-vdso.so.1 (0x00007ffde8fa1000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f25e7e40000)
librt.so.1 => /lib64/librt.so.1 (0x00007f25e7c38000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f25e7a01000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f25e77e5000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f25e75e1000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f25e7276000)
libc.so.6 => /lib64/libc.so.6 (0x00007f25e6eb4000)
/lib64/ld-linux-x86-64.so.2 (0x000055ca56625000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f25e6cb1000)
libz.so.1 => /lib64/libz.so.1 (0x00007f25e6a9a000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f25e6874000)
libm.so.6 => /lib64/libm.so.6 (0x00007f25e656b000)

(Note that several dependencies are between Fedora 25 components
in my example above, e.g. libfreebl3.so is not consumed by 'apr' - I'm
suspecting that libxml2 drew in several subdependencies.)

So far we haven't made libxml2 / libexpat a truly loadable selection.

But we've succeeded in keeping all of these components and their
library dependencies out of the process map for all apr-consuming
apps which don't invoke these API's...

apr_crypto_openssl-2.so
apr_crypto_openssl.so
apr_dbd_mysql-2.so
apr_dbd_mysql.so
apr_dbd_odbc-2.so
apr_dbd_odbc.so
apr_dbd_pgsql-2.so
apr_dbd_pgsql.so
apr_dbd_sqlite3-2.so
apr_dbd_sqlite3.so
apr_dbm_db-2.so
apr_dbm_db.so
apr_dbm_gdbm-2.so
apr_dbm_gdbm.so
apr_dbm_ndbm-2.so
apr_dbm_ndbm.so

APR-util 1.6.x is even sleeker, using expat rather than libxml2...

$ ldd .libs/libaprutil-1.so
linux-vdso.so.1 (0x00007ffc02fcd000)
libexpat.so.1 => /opt/bleed/lib/libexpat.so.1 (0x00007f4c9ab37000)
libapr-1.so.0 => /opt/apr16-ossl102/lib/libapr-1.so.0 (0x00007f4c9a8ff000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f4c9a6a9000)
librt.so.1 => /lib64/librt.so.1 (0x00007f4c9a4a1000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f4c9a26a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4c9a04e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c99e4a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4c99a87000)
/lib64/ld-linux-x86-64.so.2 (0x000055a9a1c31000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f4c99884000)


So my only objection would be adding any hard dependency to any
redis provider. If it's module, and apr_memcache can map into the
same framework, we can keep extending this for a very long time.


> There is an extension to apr_crypto on apr-util v1.6 that I’d like to get
> out the door, redis for apr_socache can go out at the same time.
>

apr is probably worth refreshing at the same time, for some bug fixes and
new 1.6 APIs.

You raised a good point, we don't release often because the code is quite
stable. If we are enhancing APR, we should be moving ahead with more
frequent releases. The actual work/development/progress should drive
releases, not some artificial calendar for very few changes.

The feature sounds like a win!

Mime
View raw message