Re: Apache returning different sizes for same request [was Re: Controlling caching / session collision]
Ouch. ;) That was it. We searched through all the JSPs and fixed that in several places. The problems are greatly reduced now. Thank you very much! Is there any analog to this in Servlets? Is there a clearly incorrect way variables could be scoped in the a Servlet that could lead to the same thing? The developer, within the JSPs, has a couple lines like: jsp:useBean id=statehsaBean class=postgres.PostgreSQLBean scope=page / And since we are still experiencing the problem (though much less), I wonder if the Servlets now have some similar global variable problem. Thanks again! On Mon, 10 Jan 2005, Tim Funk wrote: The code below is a disaster. It creates a variable called result at the servlet instance level. This means that 2 concurrent requests to that JSP page will cause the page to fail. I didn't read the reast of the code - because that line is so evil - that ... well I'm speechless. Change it to: % ResultSet result; % -Tim Brian McEntire wrote: Looking at one of the problematic JSP pages, I see (snippets): %! ResultSet result; % - 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: Apache returning different sizes for same request [was Re: Controlling caching / session collision]
%! String myVar =;% creates an instance myVar in the servlet. Only 1 instance of a given servlet is loaded at a time and many requests all execute the service() method concurrently. %String myVar=;% would create a variable in the scope of the _jspService() method. Which is thread safe. jsp:useBean is thread safe. (Unless the variable is pulled from application or session scope) -Tim Brian McEntire wrote: Ouch. ;) That was it. We searched through all the JSPs and fixed that in several places. The problems are greatly reduced now. Thank you very much! Is there any analog to this in Servlets? Is there a clearly incorrect way variables could be scoped in the a Servlet that could lead to the same thing? The developer, within the JSPs, has a couple lines like: jsp:useBean id=statehsaBean class=postgres.PostgreSQLBean scope=page / And since we are still experiencing the problem (though much less), I wonder if the Servlets now have some similar global variable problem. Thanks again! On Mon, 10 Jan 2005, Tim Funk wrote: The code below is a disaster. It creates a variable called result at the servlet instance level. This means that 2 concurrent requests to that JSP page will cause the page to fail. I didn't read the reast of the code - because that line is so evil - that ... well I'm speechless. Change it to: % ResultSet result; % -Tim Brian McEntire wrote: Looking at one of the problematic JSP pages, I see (snippets): %! ResultSet result; % - 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: Apache returning different sizes for same request [was Re: Controlling caching / session collision]
On Fri, 7 Jan 2005, Caldarale, Charles R wrote:
My browser requested listByOwner.jsp but received
decodedDataChartContents.jsp. I expected listByOwner
but saw decodedDataChartContents.
One of the more common causes of this is inadvertent data sharing due to
applications that aren't thread-safe. Examine the app code for
unprotected static fields, request-specific data stored in a session
object, etc.
You should also try running the requests through Tomcat only (usually
port 8080 unless you've disabled the normal http connector) to see if
the problem stays with Tomcat or disappears when mod_jk is out of the
picture.
I'm the (poor :) sys admin and I don't know much Java but I can read it at
a beginner level. I'm working with the developer of this application. He
doesn't know threads well but doesn't think his application uses any. He
also says the application does not make use of sessions.
Looking at one of the problematic JSP pages, I see (snippets):
jsp:useBean id=state class=postgres.PostgreSQLBean scope=page /
%!
ResultSet result;
%
and
try {
state.connectToDB(db.server.sanitized.gov);
if (state.isConnected())
result = state.executeQuery(SELECT owner_code
FROM owner ORDER BY owner_code);
while (result.next()) {
%
option value=%= result.getString(1) %%= result.getString(1) %
%
}
state.closeStatement();
result.close();
state.closeConnection();
} catch (SQLException e) {
} catch (Exception e) {
}
- - -
That's all the Java / tags on the whole page. Do you see anything wrong
with the scope of the variables, threads, or sessions?
* The other question I have: Does anyone know of a simple way to make
Tomcat log accesses in a format like Apache's Combined Log format?
I wrote test plans in JMeter and a PERL script which can monitor the
Apache access log in real time and show the success and failure of each
request-response through Apache and mod_jk (based on the results of served
JSPs having known sizes.)
I left the default Tomcat port open (for internal use) on port 8080 and I
can access the JSPs that are having problems directly though Tomcat. This
eliminates mod_jk and Apache for troubleshooting. The only problem is,
this is an intermittent problem so it very difficult to judge improvement
with out JMeter and the test script which needs a combined access log as
input.
I'd be happy to share the PERL script with anyone interested. Contact me
if you want it.
Thanks!
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache returning different sizes for same request [was Re: Controlling caching / session collision]
The code below is a disaster. It creates a variable called result at the servlet instance level. This means that 2 concurrent requests to that JSP page will cause the page to fail. I didn't read the reast of the code - because that line is so evil - that ... well I'm speechless. Change it to: % ResultSet result; % -Tim Brian McEntire wrote: Looking at one of the problematic JSP pages, I see (snippets): %! ResultSet result; % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache returning different sizes for same request [was Re: Controlling caching / session collision]
From: Brian McEntire [mailto:[EMAIL PROTECTED] Subject: Apache returning different sizes for same request [was Re: Controlling caching / session collision] My browser requested listByOwner.jsp but received decodedDataChartContents.jsp. I expected listByOwner but saw decodedDataChartContents. One of the more common causes of this is inadvertent data sharing due to applications that aren't thread-safe. Examine the app code for unprotected static fields, request-specific data stored in a session object, etc. You should also try running the requests through Tomcat only (usually port 8080 unless you've disabled the normal http connector) to see if the problem stays with Tomcat or disappears when mod_jk is out of the picture. - 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 unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
