Re: mod_proxy_balancer doesn't work with 2.4.32

[Rainer Jung]

Am 15.03.2018 um 18:25 schrieb lucas29252:

Steffen sent me the patched module and it works!


Same here.

Regards,

Rainer

Re: mod_proxy_balancer doesn't work with 2.4.32

[Eric Covener]

On Thu, Mar 15, 2018 at 1:25 PM, lucas29252  wrote:
> Steffen sent me the patched module and it works!

Thanks Steffen and Lucas!

(and Yann)

Re: mod_proxy_balancer doesn't work with 2.4.32

[lucas29252]

Steffen sent me the patched module and it works!



--
Sent from: 
http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 6:07 PM, Rainer Jung  wrote:
> Am 15.03.2018 um 16:48 schrieb Yann Ylavic:
>>
>> On Thu, Mar 15, 2018 at 3:20 PM, Rainer Jung 
>> wrote:
>> Index: modules/slotmem/mod_slotmem_shm.c
>> ===
>> --- modules/slotmem/mod_slotmem_shm.c   (revision 1826753)
>> +++ modules/slotmem/mod_slotmem_shm.c   (working copy)
>> @@ -447,9 +466,9 @@ static apr_status_t slotmem_create(ap_slotmem_inst
>>  }
>>  ap_log_error(APLOG_MARK, rv == APR_SUCCESS ? APLOG_DEBUG :
>> APLOG_ERR,
>>   rv, ap_server_conf, APLOGNO(02611)
>> - "create: apr_shm_create(%s) %s",
>> - fname ? fname : "",
>> - rv == APR_SUCCESS ? "succeeded" : "failed");
>> + "create: apr_shm_%s(%s) %s",
>> + fbased && is_child_process() ? "attach" : "create",
>> + fname, rv == APR_SUCCESS ? "succeeded" : "failed");
>>  if (rv != APR_SUCCESS) {
>>  return rv;
>>  }
>
>
> Removing the fname null check was intentional?

Can't happen, either fbased (this fname != NULL), or fname is set to
"none" above.

Thanks,
Yann.

Re: mod_proxy_balancer doesn't work with 2.4.32

[Rainer Jung]

Am 15.03.2018 um 16:48 schrieb Yann Ylavic:

On Thu, Mar 15, 2018 at 3:20 PM, Rainer Jung  wrote:
Index: modules/slotmem/mod_slotmem_shm.c
===
--- modules/slotmem/mod_slotmem_shm.c   (revision 1826753)
+++ modules/slotmem/mod_slotmem_shm.c   (working copy)
@@ -447,9 +466,9 @@ static apr_status_t slotmem_create(ap_slotmem_inst
 }
 ap_log_error(APLOG_MARK, rv == APR_SUCCESS ? APLOG_DEBUG : APLOG_ERR,
  rv, ap_server_conf, APLOGNO(02611)
- "create: apr_shm_create(%s) %s",
- fname ? fname : "",
- rv == APR_SUCCESS ? "succeeded" : "failed");
+ "create: apr_shm_%s(%s) %s",
+ fbased && is_child_process() ? "attach" : "create",
+ fname, rv == APR_SUCCESS ? "succeeded" : "failed");
 if (rv != APR_SUCCESS) {
 return rv;
 }


Removing the fname null check was intentional?

Probably, just want to make sure.

Thanks as always,

Rainer

Re: mod_proxy_balancer doesn't work with 2.4.32

[Rainer Jung]

Am 15.03.2018 um 16:48 schrieb Yann Ylavic:

On Thu, Mar 15, 2018 at 3:20 PM, Rainer Jung  wrote:


For the sake of completeness, here are the full trace8 (failed) startup logs
for this reproduction scenario:


Thanks Rainer!

Could you (or Steffen, or Lucas) try the attached patch? It's based on
2.4.x, but should work for trunk too..


I currently do not have a quick way to do builds on Windows, but if 
Steffen could provide a build including your patch I could easily redo 
the described test.


Regards,

Rainer

Re: mod_proxy_balancer doesn't work with 2.4.32

[Jim Jagielski]

*bringo*!

https://www.youtube.com/watch?v=4MpyHBoiTwk

> On Mar 15, 2018, at 9:58 AM, Eric Covener  wrote:
> 
> On Thu, Mar 15, 2018 at 9:44 AM, Yann Ylavic  wrote:
>> On Thu, Mar 15, 2018 at 2:22 PM, Yann Ylavic  wrote:
>>> On Thu, Mar 15, 2018 at 11:56 AM, Steffen  wrote:
 
 
 Looks a serious regression.
 
 Reported:  www.apachelounge.com/viewtopic.php?p=36597
