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
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
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
Dong, I'm not sure I understand your suggestion, I attached below my bug
catcher in org.apache.catalina.connector.Request.
Do you mean I should add a delay before the while loop to increase the
length of the critical section?
What do you mean by yelding the CPU (sorry I'm French) ?
Gael
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
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
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
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
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
First, to clarify in my message, I did put 2 stack traces of 2
independent errors.
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.
HttpEventContextObject.getParameter() does just extract the
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
Hello,
Tomcat5.exe from 5.5.20 is half the size of 5.5.17 but I can't find any
change mentioned in Tomcat's change log page.
Is there a place to find out what has changed?
Thanks,
Gael
-
To start a new topic, e-mail:
the procrun monitor GUI.
Best regards,
Gael
-Original Message-
From: Mladen Turk [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 16, 2006 6:43 PM
To: Tomcat Users List
Subject: Re: Tomcat5.exe from 5.5.20 is half the size of 5.5.17, any
change log to read?
Marziou, Gael wrote:
Hello
14 matches
Mail list logo
