Re: slotmen API thoughts
On Dec 31, 2008, at 3:12 PM, Chris Darroch wrote: Hi -- First of all, many thanks to Jim Jagielski, Jean-Frederic Clere, and Brian Akins for the slotmem API! Personally I think it would be great to see the mod_auth_digest and/or mod_proxy module gradually migrate toward using either the slotmem or socache APIs, as appropriate (and perhaps even the scoreboard itself?) :) The prime candidate for me right now is Paul's heartbeat stuff. Reading and writing a file? How gauche! :) A few initial thoughts, in two categories, specific and general. In the specific realm, I think mod_sharedmem.c should not be hard-coded to persist data into *.slotmem files in a "logs/" directory. I know that we install some httpd instances with non-default layouts, e.g., the "GNU layout" where log files live under var/apache/log and other runtime files under var/apache/run. Yeah, I agree... I spent most of the time trying to cleanup the actual mechanics and not worrying about the persist stuff, which I see as secondary. Being able to make it runtime configurable (wrt both enabling/disabling as well as location) is on the TODO I came the conclusion that the API more or less prevented such options, because access to slots is performed through pointers to physical memory. The mem method returns such a pointer given an index. In fact, beyond the two existing providers -- unshared and shared memory -- I'm not at all sure what other kinds of things one could really do. I see slotmem and socache as complimentary slotmem takes care of the actual mechanics of where the data exists and "how" it exists and so_cache takes care of the cache-like nature of the data (lifetime, expires, etc...)... So so_cache's SHMCBIndex would use slotmem, for example... After all, we just pass around void* pointers, so what they really point to is abstract.
Re: slotmen API thoughts
On Dec 31, 2008, at 3:12 PM, Chris Darroch wrote:
- model API closely on socache API
- include/ap_slotcache.h defines the following:
- does not define internals of ap_slotcache_t; leave that to providers
- no lock/unlock functions; leave that to callers but signal
need for them with AP_SLOTCACHE_FLAG_NOTMPSAFE (parallel to
AP_SOCACHE_FLAG_NOTMPSAFE, note "NOTMPSAFE" == "not MP-safe")
- slotcache provider methods:
- create() - takes num_items and item_size
- to be called during initial config pass, providers
should not initialize or create mutexes here, etc.
"should not"??
- init() - to be called during post-config pass, passed pconf
pool,
performs real initialization
- destroy() - to be called from pconf pool cleanup
- store()- takes index, value of item_size length
- retrieve() - takes index and unsigned char* buffer to write into
- reset()- takes index, clears value
- maybe do(), or status(), akin to socache's status()?
- AP_SLOTCACHE_PROVIDER_GROUP ("slotcache") and
AP_SLOTCACHE_PROVIDER_VERSION ("0")
To my mind, the great advantage of having accessor methods like
store(), retrieve(), and reset() instead of a mem() method is that
a wide variety of providers can be envisioned.
I agree that abstracting out get/set (or retrieve/store) allows
for more generic usages... also allows for the provider itself
to determine if mutexes are needed or not... Maybe I'll have
some time over the weekend to hash this out.
One thing which adds a wrinkle is that I envision various modules
using various providers for slotmem, so, for example, mod_proxy
would used shared mem and mod_cache would use DBM for example.
In this case, you have one interface to 2 providers working at
the same time and I'm not sure if ap_slotcache_t collisions
could occur (if DBM defines it one way and sharedmem defines
it another, and both providers are compiled and active, will
stuff break?)... That was the rationale behind up-front defining
the struct but trying to make it generic enough...
mod_dbd issues
Hi, I'm trying to use mod_dbd for a Linux module with a Postgres backend and am running into a bunch of issues. It seems easy enough but all my queries are failing becasue I'm not getting back a valid db handle either. Here's my httpd.conf: LoadModule dbd_module modules/mod_dbd.so DBDriver pgsql DBDParams "hostaddr=192.168.1.2 dbname=*** user=*** connect_timeout=2" DBDMin 5 DBDKeep 20 DBDMax 50 DBDExptime 120 and in my module code: //connect to database dbd = ap_dbd_acquire(r); //I get back a non-null dbd value PGconn *conn = apr_dbd_native_handle(dbd->driver,dbd); ...do stuff... When I connect with the native Postgres function things work just fine. I've tried this on CentOS 5 and FC9 with the same behavior. On CentOS 5 I'm getting these errors as well when trying to restart (this is not with my module even loaded, simply just by loading mod_dbd): *** glibc detected *** /usr/sbin/httpd: corrupted double-linked list: 0x08ecb7a8 *** [Thu Jan 01 11:11:41 2009] [warn] child process 25480 still did not exit, sending a SIGTERM At a bit of a loss, with the exception of recompining apache with debug I'm not really sure how to tackle the issue, perhaps it's a simple issue someone may know right away. Thanks. -Matt
Re: slotmen API thoughts
On Jan 1, 2009, at 11:44 AM, Jim Jagielski wrote: One thing which adds a wrinkle is that I envision various modules using various providers for slotmem, so, for example, mod_proxy would used shared mem and mod_cache would use DBM for example. In this case, you have one interface to 2 providers working at the same time and I'm not sure if ap_slotcache_t collisions could occur (if DBM defines it one way and sharedmem defines it another, and both providers are compiled and active, will stuff break?)... That was the rationale behind up-front defining the struct but trying to make it generic enough... After researching, typedef's abstraction alleviates this issue. So I'll start working on getter/setter functions for slotmem and removing user-land locks. But I won't commit anything until 2.3.1 is released...
Re: mod_dbd issues
On 01/01/2009 05:50 PM, Matthew Rushton wrote: > Hi, > I'm trying to use mod_dbd for a Linux module with a Postgres backend and am > running into a bunch of issues. It seems easy enough but all my queries are > failing becasue I'm not getting back a valid db handle either. Here's my > httpd.conf: > > LoadModule dbd_module modules/mod_dbd.so > DBDriver pgsql > DBDParams "hostaddr=192.168.1.2 dbname=*** user=*** connect_timeout=2" > DBDMin 5 > DBDKeep 20 > DBDMax 50 > DBDExptime 120 > > and in my module code: > > //connect to database > dbd = ap_dbd_acquire(r); > //I get back a non-null dbd value > PGconn *conn = apr_dbd_native_handle(dbd->driver,dbd); > ...do stuff... > > When I connect with the native Postgres function things work just fine. I've > tried this on CentOS 5 and FC9 with the same behavior. On CentOS 5 I'm > getting these errors as well when trying to restart (this is not with my > module even loaded, simply just by loading mod_dbd): > > *** glibc detected *** /usr/sbin/httpd: corrupted double-linked list: > 0x08ecb7a8 *** > [Thu Jan 01 11:11:41 2009] [warn] child process 25480 still did not exit, > sending a SIGTERM > > At a bit of a loss, with the exception of recompining apache with debug I'm > not really sure how to tackle the issue, perhaps it's a simple issue someone > may know right away. Thanks. > -Matt I assume that you use the CentOS provided httpd version. This is fairly old. Please retry with the latest one and let us know if you still have problems. Regards Rüdiger
Re: mod_dbd issues
After some debugging inside Apache I have figured out half the problem, I was using dbd instead of dbd->handle. It sucks being a newbie:( The CentOS problem remains though and is unrelated. I will try and put the latest on and see if that fixes the issue. Thanks for the help. -Matt --- On Thu, 1/1/09, Ruediger Pluem wrote: > From: Ruediger Pluem > Subject: Re: mod_dbd issues > To: dev@httpd.apache.org > Date: Thursday, January 1, 2009, 4:13 PM > On 01/01/2009 05:50 PM, Matthew Rushton wrote: > > Hi, > > I'm trying to use mod_dbd for a Linux module > with a Postgres backend and am running into a bunch of > issues. It seems easy enough but all my queries are failing > becasue I'm not getting back a valid db handle either. > Here's my httpd.conf: > > > > LoadModule dbd_module modules/mod_dbd.so > > DBDriver pgsql > > DBDParams "hostaddr=192.168.1.2 dbname=*** > user=*** connect_timeout=2" > > DBDMin 5 > > DBDKeep 20 > > DBDMax 50 > > DBDExptime 120 > > > > and in my module code: > > > > //connect to database > > dbd = ap_dbd_acquire(r); > > //I get back a non-null dbd value > > PGconn *conn = > apr_dbd_native_handle(dbd->driver,dbd); > > ...do stuff... > > > > When I connect with the native Postgres function > things work just fine. I've tried this on CentOS 5 and > FC9 with the same behavior. On CentOS 5 I'm getting > these errors as well when trying to restart (this is not > with my module even loaded, simply just by loading mod_dbd): > > > > *** glibc detected *** /usr/sbin/httpd: corrupted > double-linked list: 0x08ecb7a8 *** > > [Thu Jan 01 11:11:41 2009] [warn] child process 25480 > still did not exit, sending a SIGTERM > > > > At a bit of a loss, with the exception of recompining > apache with debug I'm not really sure how to tackle the > issue, perhaps it's a simple issue someone may know > right away. Thanks. > > -Matt > > I assume that you use the CentOS provided httpd version. > This is fairly old. Please retry > with the latest one and let us know if you still have > problems. > > Regards > > Rüdiger
Re: Re: mod_fcgid license questions
Hi, guys Good news is I track down another author now. We are talking about the license questions now, so far so good :) Thanks > -原始邮件- > 发件人: "Chris Darroch" > 发送时间: 2009年1月1日 星期四 > 收件人: dev@httpd.apache.org > 抄送: > 主题: Re: mod_fcgid license questions > > Hi -- > > > On 31 Dec 2008, at 05:48, Roy T. Fielding wrote: > > > >>> Foes anyone have a sense of whether these would indeed require > >>> a CLA and SGA? > >> > >> They look like simple repairs to me. More importantly, if he thinks > >> they are simple repairs and he is happy to see them Apache Licensed, > >> then there is no need for a CLA or software grant. > > > > +1. This is in the same ballpark as third-party patches we routinely > > accept, e.g. from reports in bugzilla. > >OK, that sounds reasonable. I think we're just waiting to hear > from one other person, then. > > Chris. > > -- > GPG Key ID: 366A375B > GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B >
Re: mod_fcgid license questions
On Wed, 31 Dec 2008, pqf wrote: > Hi, guys > Thanks Chris first :) > Please take a look at the attachments, I got it from my mail archive. > The errorlog patch is a minor patch. the poll patch change not much > lines of code, but it did come with original idea. If Piotr > Gackiewicz think his job is "simple repairs", I think these patchs can > be put to "minor patch" group too. > > - Original Message - > From: "Chris Darroch" > To: > Sent: Wednesday, December 31, 2008 1:31 PM > Subject: Re: mod_fcgid license questions > > > > pqf wrote: > > > >> version 1.10 ( Jul 3rd 2006 ) > >> 1. Use poll() instead of select() in UNIX. It becomes problematic on > >>apache2 with large number of logfiles. Apache2 calls poll() > >>(when OS supports it), and in that case it doesn't need to be recompiled > >>with larger FD_SETSIZE. select() is still limited to FD_SETSIZE." > >>(Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) > >> 2. Bug fix: "Some requests fail with HTTP 500 and no errorlog entry is > >>generated" (Thank Piotr Gackiewicz gacek at intertele.pl for the patch.) Hi, my name is Piotr Gackiewicz and I am the autor of these patches. I confirm, that I personaly consider them as minor changes and agree, that you should put them into "minor patch" group. Without signing CLA and official Software Grant. I appreciate transferring this software into ASF very much and would like thank all you guys for the great work you put into this great software, which Apache is. Best regards, -- Piotr Gackiewicz Intertele S.A. - operator systemów ITL.PL i DOMENY.ITL.PL al. T. Rejtana 1, 35-326 Rzeszów TEL: +48 17 8507580, FAX: +48 17 8520275, INFOLINIA: 0 801 335523 http://www.itl.pl - niezawodne serwery wirtualne http://domeny.itl.pl- tanie domeny internetowe http://www.intertele.pl