>>> 
>>> It does not look like mod_slotmem_shm is used (missing some error
>>> logging from there), mod_slotmem_plain maybe?
>>> 
>>> Also, more context would be appreciated, full/relevant VirtualHost
>>> config (including IP:port, ServerName/ServerAlias eventually
>>> "anonymized"), BalancerPersist on/off(?) and whether or not other
>>> balancers are configured elsewhere (i.e. full httpd.conf if
>>> possible...).
>>> 
>>> Can Windows users reproduce this very basic case here with
>>> mod_slotmem_shm (it doesn't seem Windows specific to me)?
>> 
>> Wait:
>> [pid 19136:tid 136] mod_proxy_balancer.c(917): AH01178: Doing
>> balancers create: 552, 1 (6)
>> [pid 19136:tid 136] mod_proxy_balancer.c(986): AH01184: Doing workers
>> create: balancer://mycluster (p111c5be7_mycluster), 984, 2 [0]
>> [pid 30160:tid 756] mod_proxy_balancer.c(917): AH01178: Doing
>> balancers create: 552, 1 (6)
>> [pid 30160:tid 756] (17)File exists: AH01179: balancer slotmem_create failed
>> 
>> Two processes (PIDs) creating the same balancer, two httpd instances
>> with the same configuration?
> 
>> (IIRC, Windows MPM is threaded only, no "forking" right?).
> 
> the parent and child both run postconfig though on Windows.
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 3:20 PM, Rainer Jung  wrote:
>
> For the sake of completeness, here are the full trace8 (failed) startup logs
> for this reproduction scenario:

Thanks Rainer!

Could you (or Steffen, or Lucas) try the attached patch? It's based on
2.4.x, but should work for trunk too..


Regards,
Yann.
Index: modules/slotmem/mod_slotmem_shm.c
===
--- modules/slotmem/mod_slotmem_shm.c	(revision 1826753)
+++ modules/slotmem/mod_slotmem_shm.c	(working copy)
@@ -274,11 +274,25 @@ static apr_status_t restore_slotmem(sharedslotdesc
 return rv;
 }
 
+static APR_INLINE int is_child_process(void)
+{
+#ifdef WIN32
+return getenv("AP_PARENT_PID") != NULL;
+#else
+return 0;
+#endif
+}
+
 static apr_status_t cleanup_slotmem(void *is_startup)
 {
 int is_exiting = (ap_state_query(AP_SQ_MAIN_STATE) == AP_SQ_MS_EXITING);
 ap_slotmem_instance_t *mem;
 
+if (is_child_process()) {
+*retained_globallistmem = globallistmem = NULL;
+return APR_SUCCESS;
+}
+
 /* When in startup/pre-config's cleanup, the retained data and global pool
  * are not used yet, but the SHMs contents were untouched hence they don't
  * need to be persisted, simply unlink them.
@@ -439,8 +453,13 @@ static apr_status_t slotmem_create(ap_slotmem_inst
 
 {
 if (fbased) {
-apr_shm_remove(fname, pool);
-rv = apr_shm_create(, size, fname, gpool);
+if (is_child_process()) {
+rv = apr_shm_attach(, fname, gpool);
+}
+else {
+apr_shm_remove(fname, pool);
+rv = apr_shm_create(, size, fname, gpool);
+}
 }
 else {
 rv = apr_shm_create(, size, NULL, pool);
@@ -447,9 +466,9 @@ static apr_status_t slotmem_create(ap_slotmem_inst
 }
 ap_log_error(APLOG_MARK, rv == APR_SUCCESS ? APLOG_DEBUG : APLOG_ERR,
  rv, ap_server_conf, APLOGNO(02611)
- "create: apr_shm_create(%s) %s",
- fname ? fname : "",
- rv == APR_SUCCESS ? "succeeded" : "failed");
+ "create: apr_shm_%s(%s) %s",
+ fbased && is_child_process() ? "attach" : "create",
+ fname, rv == APR_SUCCESS ? "succeeded" : "failed");
 if (rv != APR_SUCCESS) {
 return rv;
 }
@@ -811,7 +830,10 @@ static int pre_config(apr_pool_t *pconf, apr_pool_
 }
 globallistmem = *retained_globallistmem;
 
-if (ap_state_query(AP_SQ_MAIN_STATE) != AP_SQ_MS_CREATE_PRE_CONFIG) {
+if (is_child_process()) {
+gpool = pconf;
+}
+else if (ap_state_query(AP_SQ_MAIN_STATE) != AP_SQ_MS_CREATE_PRE_CONFIG) {
 gpool = ap_pglobal;
 }
 else {

Re: mod_proxy_balancer doesn't work with 2.4.32

[Eric Covener]

IIRC they use a combo of AP_PARENT_PID and postconfig userdata to tell
between parent/child an first/second pass.

But i also vaguely recall there is a helper for it now?

On Thu, Mar 15, 2018 at 10:25 AM, Yann Ylavic  wrote:
> On Thu, Mar 15, 2018 at 3:05 PM, Yann Ylavic  wrote:
>> On Thu, Mar 15, 2018 at 2:58 PM, Eric Covener  wrote:
>>> On Thu, Mar 15, 2018 at 9:44 AM, Yann Ylavic  wrote:

 (IIRC, Windows MPM is threaded only, no "forking" right?).
>>>
>>> the parent and child both run postconfig though on Windows.
>>
>> Argh, that's it! (weird behaviour though, IMHO).
>>
>> The slotmem does not try to attach() first anymore, this needs to be 
>> restored...
>
> Is there a way for a module to know whether it's run by the parent or
> child process on Windows?



-- 
Eric Covener
cove...@gmail.com

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 3:05 PM, Yann Ylavic  wrote:
> On Thu, Mar 15, 2018 at 2:58 PM, Eric Covener  wrote:
>> On Thu, Mar 15, 2018 at 9:44 AM, Yann Ylavic  wrote:
>>>
>>> (IIRC, Windows MPM is threaded only, no "forking" right?).
>>
>> the parent and child both run postconfig though on Windows.
>
> Argh, that's it! (weird behaviour though, IMHO).
>
> The slotmem does not try to attach() first anymore, this needs to be 
> restored...

Is there a way for a module to know whether it's run by the parent or
child process on Windows?

Re: mod_proxy_balancer doesn't work with 2.4.32

[Rainer Jung]

Am 15.03.2018 um 15:06 schrieb Yann Ylavic:

On Thu, Mar 15, 2018 at 2:59 PM, lucas29252  wrote:

Hi, I'm the original reporter.

I've just make a fresh install of  httpd-2.4.32-Win64-VC15.zip


And then uncommented the following modules:

lbmethod_byrequests_module
proxy_module
slotmem_shm_module

And in the #Virtual hosts section added the following:


 ServerAdmin webmas...@dummy-host.example.com
 DocumentRoot "C:/Apache24/docs/dummy-host.example.com"
 ServerName dummy-host.example.com
 ServerAlias www.dummy-host.example.com
 ErrorLog "logs/dummy-host.example.com-error.log"
 CustomLog "logs/dummy-host.example.com-access.log" common

 LogLevel debug

 
   BalancerMember http://localhost:8080 retry=0
   BalancerMember http://localhost:8880 retry=0 status=+H
 

 ProxyPass /  "balancer://mycluster/"
 ProxyPassReverse  /  "balancer://mycluster/"




Thanks, I think I see where it comes from, will provide a patch soon.


For the sake of completeness, here are the full trace8 (failed) startup 
logs for this reproduction scenario:


C:\Users\myuser\Apache\Apache24\bin>httpd
AH00112: Warning: DocumentRoot [C:/Apache24/docs/dummy-host.example.com] 
does not exist
[Thu Mar 15 15:16:22.739001 2018] [core:trace3] [pid 5968:tid 428] 
core.c(3345): Setting LogLevel for all modules to trace8
[Thu Mar 15 15:16:22.739001 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2327): AH01147: Defining worker 'http://localhost:8080' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.739001 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2332): AH01148: Defined worker 'http://localhost:8080' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.739001 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2327): AH01147: Defining worker 'http://localhost:8880' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.739001 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2332): AH01148: Defined worker 'http://localhost:8880' for 
balancer 'balancer://mycluster'



C:\Users\myuser\Apache\Apache24\logs>type dummy-host.example.com-error.log
[Thu Mar 15 15:16:22.801414 2018] [proxy_balancer:debug] [pid 5968:tid 
428] mod_proxy_balancer.c(917): AH01178: Doing balancers create: 552, 1 (6)
[Thu Mar 15 15:16:22.816981 2018] [proxy_balancer:debug] [pid 5968:tid 
428] mod_proxy_balancer.c(986): AH01184: Doing workers create: 
balancer://mycluster (p36f4bd69_mycluster), 984, 2 [0]
[Thu Mar 15 15:16:23.332625 2018] [proxy_balancer:debug] [pid 7520:tid 
416] mod_proxy_balancer.c(917): AH01178: Doing balancers create: 552, 1 (6)
[Thu Mar 15 15:16:23.332625 2018] [proxy_balancer:emerg] [pid 7520:tid 
416] (17)File exists: AH01179: balancer slotmem_create failed



C:\Users\myuser\Apache\Apache24\logs>type error.log
AH00112: Warning: DocumentRoot [C:/Apache24/docs/dummy-host.example.com] 
does not exist
[Thu Mar 15 15:16:22.785730 2018] [core:trace3] [pid 5968:tid 428] 
core.c(3345): Setting LogLevel for all modules to trace8
[Thu Mar 15 15:16:22.785730 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2327): AH01147: Defining worker 'http://localhost:8080' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.785730 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2332): AH01148: Defined worker 'http://localhost:8080' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.785730 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2327): AH01147: Defining worker 'http://localhost:8880' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.785730 2018] [proxy:debug] [pid 5968:tid 428] 
mod_proxy.c(2332): AH01148: Defined worker 'http://localhost:8880' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:22.816981 2018] [mpm_winnt:notice] [pid 5968:tid 428] 
AH00455: Apache/2.4.32 (Win64) configured -- resuming normal operations
[Thu Mar 15 15:16:22.816981 2018] [mpm_winnt:notice] [pid 5968:tid 428] 
AH00456: Apache Lounge VC15 Server built: Mar 12 2018 15:30:34
[Thu Mar 15 15:16:22.816981 2018] [core:notice] [pid 5968:tid 428] 
AH00094: Command line: 'httpd -d C:/Users/myuser/Apache/Apache24'
[Thu Mar 15 15:16:22.848233 2018] [mpm_winnt:notice] [pid 5968:tid 428] 
AH00418: Parent: Created child process 7520
AH00112: Warning: DocumentRoot [C:/Apache24/docs/dummy-host.example.com] 
does not exist
[Thu Mar 15 15:16:23.270113 2018] [core:trace3] [pid 7520:tid 416] 
core.c(3345): Setting LogLevel for all modules to trace8
[Thu Mar 15 15:16:23.270113 2018] [proxy:debug] [pid 7520:tid 416] 
mod_proxy.c(2327): AH01147: Defining worker 'http://localhost:8080' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:23.270113 2018] [proxy:debug] [pid 7520:tid 416] 
mod_proxy.c(2332): AH01148: Defined worker 'http://localhost:8080' for 
balancer 'balancer://mycluster'
[Thu Mar 15 15:16:23.270113 2018] [proxy:debug] [pid 7520:tid 416] 
mod_proxy.c(2327): 

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 2:59 PM, lucas29252  wrote:
> Hi, I'm the original reporter.
>
> I've just make a fresh install of  httpd-2.4.32-Win64-VC15.zip
> 
>
> And then uncommented the following modules:
>
> lbmethod_byrequests_module
> proxy_module
> slotmem_shm_module
>
> And in the #Virtual hosts section added the following:
>
> 
> ServerAdmin webmas...@dummy-host.example.com
> DocumentRoot "C:/Apache24/docs/dummy-host.example.com"
> ServerName dummy-host.example.com
> ServerAlias www.dummy-host.example.com
> ErrorLog "logs/dummy-host.example.com-error.log"
> CustomLog "logs/dummy-host.example.com-access.log" common
>
> LogLevel debug
>
> 
>   BalancerMember http://localhost:8080 retry=0
>   BalancerMember http://localhost:8880 retry=0 status=+H
> 
>
> ProxyPass /  "balancer://mycluster/"
> ProxyPassReverse  /  "balancer://mycluster/"
>
> 

Thanks, I think I see where it comes from, will provide a patch soon.

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 2:58 PM, Eric Covener  wrote:
> On Thu, Mar 15, 2018 at 9:44 AM, Yann Ylavic  wrote:
>>
>> (IIRC, Windows MPM is threaded only, no "forking" right?).
>
> the parent and child both run postconfig though on Windows.

Argh, that's it! (weird behaviour though, IMHO).

The slotmem does not try to attach() first anymore, this needs to be restored...

Re: mod_proxy_balancer doesn't work with 2.4.32

[lucas29252]

Hi, I'm the original reporter.

I've just make a fresh install of  httpd-2.4.32-Win64-VC15.zip

  

And then uncommented the following modules:

lbmethod_byrequests_module
proxy_module
slotmem_shm_module

And in the #Virtual hosts section added the following:


ServerAdmin webmas...@dummy-host.example.com
DocumentRoot "C:/Apache24/docs/dummy-host.example.com"
ServerName dummy-host.example.com
ServerAlias www.dummy-host.example.com
ErrorLog "logs/dummy-host.example.com-error.log"
CustomLog "logs/dummy-host.example.com-access.log" common

LogLevel debug


  BalancerMember http://localhost:8080 retry=0
  BalancerMember http://localhost:8880 retry=0 status=+H


ProxyPass /  "balancer://mycluster/"  
ProxyPassReverse  /  "balancer://mycluster/"  





You get the same error in the log:

[proxy_balancer:debug] [pid 23672:tid 520] mod_proxy_balancer.c(917):
AH01178: Doing balancers create: 552, 1 (6)
[proxy_balancer:debug] [pid 23672:tid 520] mod_proxy_balancer.c(986):
AH01184: Doing workers create: balancer://mycluster (pfbbe1180_mycluster),
984, 2 [0]
[proxy_balancer:debug] [pid 29888:tid 544] mod_proxy_balancer.c(917):
AH01178: Doing balancers create: 552, 1 (6)
[proxy_balancer:emerg] [pid 29888:tid 544] (17)File exists: AH01179:
balancer slotmem_create failed





--
Sent from: 
http://apache-http-server.18135.x6.nabble.com/Apache-HTTP-Server-Dev-f4771363.html

Re: mod_proxy_balancer doesn't work with 2.4.32

[Eric Covener]

On Thu, Mar 15, 2018 at 9:44 AM, Yann Ylavic  wrote:
> On Thu, Mar 15, 2018 at 2:22 PM, Yann Ylavic  wrote:
>> On Thu, Mar 15, 2018 at 11:56 AM, Steffen  wrote:
>>>
>>>
>>> Looks a serious regression.
>>>
>>> Reported:  www.apachelounge.com/viewtopic.php?p=36597
>>
>> It does not look like mod_slotmem_shm is used (missing some error
>> logging from there), mod_slotmem_plain maybe?
>>
>> Also, more context would be appreciated, full/relevant VirtualHost
>> config (including IP:port, ServerName/ServerAlias eventually
>> "anonymized"), BalancerPersist on/off(?) and whether or not other
>> balancers are configured elsewhere (i.e. full httpd.conf if
>> possible...).
>>
>> Can Windows users reproduce this very basic case here with
>> mod_slotmem_shm (it doesn't seem Windows specific to me)?
>
> Wait:
>  [pid 19136:tid 136] mod_proxy_balancer.c(917): AH01178: Doing
> balancers create: 552, 1 (6)
>  [pid 19136:tid 136] mod_proxy_balancer.c(986): AH01184: Doing workers
> create: balancer://mycluster (p111c5be7_mycluster), 984, 2 [0]
>  [pid 30160:tid 756] mod_proxy_balancer.c(917): AH01178: Doing
> balancers create: 552, 1 (6)
>  [pid 30160:tid 756] (17)File exists: AH01179: balancer slotmem_create failed
>
> Two processes (PIDs) creating the same balancer, two httpd instances
> with the same configuration?

> (IIRC, Windows MPM is threaded only, no "forking" right?).

the parent and child both run postconfig though on Windows.

-- 
Eric Covener
cove...@gmail.com

Re: mod_proxy_balancer doesn't work with 2.4.32

[Steffen]

I am just passing the issue to list. I hope the reporter follows this list, the 
link I posted in the forum. 



> Op 15 mrt. 2018 om 14:34 heeft Yann Ylavic  het 
> volgende geschreven:
> 
>> On Thu, Mar 15, 2018 at 2:22 PM, Yann Ylavic  wrote:

> LogLevel debug maybe Steffen?

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 2:22 PM, Yann Ylavic  wrote:
> On Thu, Mar 15, 2018 at 11:56 AM, Steffen  wrote:
>>
>>
>> Looks a serious regression.
>>
>> Reported:  www.apachelounge.com/viewtopic.php?p=36597
>
> It does not look like mod_slotmem_shm is used (missing some error
> logging from there), mod_slotmem_plain maybe?
>
> Also, more context would be appreciated, full/relevant VirtualHost
> config (including IP:port, ServerName/ServerAlias eventually
> "anonymized"), BalancerPersist on/off(?) and whether or not other
> balancers are configured elsewhere (i.e. full httpd.conf if
> possible...).
>
> Can Windows users reproduce this very basic case here with
> mod_slotmem_shm (it doesn't seem Windows specific to me)?

Wait:
 [pid 19136:tid 136] mod_proxy_balancer.c(917): AH01178: Doing
balancers create: 552, 1 (6)
 [pid 19136:tid 136] mod_proxy_balancer.c(986): AH01184: Doing workers
create: balancer://mycluster (p111c5be7_mycluster), 984, 2 [0]
 [pid 30160:tid 756] mod_proxy_balancer.c(917): AH01178: Doing
balancers create: 552, 1 (6)
 [pid 30160:tid 756] (17)File exists: AH01179: balancer slotmem_create failed

Two processes (PIDs) creating the same balancer, two httpd instances
with the same configuration?
(IIRC, Windows MPM is threaded only, no "forking" right?).

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 2:22 PM, Yann Ylavic  wrote:
> On Thu, Mar 15, 2018 at 11:56 AM, Steffen  wrote:
>>
>>
>> Looks a serious regression.
>>
>> Reported:  www.apachelounge.com/viewtopic.php?p=36597
>
> It does not look like mod_slotmem_shm is used (missing some error
> logging from there), mod_slotmem_plain maybe?

Hmm no, mod_proxy_balancer is asking for slotmem_shm explicitely, so
it can't be _plain.

I really wonder why mod_slotmem_shm::slotmem_create() fails w/o its
own error message (AH02611)...
LogLevel debug maybe Steffen?

Re: mod_proxy_balancer doesn't work with 2.4.32

[Jim Jagielski]

Besides, isn't this specifically tested in the Perl test framework?

> On Mar 15, 2018, at 9:28 AM, Jim Jagielski  wrote:
> 
> I can't...
> 
>> On Mar 15, 2018, at 9:22 AM, Ruediger Pluem  wrote:
>> 
>> Can anyone reproduce outside of Windows?
>> 
>> Regards
>> 
>> Rüdiger
>> 
>> On 03/15/2018 01:47 PM, Jim Jagielski wrote:
>>> No doubt something in Yann's slotmem changes that affect Windows.
>>> 
 On Mar 15, 2018, at 6:56 AM, Steffen  wrote:
 
 
 
 Looks a serious regression.
 
 Reported:  www.apachelounge.com/viewtopic.php?p=36597
 
 
>>> 
>>> 
> 

Re: mod_proxy_balancer doesn't work with 2.4.32

[Jim Jagielski]

I can't...

> On Mar 15, 2018, at 9:22 AM, Ruediger Pluem  wrote:
> 
> Can anyone reproduce outside of Windows?
> 
> Regards
> 
> Rüdiger
> 
> On 03/15/2018 01:47 PM, Jim Jagielski wrote:
>> No doubt something in Yann's slotmem changes that affect Windows.
>> 
>>> On Mar 15, 2018, at 6:56 AM, Steffen  wrote:
>>> 
>>> 
>>> 
>>> Looks a serious regression.
>>> 
>>> Reported:  www.apachelounge.com/viewtopic.php?p=36597
>>> 
>>> 
>> 
>> 

Re: mod_proxy_balancer doesn't work with 2.4.32

[Yann Ylavic]

On Thu, Mar 15, 2018 at 11:56 AM, Steffen  wrote:
>
>
> Looks a serious regression.
>
> Reported:  www.apachelounge.com/viewtopic.php?p=36597

It does not look like mod_slotmem_shm is used (missing some error
logging from there), mod_slotmem_plain maybe?

Also, more context would be appreciated, full/relevant VirtualHost
config (including IP:port, ServerName/ServerAlias eventually
"anonymized"), BalancerPersist on/off(?) and whether or not other
balancers are configured elsewhere (i.e. full httpd.conf if
possible...).

Can Windows users reproduce this very basic case here with
mod_slotmem_shm (it doesn't seem Windows specific to me)?


Regards,
Yann.

Re: mod_proxy_balancer doesn't work with 2.4.32

[Ruediger Pluem]

Can anyone reproduce outside of Windows?

Regards

Rüdiger

On 03/15/2018 01:47 PM, Jim Jagielski wrote:
> No doubt something in Yann's slotmem changes that affect Windows.
> 
>> On Mar 15, 2018, at 6:56 AM, Steffen  wrote:
>>
>>
>>
>> Looks a serious regression.
>>
>> Reported:  www.apachelounge.com/viewtopic.php?p=36597
>>
>>
> 
> 

Re: mod_proxy_balancer doesn't work with 2.4.32

[Jim Jagielski]

No doubt something in Yann's slotmem changes that affect Windows.

> On Mar 15, 2018, at 6:56 AM, Steffen  wrote:
> 
> 
> 
> Looks a serious regression.
> 
> Reported:  www.apachelounge.com/viewtopic.php?p=36597
> 
> 

Re: mod_proxy_balancer build failure

[William A. Rowe Jr.]

On 2/9/2011 10:07 PM, Gregg L. Smith wrote:
 Hi Jim,
 
 Thank you, yet I'm more concerned about the former one honestly as it's a 
 no-go.
 
 I looked up the error and you can not declare a function internal to the dll 
 as a dll import. Because of PROXY_DECLARE the function gets an import tag, so 
 the function needs to be exported or made static.
 
 If it is your intention to export this function, things are further 
 complicated by the fact if you /D PROXY_DECLARE_EXPORT, all functions in 
 mod_proxy.h switch to export, so this function needs to be separated from the 
 rest of the PROXY_DECLAREs.
 
 The attached patch does just that, allowing the function to be exported 
 without exporting everything else, allowing this to build for Win32. If it 
 was never your intention to export it, just make it static.

This might be symptomatic of something deeper... are we falling in the
trap of module load order dependencies AGAIN?

/sigh

Re: mod_proxy_balancer build failure

[Jim Jagielski]

PROXY_DECLARE(apr_status_t) ap_proxy_update_members is what I
want and what I meant.

On Feb 9, 2011, at 11:07 PM, Gregg L. Smith wrote:

 Hi Jim,
 
 Thank you, yet I'm more concerned about the former one honestly as it's a 
 no-go.
 
 I looked up the error and you can not declare a function internal to the dll 
 as a dll import. Because of PROXY_DECLARE the function gets an import tag, so 
 the function needs to be exported or made static.
 
 If it is your intention to export this function, things are further 
 complicated by the fact if you /D PROXY_DECLARE_EXPORT, all functions in 
 mod_proxy.h switch to export, so this function needs to be separated from the 
 rest of the PROXY_DECLAREs.
 
 The attached patch does just that, allowing the function to be exported 
 without exporting everything else, allowing this to build for Win32. If it 
 was never your intention to export it, just make it static.
 
 Cheers,
 
 Gregg
 
 -Original Message-
 From: Jim Jagielski j...@apache.org
 To: dev@httpd.apache.org
 Date: Wed, 9 Feb 2011 09:26:05 -0500
 Subject: Re: mod_proxy_balancer build failure
 
 
 On Feb 8, 2011, at 9:11 PM, Gregg L. Smith wrote:
 
 Good evening,
 
 -- Build started: Project: mod_proxy_balancer, Configuration: Release 
 Win32 --
 Compiling...
 mod_proxy_balancer.c
 .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : 
 definition of dllimport function not allowed
 .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch
 
 The latter fixed in r1068871
 
 
 
 
 
 balancer.diff

Re: Re: mod_proxy_balancer build failure

[Gregg L. Smith]

Hi Jim,

r1069381 works, thank you.

Cheers,
Gregg

-Original Message-
From: Jim Jagielski j...@apache.org
To: dev@httpd.apache.org
Date: Thu, 10 Feb 2011 08:24:12 -0500
Subject: Re: mod_proxy_balancer build failure

PROXY_DECLARE(apr_status_t) ap_proxy_update_members is what I
want and what I meant.

On Feb 9, 2011, at 11:07 PM, Gregg L. Smith wrote:

 Hi Jim,
 
 Thank you, yet I'm more concerned about the former one honestly as it's a 
 no-go.
 
 I looked up the error and you can not declare a function internal to the dll 
 as a dll import. Because of PROXY_DECLARE the function gets an import tag, so 
 the function needs to be exported or made static.
 
 If it is your intention to export this function, things are further 
 complicated by the fact if you /D PROXY_DECLARE_EXPORT, all functions in 
 mod_proxy.h switch to export, so this function needs to be separated from the 
 rest of the PROXY_DECLAREs.
 
 The attached patch does just that, allowing the function to be exported 
 without exporting everything else, allowing this to build for Win32. If it 
 was never your intention to export it, just make it static.

 Cheers,

 Gregg

 -Original Message-
 From: Jim Jagielski j...@apache.org
 To: dev@httpd.apache.org
 Date: Wed, 9 Feb 2011 09:26:05 -0500
 Subject: Re: mod_proxy_balancer build failure


 On Feb 8, 2011, at 9:11 PM, Gregg L. Smith wrote:

 Good evening,

 -- Build started: Project: mod_proxy_balancer, Configuration: Release 
 Win32 --
 Compiling...
 mod_proxy_balancer.c
 .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : 
 definition of dllimport function not allowed
 .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch

 The latter fixed in r1068871





 balancer.diff

Re: mod_proxy_balancer build failure

[William A. Rowe Jr.]

On 2/10/2011 7:24 AM, Jim Jagielski wrote:
 PROXY_DECLARE(apr_status_t) ap_proxy_update_members is what I
 want and what I meant.

Modules should not be exporting functions, they should be registering
optional functions at the reg phase, other modules picking them up
if available in their config phase.  Right?

Re: mod_proxy_balancer build failure

[Jim Jagielski]

On Feb 8, 2011, at 9:11 PM, Gregg L. Smith wrote:

 Good evening,
 
 -- Build started: Project: mod_proxy_balancer, Configuration: Release 
 Win32 --
 Compiling...
 mod_proxy_balancer.c
 .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : 
 definition of dllimport function not allowed
 .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch

The latter fixed in r1068871

Re: Re: mod_proxy_balancer build failure

[Gregg L. Smith]

Hi Jim,

Thank you, yet I'm more concerned about the former one honestly as it's a no-go.

I looked up the error and you can not declare a function internal to the dll as 
a dll import. Because of PROXY_DECLARE the function gets an import tag, so the 
function needs to be exported or made static.

If it is your intention to export this function, things are further complicated 
by the fact if you /D PROXY_DECLARE_EXPORT, all functions in mod_proxy.h switch 
to export, so this function needs to be separated from the rest of the 
PROXY_DECLAREs.

The attached patch does just that, allowing the function to be exported without 
exporting everything else, allowing this to build for Win32. If it was never 
your intention to export it, just make it static.

Cheers,

Gregg

-Original Message-
From: Jim Jagielski j...@apache.org
To: dev@httpd.apache.org
Date: Wed, 9 Feb 2011 09:26:05 -0500
Subject: Re: mod_proxy_balancer build failure


On Feb 8, 2011, at 9:11 PM, Gregg L. Smith wrote:

 Good evening,

 -- Build started: Project: mod_proxy_balancer, Configuration: Release 
 Win32 --
 Compiling...
 mod_proxy_balancer.c
 .\mod_proxy_balancer.c(1332) : error C2491: 'ap_proxy_update_members' : 
 definition of dllimport function not allowed
 .\mod_proxy_balancer.c(1343) : warning C4018: '' : signed/unsigned mismatch

The latter fixed in r1068871







balancer.diff
Description: Binary data

Re: mod_proxy_balancer dynamic change properties

[Kevac Marko]

On Wed, Jun 17, 2009 at 12:39 PM, h iroshaniroshanm...@gmail.com wrote:
 Hi kevac Marko,

 Thank you very much .I just want to do the same thing  here. My workers are
 Tomcat and I am going to change lbfactor  according to there Memory
 usage.Can we use normal socket connection to retrieve information from the
 workers or is there any simple way to communicate with worker node?.

If you are using Java stuff, than you should look at mod_cluster.

We read load information from shared memory. Load information is
written there via separate program.

-- 
Marko Kevac

Re: mod_proxy_balancer dynamic change properties

[Kevac Marko]

Yes, you can do that. We wrote module that changes loadfactor in
accordance to machine load.

On Wed, Jun 17, 2009 at 12:12 AM, h iroshaniroshanm...@gmail.com wrote:
 Hi Rüdiger,

 thanks lot ,

 I  already followed the source code of the mod_cluster. Its uses another
 shared memory implementation called slotmem rather than using scorebord.
 Are you sure is it possible to change this scorebord lbfactor property
 dynamically and it will affect the request distribution according to that
 dynamically updated lbfactor value.Please help me.


 Regards
 Iroshan
 4th year under graduate in computer science
 University Of Colombo
 Sri Lanka




-- 
Marko Kevac

Re: mod_proxy_balancer dynamic change properties

[h iroshan]

Hi kevac Marko,

Thank you very much .I just want to do the same thing  here. My workers are
Tomcat and I am going to change lbfactor  according to there Memory
usage.Can we use normal socket connection to retrieve information from the
workers or is there any simple way to communicate with worker node?.

Currently I am doing ,when the balancer init the workers ,I initialise
another thread with socket server wich is listining  for the Worker node.
Worker node also have Socket client it send there Memeory usage to  the
Server Side. But I know thuis is not the way to do that.

I want to do this in a satnderd way please help me..

Thank you,

Regards
Iroshan
4th year under graduate in computer science
University Of Colombo
Sri Lanka

Re: mod_proxy_balancer dynamic change properties

[jean-frederic clere]

h iroshan wrote:

Hi Rüdiger,

thanks lot ,

I  already followed the source code of the mod_cluster. Its uses another 
shared memory implementation called slotmem rather than using scoreboard.


A slotmem code is already in httpd-trunk.

Are you sure is it possible to change this scorebord lbfactor property 
dynamically and it will affect the request distribution according to 
that dynamically updated lbfactor value.


Please read the code, try the stuff and have fun.

Cheers

Jean-Frederic

Re: mod_proxy_balancer dynamic change properties

[h iroshan]

Hi jean-frederic clere,

Thanks lot, Is there any technical documentation for these modules,Such as
mod_cluster,mod_proxy_balaner.

Regards,
Iroshan

Re: mod_proxy_balancer dynamic change properties

[Ruediger Pluem]

On 06/16/2009 08:43 PM, h iroshan wrote:
 Hi All,
 
 I want to know whether the mod_proxy_balancer can dynamically change there
 propertis during the run time. For ex- can we change lbfactor's values for
 workers periodically according to there work load.
 
 If it is ok, is it possible to do that by updating theworkers  lbfactor
 values in the scoreboard.
 Please help me.

Maybe the below is what you are looking for:

http://httpd.apache.org/docs/2.2/en/mod/mod_proxy_balancer.html#enable

Regards

Rüdiger

Re: mod_proxy_balancer dynamic change properties

[h iroshan]

Hi Rüdiger and all,

Actually I want to know  ,can't we done it by changing the source code of
mode proxy balancer.Because properties of the mod_proxy_balancer gets from
the config. After first time set values for the scoreboard properties by
config file , mod_proxy_balancer uses this scoreboard lbfactor value.
lbfactor value never updated again and again

So is it possible to update scoreboard lbfactor by source code periodically
in order to provide  dyanamic load balancing mechanism to this module.

please help me

Regards,
Iroshan
4th year under graduate in computer science
University Of Colombo
Sri Lanka

Re: mod_proxy_balancer dynamic change properties

[Ruediger Pluem]

On 06/16/2009 09:20 PM, h iroshan wrote:
 Hi Rüdiger and all,
 
 Actually I want to know  ,can't we done it by changing the source code of
 mode proxy balancer.Because properties of the mod_proxy_balancer gets from
 the config. After first time set values for the scoreboard properties by
 config file , mod_proxy_balancer uses this scoreboard lbfactor value.
 lbfactor value never updated again and again
 
 So is it possible to update scoreboard lbfactor by source code periodically
 in order to provide  dyanamic load balancing mechanism to this module.

Yes it can be changed dynamically. Please see the implementation of the 
balancer-manager
handler. I guess another good source for you could be

http://jfclere.blogspot.com/

which talks about mod_cluster (actutally Jean-Frederic is the author of 
mod_cluster).

Regards

Rüdiger

Re: mod_proxy_balancer dynamic change properties

[h iroshan]

 Hi Rüdiger,

thanks lot ,

I  already followed the source code of the mod_cluster. Its uses another
shared memory implementation called slotmem rather than using scorebord.
Are you sure is it possible to change this scorebord lbfactor property
dynamically and it will affect the request distribution according to that
dynamically updated lbfactor value.Please help me.


Regards
Iroshan
4th year under graduate in computer science
University Of Colombo
Sri Lanka

Re: mod_proxy_balancer lbset functionality

[Rainer Jung]

On 01.02.2009 22:51, Jim Jagielski wrote:

On Feb 1, 2009, at 3:08 AM, Mladen Turk wrote:

Think Jim introduced the lbset balancer property, so he would probably
know best how this is supposed to work.

IIUC lbset should allow to create the group of balancer members,
and that's great. However IMO the logic inside balancer providers
in not valid. The balancing should be done for a particular
set, however IMO it's done always from 0...current set

Here is the code
if (worker-s-lbset  cur_lbset)
continue;
...
cur_lbset++

IMO it should be
if (worker-s-lbset != cur_lbset)
continue;
...
cur_lbset++



Yes... the current logic assumes that the ordering of the
configed lbsets is sequential, which is not a valid assumption.

fixed. Thanks!


Both ways would make sense. I remember when Jim added it in 2006, which 
was shortly after mod_jk added the distance attribute. So I think the 
original intention might have actually been to express preferences and 
not really separate independent groups (like domains in mod_jk).


Regards,

Rainer

Re: mod_proxy_balancer lbset functionality

[Jim Jagielski]

On Feb 1, 2009, at 3:08 AM, Mladen Turk wrote:


Hi,

Think Jim introduced the lbset balancer property, so he would probably
know best how this is supposed to work.

IIUC lbset should allow to create the group of balancer members,
and that's great. However IMO the logic inside balancer providers
in not valid. The balancing should be done for a particular
set, however IMO it's done always from 0...current set

Here is the code
if (worker-s-lbset  cur_lbset)
 continue;
...
cur_lbset++

IMO it should be
if (worker-s-lbset != cur_lbset)
 continue;
...
cur_lbset++



Yes... the current logic assumes that the ordering of the
configed lbsets is sequential, which is not a valid assumption.

fixed. Thanks!

Re: mod_proxy_balancer enhancements

[Akins, Brian]

On 8/28/08 8:45 PM, Jess Holle [EMAIL PROTECTED] wrote:

 Possible solutions include:
 Having an option to have a background thread ping the backends rather than
 allowing normal requests to do so.


One way to possibly do this is to have a single health checking that's in
the parent that can notify children of origin server changes.  Could just
be setting some flags in shared memory.  The health-checker could be an
external process managed like a logger as well or just forked from parent.

-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

Re: mod_proxy_balancer

[Jim Jagielski]

Hmmm... maybe:

   worker_is_initialized = (workers-s  PROXY_WORKER_IS_INITIALIZED 
(workers));


instead of

worker_is_initialized = workers-s ?
PROXY_WORKER_IS_INITIALIZED 
(workers) : 0;


??

Re: mod_proxy_balancer

[Ruediger Pluem]

On 09/03/2007 11:40 PM, Vinicius Petrucci wrote:
 Ruedinger:
 
 In your patch, I think the call PROXY_WORKER_IS_INITIALIZED(workers)
 before initialize the pointer *workers is causing that error log:
 
 [Mon Sep 03 18:32:34 2007] [notice] child pid 5225 exit signal
 Segmentation fault (11)

Sorry my fault. Can you please try the attached one please?

 
 But if I call the method: ap_proxy_initialize_worker_share(conf,
 workers, s); before, I always get worker initialized...

Which is why I called it before :-).

Regards

Rüdiger

Index: modules/proxy/mod_proxy_balancer.c
===
--- modules/proxy/mod_proxy_balancer.c	(Revision 572643)
+++ modules/proxy/mod_proxy_balancer.c	(Arbeitskopie)
@@ -86,22 +86,24 @@
 {
 int i;
 proxy_worker *workers;
+int worker_is_initialized;
 
 workers = (proxy_worker *)balancer-workers-elts;
 
 for (i = 0; i  balancer-workers-nelts; i++) {
+worker_is_initialized = workers-s ? 
+PROXY_WORKER_IS_INITIALIZED(workers) : 0;
 ap_proxy_initialize_worker_share(conf, workers, s);
 ap_proxy_initialize_worker(workers, s);
+if (!worker_is_initialized) {
+/* Set to the original configuration */
+workers-s-lbstatus = workers-s-lbfactor =
+(workers-lbfactor ? workers-lbfactor : 1);
+workers-s-lbset = workers-lbset;
+}
 ++workers;
 }
 
