Re: mod_dbd analogue for memcached
Hiya, For our needs, mod_memcache (http://code.google.com/p/modmemcache/) will need one major change: memcache groups. MemcacheGroup group01 MemcacheServer localhost:1234 MemcacheServer localhost:1235 /MemcacheGroup MemcacheGroup group01 MemcacheServer localhost:1234 MemcacheServer localhost:1235 /MemcacheGroup I'm just catching up, but I'd be happy to add some of this functionality to mod_memcache. Josh
Re: Mod_memcache status
Haven't touched it in a long time. I'd be happy to pick it back up if there are specific things you wanted implemented. It didn't get much use. On Mon, Jan 5, 2009 at 5:41 AM, Akins, Brian brian.ak...@turner.com wrote: Anyone know anything about status of this? http://code.google.com/p/modmemcache/ -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: store_headers in memcache and diskcache
On Feb 9, 2008 9:04 AM, Justin Erenkrantz [EMAIL PROTECTED] wrote: On Feb 9, 2008 5:36 AM, josh rotenberg [EMAIL PROTECTED] wrote: If you want to collaborate on the google project let me know and I can add you, or you can take over, or however. Or, better yet, how about adding mod_memcache_cache (gah - crappy name) to trunk? There's no real reason why we shouldn't have it if there are interested developers to work and maintain it. -- justin Seems like switching the names around a la mod_proxy would sound better: mod_cache_disk, mod_cache_mem, mod_cache_memcached, etc. I don't have a problem with putting it in trunk assuming its a good candidate (I'll just have to get someone to apply my patches if I keep working on it). Josh
Re: store_headers in memcache and diskcache
On Feb 9, 2008 4:18 PM, Issac Goldstand [EMAIL PROTECTED] wrote: josh rotenberg wrote: Seems like switching the names around a la mod_proxy would sound better: mod_cache_disk, mod_cache_mem, mod_cache_memcached, etc. Ack. Pain in the ass But the man speaks sense. Really not so happy with doing it now - even as a major bump... My personal opinions: +1 on 3.x -0 on 2.4 Issac Yeah, not really a short term expectation, just sayin' really ...
Re: PATCH: httpd-trunk -- add mod_cache.h to the header list installed in include/
logged this in bugzilla a little while ago as well .. http://issues.apache.org/bugzilla/show_bug.cgi?id=42431 On Feb 8, 2008 7:02 AM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: See below. Any thing overly private in that file ? Otherwise I'd love to add it there, Thanks, Dw. Index: Makefile.in === --- httpd-trunk/Makefile.in (revision 618646) +++ httpd-trunk/Makefile.in (working copy) @@ -192,6 +192,7 @@ $(srcdir)/modules/http/mod_core.h \ $(srcdir)/modules/proxy/mod_proxy.h \ $(srcdir)/modules/ssl/mod_ssl.h \ + $(srcdir)/modules/cache/mod_cache.h \ $(srcdir)/os/$(OS_DIR)/*.h
Re: store_headers in memcache and diskcache
Dirk, my comments inline ... On Feb 8, 2008 11:19 AM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: .. snip snip .. Ok - more or less merged a lot between both modules (2) --- al the good bits are yours :) Does that make sense to you ? Hah! Then there is a lot of work to do! Issues I am particularly torn over are: - change from re-alloc to brigades -- but this means we have 100-500k chunks sitting in memory 2x or 3x --- ultimately perhaps apr_memcache needs to understands the brigades perhaps. I thought a lot about this, actually. An apr_memcache_(set|get)_brigade or something would be handy. I was also really wishing for the memcached 'append' command, which didn't exist at the time. If we check the version on server init it could do one or the other. - passing of the info glob -- I guess we should make it perhaps number \0number\0 or something for convenience and speed ? Yeah, agreed. I'm not particularly happy/bound to my serialization of the info and headers, its not the most optimal solution. My goals at the time were basically to make it work, and to some degree make it human readable for testing. - I am making MD5 keys -- you are trusting the URI. What is best really ? Again, I was mainly trying to keep things simple for testing, so I have no issue with a better alternative. - create/open -- we could fetch it all already then. - Or defer to the actual header/body routines - as you and I do now. - Or just 'punt' and store the thing as one big wack - as generally you are propably going to need both ? I struggled with this one a lot. In some ways an all or nothing approach seems better. Less setting and getting, its there or its not. I guess I was mainly trying to follow the mod_disk_cache model, and in some ways conform to what the provider api for caching seems to assume, that the two are separate. I think I was also discussing with someone the possibility of having body data auto-populate in the cache (via something completely outside of apache) and it sounded cool to be able to dump content into the cache without having to worry about faking up a header entry. And/or the possibility of allowing headers and bodies to be stored in different servers/pools, so that perhaps header info is expiring or LRU'ing at a different rate. Just thoughts, really, though, not sure if it makes sense to overdesign for it. If you want to collaborate on the google project let me know and I can add you, or you can take over, or however. Thanks, Josh
Re: store_headers in memcache and diskcache
if it helps at all, here was my attempt at a working mod_memcached_cache. i've been meaning to look at it again and do some cleanup/testing/benchmarking/etc, haven't had the chance though. On Feb 5, 2008 11:17 AM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Feb 5, 2008, at 7:58 PM, Colm MacCarthaigh wrote: On Tue, Feb 05, 2008 at 01:49:43PM -0500, Garrett Rooney wrote: On Feb 5, 2008 1:45 PM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). If I had to guess I'd say it's because people have actually been working on disk cache, while mem cache has been largely ignored for a while. Definitely! I remember the original patches tried to create some nice abstractions so that more logic would move into mod_cache propery than in mod_*_cache, but there turned out to be so many corner cases within mod_disk_cache itself - and noone seems to /use/ mod_mem_cache - that that fell by the wayside :/ Thanks ! That is useful info -- so for now I'll focus on mod_disk_cache -- and once I got that mapped to mod_memcached -- will then see if we can abstract that into a cleaner mod_memcache. But first priority is getting it clean-ish/same-ish relative to the ssl use of memcached (my usecase is OpenID -- which is 'heavy' on both). Dw
Re: store_headers in memcache and diskcache
grr, this cold is making me dumber than usual. the link: http://code.google.com/p/modmemcachecache/ On Feb 6, 2008 1:25 PM, josh rotenberg [EMAIL PROTECTED] wrote: if it helps at all, here was my attempt at a working mod_memcached_cache. i've been meaning to look at it again and do some cleanup/testing/benchmarking/etc, haven't had the chance though. On Feb 5, 2008 11:17 AM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: On Feb 5, 2008, at 7:58 PM, Colm MacCarthaigh wrote: On Tue, Feb 05, 2008 at 01:49:43PM -0500, Garrett Rooney wrote: On Feb 5, 2008 1:45 PM, Dirk-Willem van Gulik [EMAIL PROTECTED] wrote: Caching experts -- why do memcache and diskcache have seemingly quite different caching strategies when it comes to storing the headers ? E.g. the cache_object_t * is populated with the status/date/etc data in memcache - but not in disk-cache. Is this work in progress or subtle design ? I am trying to understand (got a working mod_memcached_cache.c* -- and cannot quite get the right VARY behaviour). If I had to guess I'd say it's because people have actually been working on disk cache, while mem cache has been largely ignored for a while. Definitely! I remember the original patches tried to create some nice abstractions so that more logic would move into mod_cache propery than in mod_*_cache, but there turned out to be so many corner cases within mod_disk_cache itself - and noone seems to /use/ mod_mem_cache - that that fell by the wayside :/ Thanks ! That is useful info -- so for now I'll focus on mod_disk_cache -- and once I got that mapped to mod_memcached -- will then see if we can abstract that into a cleaner mod_memcache. But first priority is getting it clean-ish/same-ish relative to the ssl use of memcached (my usecase is OpenID -- which is 'heavy' on both). Dw
Re: mod_wombat build help
On linux, the check for lua needs to include libm:
(from config.log ..)
configure:2689: checking for luaL_newstate in -llua
configure:2719: gcc -o conftest -g -O2 -L/home/jrotenberg/src/lua-5.1.2//lib
conftest.c -llua 5
/home/jrotenberg/src/lua-5.1.2//lib/liblua.a(lvm.o): In function `Arith':
lvm.c:(.text+0xbeb): undefined reference to `pow'
/home/jrotenberg/src/lua-5.1.2//lib/liblua.a(lvm.o): In function `luaV_execute':
lvm.c:(.text+0x20c9): undefined reference to `pow'
/home/jrotenberg/src/lua-5.1.2//lib/liblua.a(lcode.o): In function `codearith':
lcode.c:(.text+0x11ec): undefined reference to `pow'
collect2: ld returned 1 exit status
configure:2725: $? = 1
the following patch seems to do the trick:
Index:
build/ac-macros/lua.m4===
--- build/ac-macros/lua.m4 (revision 610998)
+++ build/ac-macros/lua.m4 (working copy)
@@ -19,6 +19,7 @@
test_paths=${lua_path}
fi
+AC_CHECK_LIB([m], [pow], lib_m= -lm)
for x in $test_paths ; do
AC_MSG_CHECKING([for lua.h in ${x}/include/lua5.1])
if test -f ${x}/include/lua5.1/lua.h; then
@@ -26,7 +27,7 @@
save_CFLAGS=$CFLAGS
save_LDFLAGS=$LDFLAGS
CFLAGS=$CFLAGS
-LDFLAGS=-L$x/lib $LDFLAGS
+LDFLAGS=-L$x/lib $LDFLAGS $lib_m
AC_CHECK_LIB(lua5.1, luaL_newstate,
[
LUA_LIBS=-L$x/lib -llua5.1
@@ -44,7 +45,7 @@
save_CFLAGS=$CFLAGS
save_LDFLAGS=$LDFLAGS
CFLAGS=$CFLAGS
-LDFLAGS=-L$x/lib $LDFLAGS
+LDFLAGS=-L$x/lib $LDFLAGS $lib_m
AC_CHECK_LIB(lua, luaL_newstate,
[
LUA_LIBS=-L$x/lib -llua
On Jan 3, 2008 6:42 AM, Brian McCallister [EMAIL PROTECTED] wrote:
On Jan 1, 2008, at 10:15 PM, Justin Erenkrantz wrote:
On Dec 31, 2007 5:12 PM, Brian McCallister [EMAIL PROTECTED] wrote:
If anyone is familiar with autconf and modules, I would *love* if
that
person could take a look at helping me clean up mod_wombat's build,
which is presently a mess.
I, to be honest, don't understand enough automake/autoconf + apxs to
know what needs doing, so will just say... please help?
See below. If you'd like, I can just commit it. (It's not perfect,
but it'll build out-of-the-box on Leopard.)
Please go ahead and apply it.
THANKS!
-Brian
Re: mod_memcache??
Hi, So I've uploaded a 0.1.0 version of this. Definitely still pretty simple and rough but it seems to be working ok. I've got a few ideas for making the configuration a little nicer, and I'll probably try to implement them soon, but if you (Frank, et al) wanted to take a look and make suggestions or patches, I'm happy to listen and/or apply. Thanks, Josh On 7/1/07, josh rotenberg [EMAIL PROTECTED] wrote: Hi, I've got 1 module projects using apr_memcache now, so this would actually come in handy for me. I've started some development, and created a google project for it at http://code.google.com/p/modmemcache/ I just checked in some untested, non functioning stub files to get the ball rolling. If anyone wants to be added to the project and help out, just let me know. At this point I plan to implement as spec'ed here by Brian: http://mail-archives.apache.org/mod_mbox/httpd-dev/200702.mbox/[EMAIL PROTECTED] i.e. use the same config format and, for now, export the single function that gives access to an already initialized apr_memcache_t. Ideas for any other functionality are greatly appreciated. Thanks, Josh On 7/1/07, Akins, Brian [EMAIL PROTECTED] wrote: On 7/1/07 10:11 AM, Frank [EMAIL PROTECTED] wrote: I just wonder what has happen to this good idea? Did you start implementing it? (Today I was thinking about implementing this, coz' I need it) Never had the time. Project at work went a different direction. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: mod_memcache??
Hi, I've got 1 module projects using apr_memcache now, so this would actually come in handy for me. I've started some development, and created a google project for it at http://code.google.com/p/modmemcache/ I just checked in some untested, non functioning stub files to get the ball rolling. If anyone wants to be added to the project and help out, just let me know. At this point I plan to implement as spec'ed here by Brian: http://mail-archives.apache.org/mod_mbox/httpd-dev/200702.mbox/[EMAIL PROTECTED] i.e. use the same config format and, for now, export the single function that gives access to an already initialized apr_memcache_t. Ideas for any other functionality are greatly appreciated. Thanks, Josh On 7/1/07, Akins, Brian [EMAIL PROTECTED] wrote: On 7/1/07 10:11 AM, Frank [EMAIL PROTECTED] wrote: I just wonder what has happen to this good idea? Did you start implementing it? (Today I was thinking about implementing this, coz' I need it) Never had the time. Project at work went a different direction. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: Looking for TFM on OS X module building
I put my tarball of stuff up on google code for anyone else that might be interested: http://code.google.com/p/modskeleton/ The goal is to have something that sets you up for mutliple source files, a utils directory for other binary tools/scripts, etc. As the name suggests, it is just a skeleton. Very happy to add people to the project, accept patches and/or ideas, etc. Josh On 5/1/07, Graham Dumpleton [EMAIL PROTECTED] wrote: On 01/05/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I use a little hack to find the appropriate apxs, you need csh for tha though, but that is installed on almost any unix: APXS := $(wildcard $(shell csh -c which apxs2 2/dev/null)) APXS := $(if $(APXS),$(APXS),$(wildcard $(shell csh -c which apxs 2/dev/null))) For a 'configure' based solution which can work out whether you have apxs2 or apxs, and which can also select alternate makefiles dependent on whether Apache 1.3 or Apache 2.X is being used, have a look at mod_wsgi. The mod_wsgi stuff also does other things related to Python, but easy enough to drop that stuff out. Files can be viewed at: http://modwsgi.googlecode.com/svn/trunk/ Graham
Re: Looking for TFM on OS X module building
Tim, I'm developing on both OS X (10.4.9, Intel) and Linux with the same setup. I end up with .so on both. You might have some luck using apxs to get it going. Alternatively, I put together a simple module build environment skeleton package with all of the autoconf stuff ready to be quickly edited for your module name. If you want I can send it over. Josh On 4/27/07, Tim Bray [EMAIL PROTECTED] wrote: I'm sketching in a module for 2.2.4 and having trouble with compiling it on OS X. Neither google nor a survey of this group's archive turn up any ideas. Suppose I have mod_foo.c; I assume the goal is to produce a mod_foo.so or mod_foo.dylib in $INSTALL/modules/ Is this written up anywhere, or alternatively does anyone have any experience to share? -Tim (who previously wrote two big Apache 1.* modules and is feeling a little lost in 2.2-land)
