> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bill Barker
> Subject: Re: Multi processor issue
> 
> After the request parameters are parsed, Tomcat makes it's 
> parameter map read-only (i.e. "locked").

This is true, but it's not a simple case of someone calling put() after
locking the ParameterMap.  Here's the code of interest
(org.apache.catalina.connector.Request):

1015    public Map getParameterMap() {
1017        if (parameterMap.isLocked())
1018            return parameterMap;
1020        Enumeration enumeration = getParameterNames();
1021        while (enumeration.hasMoreElements()) {
1022            String name = enumeration.nextElement().toString();
1023            String[] values = getParameterValues(name);
1024            parameterMap.put(name, values);
1025        }
1027        parameterMap.setLocked(true);
1029        return parameterMap;
1031    }

The stack trace shows the failed call to put() being made from line
1024.  In order to get this far, the test for isLocked() at line 1017
must have returned false.  In other words, the locked state of the
ParameterMap associated with this request changed between lines 1017 and
1024.  Since locked isn't set until line 1027 (and that appears to be
the only place in Tomcat that does so), some thread other than the one
in the stack trace must have changed the state by coming through this
code simultaneously.  Restricting Tomcat to a single CPU almost
completely precludes that from ever happening.  (But if left running
long enough - possibly years - the situation could still occur with a
single CPU, when one thread's time slice expired between lines 1020 and
1025, and whatever second thread is also erroneously processing the same
Request object starts running.  Contrary to what another poster stated,
this is definitely a multi-thread issue, not a multi-processor one.)

If hardware or OS infrastructure were the cause, I would expect that to
manifest itself in more ways than just this one particular situation in
Tomcat.  If it were my system, I'd be adding some trap code to mark a
Request object as taken when a thread starts processing it, and verify
that a request isn't already taken when a thread starts processing it.
Unfortunate that the OP's company seems to have lost interest in fixing
what appears to be a bona fide problem in their application.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to