-workers = (proxy_worker *)balancer-workers-elts;
-for (i = 0; i  balancer-workers-nelts; i++) {
-/* Set to the original configuration */
-workers[i].s-lbstatus = workers[i].s-lbfactor =
-  (workers[i].lbfactor ? workers[i].lbfactor : 1);
-workers[i].s-lbset = workers[i].lbset;
-}
 /* Set default number of attempts to the number of
  * workers.
  */

Re: mod_proxy_balancer

[Vinicius Petrucci]

I don't know why, but each time a new child is created the variable
worker_is_initialized is 0.

Therefore, the problem of reseting to the original configuration is not solved.

I'm debugging more on this...

On 04/09/07, Ruediger Pluem [EMAIL PROTECTED] wrote:


 On 09/03/2007 11:40 PM, Vinicius Petrucci wrote:
  Ruedinger:
 
  In your patch, I think the call PROXY_WORKER_IS_INITIALIZED(workers)
  before initialize the pointer *workers is causing that error log:
 
  [Mon Sep 03 18:32:34 2007] [notice] child pid 5225 exit signal
  Segmentation fault (11)

 Sorry my fault. Can you please try the attached one please?

 
  But if I call the method: ap_proxy_initialize_worker_share(conf,
  workers, s); before, I always get worker initialized...

 Which is why I called it before :-).

 Regards

 Rüdiger





