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, e-mai
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: users@t
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 t
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 cognizan
> 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
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
> 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
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 durat
> 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
> Mark Thomas said:
>
> 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.
That's the key point, also I am under the impression th
Caldarale, Charles R wrote:
>> 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
> 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 sco
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
>> sa
Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:[EMAIL PROTECTED]
>> Subject: Re: Multi processor issue
>>
>> This requirement will be enforceable in 5.5.21 onwards. It was
>> implemented in response to
>> http://issues.apache.org/bugzilla/show_bug.
> From: Mark Thomas [mailto:[EMAIL PROTECTED]
> Subject: Re: Multi processor issue
>
> This requirement will be enforceable in 5.5.21 onwards. It was
> implemented in response to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34956
Does the change in 5.5.21 address the
Leon Rosenberg wrote:
> BINGO :-)
>
> Please check the servlet spec 2.5, SRV 8.2
>
> 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."
>
> Please note that the last paragraph. I assume
> 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&#x
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gael,
Marziou, Gael wrote:
> So, we see that the problems occurs between
> ProxySessionController.forwardRequest() and the first line of
> PassThroughController.doHttp(). In fact we can go down to
> PassThroughController.doGet() as it is just directly
> 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 gues
Some fresh news and hopefully I have narrowed the scope enough to get
the root cause.
First, the previous traces that I posted last week were wrong because my
bug catcher was buggy: I forgot to reset the fields in recycle().
So, I fixed this and saved few other fields in
org.apache.catalina.conne
-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 th
/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: Chris
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).
-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
> 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 i
-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 initializ
> From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
> It's not really, IF you take time to read the specs - but few do.
> Admittedly, there are a lot of things that should be studied, and
> project deadlines rarely take that into account.
And budgets, and hence project staffing (and skill) lev
arles R [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 13 December 2006 3:36 PM
To: Tomcat Users List
Subject: RE: Multi processor issue
> From: JiaDong Huang [mailto:[EMAIL PROTECTED]
> Subject: RE: Multi processor issue
>
> What I have been saying is that we should reconsider very
>
> 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
> q
l has
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
Users List'"
Sent: 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
> 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 proces
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 wit
> 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
tr
> 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
>
> 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
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 thre
> 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
> 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 remain
-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
-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. Befo
Message-
From: JiaDong Huang [mailto:[EMAIL 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, withi
Subject: RE: Multi processor issue
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
[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 actual
> 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", b
-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 mach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dong,
JiaDong Huang wrote:
> Let's step back and see the whole picture, more widely. Let's presume
> the symptom as: the company's Web developers have done the same test
> with MT on single CPU and nothing wrong found. And the issue only
> happens wit
> 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)
> 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" - threa
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]
> 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'
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 PROTEC
> 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 t
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, we
> 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 some
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
;
o:[EMAIL 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 al
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 msvcr
> 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 be
> 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.
> D
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
> 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 sh
> 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 obj
-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
: 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 it be that
for tomcat
:-)
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(
> > HttpEventC
concurrently and both calls comes through to the Request object? That
would be a clear synchronization issue and pretty typical for tomcat
:-)
regards
Leon
On 12/8/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> From: Marziou, Gael [mailto:[EMAIL PROTECTED]
> Subject: RE: Multi pro
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
> 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 code is the source of the
second thread.
> Can you post the stack trace for that IllegalStateException?
Sure but that's only one of the symptoms we got.
I don't remember if the stack traces below were taken on 5.5.18 or
5.5.20 after we upgraded but as far as I know this part of the code was
not changed.
java.lang.IllegalStateException:
> could you tell me 32-bit or 64-bit OS, service pack levels, and what
the hardware is?
Peter, I'm not sure it will help you, the only advice I can give you is
to test on same configuration as your future production environment.
We knew it from the beginning but were not listened.
Windows 200
-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
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 wer
> 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 J
Gael" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
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
w
> 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
>
> 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 pac
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 workaround.
However, our experience could help others or someone may have other
ideas.
We have recently switched a stable web a
79 matches
Mail list logo
