RE: response.reset() and forward() ... problematic? DBCP related?
Thanks for the nice feed-back Anthony.
And Antonio, just for the record, the snipplet:
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req, HttpServletResponse
res) {
[...]
}
}
IS thread safe, since only method variables are used (which actually are copied for
every thread).
-Original Message-
From: Anthony Presley [mailto:[EMAIL PROTECTED]
Sent: 12 2003 . 18:33
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Thanks for your help everyone . after some number of hours of work yesterday, I
managed to get everything changed over, and I'm NOT using the SingleThreadModel. I
inherited part of the code, and wrote most of the rest a couple of perl scripts
was able to help significantly.
Long and the short, was we were trying to get away with an OOP design, in which all of
our servlets derived from a single class (which in turn, implements HttpServlet), so
that our forward(), logging, and erroring methods could be easily implemented. In
doing so, you were all correct, we were over-writing our own variables.
On Wednesday I upgraded to the latest DBCP and Commons Pool, as well as the latest
JDBC driver for our vendor, reducing the number of those errors from an enormous 760
to 220. Today, thus far, we've had a total of 10 errors, only two of which were
related to that same problem, and probably are from me missing something in the code.
Thanks for your help in this mess
--Anthony
On Thu, 2003-12-11 at 15:00, Antonio Fiol Bonnn wrote:
So . what your telling me, is that it's a concurrency problem
created by having object attributes? That if they were, in fact
being called more like:
doProcess2 ();
than like:
doProcess1 ();
I wouldn't have these problems? Very interesting.
Not quite. I don't really understand your structue, but it seems it
needs some refactoring.
Please write back and ensure that's what you mean . because I'm
pretty sure it is. Oh, fun. Here I go to change some 100K
lines of code :-)
As a rule of thumb, do not let your req and res leave local scope
(do not store them anywhere [attribute, static attribute, other
object, ...]).
If you need help with the refactoring and I can access your code, I
might help on saturday. (Which timezone do you live on?)
Yours,
Antonio Fiol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.reset() and forward() ... problematic? DBCP related?
As long as you are using global variables to point to your request and
response objects, you will eventually run into concurrency problems.
On Monday 15 December 2003 10:15 am, Altankov Peter wrote:
Thanks for the nice feed-back Anthony.
And Antonio, just for the record, the snipplet:
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req,
HttpServletResponse res) { [...]
}
}
IS thread safe, since only method variables are used (which actually are
copied for every thread).
-Original Message-
From: Anthony Presley [mailto:[EMAIL PROTECTED]
Sent: 12 2003 . 18:33
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Thanks for your help everyone . after some number of hours of work
yesterday, I managed to get everything changed over, and I'm NOT using the
SingleThreadModel. I inherited part of the code, and wrote most of the
rest a couple of perl scripts was able to help significantly.
Long and the short, was we were trying to get away with an OOP design, in
which all of our servlets derived from a single class (which in turn,
implements HttpServlet), so that our forward(), logging, and erroring
methods could be easily implemented. In doing so, you were all correct, we
were over-writing our own variables.
On Wednesday I upgraded to the latest DBCP and Commons Pool, as well as the
latest JDBC driver for our vendor, reducing the number of those errors from
an enormous 760 to 220. Today, thus far, we've had a total of 10 errors,
only two of which were related to that same problem, and probably are from
me missing something in the code.
Thanks for your help in this mess
--Anthony
On Thu, 2003-12-11 at 15:00, Antonio Fiol Bonnn wrote:
So . what your telling me, is that it's a concurrency problem
created by having object attributes? That if they were, in fact
being called more like:
doProcess2 ();
than like:
doProcess1 ();
I wouldn't have these problems? Very interesting.
Not quite. I don't really understand your structue, but it seems it
needs some refactoring.
Please write back and ensure that's what you mean . because I'm
pretty sure it is. Oh, fun. Here I go to change some 100K
lines of code :-)
As a rule of thumb, do not let your req and res leave local scope
(do not store them anywhere [attribute, static attribute, other
object, ...]).
If you need help with the refactoring and I can access your code, I
might help on saturday. (Which timezone do you live on?)
Yours,
Antonio Fiol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ben Souther
F.W. Davison Company, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.reset() and forward() ... problematic? DBCP related?
I totally agree with you, its not :), I just had 10 free minutes and layed out some
hints
-Original Message-
From: Antonio Fiol Bonnin [mailto:[EMAIL PROTECTED]
Sent: 11 2003 . 22:51
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Sorry, but I think your solution is not completely thread safe, because you do not
declare doGet synchronized. If you did that, it would be thread safe. But what is the
point then? Declare the servlet as implements SingleThreadModel, and you are done!
Obviously, you will not avoid other global or out of scope variables concurrency
problems with that.
Yours,
Antonio Fiol
Altankov Peter wrote:
If you go for the SingleThreadModel, try this to workaround your
problem:
public class TestServlet extends HttpServlet implements SingleThreadModel {
...
}
However, this interface does not prevent synchronization problems that
result from servlets accessing shared resources such as static class
variables or classes outside the scope of the servlet and moreover its
depricated.(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/
javax/servlet/SingleThreadModel.html)
In general avoid any global variables in the scope of the servlet class
definition unless you know what you are doing. Use method variables
instead. If you decide to go for the real problem solution, either
declare the req and res objects in the, lets say, doGet method and
pass them to the forward method, or keep their declaration in the
servlet class but mark the forward method as syncronized (causing
threads to enter it one by one).
Here are your hnt snipplets:
// the workaround
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
[.]
forward(whatever);
}
protected synchronized void forward(String s) {
[.. Here is where you refer the global req and res objects ..]
[.. but its safe, since the method is marked as synchronized ..]
}
}
-- Or --
// some real solution
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
HttpServletRequest req;
HttpServletResponse res;
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req, HttpServletResponse
res) {
[...]
}
}
I hope this helps.
-Original Message-
From: Philipp Taprogge [mailto:[EMAIL PROTECTED]
Sent: 11 2003 . 16:28
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP
related?
Hi!
Antonio Fiol Bonnn wrote:
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have
been overwritten by another request.
Hmm... Im a bit lost here... could anyone perhaps be so kind and post a
code snipplet of how a thread safe use of a Servlet's request and
response attribute could look like? I have not been working with
Servlets for too long and I worried I might run into the same problem.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.reset() and forward() ... problematic? DBCP related?
Thanks for your help everyone . after some number of hours of work yesterday, I managed to get everything changed over, and I'm NOT using the SingleThreadModel. I inherited part of the code, and wrote most of the rest a couple of perl scripts was able to help significantly. Long and the short, was we were trying to get away with an OOP design, in which all of our servlets derived from a single class (which in turn, implements HttpServlet), so that our forward(), logging, and erroring methods could be easily implemented. In doing so, you were all correct, we were over-writing our own variables. On Wednesday I upgraded to the latest DBCP and Commons Pool, as well as the latest JDBC driver for our vendor, reducing the number of those errors from an enormous 760 to 220. Today, thus far, we've had a total of 10 errors, only two of which were related to that same problem, and probably are from me missing something in the code. Thanks for your help in this mess --Anthony On Thu, 2003-12-11 at 15:00, Antonio Fiol Bonnín wrote: So . what your telling me, is that it's a concurrency problem created by having object attributes? That if they were, in fact being called more like: doProcess2 (); than like: doProcess1 (); I wouldn't have these problems? Very interesting. Not quite. I don't really understand your structue, but it seems it needs some refactoring. Please write back and ensure that's what you mean . because I'm pretty sure it is. Oh, fun. Here I go to change some 100K lines of code :-) As a rule of thumb, do not let your req and res leave local scope (do not store them anywhere [attribute, static attribute, other object, ...]). If you need help with the refactoring and I can access your code, I might help on saturday. (Which timezone do you live on?) Yours, Antonio Fiol - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.reset() and forward() ... problematic? DBCP related?
Antonio Fiol wrote:
If you really cannot follow any of the above, there is still one
solution:
- Make sure your servlet implements SingleThreadModel. This will
ensure a different instance is used for all concurrent requests, or
that
no concurrent requests will occur.
Hope that helps.
Antonio Fiol
Either that or you can just declare your method syncrnized:
protected synchronized void forward(String s) {
Which ofcourse will become a bottleneck of you application during loads.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.reset() and forward() ... problematic? DBCP related?
Hi!
Antonio Fiol Bonnín wrote:
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have been
overwritten by another request.
Hmm... Im a bit lost here... could anyone perhaps be so kind and post
a code snipplet of how a thread safe use of a Servlet's request and
response attribute could look like? I have not been working with
Servlets for too long and I worried I might run into the same problem.
Thanks in advance
Phil
--
I love deadlines, I love the whooshing noise they make as they go by
- Douglas Adams
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.reset() and forward() ... problematic? DBCP related?
Below
On Thu, 2003-12-11 at 00:49, Antonio Fiol Bonnín wrote:
Anthony Presley wrote:
[... reduced to a minimum, but the problem still there ...]
protected void forward(String s) {
ServletConfig sc = null;
ServletContext sContext = null;
RequestDispatcher rd = null;
sc = this.getServletConfig();
sContext = sc.getServletContext();
rd = sContext.getRequestDispatcher(s);
rd.forward(req, res);
Hey! Where are you getting req and res from?!! My guess at the end.
These are, as you described, declared more or less. However, I'm
actually declaring them from a class hierarchy ... meaning that I have a
super class, which has req and res in it, and all of my servlet's derive
from it. When they call a forward, I then do not need to (necessarily)
call it with request and response. IE, psuedo
class Super {
protected Request req;
protected Response res;
set (Request r1, Response r2) {
req = r1;
res = r2;
}
forward1 (String s) {
// Get rd
rd.forward (req, res);
}
forward2 (String s, Request r1, Response r2) {
// Get rd
rd.forward (r1, r2);
}
}
class Sub extends Super {
doProcess1 () {
set (request, response);
.
forward1 (/index.jsp);
}
doProcess2 () {
.
forward2 (/index.jsp, request, response);
}
}
So . what your telling me, is that it's a concurrency problem
created by having object attributes? That if they were, in fact being
called more like:
doProcess2 ();
than like:
doProcess1 ();
I wouldn't have these problems? Very interesting.
Please write back and ensure that's what you mean . because I'm
pretty sure it is. Oh, fun. Here I go to change some 100K lines
of code :-)
--Anthony
3. I've bumped the response buffer (in the servlet) from 8K to 75K
(75000), which reduces the errors, but they are still present. Is there
a GOOD way to estimate the amount needed?
No need to increase anything. It might alleviate the problem or even
improve performance (??), but not solve anything.
4. Using DBCP 1.0 using the latest DBCP (1.1?), seems to reduce
the errors further (1 in 10, approx). I've rewritten the code to ensure
that connections are being opened / closed locally, and quickly. Timing
it shows that the DB connection is pulled from the pool for about 2300
milli, and the JSP runs for about 2 milli to display.
Same here. The shorter your DB connections are open, the better, but
this will not solve your problem.
I'm not 100% sure yet if the problem persists in the JSP (using a simple
JSP and simple servlet does not cause these problems, however, the
greater the complexity, the higher the likelihood of getting these
errors which baffle's me, because rerequesting it shows up fine,
with nothing in the logs) or the servlet.
But the greater the complexity, the greater your chances to get two
users using your servlet concurrently.
Anyone seen this before? I'm about at my wits end. Been refactoring
for a week now, and still it persists.
Yes. I found it to be a very common mistake. Now you know where the
problem lies, you probably already thought of a solution specific to
your case.
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have been
overwritten by another request.
Just in case my English is too bad, and so that the archive is useful
for people searching it:
- NEVER use object attributes in Servlets, as a rule of thumb.
- ALWAYS use local variables instead.
If you really cannot follow the above, then:
- Make sure that you need ONLY ONE INSTANCE of the object stored in that
attribute.
- One instance for: all concurrent users, and all successive requests.
- Make sure that this instance is THREAD SAFE.
- A typical example of this is the use of a logger.
- Another example are STATIC attributes, which are, in general, less
error-prone in this context.
If you really cannot follow any of the above, there is still one solution:
- Make sure your servlet implements SingleThreadModel. This will
ensure a different instance is used for all concurrent requests, or that
no concurrent requests will occur.
Hope that helps.
Antonio Fiol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.reset() and forward() ... problematic? DBCP related?
If you go for the SingleThreadModel, try this to workaround your problem:
public class TestServlet extends HttpServlet implements SingleThreadModel {
...
}
However, this interface does not prevent synchronization problems that result from
servlets accessing shared resources such as static class variables or classes outside
the scope of the servlet and moreover its
depricated.(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/javax/servlet/SingleThreadModel.html)
In general avoid any global variables in the scope of the servlet class definition
unless you know what you are doing. Use method variables instead.
If you decide to go for the real problem solution, either declare the req and res
objects in the, lets say, doGet method and pass them to the forward method, or keep
their declaration in the servlet class but mark the forward method as syncronized
(causing threads to enter it one by one).
Here are your hnt snipplets:
// the workaround
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
[.]
forward(whatever);
}
protected synchronized void forward(String s) {
[.. Here is where you refer the global req and res objects ..]
[.. but its safe, since the method is marked as synchronized ..]
}
}
-- Or --
// some real solution
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
HttpServletRequest req;
HttpServletResponse res;
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req, HttpServletResponse
res) {
[...]
}
}
I hope this helps.
-Original Message-
From: Philipp Taprogge [mailto:[EMAIL PROTECTED]
Sent: 11 2003 . 16:28
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Hi!
Antonio Fiol Bonnn wrote:
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have
been
overwritten by another request.
Hmm... Im a bit lost here... could anyone perhaps be so kind and post
a code snipplet of how a thread safe use of a Servlet's request and
response attribute could look like? I have not been working with
Servlets for too long and I worried I might run into the same problem.
Thanks in advance
Phil
--
I love deadlines, I love the whooshing noise they make as they go by
- Douglas Adams
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: response.reset() and forward() ... problematic? DBCP related?
A word of warning - synchronizing the forward() method does not stop another
thread from changing the values of the 'req' and 'res' variables, so you
will still get problems if you implement the first solution.
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Sent: 11 December 2003 16:00
To: Tomcat Users List
Subject: RE: response.reset() and forward() ... problematic? DBCP related?
If you go for the SingleThreadModel, try this to workaround your problem:
public class TestServlet extends HttpServlet implements
SingleThreadModel {
...
}
However, this interface does not prevent synchronization problems that
result from servlets accessing shared resources such as static class
variables or classes outside the scope of the servlet and moreover its
depricated.(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/javax
/servlet/SingleThreadModel.html)
In general avoid any global variables in the scope of the servlet class
definition unless you know what you are doing. Use method variables instead.
If you decide to go for the real problem solution, either declare the req
and res objects in the, lets say, doGet method and pass them to the forward
method, or keep their declaration in the servlet class but mark the forward
method as syncronized (causing threads to enter it one by one).
Here are your hnt snipplets:
// the workaround
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException,
IOException
{
[.]
forward(whatever);
}
protected synchronized void forward(String s) {
[.. Here is where you refer the global req and res objects
..]
[.. but its safe, since the method is marked as synchronized
..]
}
}
-- Or --
// some real solution
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException,
IOException
{
HttpServletRequest req;
HttpServletResponse res;
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req,
HttpServletResponse res) {
[...]
}
}
I hope this helps.
-Original Message-
From: Philipp Taprogge [mailto:[EMAIL PROTECTED]
Sent: 11 2003 . 16:28
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Hi!
Antonio Fiol Bonnn wrote:
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have
been
overwritten by another request.
Hmm... Im a bit lost here... could anyone perhaps be so kind and post
a code snipplet of how a thread safe use of a Servlet's request and
response attribute could look like? I have not been working with
Servlets for too long and I worried I might run into the same problem.
Thanks in advance
Phil
--
I love deadlines, I love the whooshing noise they make as they go by
- Douglas Adams
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.reset() and forward() ... problematic? DBCP related?
Why are you declaring req and res as global variables?
The request and respnose objects get passed to the doGet and doPost methods
by the container.
On Thursday 11 December 2003 11:06 am, you wrote:
A word of warning - synchronizing the forward() method does not stop
another thread from changing the values of the 'req' and 'res' variables,
so you will still get problems if you implement the first solution.
-Original Message-
From: Altankov Peter [mailto:[EMAIL PROTECTED]
Sent: 11 December 2003 16:00
To: Tomcat Users List
Subject: RE: response.reset() and forward() ... problematic? DBCP related?
If you go for the SingleThreadModel, try this to workaround your problem:
public class TestServlet extends HttpServlet implements
SingleThreadModel {
...
}
However, this interface does not prevent synchronization problems that
result from servlets accessing shared resources such as static class
variables or classes outside the scope of the servlet and moreover its
depricated.(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/java
x /servlet/SingleThreadModel.html)
In general avoid any global variables in the scope of the servlet class
definition unless you know what you are doing. Use method variables
instead. If you decide to go for the real problem solution, either declare
the req and res objects in the, lets say, doGet method and pass them to
the forward method, or keep their declaration in the servlet class but mark
the forward method as syncronized (causing threads to enter it one by one).
Here are your hnt snipplets:
// the workaround
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException,
IOException
{
[.]
forward(whatever);
}
protected synchronized void forward(String s) {
[.. Here is where you refer the global req and res objects
..]
[.. but its safe, since the method is marked as
synchronized ..]
}
}
-- Or --
// some real solution
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException,
IOException
{
HttpServletRequest req;
HttpServletResponse res;
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req,
HttpServletResponse res) {
[...]
}
}
I hope this helps.
-Original Message-
From: Philipp Taprogge [mailto:[EMAIL PROTECTED]
Sent: 11 2003 . 16:28
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Hi!
Antonio Fiol Bonnn wrote:
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have
been
overwritten by another request.
Hmm... Im a bit lost here... could anyone perhaps be so kind and post
a code snipplet of how a thread safe use of a Servlet's request and
response attribute could look like? I have not been working with
Servlets for too long and I worried I might run into the same problem.
Thanks in advance
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: response.reset() and forward() ... problematic? DBCP related?
Sorry, but I think your solution is not completely thread safe, because
you do not declare doGet synchronized. If you did that, it would be
thread safe. But what is the point then? Declare the servlet as
implements SingleThreadModel, and you are done!
Obviously, you will not avoid other global or out of scope variables
concurrency problems with that.
Yours,
Antonio Fiol
Altankov Peter wrote:
If you go for the SingleThreadModel, try this to workaround your problem:
public class TestServlet extends HttpServlet implements SingleThreadModel {
...
}
However, this interface does not prevent synchronization problems that result from
servlets accessing shared resources such as static class variables or classes outside
the scope of the servlet and moreover its
depricated.(http://jakarta.apache.org/tomcat/tomcat-5.0-doc/servletapi/javax/servlet/SingleThreadModel.html)
In general avoid any global variables in the scope of the servlet class definition
unless you know what you are doing. Use method variables instead.
If you decide to go for the real problem solution, either declare the req and res
objects in the, lets say, doGet method and pass them to the forward method, or keep
their declaration in the servlet class but mark the forward method as syncronized
(causing threads to enter it one by one).
Here are your hnt snipplets:
// the workaround
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
[.]
forward(whatever);
}
protected synchronized void forward(String s) {
[.. Here is where you refer the global req and res objects ..]
[.. but its safe, since the method is marked as synchronized ..]
}
}
-- Or --
// some real solution
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException
{
HttpServletRequest req;
HttpServletResponse res;
[]
forward(whatever, req, res);
}
protected void forward(String s, HttpServletRequest req, HttpServletResponse
res) {
[...]
}
}
I hope this helps.
-Original Message-
From: Philipp Taprogge [mailto:[EMAIL PROTECTED]
Sent: 11 2003 . 16:28
To: Tomcat Users List
Subject: Re: response.reset() and forward() ... problematic? DBCP related?
Hi!
Antonio Fiol Bonnn wrote:
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have
been
overwritten by another request.
Hmm... Im a bit lost here... could anyone perhaps be so kind and post
a code snipplet of how a thread safe use of a Servlet's request and
response attribute could look like? I have not been working with
Servlets for too long and I worried I might run into the same problem.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: response.reset() and forward() ... problematic? DBCP related?
So . what your telling me, is that it's a concurrency problem created by having object attributes? That if they were, in fact being called more like: doProcess2 (); than like: doProcess1 (); I wouldn't have these problems? Very interesting. Not quite. I don't really understand your structue, but it seems it needs some refactoring. Please write back and ensure that's what you mean . because I'm pretty sure it is. Oh, fun. Here I go to change some 100K lines of code :-) As a rule of thumb, do not let your req and res leave local scope (do not store them anywhere [attribute, static attribute, other object, ...]). If you need help with the refactoring and I can access your code, I might help on saturday. (Which timezone do you live on?) Yours, Antonio Fiol smime.p7s Description: S/MIME Cryptographic Signature
Re: response.reset() and forward() ... problematic? DBCP related?
Answer included in your text, and at the end.
Anthony Presley wrote:
[...] and I'm having a lot of errors, which
scale based on the number of users. For instance, assuming I have
around 10 people working on the system, I will have no errors. As that
number scales, it becomes a huge problem, and lots of error's start
showing up. I've tracked down and squashed most of the DB errors, but
am left with the following quandry:
It smells like a concurrency problem.
I'm not storing any data in the session, and use forward() ... a lot.
When the following code executes, and I only open one request (ie, I
click on the link to open a new window which fetches a servlet
response), it works flawlessly. When I click more than once, I start
getting forward() errors.
Smell is getting intense ;-)
Here's some code snippets:
[... reduced to a minimum, but the problem still there ...]
protected void forward(String s) {
ServletConfig sc = null;
ServletContext sContext = null;
RequestDispatcher rd = null;
sc = this.getServletConfig();
sContext = sc.getServletContext();
rd = sContext.getRequestDispatcher(s);
rd.forward(req, res);
Hey! Where are you getting req and res from?!! My guess at the end.
3. I've bumped the response buffer (in the servlet) from 8K to 75K
(75000), which reduces the errors, but they are still present. Is there
a GOOD way to estimate the amount needed?
No need to increase anything. It might alleviate the problem or even
improve performance (??), but not solve anything.
4. Using DBCP 1.0 using the latest DBCP (1.1?), seems to reduce
the errors further (1 in 10, approx). I've rewritten the code to ensure
that connections are being opened / closed locally, and quickly. Timing
it shows that the DB connection is pulled from the pool for about 2300
milli, and the JSP runs for about 2 milli to display.
Same here. The shorter your DB connections are open, the better, but
this will not solve your problem.
I'm not 100% sure yet if the problem persists in the JSP (using a simple
JSP and simple servlet does not cause these problems, however, the
greater the complexity, the higher the likelihood of getting these
errors which baffle's me, because rerequesting it shows up fine,
with nothing in the logs) or the servlet.
But the greater the complexity, the greater your chances to get two
users using your servlet concurrently.
Anyone seen this before? I'm about at my wits end. Been refactoring
for a week now, and still it persists.
Yes. I found it to be a very common mistake. Now you know where the
problem lies, you probably already thought of a solution specific to
your case.
My guess:
req and res are attributes of the Servlet, like in:
public class TestServlet extends HttpServlet {
private HttpServletRequest req;
private HttpServletResponse res;
[...]
}
So you are calling forward(s) for a request once req and res have been
overwritten by another request.
Just in case my English is too bad, and so that the archive is useful
for people searching it:
- NEVER use object attributes in Servlets, as a rule of thumb.
- ALWAYS use local variables instead.
If you really cannot follow the above, then:
- Make sure that you need ONLY ONE INSTANCE of the object stored in that
attribute.
- One instance for: all concurrent users, and all successive requests.
- Make sure that this instance is THREAD SAFE.
- A typical example of this is the use of a logger.
- Another example are STATIC attributes, which are, in general, less
error-prone in this context.
If you really cannot follow any of the above, there is still one solution:
- Make sure your servlet implements SingleThreadModel. This will
ensure a different instance is used for all concurrent requests, or that
no concurrent requests will occur.
Hope that helps.
Antonio Fiol
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