-- 
Vinicius Tavares Petrucci
home page: http://www.ic.uff.br/~vpetrucci

Re: mod_proxy_balancer

[Vinicius Petrucci]

Hi,

As I said before, your last patch didn't solve the bug because the
variable you created (worker_is_initialized) always gets zero value.

I've created the patches attached. The solution was to simply move the
code section that set lbfactor, lbstatus, and lbset to the original
configuration inside the function ap_proxy_initialize_worker_share()
in proxy_util.c.

It works using my httpd-trunk version. Could you guys confirm if it is correct?

Vinicius

On 04/09/07, Vinicius Petrucci [EMAIL PROTECTED] wrote:
 I don't know why, but each time a new child is created the variable
 worker_is_initialized is 0.

 Therefore, the problem of reseting to the original configuration is not 
 solved.

 I'm debugging more on this...

 On 04/09/07, Ruediger Pluem [EMAIL PROTECTED] wrote:
 
 
  On 09/03/2007 11:40 PM, Vinicius Petrucci wrote:
   Ruedinger:
  
   In your patch, I think the call PROXY_WORKER_IS_INITIALIZED(workers)
   before initialize the pointer *workers is causing that error log:
  
   [Mon Sep 03 18:32:34 2007] [notice] child pid 5225 exit signal
   Segmentation fault (11)
 
  Sorry my fault. Can you please try the attached one please?
 
  
   But if I call the method: ap_proxy_initialize_worker_share(conf,
   workers, s); before, I always get worker initialized...
 
  Which is why I called it before :-).
 
  Regards
 
  Rüdiger
 
 
 


 --
 Vinicius Tavares Petrucci
 home page: http://www.ic.uff.br/~vpetrucci



-- 
Vinicius Tavares Petrucci
home page: http://www.ic.uff.br/~vpetrucci
Index: httpd-trunk/modules/proxy/mod_proxy_balancer.c
===
--- httpd-trunk/modules/proxy/mod_proxy_balancer.c	(revision 572771)
+++ httpd-trunk/modules/proxy/mod_proxy_balancer.c	(working copy)
@@ -95,13 +95,6 @@
 ++workers;
 }
 
-workers = (proxy_worker *)balancer-workers-elts;
-for (i = 0; i  balancer-workers-nelts; i++) {
-/* Set to the original configuration */
-workers[i].s-lbstatus = workers[i].s-lbfactor =
-  (workers[i].lbfactor ? workers[i].lbfactor : 1);
-workers[i].s-lbset = workers[i].lbset;
-}
 /* Set default number of attempts to the number of
  * workers.
  */
Index: httpd-trunk/modules/proxy/proxy_util.c
===
--- httpd-trunk/modules/proxy/proxy_util.c	(revision 572771)
+++ httpd-trunk/modules/proxy/proxy_util.c	(working copy)
@@ -1723,6 +1723,10 @@
 
 worker-s-status |= (worker-status | PROXY_WORKER_INITIALIZED);
 
+/* Set to the original configuration */
+	worker-s-lbstatus = worker-s-lbfactor =
+	(worker-lbfactor ? worker-lbfactor : 1);
+	worker-s-lbset = worker-lbset;
 }
 
 PROXY_DECLARE(apr_status_t) ap_proxy_initialize_worker(proxy_worker *worker, server_rec *s)

Re: mod_proxy_balancer

[Ruediger Pluem]

