Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 38227]  - AJP proxy not thread-safe?
In-Reply-To: <bug-38227-7868@http.issues.apache.org/bugzilla/>
Message-Id: <20060410234034.A54076ACA9@ajax.apache.org>
Date: Tue, 11 Apr 2006 00:40:34 +0100 (BST)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38227>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38227


------- Additional Comments From jim.robinson@stanford.edu  2006-04-11 00:40 -------
Created an attachment (id=18055)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18055&action=view)
make mod_proxy_balancer init_balancer_member call ap_proxy_initialize_worker

(In reply to comment #13)
>
> As mentioned, this possibly works as designed. This depends on your MPM
settings.
> 
> > 
> > From this first pass, it looks to me like 2.2.1 fixes the problem I was
> 
> Sounds good. Please let me know the results if you do more intense tests.

Hi,

I've done some more testing, and I *think* I may have found a bug with
the load balancer.  I am running httpd 2.2.1, with server/thread
limits of

  StartServers 8
  ServerLimit 16
  ThreadsPerChild 64

I allowed for 1024 threads on the Tomcat side.	The proxy setup is the
same as I mention in comment #9.

When I was initially load testing the 2.2.1 server, I happened to be
setting the max attributes on the balancer:

  <Proxy balancer://tomcat>
    BalancerMember ajp://server.mydomain.org:8009 route=server.mydomain.org
max=64
  </Proxy>

This seemed rock solid, I threw batches of 500+ concurrent requests
from our Sun Fire T2000 to this linux server, and it dealt with the
load.

However, I then tried removing the 'max' attribute, and ran into some
problem.  I found that, without the hard-coded the max attribute, I
could reliably lock the system up when throwing 500 concurrent
requests at it.

My understanding from previous comments and the notes is that, if one
does not specify additional attributes, the defaults should be to use
the ThreadsPerChild to set s/max:

  smin=0  smax=64 max=64

Setting LogLevel to debug I saw that mod_proxy code says

[debug] proxy_util.c(1690): proxy: initialized worker 0 in child 15926 for
(argo02.highwire.org) min=0 max=64 smax=64
[debug] proxy_util.c(1690): proxy: initialized worker 2 in child 15926 for (*)
min=0 max=64 smax=64

But that it never said it had initialized worker 1.  Adding my own
debugging, I can see that 'worker 1' is the one which is being used by
the balancer, and that the 'worker 1' hmax was always 0 *if I did not
set the 'max=64' attribute.*  In other words, it was never inheriting
the 'default' hmax.

Delving into the mod_balancer code, I found that

  mod_proxy_balancer.c:77
  init_balancer_member(proxy_server_conf *, server_rec *, proxy_balancer *)

was running

  ap_proxy_initialize_worker_share(conf, workers, s);

but was not running, as far as I could tell, anything which might
initialize all the other fields for the worker.  Is this a bug?

I noted that mod_proxy.c:1867 and mod_proxy.c:1868 performs a two-step
initialization, where it calls ap_proxy_initialize_worker_share and
then it calls

 ap_proxy_initialize_worker(workers, s);

Now, I don't know if this lack of a two-step initialization in
mod_proxy_balancer is a problem (or if it just a lack of understanding
of the code on my part), but I am finding that adding the second
initialization call to init_balancer_member seemed to fix the problem
for me (the default, ThreadsPerChild based, hmax was picked up for
worker 1).

Any thoughts?

Thank you for your time,

Jim


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org