Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
On 04/06/2007 01:13 PM, Georg von Zezschwitz wrote: > Jim Jagielski wrote: > >>> >>> If we state that the evaluation takes place in the occurence of >>> stickysession attributes >>> and suggest >>> >>>stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to >>> the user >>> >>> it will perform faster in average. >>> >>> As I promised to write the patch, I would do it the way Jim suggested >>> it for backward >>> compatibility, however I would also add a table "sticky_type" >>> containing the "Cookie vs. >>> Path vs. Env"-prefix (in a parsed way) to the balancer struct. >>> >>> Is this OK for everybody? >>> >> >> Patch for trunk... > > > Hi, > > attached is the patch for trunk with documentation & Co. > > Could anybody review it & commit? Many thanks for sending the patch and my apologies that reviewing it took that long. Please find my comments below. Regards Rüdiger Throughout the code there are a number of code style issues that should be fixed. Most of them are related to missing spaces before or after assignments or operators. I do not mention them explicitly in my review later. Please have a look at http://httpd.apache.org/dev/styleguide.html. Index: docs/manual/mod/mod_proxy.xml === --- docs/manual/mod/mod_proxy.xml (revision 526077) +++ docs/manual/mod/mod_proxy.xml (working copy) @@ -707,9 +707,19 @@ stickysession - -Balancer sticky session name. The value is usually set to something -like JSESSIONID or PHPSESSIONID, -and it depends on the backend application server that support sessions. +Balancer sticky session name. Multiple definitions are possible and +are interpreted in the sequence of their definition. The +value can be preceeded with a specification Cookie, +Path or Env to restrict the search. +Without this specification, the identifier is searched in the URL path +and then in the cookie. The value is usually set to something +like JSESSIONID or PHPSESSIONID, e.g. + +stickysession=Cookie:JSESSIONID + stickysession=Path:;jsessionid + +for Java Servlets and depends on the backend application server +that support sessions. I think the examples should be split into two separate sentences: One for the simple case (no specification) for which PHPSESSIONID is a good example and one for the more complex case (two settings with different specifications) for which Java Servlets are a good example. Index: modules/proxy/mod_proxy_balancer.c === --- modules/proxy/mod_proxy_balancer.c (revision 526077) +++ modules/proxy/mod_proxy_balancer.c (working copy) @@ -581,6 +605,30 @@ } } +static void print_balancer_sticky(request_rec *r, + apr_array_header_t *sticky) +{ +int i; +struct proxy_sticky_entry *entries; + +if (sticky==NULL) +return; +entries = (struct proxy_sticky_entry *) sticky->elts; +for (i = 0; i < sticky->nelts; i++) { + if (i>0) + ap_rputs (" ", r); + switch (entries[i].method) { + case PROXY_STICKY_COOKIE: + ap_rputs ("Cookie:", r); break; + case PROXY_STICKY_PATH: + ap_rputs ("Path:", r); break; + case PROXY_STICKY_ENV: + ap_rputs ("Env:", r); break; Style + } + ap_rputs (entries[i].name, r); +} +} + /* Manages the loadfactors and member status */ static int balancer_handler(request_rec *r) @@ -645,10 +693,30 @@ if (bsel) { const char *val; if ((val = apr_table_get(params, "ss"))) { -if (strlen(val)) -bsel->sticky = apr_pstrdup(conf->pool, val); -else -bsel->sticky = NULL; +char *tok_cntx; +bsel->sticky = apr_array_make(conf->pool, 1, + sizeof (struct proxy_sticky_entry)); +char *v = apr_strtok(apr_pstrdup(r->pool, val), "+", &tok_cntx); This is not allowed in ANSI C: Declarations of variables need to be at the beginning of a block. Better use ap_strchr here. +while (v!=NULL) { +struct proxy_sticky_entry * entry = + (struct proxy_sticky_entry *) apr_array_push(bsel->sticky); +const char *colon_pos = strchr (v, ':'); +entry->method = PROXY_STICKY_COOKIE | PROXY_STICKY_PATH; +if (colon_pos!=NULL) { +while (*++colon_pos==' ') +continue; +entry->name = apr_pstrdup(conf->pool, colon_pos); +if (!strncasecmp ("cookie:", v, 7)) +entry->method = PROXY_STICKY_COOKIE; +else if (!strncasecmp ("path:", v, 5)) +
Putting a web front end on an embedded device
Hi All: Sorry in advance if this has been asked before, I've only been looking at modules for a couple of weeks, but I checked everywhere I could think of and I'm still looking for some answers. I have a relatively high powered device on a network with a TCP debug/status port. Users can telnet to this port, enter their credentials, and tell the device to start spewing data at them. This particular device outputs XML. Multiple users can connect to the device simultaneously and each user has a different profile (list of events they subscribe to). Naturally, I'd like to put an apache web server on the network so I can support a web front end. So far, this is what I'm thinking: - User enters credentials, the module opens a socket to the device, passes along credentials, and holds the request_rec connection to the browser open ("comet" style streaming). - Device passes back some administrative preamble and starts to stream data to the module - the module passes the chunks of xml to a filter which applies an XSLT transform to JS
trunk veto; ProxyPassInterpolateEnv
Nick, I'm moving from from a -.9 to a -1 of trunk on this because altering the semantics of ALL of the existing ProxyPass[Reverse] directives in one misplaced or poorly understood directive seems highly hazardous. On any server with more than one administrator, this can be very toxic and cause all sorts of ill will as Joe turns on the directive, breaking James' mappings. Similar issues occur when ProxyPass directives are scattered throughout many .conf'lets. Can this please be reverted, and replace if you like with a second set of unambiguous ProxyPassEnv[Reverse|CookieDomain|CookiePath] directives which triggers honoring the env var interpolation on a per-mapping basis? My suggestion is to simply add a boolean to the stored ProxyPass entries which is set for ProxyPassEnv* and otherwise left unset. The existing ProxyPass* becomes conditional on the per-entry boolean instead of a global setting. Thanks, Bill * mod_proxy: Support variable interpolation in reverse proxy configuration http://svn.apache.org/viewvc?view=rev&revision=421686 (code) http://svn.apache.org/viewvc?view=rev&revision=422178 (code) http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy.xml?r1=420990&r2=421725 (docs) +1: niq, mturk -.9: wrowe notes; modifying the existing syntax seems inappropriate, new ProxyPassSubstitute or similarly named directives would seem to make more sense, permit direct Reverse'als when appropriate and restrict the Substitutions to be parsed only when required.
Re: [PATCH] mod_wombat: add table_get and table_set
On 5/4/07 7:42 PM, "Rici Lake" <[EMAIL PROTECTED]> wrote: > In Lua, setting to nil is equivalent to deletion. So I think this should be: > > if (lua_isnoneornil(L, 3) > apr_table_unset(t, key); > else { > const char *val = luaL_checkstring(L, 3); > apr_table_set(t, key, val); > } +1 > if (val == NULL) > lua_pushnil(L); > else > lua_pushstring(L, val); > +1 > Agreed. Also, it's misleading -- they are APR tables, not Lua tables. Brian M. changed this before committing, I think. >> > This is poor Lua style. You shouldn't assume (or require) the stack to > be empty at the start of the function. Use top-relative (negative) indices > instead -- they are no slower. Until a day before I submitted patch, I had never touched Lua, so I'm sure I have bad style and form :) > Also use lua_{get,set}field for clarity, and luaL_register (luaL_openlib > is deprecated). I had been using the PiL 5.0 for docs and lua-users.org was down most of last week. I got hard copy of 5.1 PiL this weekend, so maybe my style will improve ;) Thanks for all the pointers. I think mod_wombat is almost in a state where I can start actually working on the original problem I needed to solve. Question: what would be the best way to load "other modules" to mod_wombat (not apache modules). For example, I want/need to load the lua pcre stuff, but I don't want to write a new apache module just to hook that into mod_wombat. I am new to Lua, so I am sure there is a better way. Can ping me off list if this seems OT for httpd-dev -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
CHANGES file for 1.3 and 2.x
Seems to me that the more we work on the various 2.x trees (2.0.x, 2.2.x and trunk), the harder it becomes to get the various correct CHANGES entries in sync... For example, the CHANGES for 2.2 and trunk just refer to changes up to 2.0.56... What's the best way of syncing these? Should we stop having a single CHANGES that tries to merge all development together? Why not have something like: o Apache 1.3.x: CHANGES stay as is o Apache 2.0.x: CHANGES just incorporates 2.0.x work and we can either URL refer to older changes at the bottom of the file or, when we release, merge them. o Apache 2.2.x: CHANGES just notes 2.2.x work and we either refer to 2.0.x CHANGES and 1.3.x CHANGES or auto-merge when we release. o : Same pattern... Comments? Ideas?
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Ruediger Pluem wrote: On 04/06/2007 01:13 PM, Georg von Zezschwitz wrote: Jim Jagielski wrote: attached is the patch for trunk with documentation & Co. Could anybody review it & commit? Many thanks for sending the patch and my apologies that reviewing it took that long. Please find my comments below. I think we could use a simple two use case situation. To be able to backport that to the 2.2 branch I propose a following patch. It adds additional struct member sticky_path that is set to the sticky so if someone has in the config ... stickysession=JSESSIONID ... both sticky and sticky_path will be the same. However if there is a stickysession with ... stickysession=JSESSIONID|;jsessionid ... will make w->sticky=JSESSIONID and w->sticky_path=;jsessionid I'm not aware of any other way without introducing additional directives that could be backported to 2.2 The question is, is that backportable as well? If it is, I'll put that for a vote in STATUS. Regards, Mladen. sticky_session.patch.txt Description: application/octet-string
Re: CHANGES file for 1.3 and 2.x
On 05/07/2007 05:38 PM, Jim Jagielski wrote: > Seems to me that the more we work on the various 2.x trees > (2.0.x, 2.2.x and trunk), the harder it becomes to get > the various correct CHANGES entries in sync... For example, > the CHANGES for 2.2 and trunk just refer to changes up > to 2.0.56... What's the best way of syncing these? Should > we stop having a single CHANGES that tries to merge all > development together? Why not have something like: > > o Apache 1.3.x: CHANGES stay as is > o Apache 2.0.x: CHANGES just incorporates 2.0.x work > and we can either URL refer to older changes > at the bottom of the file or, when we release, > merge them. > o Apache 2.2.x: CHANGES just notes 2.2.x work and we > either refer to 2.0.x CHANGES and 1.3.x CHANGES > or auto-merge when we release. > o : Same pattern... > > Comments? Ideas? > > I do not think that we need to merge the files. Having pointers to the other files seems to be sufficient for me. This still leaves the task of syncing the CHANGES files of the stable branches with that of the trunk which still leaves enough room for getting out of sync. So having some sort of auto-merge here would be cool. Regards Rüdiger
PATCH: mod_wombat: add default scope and cache to config
This patch adds: LuaDefaultCacheStyle and LuaDefaultScope To set defaults for these. The code needs to be change around so that we check dir_config first, and then revert to default. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies default-config.diff Description: Binary data
[Solved] Child pool not usable for logging
Am Sonntag, den 06.05.2007, 14:25 +0530 schrieb Saju Pillai: > err - asking obvious question but .. Your LogLevel is set to debug right ? You were pretty close. According to nicks book (bottom of p. 324), ap_log_perror does not have access to the server_rec and therefor can not know the log level. Sincerely, Joachim
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
On 05/07/2007 05:56 PM, Mladen Turk wrote: > > I think we could use a simple two use case situation. > To be able to backport that to the 2.2 branch I propose > a following patch. > > It adds additional struct member sticky_path that is > set to the sticky so if someone has in the config > > ... stickysession=JSESSIONID ... both sticky and > sticky_path will be the same. > However if there is a stickysession with > ... stickysession=JSESSIONID|;jsessionid ... > will make w->sticky=JSESSIONID and w->sticky_path=;jsessionid > > I'm not aware of any other way without introducing additional > directives that could be backported to 2.2 > > The question is, is that backportable as well? I think this is backportable in general if we do a minor bump (which is possible for backports). Currently I see the following problems with the patch which seem to be solvable: 1. Documentation. We definitely need a patch for the documentation that describes how to handle the servlet case with the above patch. Otherwise people keep falling into the pit. 2. Apart from route search balancer->sticky is used in several additional locations for - Status pages (mod_status hook, loadbalancer manager) - Some notes / environment variables are set to balancer->sticky which is wrong if balancer->sticky_path was used to find the actual route. Furthermore it might be worth adding an additional environment variable (e.g. BALANCER_SESSION_STICKY_TYPE) that indicates whether BALANCER_SESSION_STICKY contains balancer->sticky or balancer->sticky_path. Adjusting sessionstickyness via the loadbalancer manager might not be needed as this currently does not work anyway since the balancer configuration is not stored in shared memory (Maybe we should turn off the possibility to change the balancer configuration via the manager until this is fixed as this can lead to weird results with different processes using different configurations). 3. The minor bump is missing which is needed due to the change of the struct. 4. I am confused by the following part of the patch :-): +balancer->sticky = balancer->sticky_path = apr_pstrdup(p, val); +if ((path = strchr(balancer->sticky, '|'))) { +*path++ = '\0'; +balancer->sticky_path = path; +} +else +balancer->sticky_path = balancer->sticky; Why setting balancer->sticky_path twice in both cases (string with or without |) Regards Rüdiger
PATCH: mod_wombat fix finfo "leak" in vmprep.c load_file
Was always allocating finfo from a pool. Now just do it on stack. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies finfo-leak.diff Description: Binary data
Apache 2.2.4 under Win32 Longhorn
Hello, I've tested apache_2.2.4-win32-x86-openssl-0.9.8d.msi under Longhorn Beta 3 (VMware). Only thing that I changed from the default windows setup, was that I turned off the firewall to test it from my network. After installation I got an error message "Process successfull executed". I got that message also after rebooting windows. But Apache works fine! I hadn't time to test that with PHP yet. regards Mario Brandt
Re: [Solved] Child pool not usable for logging
On May 7, 2007, at 11:38 AM, Joachim Zobel wrote: Am Sonntag, den 06.05.2007, 14:25 +0530 schrieb Saju Pillai: err - asking obvious question but .. Your LogLevel is set to debug right ? You were pretty close. According to nicks book (bottom of p. 324), ap_log_perror does not have access to the server_rec and therefor can not know the log level. It's not really up to the function invocation: they all wrap around a core function (to which I pointed in my other post) which does not log for the more granular qualifiers. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: trunk veto; ProxyPassInterpolateEnv
On Mon, 07 May 2007 09:15:09 -0500 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > Nick, > > I'm moving from from a -.9 to a -1 of trunk on this because altering > the semantics of ALL of the existing ProxyPass[Reverse] directives in > one misplaced or poorly understood directive seems highly hazardous. > > On any server with more than one administrator, this can be very toxic > and cause all sorts of ill will as Joe turns on the directive, > breaking James' mappings. Similar issues occur when ProxyPass > directives are scattered throughout many .conf'lets. The likelihood of anything breaking in an existing config seems negligible, as the syntax for variable interpolation won't figure in a literal URL-matching pattern (the syntax is ${var}). AFAICS it would be perfectly safe to enable interpolation automatically, without a directive. The reason for doing so is performance: enabling interpolation incurs an overhead of making per-request copies of configuration stuff. > Can this please be reverted, and replace if you like with a second set > of unambiguous ProxyPassEnv[Reverse|CookieDomain|CookiePath] > directives which triggers honoring the env var interpolation on a > per-mapping basis? That's a lot of extra complexity. A little in the code and configuration, but a lot in the documentation. The sheer length of some of our documents (including the proxy's) is already a hurdle for users getting to grips with it. Any chance you could outline an example to explain how my patch would break something? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Apache 2.2.4 under Win32 Longhorn
what? - Original Message - From: "Mario Brandt" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 08, 2007 3:47 AM Subject: Apache 2.2.4 under Win32 Longhorn > Hello, > I've tested apache_2.2.4-win32-x86-openssl-0.9.8d.msi under Longhorn Beta 3 > (VMware). Only thing that I changed from the default windows setup, was that > I turned off the firewall to test it from my network. > > After installation I got an error message "Process successfull executed". I > got that message also after rebooting windows. But Apache works fine! I > hadn't time to test that with PHP yet. > > regards > Mario Brandt
Re: Apache 2.2.4 under Win32 Longhorn
yacsha wrote: > what? I think Mario's post below is quite clear. I am wondering, however, *where* he sees the error message he cites. A log? A popup command window? An ok box? Is there additional details (a window caption or other details?) Does it continue to happen on each reboot? But glad to hear this works just fine - it implies we are not far from working also on Vista, Longhorn's 'end user workstation' cousin. > - Original Message - > From: "Mario Brandt" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, May 08, 2007 3:47 AM > Subject: Apache 2.2.4 under Win32 Longhorn > > >> Hello, >> I've tested apache_2.2.4-win32-x86-openssl-0.9.8d.msi under Longhorn Beta 3 >> (VMware). Only thing that I changed from the default windows setup, was that >> I turned off the firewall to test it from my network. >> >> After installation I got an error message "Process successfull executed". I >> got that message also after rebooting windows. But Apache works fine! I >> hadn't time to test that with PHP yet. >> >> regards >> Mario Brandt
Re: Apache 2.2.4 under Win32 Longhorn
William A. Rowe, Jr. wrote: yacsha wrote: what? I think Mario's post below is quite clear. I am wondering, however, *where* he sees the error message he cites. A log? A popup command window? An ok box? Is there additional details (a window caption or other details?) Does it continue to happen on each reboot? But glad to hear this works just fine - it implies we are not far from working also on Vista, Longhorn's 'end user workstation' cousin. Just tracking the Vista problems down. One problem is the installer. Every awk config rewrite fails so the installation ends up without config files. Didn't try with Administrator account directly, but with the member of the administrators group. The problem described is probably related to ApacheMonitor, and I'm still debugging why it fails. Hope I'll have some answers in few days. Regards, Mladen.
Re: Apache 2.2.4 under Win32 Longhorn
Mladen Turk wrote: > > Just tracking the Vista problems down. > One problem is the installer. Every awk config rewrite fails > so the installation ends up without config files. > Didn't try with Administrator account directly, but with the > member of the administrators group. I'll look as soon as my Longhorn beta is up and running, I'm betting that this is all related to the permissions and 'no documents in the application tree' ruleset. I can't imagine awk's posix fopen/fwrite code is broken by vista.
Re: Apache 2.2.4 under Win32 Longhorn
William A. Rowe, Jr. wrote: Mladen Turk wrote: Just tracking the Vista problems down. One problem is the installer. Every awk config rewrite fails so the installation ends up without config files. Didn't try with Administrator account directly, but with the member of the administrators group. I'll look as soon as my Longhorn beta is up and running, I'm betting that this is all related to the permissions and 'no documents in the application tree' ruleset. Right, once when I added 'Full Control' to the 'Program Files' for Users group, the installer works. ... and with the latest patch ApacheMonitor works as well :) Regards, Mladen.