On 09/02/2007 04:57 PM, Vinicius Petrucci wrote:
 Hi Guys,
 
 I've read Ruediger's patch about preventing mod_proxy_balancer from
 overwriting the status of workers when creating a new child process
 (http://svn.apache.org/viewcvs?rev=374929view=rev).
 
 I'm running the latest stable release of Apache (2.2.4) and I think
 the same bug is overwriting the lbfactor value to 1 (original
 configuration) when creating a new child process. Is it really a bug?
 How can I prevent that?

Can you please try if the attached patch against trunk fixes your issue
(also applies for 2.2.x with little fuzz)?
Can you please open a bug report in bugzilla for this? This eases tracking
for us. Thanks.

I CCed dev@httpd.apache.org as this is the correct mailing list for
such issues (apart from bugzilla as mentioned above).

Regards

Rüdiger


Index: modules/proxy/mod_proxy_balancer.c
===
--- modules/proxy/mod_proxy_balancer.c	(revision 572243)
+++ modules/proxy/mod_proxy_balancer.c	(working copy)
@@ -86,22 +86,23 @@
 {
 int i;
 proxy_worker *workers;
+int worker_is_initialized;
 
 workers = (proxy_worker *)balancer-workers-elts;
 
 for (i = 0; i  balancer-workers-nelts; i++) {
+worker_is_initialized = PROXY_WORKER_IS_INITIALIZED(workers);
 ap_proxy_initialize_worker_share(conf, workers, s);
 ap_proxy_initialize_worker(workers, s);
+if (!worker_is_initialized) {
+/* Set to the original configuration */
+workers[i].s-lbstatus = workers[i].s-lbfactor =
+(workers[i].lbfactor ? workers[i].lbfactor : 1);
+workers[i].s-lbset = workers[i].lbset;
+}
 ++workers;
 }
 
-workers = (proxy_worker *)balancer-workers-elts;
-for (i = 0; i  balancer-workers-nelts; i++) {
-/* Set to the original configuration */
-workers[i].s-lbstatus = workers[i].s-lbfactor =
-  (workers[i].lbfactor ? workers[i].lbfactor : 1);
-workers[i].s-lbset = workers[i].lbset;
-}
 /* Set default number of attempts to the number of
  * workers.
  */

Re: mod_proxy_balancer

[Vinicius Petrucci]

Hi !

I found this bug already opened at Bugzilla:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39907

In response to Ruediger's new patch, the call
PROXY_WORKER_IS_INITIALIZED(workers) is causing that error log:

[Mon Sep 03 18:32:34 2007] [notice] child pid 5225 exit signal
Segmentation fault (11)

Runtime s structure from worker not initialized?

Vinicius

-- 
Vinicius Tavares Petrucci
home page: http://www.ic.uff.br/~vpetrucci

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Darryl Miles]

Henri Gomez wrote:

Well you we always indicate some sort of CPU power for a remote (a sort 
of bogomips) and use this in computation.


Why should the CPU power matter, what if the high power CPU is getting 
all the complex requests and the lower power CPU is ending up with 
simple request (static content).



You are better implementing it in control packets over AJP that can 
advertise that hosts current willingness to take on new requests on a 
32/64bit scale.  Call this a flow control back pressure packet, a 
stateless beacon of information which may or may not be used by the 
client AJP.


Then have a pluggable implementation at the server end of calculating 
that value and frequency for advertising it.  All the apache LB has to 
do is work from that load calculation.  All existing AJPs have to do is 
just ignore the packet.


In the case of different horse power CPUs that factor is better fed into 
the server AJP algorithm by biasing the advertised willingness to take 
on new requests after a certain low level is reached.  Only the server 
end of the AJP know the true request rate and how near that system is to 
breaking point.


This scheme also works where apache may not see all the work the backend 
is doing, like if you have a different apache front end clusters linked 
to the same single backend cluster.



Darryl

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Henri Gomez]

The TomcatoMips indicator was just something to tell that it's not the
raw CPU power which is important, but the estimated LOAD capacity of
an instance.

Accounting informations should included average time to execute a
request, number of thread in use (AJP/HTTP), estimated free memory...

Just to be sure that when a tomcat (for example), is near overload,
the next requests will be routed to another less loaded tomcat.

2006/6/22, Darryl Miles [EMAIL PROTECTED]:

Henri Gomez wrote:

 Well you we always indicate some sort of CPU power for a remote (a sort
 of bogomips) and use this in computation.

Why should the CPU power matter, what if the high power CPU is getting
all the complex requests and the lower power CPU is ending up with
simple request (static content).


You are better implementing it in control packets over AJP that can
advertise that hosts current willingness to take on new requests on a
32/64bit scale.  Call this a flow control back pressure packet, a
stateless beacon of information which may or may not be used by the
client AJP.

Then have a pluggable implementation at the server end of calculating
that value and frequency for advertising it.  All the apache LB has to
do is work from that load calculation.  All existing AJPs have to do is
just ignore the packet.

In the case of different horse power CPUs that factor is better fed into
the server AJP algorithm by biasing the advertised willingness to take
on new requests after a certain low level is reached.  Only the server
end of the AJP know the true request rate and how near that system is to
breaking point.

This scheme also works where apache may not see all the work the backend
is doing, like if you have a different apache front end clusters linked
to the same single backend cluster.


Darryl

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Darryl Miles]

Henri Gomez wrote:

The TomcatoMips indicator was just something to tell that it's not the
raw CPU power which is important, but the estimated LOAD capacity of
an instance.



But its still apache working out TomcatoMips.  I think that approach is 
still flawed.


I'm saying only the server end of the AJP knows the true situation.  The 
current setup presumes that the running apache instance has all the 
facts necessary to determine balancing.  When all it knows about is the 
work it has given the backend and the work rate its betting it back.



I'm thinking both ends apache and tomcat should make load calculations 
based on that they know at hand.  As far as I know there is no provision 
in the AJP to announce Willingness to serve.  Both ends should feed 
their available information and configuration biases it into their 
respective algorithm and come out with a result that can be compared 
against each other.  The worker would then announce as necessary (there 
maybe a minimum % change to damper information flap) down the connector 
the info to apache.  There probably need to be a random magic number and 
wrapping sequence number in the packet to help the apache end spot 
obvious problems.


This would allow kernel load avg/io load (and anything else) to be 
periodically taken into account at the tomcat end.  It would be expected 
that each member of the backend tomcat cluster is using the same 
algorithm to announce willingness.  Otherwise you get disparity when 
apache comes to make a decision.



So I suppose its just the framework to allow an LB worker to announce 
its willingness to serve I am calling for here.  Not any specific 
algorithm, that issue can be toyed with until the end of time.



An initial implementation would need to experiment and work out:
 * How that willingess value impacts/biases the existing apache LB 
calculations.
 * Guidelines on how to configure algorithm at each end up based on 
known factors (like CPUs, average background workload, relative IO 
performance).


I'm thinking with that you can hit the widest audience to make a usable 
default without giving much thought to configuration.  The type of 
approach kernels make these days, you only have to tweak and think about 
configuration in extreme scenarios but for the most it works well out of 
the box.



Darryl

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jean-frederic Clere]

Henri Gomez wrote:


The TomcatoMips indicator was just something to tell that it's not the
raw CPU power which is important, but the estimated LOAD capacity of
an instance.

Accounting informations should included average time to execute a
request, number of thread in use (AJP/HTTP), estimated free memory...

Just to be sure that when a tomcat (for example), is near overload,
the next requests will be routed to another less loaded tomcat.


If you want such information I think Tomcat (or the backend server) has 
to provide it.


Cheers

Jean-Frederic



2006/6/22, Darryl Miles [EMAIL PROTECTED]:


Henri Gomez wrote:

 Well you we always indicate some sort of CPU power for a remote (a 
sort

 of bogomips) and use this in computation.

Why should the CPU power matter, what if the high power CPU is getting
all the complex requests and the lower power CPU is ending up with
simple request (static content).


You are better implementing it in control packets over AJP that can
advertise that hosts current willingness to take on new requests on a
32/64bit scale.  Call this a flow control back pressure packet, a
stateless beacon of information which may or may not be used by the
client AJP.

Then have a pluggable implementation at the server end of calculating
that value and frequency for advertising it.  All the apache LB has to
do is work from that load calculation.  All existing AJPs have to do is
just ignore the packet.

In the case of different horse power CPUs that factor is better fed into
the server AJP algorithm by biasing the advertised willingness to take
on new requests after a certain low level is reached.  Only the server
end of the AJP know the true request rate and how near that system is to
breaking point.

This scheme also works where apache may not see all the work the backend
is doing, like if you have a different apache front end clusters linked
to the same single backend cluster.


Darryl

Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mathieu CARBONNEAUX]

like alteon load balancer from nortel... they provide health check for many protocole...for http is only simple get to backend... and on the backend you must provide a responde this check (ex:statics file)...you can define how many ping after how it consider the backend dead...and how many seconds between ping...From: Jim Jagielski [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Mon, 19 Jun 2006 23:02:11 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODORuediger Pluem wrote:  +1. Just one thought: I think it would be useful to have this 'health check' approach somewhat generic so that we can implement the call to it inside mod_proxy and its connection pooling itself (e.g. with providers supplied by schema handlers / modules). For AJP this would be CPING/CPONG of course and mod_proxy itself could offer a generic TCP connection 'health check' provider that simply checks the status of a TCP connection as far as this is possible without reading or writing data. This would be a very generic provider. Other protocol handlers could define other (better) protocol specific providers and just plug them in. Agreed. Making a generic hearbeat interface that could vary dependingon the actual protocol would be v. cool. So for AJP, CPING/CPONG,for HTTP some sort of generic TRACE (or HEAD)...-- ===   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/	"If you can dodge a wrench, you can dodge a ball."

Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mathieu CARBONNEAUX]

why not add proxy hook like scheme handler do to that ?From: Ruediger Pluem [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Mon, 19 Jun 2006 23:04:55 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODOOn 06/19/2006 10:23 PM, Mladen Turk wrote: Henri Gomez wrote:  Good to see that PING/PONG got such a good response here. When I added this to mod_jk it was just a quick way to detect hang JVMs but it seems to many on the TC-DEV not a very usefull feature :)  And may thanks for such a great idea Henri ;) Actually its a great way to detect all those busy/broken/hanged/disconnected servers.  I'm not sure how we could add that feature to the http/https protocol, the Rudiger suggested.To be honest I currently have no generic idea how to do this withoutsupport from the backend. My point was more about that I would loveto see this health check integrated into the generic code of mod_proxyand its connection pooling and let the protocol modules provide the codethat actually does the dirty work of the protocol specific aspects of such ahealth check. This would make it easy to add health checks for other protocols/ add better ones for protocols with existing ones. As said currently I wouldonly see two health check providers:- CPING/CPONG for AJP.- A generic TCP connection check.But this would be open to further bright ideas.RegardsRüdiger

Re: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mathieu CARBONNEAUX]

you must have the possibility to add a wheight to each backend to moderate the load (like nortel alteon)... no?From: Mladen Turk [mailto:[EMAIL PROTECTED]To: dev@httpd.apache.orgSent: Tue, 20 Jun 2006 09:02:44 +0200Subject: [EMAIL PROTECTED] Re: mod_proxy_balancer/mod_proxy_ajp TODOHenri Gomez wrote: Important point in load balancing will be to collect CPU load (job load) from the remote. We often make the mistake to split requests between servers as if it cost the same CPU power (or cpu load) for each of them, but in Java / J2EE some requests could be more CPU/IO/DB consuming than others.Well, I'm not sure that having the CPU load would mean something.For example you might have P3/1GHz and P66/100GHz with thesame load (close to 80%), and that info in that case would beactually misleading. It might help only if your hardware topologyis exactly the same for all backend servers.The bussines method OTOH will favor the 100GHz box over 1GHz one,thus giving more sense. Even with the same hardware topology,it is presumable that the shorter reply timeout would mean lessCPU cycles used.Regards,Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Henri Gomez wrote:

Important point in load balancing will be to collect CPU load (job
load) from the remote.
We often make the mistake to split requests between servers as if it
cost the same CPU power (or cpu load) for each of them, but in Java /
J2EE some requests could be more CPU/IO/DB consuming than others.



Well, I'm not sure that having the CPU load would mean something.
For example you might have P3/1GHz and P66/100GHz with the
same load (close to 80%), and that info in that case would be
actually misleading. It might help only if your hardware topology
is exactly the same for all backend servers.

The bussines method OTOH will favor the 100GHz box over 1GHz one,
thus giving more sense. Even with the same hardware topology,
it is presumable that the shorter reply timeout would mean less
CPU cycles used.

Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Cheenu]

I have had a need for this functionality in one application or other for a while now and have been researching various means of acheiving it without actually coding.mod_backhand (
www.backhand.org) which seems to be an abandoned project was very promising a few years back.I think, section 3.3 of http://www.backhand.org/ApacheCon2001/US/backhand_course_notes.pdf
 was some attempt in the past in this direction.Just wanted to put in this casual note.Thanks for keeping up the good work folks - appreciate itCheenuOn 6/20/06, 
Mladen Turk [EMAIL PROTECTED] wrote:
Henri Gomez wrote: Important point in load balancing will be to collect CPU load (job load) from the remote. We often make the mistake to split requests between servers as if it cost the same CPU power (or cpu load) for each of them, but in Java /
 J2EE some requests could be more CPU/IO/DB consuming than others.Well, I'm not sure that having the CPU load would mean something.For example you might have P3/1GHz and P66/100GHz with the
