Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <013801c3638b$9dba6bb0$ec66a8c0@bbarkerxp>
From: "Bill Barker" <wbarker@wilshire.com>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
References: <DE431F295862C24B8A5126CD96D5587D025AFD61@MAIL>
Subject: Re: [j-t-c] Thread problem in jk_uri_worker_map.c
Date: Fri, 15 Aug 2003 17:16:19 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1060992924-17237-315"

------------=_1060992924-17237-315
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

The easiest solution would be to change the map_uri_to_worker contract to be
that the uri parameter is modifiable.  Then Apache can dup it using the
request's pool, it looks like IIS is doing this most of the time anyway, and
Netscape isn't using map_uri_to_worker at all.  That leave Domino, which I
don't really know.


----- Original Message -----
From: "Marc Saegesser" <Marc.Saegesser@apropos.com>
To: <Tomcat-dev@jakarta.apache.org>
Sent: Friday, August 15, 2003 3:11 PM
Subject: [j-t-c] Thread problem in jk_uri_worker_map.c


I've run into a threading problem in
/j-t-c/native/jk/common/jk_uri_worker_map.c.  The problem has been around
for a long time, but I believe the changes checked in for version 1.15 on
June, 27, 2003 made the problem worse.  I have only been able to reproduce
the problem on multi-processor machines running under a fairly heavy load.
Unfortunately, I don't have a good solution, yet.

The worker map contains a temp pool (jk_uri_worker_map.tp) that is used in
the map_uri_to_worker() function.  The temp pool is used to store a copy of
the incoming URI so that it can be altered to remove any jsessionid and to
remove multiple adjacent / characters.

The problem is that this single pool is shared by all the worker threads so
if multiple threads are executing map_uri_to_worker() simultaneously there
is a chance that the pool will get corrupted.  This can happen in two ways.
The jk_pool code is not thread safe so the internal state of the pool may be
corrupted.  Second, the map_uri_to_worker() function always calls
jk_pool_reset() after mapping the URI.  This means that if multiple URIs did
get allocated into the pool without corruption, when the first thread
finishes it will reset the pool.  This may not create a noticeable problem
because the memory in the pools isn't overwritten by a reset.  If the other
threads finish before another thread enters map_uri_to_worker() then nothing
will fail.  However, if another thread does enter map_uri_to_worker() then
its call to jk_pool_strdup() will overwrite some of the previous contents of
the pool and really bad things may happen.

As I said, I don't have a solution, yet.  Any solution would have to be
platform independent and also work with all the Web servers that use the JK
plugin (e.g. Apache 1.3, Apache 2.0, ISAPI, Netscape, ...).

Suggestions?

-- Marc


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


------------=_1060992924-17237-315
Content-Type: text/plain; name="disclaimer.txt"
Content-Disposition: inline; filename="disclaimer.txt"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.411 (Entity 5.404)

This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.

------------=_1060992924-17237-315--