Re: Lua and memcache was Re: what is in modules vs what is in the core
On 3/31/09 10:18 AM, "Bertrand Mansion" wrote: > Reading the comments in your code, it seems that mod_lua could benefit > from a better error reporting ? Perhaps. Or I just needed to actually add error checking Right now I rely on the lua side to sanity check stuff. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
RE: what is in modules vs what is in the core
prueba -Original Message- From: Graham Leggett [mailto:minf...@sharp.fm] Sent: Lunes, 30 de Marzo de 2009 08:03 p.m. To: dev@httpd.apache.org Subject: Re: what is in modules vs what is in the core Paul Querna wrote: > mod_watchdog is the latest offender in a series of modules that expose > additional functions to the API. (mod_proxy and mod_cache do too!) > > What happened to all functions that are not inside server/* must be > either dynamic optional functions or hooks? > > Doesn't anyone remember the load order pain of apache 1.3? > > Are we just getting lazy, or does it not matter to anyone now days? Or perhaps it's just a bug? Regards, Graham --
Re: Lua and memcache was Re: what is in modules vs what is in the core
Le 31 mars 09 à 15:52, Akins, Brian a écrit : OT, but will you contribute that to mod_lua ? :) Based on mod_memcache and mod_wombat . For demonstration only as this uses our hacked version, but you get the idea how simple this was. Build it in lua dir like /usr/lib/lua/5.1/apach2/memcache.so Thank you :) That's probably the way support for apr_(date, file, dbd ...) will be added to mod_lua. Reading the comments in your code, it seems that mod_lua could benefit from a better error reporting ? -- Bertrand Mansion Mamasam Tel : +33 1 48 89 88 26 http://www.mamasam.com
Lua and memcache was Re: what is in modules vs what is in the core
> OT, but will you contribute that to mod_lua ? :)
Based on mod_memcache and mod_wombat . For demonstration only as this uses
our hacked version, but you get the idea how simple this was. Build it in
lua dir like /usr/lib/lua/5.1/apach2/memcache.so
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
#include "mod_memcache.h"
#include "mod_lua_request.h"
typedef struct {
apr_memcache_t *memcache;
request_rec *request;
} lua_memcache_t;
static lua_memcache_t *check_memcache(lua_State * L, int index)
{
lua_memcache_t *lm;
luaL_checkudata(L, index, "Apache2.Memcache");
lm = (lua_memcache_t *) lua_unboxpointer(L, index);
return lm;
}
static int get_client(lua_State * L)
{
lua_memcache_t *lm;
apr_memcache_t *m;
request_rec *r = lr_check_request_rec(L, 1);
m = ap_memcache_client(r->server);
lm = apr_pcalloc(r->pool, sizeof(lua_memcache_t));
lm->memcache = m;
lm->request = r;
lua_boxpointer(L, lm);
luaL_getmetatable(L, "Apache2.Memcache");
lua_setmetatable(L, -2);
return 1;
}
/*these are fairly repetitive. can we combine this and not be slow?*/
/*only returns data for now and assumes it's a string*/
static int get_value(lua_State * L)
{
lua_memcache_t *lm = check_memcache(L, 1);
apr_memcache_t *m = lm->memcache;
request_rec *r = lm->request;
const char *key = luaL_checkstring(L, 2);
char *data = NULL;
apr_size_t len;
apr_status_t rv;
apr_uint16_t flags;
rv = apr_memcache_getp(m, r->pool, key, &data, &len, &flags);
if(APR_SUCCESS != rv || NULL == data) {
lua_pushnil(L);
} else {
lua_pushstring(L, data);
}
return 1;
}
/*only returns data for now and assumes it's a string*/
static int set_value(lua_State * L)
{
lua_memcache_t *lm = check_memcache(L, 1);
apr_memcache_t *m = lm->memcache;
request_rec *r = lm->request;
const char *key = luaL_checkstring(L, 2);
char *data = (char *)luaL_checkstring(L, 3);
apr_uint32_t timeout = luaL_checkint(L, 4);
apr_size_t len;
apr_status_t rv;
apr_uint16_t flags = 0;
/*do we have to make a copy??*/
data = apr_pstrdup(r->pool, data);
len = strlen(data);
rv = apr_memcache_set(m, key, data, len, timeout, flags);
/*how to handle errors?*/
return 0;
}
static int incr_value(lua_State * L)
{
lua_memcache_t *lm = check_memcache(L, 1);
apr_memcache_t *m = lm->memcache;
request_rec *r = lm->request;
const char *key = luaL_checkstring(L, 2);
int n = 1;
int nv = 0;
int top = lua_gettop(L);
apr_status_t rv;
/*default to one, but if user gives another argument, use it*/
if(top > 2) {
n = luaL_checknumber(L, 3);
}
rv = apr_memcache_incr(m, key, n, &nv);
/*XXX: need to deal with errors. what if rv != APR_SUCCESS*/
lua_pushnumber(L, nv);
return 1;
}
static int decr_value(lua_State * L)
{
lua_memcache_t *lm = check_memcache(L, 1);
apr_memcache_t *m = lm->memcache;
request_rec *r = lm->request;
const char *key = luaL_checkstring(L, 2);
int n = 1;
int nv = 0;
int top = lua_gettop(L);
apr_status_t rv;
/*default to one, but if user gives another argument, use it*/
if(top > 2) {
n = luaL_checknumber(L, 3);
}
rv = apr_memcache_decr(m, key, n, &nv);
/*XXX: need to deal with errors. what if rv != APR_SUCCESS*/
lua_pushnumber(L, nv);
return 1;
}
static const struct luaL_Reg memcache_funcs[] = {
{"client", get_client},
{NULL, NULL}
};
static const struct luaL_Reg memcache_methods[] = {
{"get", get_value},
{"set", set_value},
{"incr", incr_value},
{"decr", decr_value},
{NULL, NULL}
};
int luaopen_apache2_memcache(lua_State * L)
{
luaL_newmetatable(L, "Apache2.Memcache");
lua_pushvalue(L, -1);
lua_setfield(L, -2, "__index");
luaL_register(L, NULL, memcache_methods);
luaL_register(L, "memcache", memcache_funcs);
return 1;
}
Re: what is in modules vs what is in the core
Paul Querna wrote: mod_watchdog is the latest offender in a series of modules that expose additional functions to the API. (mod_proxy and mod_cache do too!) So, you came back from different direction, cool :) If you really like to put the watchdog functionality inside the mpm (and IMO that's all this about, sorry if I got the wrong impression) then the mpm api needs to get extended and implemented by *all* mpm's. Are we just getting lazy, or does it not matter to anyone now days? IIRC you wish to use the watchdog directly from simple mpm, redesign the watchdog api so that it can be used from simple mpm at the first place, and leave to the others to cope with the rest. I would personally love to see the watchdog (actually generic event ap_listener) functionality in the mpm's core, and my first thing on the todo list is to extend the mpm with child singleton hook. Just like we have child_init we would have child_singleton_init hook but run only for a single child, and run again once for the next one when the previous dies. That way we would get rid of all the singleton and startup mutex hacks, to obtain something that is inherently known by the mpm. However this needs to be implemented inside each and every mpm if we wish to have any sort of the api. Other solutions would be to simply move the mod_watchdog to server/watchdog.c or that we all just use the simple mpm :) Regards -- ^(TM)
Re: what is in modules vs what is in the core
> -Ursprüngliche Nachricht- > Von: Paul Querna > Gesendet: Dienstag, 31. März 2009 01:37 > An: dev@httpd.apache.org > Betreff: what is in modules vs what is in the core > > mod_watchdog is the latest offender in a series of modules that expose > additional functions to the API. (mod_proxy and mod_cache do too!) Which functions do you have in mind regarding mod_proxy / mod_cache? > > What happened to all functions that are not inside server/* must be > either dynamic optional functions or hooks? I wasn't aware of this rule but it make much sense to me. > > Doesn't anyone remember the load order pain of apache 1.3? > > Are we just getting lazy, or does it not matter to anyone now days? I guess we are just getting lazy here and must pay more attention to these points. Regards Rüdiger
Re: what is in modules vs what is in the core
On Tue, Mar 31, 2009 at 4:25 AM, M. Brian Akins wrote: > As I hack on some lua stuff, it's useful to have the symbols for functions. > That may just be because I'm lazy, because I could do optional function > lookups in library opens, I suppose. OT, but I like my Lua glue in a lua > module and just use "require 'apache2.memcache'" (or whatever) to do the > linking. This works really well with per thread lua states that are all > loaded at startup... (hint, hint) OT, but will you contribute that to mod_lua ? :) -- Bertrand Mansion Mamasam
Re: what is in modules vs what is in the core
Maybe a more layered approach would be something to consider for 3.0? Seems to me that the layers and groups of modules keeps expanding and expanding. 2.0 -> 2.2 had the whole auth move over so maybe it's time to rethink the current module system for 3.0? ~Jorge On Tue, Mar 31, 2009 at 4:25 AM, M. Brian Akins wrote: > > On Mar 30, 2009, at 7:37 PM, Paul Querna wrote: > >> mod_watchdog is the latest offender in a series of modules that expose >> additional functions to the API. (mod_proxy and mod_cache do too!) >> >> What happened to all functions that are not inside server/* must be >> either dynamic optional functions or hooks? > > > Some modules (mostly 3rd party??) allow it either way - optional function or > just linkage. I'm personally a fan of hooks and providers. (With > providers, I usually just do the lookup once in, say, post-config, and > "cache" the results in the "subscribing" module - this saves some hash > lookups on potentially every single request.) > > As I hack on some lua stuff, it's useful to have the symbols for functions. > That may just be because I'm lazy, because I could do optional function > lookups in library opens, I suppose. OT, but I like my Lua glue in a lua > module and just use "require 'apache2.memcache'" (or whatever) to do the > linking. This works really well with per thread lua states that are all > loaded at startup... (hint, hint) > > --Brian >
Re: what is in modules vs what is in the core
On Mar 30, 2009, at 7:37 PM, Paul Querna wrote: mod_watchdog is the latest offender in a series of modules that expose additional functions to the API. (mod_proxy and mod_cache do too!) What happened to all functions that are not inside server/* must be either dynamic optional functions or hooks? Some modules (mostly 3rd party??) allow it either way - optional function or just linkage. I'm personally a fan of hooks and providers. (With providers, I usually just do the lookup once in, say, post-config, and "cache" the results in the "subscribing" module - this saves some hash lookups on potentially every single request.) As I hack on some lua stuff, it's useful to have the symbols for functions. That may just be because I'm lazy, because I could do optional function lookups in library opens, I suppose. OT, but I like my Lua glue in a lua module and just use "require 'apache2.memcache'" (or whatever) to do the linking. This works really well with per thread lua states that are all loaded at startup... (hint, hint) --Brian
Re: what is in modules vs what is in the core
Paul Querna wrote: mod_watchdog is the latest offender in a series of modules that expose additional functions to the API. (mod_proxy and mod_cache do too!) What happened to all functions that are not inside server/* must be either dynamic optional functions or hooks? Doesn't anyone remember the load order pain of apache 1.3? Are we just getting lazy, or does it not matter to anyone now days? Or perhaps it's just a bug? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