same load (close to 80%), and that info in that case would beactually misleading. It might help only if your hardware topologyis exactly the same for all backend servers.The bussines method OTOH will favor the 100GHz box over 1GHz one,
thus giving more sense. Even with the same hardware topology,it is presumable that the shorter reply timeout would mean lessCPU cycles used.Regards,Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Bill Stoddard]

Mladen Turk wrote:

Hi guys,

I'm would like to give few notes on the things I'm
currently working on, so that eventually no duplicate
work is done if someone already have similar things
on his drawing board.

1. Additional by business load balancing method
   that will load balance on the actual load of the
   beckend servers. The servers that have shorter reply
   time will get more load.


+1 on the work, but I question the usefulness of this routing algorithm. Does reply time (from the backend 
server)correlate with resource utilization on the backend server in any but the most contrived cases?




2. Hot standby support. Something we have recently added
   to the mod_jk that allows to have the 'hot-standby'
   backend node, that sits there and does nothing until
   all the other nodes fail.


Nice.



3. CPING/CPONG support for the AJP protocol, for checking
   the status of the backend server prior of sending the
   data itself.


Sounds good.

Bill

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Bill Stoddard wrote:


1. Additional by business load balancing method
   that will load balance on the actual load of the
   beckend servers. The servers that have shorter reply
   time will get more load.


+1 on the work, but I question the usefulness of this routing algorithm. 
Does reply time (from the backend server)correlate with resource 
utilization on the backend server in any but the most contrived cases?




Well, this is the only way the balancer can deduct the load
of the backend server. If the backend server is highly loaded
or with lower performance hardware it response time will be lower
compared to the other participants in the cluster, so it will
get less load, and vice versa.
Of course the ultimate thing would be to actually receive the
feedback from the backend server about its actual CPU/memory
utilization, but thats not protocol independent.


Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Bill Stoddard wrote:


1. Additional by business load balancing method
   that will load balance on the actual load of the
   beckend servers. The servers that have shorter reply
   time will get more load.


+1 on the work, but I question the usefulness of this routing algorithm. 
Does reply time (from the backend server)correlate with resource 
utilization on the backend server in any but the most contrived cases?




Yes, the algorithm is the average over the predefined amount of time.
Further more Rainer Jung (our newest Tomcat commiter) has done a
great job by rewriting most of the lb algos to be less spiky, so I
plan to port his work to mod_proxy_balancer.

Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jim Jagielski]

Mladen Turk wrote:
 
 Hi guys,
 
 I'm would like to give few notes on the things I'm
 currently working on, so that eventually no duplicate
 work is done if someone already have similar things
 on his drawing board.
 
 1. Additional by business load balancing method
 that will load balance on the actual load of the
 beckend servers. The servers that have shorter reply
 time will get more load.

If this maps what's currently been done in mod_jk, than
a big +1. It's been on my todo but have simply not
had the cycles to do. I liked the new busyness
algo, but then there was a total rewrite (well,
not total) of it all, most likely since mod_jk doesn't
want to use providers, that makes all the lb determination
by value... I was thinking about extended the LB structs
to also include some sort of LB lbstatus calculation
which meant another cool abstraction and making the
whole make-lb-algos-independent closer to reality.

 
 2. Hot standby support. Something we have recently added
 to the mod_jk that allows to have the 'hot-standby'
 backend node, that sits there and does nothing until
 all the other nodes fail.
 

+1

 3. CPING/CPONG support for the AJP protocol, for checking
 the status of the backend server prior of sending the
 data itself.

This will be cool, but I don't think too easy. Still +1
for the effort :)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Jim Jagielski wrote:


If this maps what's currently been done in mod_jk, than
a big +1. It's been on my todo but have simply not
had the cycles to do.


That is exactly the thing that I'm planing to do.
During last year there was a lots of good stuff
added to the mod_jk that have even force some of
the users used to try to compile and use mod_jk with
httpd 2.2. IMHO there is no reason why we could
not port all that good stuff. It's on my TODO list,
and I'm glad to hear that you guys have the same
thoughts. Perhaps I could explain all that to the
much wider audience in Austin this September ;) ?

Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Bill Stoddard]

Mladen Turk wrote:

Bill Stoddard wrote:


1. Additional by business load balancing method
   that will load balance on the actual load of the
   beckend servers. The servers that have shorter reply
   time will get more load.


+1 on the work, but I question the usefulness of this routing 
algorithm. Does reply time (from the backend server)correlate with 
resource utilization on the backend server in any but the most 
contrived cases?




Yes, the algorithm is the average over the predefined amount of time.
Further more Rainer Jung (our newest Tomcat commiter) has done a
great job by rewriting most of the lb algos to be less spiky, so I
plan to port his work to mod_proxy_balancer.


Ok Mladen, thanks for the info. If the algorithm can account for things like hung applications in the backend 
(which would cause the reply time to spike) and place different applications in different balancing pools to 
keep one bad application from causing all traffic to be routed away from an otherwise available server, then 
it begins to become a usable routing algorithm.


What are some other ways to intuit backend server performance other than 'reply time'?  Some thoughts... It 
would be pretty slick to drive code into mod_proxy (or mod_lb, whatever) which could cause the server to 
'request' performance stats from a backend server; The backend server would have to recognize the 'request' 
for performance stats and be able to respond by either adding a HTTP 'performance stat' header to the response 
(e.g. X-Performance-Foo: bar) or encase the performance stat data in a multipart mime message along with the 
response data. The proxy could gather the performance stat data out of the X-Performance-Foo header (or strip 
out the performance part of the multi-part mime response) and use the performance stats any way it wanted. 
Yea, I know there are packages out there that use lan multicast to exchange data like this.


Ok, now going completely over the top wouldn't it be nice if mod_proxy could request arbitrary meta data 
(not just performance data)to be collected from backend servers; the backend servers obviously need to be able 
to understand and decode requests. ARM sort of does this for things like response time of every piece of code 
in a transaction path. I am thinking even more general. =Any= piece of information available to the backend 
server could be consolidated in a mod_proxy instance and acted upon at the scope of an entire cluster. Think 
debug data, performance data, QoS data, at whatever granularity needed (application, server, cluster).


Once mod_proxy has access to lots of interesting bits, it can be programmed to detect and respond to anomalous 
application behaviors (what's considered anomalous is tunable and maybe is dynamically adjustable). Maybe it 
autonomically collect problem determination data and send alerts to the sys admin when anomalies are detected 
or adjusts it's operating characteristics in whatever manner the admin decides is appropriate.



Bill


Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Bill Stoddard wrote:

Mladen Turk wrote:

Once mod_proxy has access to lots of interesting bits, it can be 
programmed to detect and respond to anomalous application behaviors 



Huh, the thing you are talking about is some sort of
rule based engine. Without having a virtual file system underneath
the httpd, I'm afraid something like that is impossible, or
at least unefficient. Once when we'll have the entire connection
pool mapped as a file system inside httpd we can do more sophisticated
things with balancing.
Last time I mentioned VFS, the goal was 3.0. I already have some
code inside sourceforge for couple of years, and just waiting the
'need' for it :)

Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Rainer Jung]

Hi,

sorry for breaking the mail threading, but I read this list offline 
before and just subscribed to it now.


I would like to release mod_jk 1.2.16 soon, but as soon as that release 
looks good, I would be willing to help syncing features between 
mod_proxy_balancer/mod_proxy_ajp and mod_jk.


Comments see inline.


Mladen Turk wrote:

Bill Stoddard wrote:
  
  1. Additional by business load balancing method

  that will load balance on the actual load of the
  beckend servers. The servers that have shorter reply
  time will get more load.
 
 +1 on the work, but I question the usefulness of this routing 
 algorithm. Does reply time (from the backend server)correlate with 
 resource utilization on the backend server in any but the most 
 contrived cases?
 


Yes, the algorithm is the average over the predefined amount of time.
Further more Rainer Jung (our newest Tomcat commiter) has done a
great job by rewriting most of the lb algos to be less spiky, so I
plan to port his work to mod_proxy_balancer.


Thanks Mladen for giving credits to my patches. Still more to do.

Concerning Busyness: This is an interesting strategy for load balancing, 
when parallelity is a critical ressource. I know cases, where people do 
huge downloads via tomcat and then it's interesting to balance the 
amount of parallel downloads.




Ok Mladen, thanks for the info. If the algorithm can account for things like 
hung \
applications in the backend  (which would cause the reply time to spike) and 
place \
different applications in different balancing pools to  keep one bad 
application from \
causing all traffic to be routed away from an otherwise available server, then  
it \
begins to become a usable routing algorithm.


You could either use Busyness as a strategy, or you can set 
reply_timeouts, so that an application getting very slow will put the 
worker into error state. Such a worker will only be retried once a minute.


With the head code of mod_jk you can now define several workers for the 
same Tomcat target and still use stickyness (needed by most 
applications). E.g. each context could get its own balancer with it's 
own error states, load balancing etc. For this you need to use the new 
attribute jvm_route. Before, the name of the worker had to be equal to 
the jvmRoute attribute on the tomcat side to make stickyness work.




What are some other ways to intuit backend server performance other than 'reply 
\
time'?  Some thoughts... It  would be pretty slick to drive code into mod_proxy 
(or \
mod_lb, whatever) which could cause the server to  'request' performance stats 
from a \
backend server; The backend server would have to recognize the 'request'  for \
performance stats and be able to respond by either adding a HTTP 'performance 
stat' \
header to the response  (e.g. X-Performance-Foo: bar) or encase the performance 
stat \
data in a multipart mime message along with the  response data. The proxy could 
\
gather the performance stat data out of the X-Performance-Foo header (or strip  
out \
the performance part of the multi-part mime response) and use the performance 
stats \
any way it wanted.  Yea, I know there are packages out there that use lan 
multicast \
to exchange data like this.

Ok, now going completely over the top wouldn't it be nice if mod_proxy 
could \
request arbitrary meta data  (not just performance data)to be collected from 
backend \
servers; the backend servers obviously need to be able  to understand and 
decode \
requests. ARM sort of does this for things like response time of every piece of 
code  \
in a transaction path. I am thinking even more general. =Any= piece of 
information \
available to the backend  server could be consolidated in a mod_proxy instance 
and \
acted upon at the scope of an entire cluster. Think  debug data, performance 
data, \
QoS data, at whatever granularity needed (application, server, cluster).

Once mod_proxy has access to lots of interesting bits, it can be programmed to 
detect \
and respond to anomalous  application behaviors (what's considered anomalous 
is \
tunable and maybe is dynamically adjustable). Maybe it  autonomically collect 
problem \
determination data and send alerts to the sys admin when anomalies are detected 
 or \
adjusts it's operating characteristics in whatever manner the admin decides is \
appropriate.


It would be definitely great to establish a meta data communication 
channel between Apache and Tomcat. Two interesting use cases would be


- load status
- available contexts

Especially the second thing would be great for automatically managing 
mod_jk routing information (JkMount).





Bill


Regards,
Mladen.



Rainer

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Ruediger Pluem]

On 06/19/2006 06:21 PM, Mladen Turk wrote:
 Hi guys,
 
 I'm would like to give few notes on the things I'm
 currently working on, so that eventually no duplicate
 work is done if someone already have similar things
 on his drawing board.
 
 1. Additional by business load balancing method
that will load balance on the actual load of the
beckend servers. The servers that have shorter reply
time will get more load.

Sounds good.

 
 2. Hot standby support. Something we have recently added
to the mod_jk that allows to have the 'hot-standby'
backend node, that sits there and does nothing until
all the other nodes fail.

+1

 
 3. CPING/CPONG support for the AJP protocol, for checking
the status of the backend server prior of sending the
data itself.

+1. Just one thought: I think it would be useful to have this 'health check'
approach somewhat generic so that we can implement the call to it inside 
mod_proxy
and its connection pooling itself (e.g. with providers supplied by schema
handlers / modules). For AJP this would be CPING/CPONG of course and
mod_proxy itself could offer a generic TCP connection 'health check' 
provider that simply
checks the status of a TCP connection as far as this is possible without
reading or writing data. This would be a very generic provider. Other 
protocol
handlers could define other (better) protocol specific providers and
just plug them in.

