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]
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]
Controlling caching / session collision
I am running Tomcat 5.0.28, mod_jk 1.2.8, and Apache/2.0.46 on Redhat Enterprise Linux WS 3.0. We have an HTML page that is a frame: top (banner), left hand (menu), and right hand (main content). There are 6 hyperlinks in the LH pane that point to *.jsp pages that load in the RH pane via a BASE TARGET=displayContents tag. Usually, these links work. But occasionally when clicking one link, content that belongs to another link appears in the main/RH pane. This problem seems to get worse the longer Tomcat is up. The JSPs that we are using don't make use of sessions as far as I can tell. Logins are not required. The JSPs are only used to generate dynamic content and forms for submission. I have tried setting the following in workers.properties: worker.workerHADS.socket_keepalive=FALSE worker.workerHADS.cache_timeout=60 worker.workerHADS.cachesize=1 worker.workerHADS.reclycle_timeout=30 I added this within the head/head section of each JSP: META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 But the problem still presents occasionally. It happens on Mozilla and IE browsers, and probably others. It looks like a server side issue. It is not 100% reproducible. It cannot be reproduced immediately after Tomcat is started. But after several hours (or possibly some number of visitors to the page) it starts to happen and gets more frequent over time. Any suggestions would be greatly appreciated! Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache returning different sizes for same request [was Re: Controlling caching / session collision]
This is a follow-up to my question. I hope someone might have seen this before. I don't know if this is a Tomcat, or mod_jk, or Apache issue, but since I've only seen it with JSPs, I think Tomcat or mod_jk factor in. Here are entries from Apache's combined access log when the problem occurs: 192.168.1.1 - - [07/Jan/2005:18:01:36 -0500] GET /jsp/dipper/listByOwner.jsp HTTP/1.1 200 5601 - Java/1.4.2_06 192.168.1.1 - - [07/Jan/2005:18:01:36 -0500] GET /jsp/dipper/decodedDataChartContents.jsp HTTP/1.1 200 8503 - Java/1.4.2_06 192.168.1.1 - - [07/Jan/2005:18:02:09 -0500] GET /jsp/dipper/listByOwner.jsp HTTP/1.1 200 8503 http://server-obscurred.gov/dipper/contents.html; Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 Those entries are slightly sanitized. The point is, in the first entry, the size of the response sent by Apache back to the client for listByOwner.jsp is correct at 5601. The correct size is sent back for decodedDataChartContents.jsp in the second entry at 8503. The problem presented with the third request: Apache sent back the wrong response. My browser requested listByOwner.jsp but received decodedDataChartContents.jsp. I expected listByOwner but saw decodedDataChartContents. Apache's log shows that the response it served was the same size as decodedDataChartContents.jsp even though the request was for listByOwner.jsp. Has anyone seen this before? Any ideas what would cause that or how to prevent it? Thanks! Brian On Fri, 7 Jan 2005, Brian McEntire wrote: I am running Tomcat 5.0.28, mod_jk 1.2.8, and Apache/2.0.46 on Redhat Enterprise Linux WS 3.0. We have an HTML page that is a frame: top (banner), left hand (menu), and right hand (main content). There are 6 hyperlinks in the LH pane that point to *.jsp pages that load in the RH pane via a BASE TARGET=displayContents tag. Usually, these links work. But occasionally when clicking one link, content that belongs to another link appears in the main/RH pane. This problem seems to get worse the longer Tomcat is up. The JSPs that we are using don't make use of sessions as far as I can tell. Logins are not required. The JSPs are only used to generate dynamic content and forms for submission. I have tried setting the following in workers.properties: worker.workerHADS.socket_keepalive=FALSE worker.workerHADS.cache_timeout=60 worker.workerHADS.cachesize=1 worker.workerHADS.reclycle_timeout=30 I added this within the head/head section of each JSP: META HTTP-EQUIV=Pragma CONTENT=no-cache META HTTP-EQUIV=Expires CONTENT=-1 But the problem still presents occasionally. It happens on Mozilla and IE browsers, and probably others. It looks like a server side issue. It is not 100% reproducible. It cannot be reproduced immediately after Tomcat is started. But after several hours (or possibly some number of visitors to the page) it starts to happen and gets more frequent over time. Any suggestions would be greatly appreciated! Thanks, Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
