Thanks Mark.
Gael
Mark Thomas wrote:
In 5.5.21 onwards, the RD will be thread safe so the OP's code should
work without modification.
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe,
Mark Thomas wrote:
I plan to look at modifying the current RD code over the holiday.
In 5.5.21 onwards, the RD will be thread safe so the OP's code should
work without modification.
Mark
-
To start a new topic, e-mail:
Can you suggest a fix? I'm not sure how this kind of thing
could be safely veto'd... for instance, it might actually be
appropriate for a RequestDispatcher to be re-used in some
context (say, repeating a request twice) or even to do so
with different threads, as long as the access is
Caldarale, Charles R wrote:
Since query information is normally unique to a request, I think the
above could be construed that the RequestDispatcher is cognizant of the
query string. If so, each RequestDispatcher would be associated with a
specific request.
I agree that the RD is cognizant
Gael,
Marziou, Gael wrote:
Can you suggest a fix? I'm not sure how this kind of thing
could be safely veto'd... for instance, it might actually be
appropriate for a RequestDispatcher to be re-used in some
context (say, repeating a request twice) or even to do so
with different threads,
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Subject: Re: Multi processor issue
I have re-read the sections of the spec you quoted several times and I
don't see anything that suggests to me that the RequestDispatcher has
only request level scope that would suggest the OPs use is invalid
Chuck,
Caldarale, Charles R wrote:
Parameters specified in the query string used to create the
RequestDispatcher take precedence over other parameters of the same name
passed to the included servlet. The parameters associated with a
RequestDispatcher are scoped to apply only for the duration
I don't think this is a bug in TC's implementation. This is a
relatively subtle mistake that seems both easy enough to make
and easy to fix.
Maybe Tomcat should enforce this like for instance when we get an
exception trying to write into a response that was already committed.
It would have
Gael,
Marziou, Gael wrote:
I don't think this is a bug in TC's implementation. This is a
relatively subtle mistake that seems both easy enough to make
and easy to fix.
Maybe Tomcat should enforce this like for instance when we get an
exception trying to write into a response that was
By looking at the code of ApplicationDispatcher, I would tend to think
that
the answer is no because of fields like wrapRequest and requestURI
(there
are other fields but they are unused) however the javadoc does not
mention it.
I forgot to include the question but some of you may have
BINGO :-)
Please check the servlet spec 2.5, SRV 8.2
To use a request dispatcher, a servlet calls either the include
method or forward
method of the RequestDispatcher interface. The parameters to these methods can
be either the request and response arguments that were passed in via the service
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: Re: Multi processor issue
The Container Provider should ensure that the dispatch of the
request to a target servlet occurs in the same thread of the
same JVM as the original request.
I'm not sure the above is really pertinent
Caldarale, Charles R wrote:
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: Re: Multi processor issue
The Container Provider should ensure that the dispatch of the
request to a target servlet occurs in the same thread of the
same JVM as the original request.
I'm not sure
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Subject: Re: Multi processor issue
What about RequestDispatcher ServletContext.getNamedDispatcher(String)
Since this method is at the Context level, any RequestDispatcher
obtained effectively has context wide scope. It is this method
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
Caldarale, Charles R wrote:
From: JiaDong Huang [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
Not sure if the app really cares which thread should do the
parameterMap initialization.
You're missing the entire point
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: [OT] Multi processor issue
In that case, the OP could wrap their own request objects to actually
prevent their bug in production while researching it in dev/test,
The problem with doing so in this case is that while it might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: [OT] Multi processor issue
In that case, the OP could wrap their own request objects to actually
prevent their bug in production while
On 12/13/06, Christopher Schultz [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
Slightly off-topic, there was a bug filed against the session manager
where a session use counter was being used in a non-threadsafe way
(and /really/ needed to be synchronized). The
/testing.
Dong
-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Sent: Thursday, 14 December 2006 3:13 AM
To: Tomcat Users List
Subject: Re: [OT] Multi processor issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
Caldarale, Charles R wrote:
From: Christopher
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dong,
JiaDong Huang wrote:
Since the Request Object usage has already been stated in the spec. Maybe
Tomcat can have certain JSP verification tool. Is any thing like that
available? Or it is not possible to do technically at all. Maybe it can that
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, 12 December 2006 2:29 AM
To: Tomcat Users List
Subject: RE: [OT] Multi processor issue
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: [OT] Multi processor issue
There is an OS called Clouds where threads could actually
migrate between
PROTECTED]
Sent: Tuesday, December 12, 2006 10:42 AM
To: 'Tomcat Users List'
Subject: RE: Multi processor issue
Gael,
If you can build the Tomcat code/component, put in time delay code and
also yield the CPU, within the ParameterMap initialization procedure.
Dong
-Original Message-
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 12 December 2006 9:21 PM
To: Tomcat Users List
Subject: RE: Multi processor issue
Do you mean I should add a delay before the while loop to increase the
length of the critical section?
Yes. Before
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dong,
JiaDong Huang wrote:
Yes. Before and maybe within the loop. That should get the MT issue
reproduced much easier.
This was a great idea, by the way.
What do you mean by yelding the CPU (sorry I'm French) ?
Yielding the CPU means to let
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Multi processor issue
Thread.yield() will also work. It's unclear which is better from the
API, but I would imagine that a VM implementor would write the
Thread.yield method such that any remaining CPU time is yielded
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
I attached below my bug catcher in
org.apache.catalina.connector.Request.
Looks good to me. I'd be very interested in the results.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
I used sleep() as you can see in the modified version of
getParameterMap() at the end of this message.
I got the issue and here is the trace.
What I call original thread is the one that was the first to call
Requuest.getParameterMap()
Correct me if I am wrong but it seems to me that the 2
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
Correct me if I am wrong but it seems to me that the 2
threads are from Tomcat, not from our application.
They are, but they go through a lot of your application code prior to
reaching getParameterMap().
I'm
Anything dealing with a session must be careful not to expose a
Request object to the session scope, since there's the risk another
request for the same session may get confused with the first - I
suspect that's what's happening here.
Will do.
You should take a careful look at all the
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
I already did at the beginning of our investigation as I suspected the
JNI code but it had no effect.
That's what I thought, but wasn't sure, since at least one of the stack
traces you sent (8 December) had
usage very well. Maybe he can make further
comments/recommendation to the Tomcat dev team.
Dong
-Original Message-
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 13 December 2006 3:24 AM
To: Tomcat Users List
Subject: RE: Multi processor issue
Anything dealing
From: JiaDong Huang [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
Not sure if the app really cares which thread should do the
parameterMap initialization.
You're missing the entire point of this exercise: no Request object
should EVER be processed by more than one thread
: Tuesday, December 12, 2006 7:24 PM
Subject: RE: Multi processor issue
Great to see the bottom of the MT issue has been revealed/understood. I
believe Gael may be able to fix his app now. Hope it can be an easy fix...
Not sure if the app really cares which thread should do the parameterMap
clarified his issue. He may be in a better position to make significant
comments, and see if you can agree.
Dong
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 13 December 2006 11:34 AM
To: Tomcat Users List
Subject: RE: Multi processor issue
From
From: JiaDong Huang [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
What I have been saying is that we should reconsider very
carefully whether there should be any enhancement in Tomcat.
From the Tomcat code you dug out, there is something not
quite perfect, in term of MT
on single CPU environment, the
issue should have been revealed too.
Dong
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Monday, 11 December 2006 3:30 PM
To: Tomcat Users List
Subject: RE: Multi processor issue
From: JiaDong Huang [mailto:[EMAIL PROTECTED
From: JiaDong Huang [mailto:[EMAIL PROTECTED]
I thought they had
done certain code review and did not find any MT safe issue.
They had (and I naively took them at their word), and they didn't find
any such issue. However, as Chuck points out so effectively, we didn't
find any issues isn't
Thanks for all replies, you have convinced me that we should investigate
further.
I propose to implement a bug catcher in Tomcat ParameterMap by storing
the thread that called the constructor amd then check its invariance
when calling other methods (e.g. isLocked) of this class, if the
invariance
From: JiaDong Huang [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
So it is just a case of simple MT issue - multiple threads have
accessed/operated on a class/object that is not MT safe.
I wouldn't label the situation as simple - threading issues frequently
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
I propose to implement a bug catcher in Tomcat ParameterMap by storing
the thread that called the constructor amd then check its invariance
when calling other methods (e.g. isLocked) of this class
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
If you're suggesting that one thread may change its process
association, that is theoretically possible on some OS implementations
(anybody remember Multics?)
There is an OS called Clouds where threads could actually migrate
between
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: [OT] Multi processor issue
There is an OS called Clouds where threads could actually
migrate between machines in a cluster. I suppose the thread
doesn't really migrate, but all of the associated data (or
handles to them) do
From: JiaDong Huang [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
It is a MT issue, but MP specific.
Strictly speaking, it's not MP-specific. If run long enough, the
problem will appear on a single CPU. Its occurrence would require the
first thread to exhaust its CPU time
the affinity 'trick' is a replacement dll for the 80 runtime stock libraries
Well, the one we used does not work this way.
In fact, we started by changing the affinity of Tomcat service's live
process using Windows taskmgr or Windows System Resource Manager.
Then, as problem disappeared,
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
So, I don't believe it's a Tomcat, I would rather think to an H/W, or
JRE or OS issue.
Fascinating - partly because I may hit the same issue soon and partly to
log it on the list for the future, could you tell me 32-bit or 64-bit
OS, service pack
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: Multi processor issue
We have recently switched a stable web application from JRun
4 to Tomcat 5.5.20 on Windows 2003 + Sun's JRE 1.5.0_08,
running some testing for months, but when we moved to
production environment we immediately
PROTECTED]
To: Tomcat Users List users@tomcat.apache.org
Sent: Friday, December 08, 2006 9:22 AM
Subject: Multi processor issue
Hi,
As a preamble, let me say that I am not complaining about Tomcat (as the
problem root cause is uncertain) and I don't expect much assistance as
we are happy with our
From: Martin Gainty [mailto:[EMAIL PROTECTED]
Subject: Re: Multi processor issue
which VM are you using for this test?
Try actually reading the message:
We have recently switched a stable web application from JRun 4 to
Tomcat
5.5.20 on Windows 2003 + Sun's JRE 1.5.0_08
- Chuck
Thanks Chuck for your reply, I only cited part of your message where I
could follow up.
Within Tomcat, request objects are normally processed by a single
thread
at a time, yet you note that two threads are accessing this particular
request - where did the second one come from?
Both were
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gael,
Within Tomcat, request objects are normally processed by a single
thread at a time, yet you note that two threads are accessing this
particular request - where did the second one come from?
Both were web threads and error did occur at the
This is our code and there's no threading here.
-Original Message-
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
Sent: Friday, December 08, 2006 6:31 PM
To: Tomcat Users List
Subject: RE: Multi processor issue
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi
:-)
regards
Leon
On 12/8/06, Caldarale, Charles R [EMAIL PROTECTED] wrote:
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
com.hp.swift.portal.state.HttpEventContextObject.getParameter(
HttpEventContextObject.java:64)
This looks suspicious - perhaps this portal
To: Tomcat Users List
Subject: Re: Multi processor issue
looks like
Request.getParameterMap()
is called twice. The first call locks the request, the second fails.
what exactly does your
com.hp.swift.portal.state.HttpEventContextObject.getParameter(HttpEventC
ontextObject.java:64) ?
Could
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Leon,
Leon Rosenberg wrote:
ApplicationHttpRequest.parseParameters isn't synchronized...
thats probably the source of your evil.
That should not really be an issue... the real problem is that it
appears that he has two threads accessing this code
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
This is our code and there's no threading here.
Does the full stack trace show where the threads originated? You appear
to have given us only a partial of each error.
Is the request object stored in any
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
Tomcat does not synchronize before locking the map but that should not
be an issue because the request is guaranteed to be processed by only
one thread.
But the evidence seems to show two threads
On 12/8/06, Caldarale, Charles R [EMAIL PROTECTED] wrote:
From: Marziou, Gael [mailto:[EMAIL PROTECTED]
Subject: RE: Multi processor issue
Tomcat does not synchronize before locking the map but that should not
be an issue because the request is guaranteed to be processed by only
one thread
Does the full stack trace show where the threads originated?
You appear to have given us only a partial of each error.
OK, see below.
Is the request object stored in any session or global structure?
No.
Could another thread have found it there and picked it up erroneously?
No.
Do
But the evidence seems to show two threads are manipulating the same
request, otherwise you wouldn't get the error on the ParameterMap.
Does a full thread dump show any threads that aren't part of the set
started by Tomcat?
either that, or a Request is reused before recycle() has been
the affinity 'trick' is a replacement dll for the 80 runtime stock libraries
The individual most familiar with interfacing to the runtime is mladen turk
I would make all attempts to ping him on the solution
As a comparison between the 2 dlls
Here are the binary characteristics of the stock
PROTECTED]
Sent: Saturday, 9 December 2006 6:18 AM
To: Tomcat Users List
Subject: Re: Multi processor issue
the affinity 'trick' is a replacement dll for the 80 runtime stock libraries
The individual most familiar with interfacing to the runtime is mladen turk
I would make all attempts to ping him
After the request parameters are parsed, Tomcat makes it's parameter map
read-only (i.e. locked). I suspect that this is the source of your
problems. Having said that, if you really do have two threads accessing a
Request instance, then you really really need to re-design your application
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
63 matches
Mail list logo