Regards

Rüdiger

P.S: Are you in Dublin next week?

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Henri Gomez]

Good to see that PING/PONG got such a good response here.

When I added this to mod_jk it was just a quick way to detect hang
JVMs but it seems to many on the TC-DEV not a very usefull feature :)

2006/6/19, Ruediger Pluem [EMAIL PROTECTED]:



On 06/19/2006 06:21 PM, Mladen Turk wrote:
 Hi guys,

 I'm would like to give few notes on the things I'm
 currently working on, so that eventually no duplicate
 work is done if someone already have similar things
 on his drawing board.

 1. Additional by business load balancing method
that will load balance on the actual load of the
beckend servers. The servers that have shorter reply
time will get more load.

Sounds good.


 2. Hot standby support. Something we have recently added
to the mod_jk that allows to have the 'hot-standby'
backend node, that sits there and does nothing until
all the other nodes fail.

+1


 3. CPING/CPONG support for the AJP protocol, for checking
the status of the backend server prior of sending the
data itself.

+1. Just one thought: I think it would be useful to have this 'health check'
approach somewhat generic so that we can implement the call to it inside 
mod_proxy
and its connection pooling itself (e.g. with providers supplied by schema
handlers / modules). For AJP this would be CPING/CPONG of course and
mod_proxy itself could offer a generic TCP connection 'health check' 
provider that simply
checks the status of a TCP connection as far as this is possible without
reading or writing data. This would be a very generic provider. Other 
protocol
handlers could define other (better) protocol specific providers and
just plug them in.

Regards

Rüdiger

P.S: Are you in Dublin next week?

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Rainer Jung wrote:

Hi,

sorry for breaking the mail threading, but I read this list offline 
before and just subscribed to it now.


I would like to release mod_jk 1.2.16 soon, but as soon as that release 
looks good, I would be willing to help syncing features between 
mod_proxy_balancer/mod_proxy_ajp and mod_jk.




Perfect. After all you have created most of the stuff,
so you are more then a welcome :)

Cheers,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Henri Gomez wrote:

Good to see that PING/PONG got such a good response here.

When I added this to mod_jk it was just a quick way to detect hang
JVMs but it seems to many on the TC-DEV not a very usefull feature :)



And may thanks for such a great idea Henri ;)
Actually its a great way to detect all those
busy/broken/hanged/disconnected servers.

I'm not sure how we could add that feature to the
http/https protocol, the Rudiger suggested.

Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Henri Gomez]

2006/6/19, Mladen Turk [EMAIL PROTECTED]:

Henri Gomez wrote:
 Good to see that PING/PONG got such a good response here.

 When I added this to mod_jk it was just a quick way to detect hang
 JVMs but it seems to many on the TC-DEV not a very usefull feature :)


And may thanks for such a great idea Henri ;)
Actually its a great way to detect all those
busy/broken/hanged/disconnected servers.

I'm not sure how we could add that feature to the
http/https protocol, the Rudiger suggested.


Well it's not easy to add this to http since HTTP stack could be
consuming but you could imagine some sort of magic URI handled quickly
by remote Tomcat (at the connector http/ajp side), and have some sort
of timeout associated to this request.

For the load-balancing algorythm, do you plan to propose a bunch of
pre build algos and let users select the right one for their use or
allow externals modules ? We could see that like mod_jk / mod_proxy
modules like apache modules  does for HTTP...

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Mladen Turk]

Henri Gomez wrote:


For the load-balancing algorythm, do you plan to propose a bunch of
pre build algos and let users select the right one for their use or
allow externals modules ? We could see that like mod_jk / mod_proxy
modules like apache modules  does for HTTP...



Something like that was suggested by Jim Jagielski more then
a year ago. I think that the problem is that this would be
a module of a module, and something like that was never done
for httpd. Not even sure if its possible.


Regards,
Mladen.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Rainer Jung]

Henri Gomez wrote:


For the load-balancing algorythm, do you plan to propose a bunch of
pre build algos and let users select the right one for their use or
allow externals modules ? We could see that like mod_jk / mod_proxy
modules like apache modules  does for HTTP...


A pluggable balancing strategy sounds nice. What I'm not sure about, if 
the size of problem is big enough to justify the work.


All three existing strategies at the moment are based on the same basic 
principles. All strategies use the same unsigned 64Bit to describe the 
actual load value and there are three possible places where the values 
are adjusted: pre request, post request and during maintenance (called 
in regular intervals).


Busyness: increment pre request, decrement post request, no op during 
maintenance


Traffic and Requests: increment pre request, no op post request, decay 
during maintenance.


Traffic and Requests use different values to increment, Traffic uses the 
amount of bytes transmitted, Requests always increments by one.


So to be able to implement interesting balancing strategies, the plugins 
would need to be able to use request/response data, like performance, 
load, error status etc.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Ruediger Pluem]

On 06/19/2006 10:37 PM, Mladen Turk wrote:
 Henri Gomez wrote:
 

 For the load-balancing algorythm, do you plan to propose a bunch of
 pre build algos and let users select the right one for their use or
 allow externals modules ? We could see that like mod_jk / mod_proxy
 modules like apache modules  does for HTTP...

 
 Something like that was suggested by Jim Jagielski more then
 a year ago. I think that the problem is that this would be
 a module of a module, and something like that was never done
 for httpd. Not even sure if its possible.

Isn't this already the case right now? AFAIK the current lb algorithms are 
provider based.
So you can plug them in. From my understanding you can add further algorithms 
either to mod_proxy_balancer
or you can put them in an separate module that registers them separately.

Regards

Rüdiger

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jim Jagielski]

Rainer Jung wrote:
 
 A pluggable balancing strategy sounds nice. What I'm not sure about, if 
 the size of problem is big enough to justify the work.
 

A lot of it already exists already. That was my whole intent
on the move to LB providers in proxy, and making such things
as finding the best worker be external to the core
code. The next step is to make the actual LB calc algo's
also be such a provider, so that we can simply call
calc_lbstatus and have that external as well :)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jim Jagielski]

Mladen Turk wrote:
 
 Henri Gomez wrote:
  
  For the load-balancing algorythm, do you plan to propose a bunch of
  pre build algos and let users select the right one for their use or
  allow externals modules ? We could see that like mod_jk / mod_proxy
  modules like apache modules  does for HTTP...
  
 
 Something like that was suggested by Jim Jagielski more then
 a year ago. I think that the problem is that this would be
 a module of a module, and something like that was never done
 for httpd. Not even sure if its possible.
 

Actually, the current balancer does provide that, ala DAV and
cache. The actual find best setup allows for submodules
to implement them.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jim Jagielski]

Ruediger Pluem wrote:
 
 +1. Just one thought: I think it would be useful to have this 'health check'
 approach somewhat generic so that we can implement the call to it inside 
 mod_proxy
 and its connection pooling itself (e.g. with providers supplied by schema
 handlers / modules). For AJP this would be CPING/CPONG of course and
 mod_proxy itself could offer a generic TCP connection 'health check' 
 provider that simply
 checks the status of a TCP connection as far as this is possible without
 reading or writing data. This would be a very generic provider. Other 
 protocol
 handlers could define other (better) protocol specific providers and
 just plug them in.
 

Agreed. Making a generic hearbeat interface that could vary depending
on the actual protocol would be v. cool. So for AJP, CPING/CPONG,
for HTTP some sort of generic TRACE (or HEAD)...
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jim Jagielski]

Mladen Turk wrote:
 
 Jim Jagielski wrote:
  
  If this maps what's currently been done in mod_jk, than
  a big +1. It's been on my todo but have simply not
  had the cycles to do.
 
 That is exactly the thing that I'm planing to do.
 During last year there was a lots of good stuff
 added to the mod_jk that have even force some of
 the users used to try to compile and use mod_jk with
 httpd 2.2. IMHO there is no reason why we could
 not port all that good stuff. It's on my TODO list,
 and I'm glad to hear that you guys have the same
 thoughts. Perhaps I could explain all that to the
 much wider audience in Austin this September ;) ?
 

++1 ;)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Ruediger Pluem]

On 06/19/2006 10:23 PM, Mladen Turk wrote:
 Henri Gomez wrote:
 
 Good to see that PING/PONG got such a good response here.

 When I added this to mod_jk it was just a quick way to detect hang
 JVMs but it seems to many on the TC-DEV not a very usefull feature :)

 
 And may thanks for such a great idea Henri ;)
 Actually its a great way to detect all those
 busy/broken/hanged/disconnected servers.
 
 I'm not sure how we could add that feature to the
 http/https protocol, the Rudiger suggested.

To be honest I currently have no generic idea how to do this without
support from the backend. My point was more about that I would love
to see this health check integrated into the generic code of mod_proxy
and its connection pooling and let the protocol modules provide the code
that actually does the dirty work of the protocol specific aspects of such a
health check. This would make it easy to add health checks for other protocols
/ add better ones for protocols with existing ones. As said currently I would
only see two health check providers:

- CPING/CPONG for AJP.
- A generic TCP connection check.

But this would be open to further bright ideas.

Regards

Rüdiger

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Jim Jagielski]

Ruediger Pluem wrote:
 
 On 06/19/2006 10:37 PM, Mladen Turk wrote:
  Henri Gomez wrote:
  
 
  For the load-balancing algorythm, do you plan to propose a bunch of
  pre build algos and let users select the right one for their use or
  allow externals modules ? We could see that like mod_jk / mod_proxy
  modules like apache modules  does for HTTP...
 
  
  Something like that was suggested by Jim Jagielski more then
  a year ago. I think that the problem is that this would be
  a module of a module, and something like that was never done
  for httpd. Not even sure if its possible.
 
 Isn't this already the case right now? AFAIK the current lb algorithms are 
 provider based.
 So you can plug them in. From my understanding you can add further algorithms 
 either to mod_proxy_balancer
 or you can put them in an separate module that registers them separately.
 

That's right. I used the DAV/cache scenario when designing the
provider impl in the balancer.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer/mod_proxy_ajp TODO

[Henri Gomez]

Important point in load balancing will be to collect CPU load (job
load) from the remote.
We often make the mistake to split requests between servers as if it
cost the same CPU power (or cpu load) for each of them, but in Java /
J2EE some requests could be more CPU/IO/DB consuming than others.



2006/6/19, Jim Jagielski [EMAIL PROTECTED]:

Ruediger Pluem wrote:

 On 06/19/2006 10:37 PM, Mladen Turk wrote:
  Henri Gomez wrote:
 
 
  For the load-balancing algorythm, do you plan to propose a bunch of
  pre build algos and let users select the right one for their use or
  allow externals modules ? We could see that like mod_jk / mod_proxy
  modules like apache modules  does for HTTP...
 
 
  Something like that was suggested by Jim Jagielski more then
  a year ago. I think that the problem is that this would be
  a module of a module, and something like that was never done
  for httpd. Not even sure if its possible.

 Isn't this already the case right now? AFAIK the current lb algorithms are 
provider based.
 So you can plug them in. From my understanding you can add further algorithms 
either to mod_proxy_balancer
 or you can put them in an separate module that registers them separately.


That's right. I used the DAV/cache scenario when designing the
provider impl in the balancer.
--
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer connection pool limitation problem

[Ruediger Pluem]

On 04/02/2006 04:46 PM, Bjørn Stabell wrote:

 
 VirtualHost *:80
 ProxyPass   /zope   http://192.168.0.242:7680/  
 max=2 timeout=1 acquire=1 ttl=1
 /VirtualHost
 
 I'm using mpm-worker, both machines are Linux machines.
 
 I thought Apache would make no more than 2 connections to the backend 
 server, but lsof on the backend server shows something else:

The cache limit is per httpd process. How many httpd processes are running?
What mpm are you using?
Can you check if there are really more than 2 connections per httpd process
on the frontend?

 
 # lsof -i :7680 | wc -l
 121

Are you sure that all of these connections are established? Could you also check
netstat -an | egrep :7680.*ESTABLISHED?

Regards

Rüdiger

Re: mod_proxy_balancer connection pool limitation problem

[Bjørn Stabell]

Hi Ruediger,

On Apr 2, 2006, at 22:54, Ruediger Pluem wrote:

On 04/02/2006 04:46 PM, Bjørn Stabell wrote:

VirtualHost *:80
ProxyPass   /zope   http://192.168.0.242:7680/   
max=2 timeout=1 acquire=1 ttl=1

/VirtualHost

I'm using mpm-worker, both machines are Linux machines.

I thought Apache would make no more than 2 connections to the backend
server, but lsof on the backend server shows something else:


The cache limit is per httpd process. How many httpd processes are  
running?

What mpm are you using?
Can you check if there are really more than 2 connections per httpd  
process

on the frontend?


# lsof -i :7680 | wc -l
121


Are you sure that all of these connections are established? Could  
you also check

netstat -an | egrep :7680.*ESTABLISHED?


I'm running mpm-worker with config:

IfModule mpm_worker_module
StartServers  2
MaxClients   128
MinSpareThreads  25
MaxSpareThreads  75
ThreadsPerChild  64
MaxRequestsPerChild   0
/IfModule


# /nb/apache-2.2/bin/httpd -l
Compiled in modules:
  core.c
  worker.c
  http_core.c
  mod_so.c


This should give 2 processes, each with 64 threads, right?  At the  
peak, 64 connections are established with the backend:


# netstat -an | egrep :7680.*ESTABLISHED | wc -l
64


Btw, since the number of processes is rather indirect with the advent  
of mpm-worker, and since most people would be most interested in  
limiting the total number of connections to the backend (to spare the  
backend), wouldn't it make more sense to limit the total number?


Btw2, it wasn't very clear from the docs at http://httpd.apache.org/ 
docs/2.2/mod/mod_proxy.html that they were per-process maximums.  I  
think most people will read Apache will never create more than the  
Hard Maximum or max connections to the backend server. as meaning  
max across all processes and threads.


Rgds,
Bjorn

Re: mod_proxy_balancer connection pool limitation problem

[Ruediger Pluem]

On 04/02/2006 05:16 PM, Bjørn Stabell wrote:

 
 IfModule mpm_worker_module
 StartServers  2
 MaxClients   128
 MinSpareThreads  25
 MaxSpareThreads  75
 ThreadsPerChild  64
 MaxRequestsPerChild   0
 /IfModule
 
 
 # /nb/apache-2.2/bin/httpd -l
 Compiled in modules:
   core.c
   worker.c
   http_core.c
   mod_so.c
 
 
 This should give 2 processes, each with 64 threads, right?  At the 
 peak, 64 connections are established with the backend:

correct.

 
 # netstat -an | egrep :7680.*ESTABLISHED | wc -l
 64

Ok, yes there had been some problems with this limit. They should be fixed with 
2.2.1.
Could you give the tar ball that Paul rolled a try or wait until the release of 
2.2.1?

 
 
 Btw, since the number of processes is rather indirect with the advent 
 of mpm-worker, and since most people would be most interested in 
 limiting the total number of connections to the backend (to spare the 
 backend), wouldn't it make more sense to limit the total number?

The total number is actually limited by maximum number of processes * max 
parameter for backend,
but I admit that this should be documented more clearly. And on worker MPM
maximum number of processes  = MaxClients / ThreadsPerChild + 1.

I guess what you have in mind is a global cache over the different processes.
I think this would require a major refactoring of the proxy code and would make
things more complex and error prone for comparable little gain.

Regards

Rüdiger

Re: mod_proxy_balancer / failover (hot standby)

[Ruediger Pluem]

On 02/28/2006 05:46 PM, [EMAIL PROTECTED] wrote:
 Hello,
 
 I´d like to restart the thread
 http://www.gossamer-threads.com/lists/apache/dev/305214

Thanks for starting this again. I also lost track of it.


 
 Please let me know if I just missed a correct config - otherwise I am curious 
 to hear what you think and if you perhaps can provide another fix...?

No you did not miss the correct config. Currently it does not work without the 
patch attached somewhere in

http://www.gossamer-threads.com/lists/apache/dev/305214

One further obstacle is that it seems to me that even with the patch it does 
not do a failover if you do
not already have a session. So some broader changes are actually needed.

I hope (and hoped) to get some feedback by other developers on this issue to 
clarify the definition of 'disabled'.
Once this is done we can go into the details about how to implement this.


Regards

Rüdiger

Re: mod_proxy_balancer: how to define failover (only)/hot standby behavior?

[Jim Jagielski]

Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.

A sort of warm standby is something that I had planned to
work into the balancer code post 2.2.1.

On Jan 24, 2006, at 11:14 AM, [EMAIL PROTECTED] wrote:


Hello,

using Apache 2.2.0/mod_proxy_balancer, is it possible to configure a
proxy balancer with two balancer members, where one of the two only  
gets

the requests, if the other one fails?

In mod_jk that was possible using local_worker_only, but with
mod_proxy_balancer I have not yet understood how to define such  
behavior

(defining loadfactor=0 would be a way, probably working right away,
but is definded to be a number between 1 and 100).

As far as I understand at the moment, it is only possible to define an
almost-only-hot-standby-behavior, where the failover-backend gets
1/100 of all requests..

Thanks in advance and best regards,
Andreas

P.S.: I posted the question to the apache-httpd-users mailing list 3
days ago, but it seems to fit better to here..I would post the answer
there, if I got one here.

Dieses Dokument ist vertraulich und ausschliesslich fuer den  
Adressaten bestimmt. Falls Sie diese E-Mail versehentlich bekommen  
haben, informieren Sie uns bitte unverzueglich und loeschen Sie  
diese Nachricht von Ihrem Computer. Jegliche Art von Reproduktion,  
Verbreitung, Vervielfaeltigung, Modifikation, Verteilung und/oder  
Publikation dieser E-Mail Nachricht ist untersagt.
Die in dieser E-Mail enthaltenen Angaben und Erklaerungen sind  
unverbindlich. Haftungsansprueche des Empfaengers jeglicher Art  
werden ausgeschlossen. Die GZS schliesst ausser fuer den Fall von  
Vorsatz oder grober Fahrlaessigkeit die Haftung fuer jeglichen  
Verlust oder Schaeden durch virenbefallene Software oder E-Mails aus.
-- 
-
This message contains confidential information and is intended only  
for the named individual. If you are not the named addressee, you  
should not disseminate, distribute or copy this e-mail. Please  
notify the sender immediately by e-mail if you have received this  
message in error and delete this e-message from your system.
No reliance may be placed on this message without written  
confirmation of its contents from an authorized representative. GZS  
accepts no liability for loss or damage caused by software viruses  
except in case of gross negligence or willful behaviour.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_proxy_balancer: how to define failover (only)/hot standby behavior?

[Mladen Turk]

Jim Jagielski wrote:

Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.

A sort of warm standby is something that I had planned to
work into the balancer code post 2.2.1.



Like said earlier.

Hot standby already works with mod_proxy balancer.
The 'hot standby' BalancerMember must be initially 'disabled'.
Other members must have 'redirect' option set to the name of
'hot standby' member.

The thing we would need to backport from mod_jk 1.2.14+ is
hot-standby to 'domain'.


Regards,
Mladen.

Re: mod_proxy_balancer: how to define failover (only)/hot standby

[Jim Jagielski]

Mladen Turk wrote:
 
 Jim Jagielski wrote:
  Actually, dev@httpd.apache.org is best, since that is where
  the development of this module is being done. I have changed
  the email headers accordingly.
  
  A sort of warm standby is something that I had planned to
  work into the balancer code post 2.2.1.
 
 
 Like said earlier.
 
 Hot standby already works with mod_proxy balancer.
 The 'hot standby' BalancerMember must be initially 'disabled'.
 Other members must have 'redirect' option set to the name of
 'hot standby' member.
 

As I understand it, this is ajp specific though, isn't
it (it's been awhile since I look at that section - iirc
it's tied into session support)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer: how to define failover (only)/hot standby

[Mladen Turk]

Jim Jagielski wrote:

Mladen Turk wrote:

Jim Jagielski wrote:

Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.

A sort of warm standby is something that I had planned to
work into the balancer code post 2.2.1.


Like said earlier.

Hot standby already works with mod_proxy balancer.
The 'hot standby' BalancerMember must be initially 'disabled'.
Other members must have 'redirect' option set to the name of
'hot standby' member.



As I understand it, this is ajp specific though, isn't
it (it's been awhile since I look at that section - iirc
it's tied into session support)



No. It works with any protocol.

Proxy balancer://mycluster
  BalancerMember ajp://hotstandby status=disabled
  BalancerMember ajp://node1 redirect=hotstandby
  BalancerMember ajp://node2 redirect=hotstandby
  ...
  BalancerMember ajp://nodeN redirect=hotstandby
/Proxy

The only problem is that it's not documented ;)

Regards,
Mladen.

Re: mod_proxy_balancer: how to define failover (only)/hot standby

[Jim Jagielski]

On Jan 24, 2006, at 12:18 PM, Mladen Turk wrote:


Jim Jagielski wrote:

Mladen Turk wrote:

Jim Jagielski wrote:

Actually, dev@httpd.apache.org is best, since that is where
the development of this module is being done. I have changed
the email headers accordingly.

A sort of warm standby is something that I had planned to
work into the balancer code post 2.2.1.


Like said earlier.

Hot standby already works with mod_proxy balancer.
The 'hot standby' BalancerMember must be initially 'disabled'.
Other members must have 'redirect' option set to the name of
'hot standby' member.


As I understand it, this is ajp specific though, isn't
it (it's been awhile since I look at that section - iirc
it's tied into session support)


No. It works with any protocol.

Proxy balancer://mycluster
  BalancerMember ajp://hotstandby status=disabled
  BalancerMember ajp://node1 redirect=hotstandby
  BalancerMember ajp://node2 redirect=hotstandby
  ...
  BalancerMember ajp://nodeN redirect=hotstandby
/Proxy

The only problem is that it's not documented ;)



Hmm... I thought that this happened via the code
in find_session_route() and relied on sticky sessions;
but again iirc they can be via cookies as well.
So one issue is that stickysession must be used, I think.

Re: mod_proxy_balancer: how to define failover (only)/hot standby

[Mladen Turk]

Jim Jagielski wrote:




The only problem is that it's not documented ;)



Hmm... I thought that this happened via the code
in find_session_route() and relied on sticky sessions;
but again iirc they can be via cookies as well.
So one issue is that stickysession must be used, I think.



Right. Also if the sessions are not replicated it makes no
sense to have hot-standby, cause the user will have to
login again.

find_session_route will check for 'redirect' if all other nodes
are unusable (in error or stopped) and make a failover.

Regards,
Mladen.

Re: mod_proxy_balancer: how to define failover (only)/hot standby

[Jim Jagielski]

Mladen Turk wrote:
 
 Jim Jagielski wrote:
  
 
  The only problem is that it's not documented ;)
 
  
  Hmm... I thought that this happened via the code
  in find_session_route() and relied on sticky sessions;
  but again iirc they can be via cookies as well.
  So one issue is that stickysession must be used, I think.
 
 
 Right. Also if the sessions are not replicated it makes no
 sense to have hot-standby, cause the user will have to
 login again.
 
 find_session_route will check for 'redirect' if all other nodes
 are unusable (in error or stopped) and make a failover.

Yes, assuming a sticky session has been setup. For HTTP, though,
having hot-standby even without sessions makes a lot of
sense in a lot of cases (think of something like images.foo.com
which handles static images). The rub there is, I think, that
this relies on forcing HTTP cookies on all HTTP servers
in the balancer, instead of having the logic itself
contained totally (as much as possible) in the balancer
code (eg, afaik, we look for the cookie but we don't
set it anyplace). That's what I meant by looking into this
post 2.2.1; having a sort of 'standby' condition, in addition
to enabled and disabled.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.

Re: mod_proxy_balancer: how to define failover (only)/hot standby

[Jim Jagielski]

On Jan 24, 2006, at 12:52 PM, Jim Jagielski wrote:

 That's what I meant by looking into this
post 2.2.1; having a sort of 'standby' condition, in addition
to enabled and disabled.


The main reason, of course, is to abstract out a concept
of sessions from the balancer code; Apache (D :) )
should be protocol insensitive as the proxy code should
be as generic as possible, and some protocols lack
any sort of session information and want/need
simply failover.