Re: Tomcat: two context path for one webapp
AlbundySzabolcs wrote: Hi, I have been trying to solve a problem, but I have not found any good solution yet. The problem is: I have a web app and this web app is deployed to the $TOMCAT_HOME/webapps/XXX directory. I can reach that on the http://localhost:8080/XXX address BUT, I would like to reach the web app on the http://localhost:8080/YYY address too. I added the following to the server.xml: Server Service Engine Host ... Context path=/YYY docBase=XXX/Context /Host /Engine /Service /Server It helped but the Tomcat started two web contexts and it caused some other problem. Is it possible to create a multiple address for one web app and both address represent same webapp? We had this configuration running in production for a number of years with no problem (the webapp could be reached under / and under /webapp). Technically, these are two different applications running from the same files, so session IDs cannot be exchanged between them. What were the problems you encountered? Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secure login only, not rest of app
Robert Denison wrote: Thanks peter, Don't suppose anyone can point me to any documentation that talks about getting caching working properly for tomcat and static content can they? A good caching tutorial is http://www.mnot.net/cache_docs/ The best site for web performance in general is http://developer.yahoo.com/performance/rules.html Tools for checking these rules are YSlow (http://developer.yahoo.com/yslow/) and http://www.webpagetest.org/ The most important rules are * Reduce number of requests (by consolidating scripts, style sheets and images), * Reduce data volume (e. g., by compression), * Allow re-use by caching, * Keep persistent connections, * Avoid sending cookies for static objects. If you have to serve users in a different continent than where your servers are, you should also think about using a CDN. Persistent connections are especially important with SSL, because SSL connection setup is expensive. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat w/apr data lost in http post request?
Christopher Schultz wrote: Can MSIE even control which data goes in which packet? That would seem to be part of the TCP/IP stack, buried in the OS, and affecting both MSIE and any other browser on the same system. We saw that Firefox uses only one packet to send a POST request (of resonable size), so the application(s) seem to have control over this. I am sure there are APIs that are sufficiently low-level for this. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Effect of Heap Size on Performance?
Washburn, Brian J [IT] wrote: Also if the application is a web app with any kind of response time requirements I would strongly suggest that you use [set of four options] My suggestion is to first get a feel for the current gc behaviour with jstat on the server: jstat -gc -t -h25 $pid 5000 Then look at the document describing garbage collection on Sun 1.6 JVMs: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html The solution to better GC behaviour may be as simple as choosing the right collector, as explained in the section Selecting a Collector. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: hanging threads on Tomcat
Patrick Plaatje wrote: Thanks for the swift replies, i have two dump, appr a few seconds apart uploaded to: http://www.ipros.nl/uploads/catalina_stripped_1.out http://www.ipros.nl/uploads/catalina_stripped_2.out Many threads appear to be waiting on the same instance of org.apache.tomcat.dbcp.pool.impl.GenericObjectPool in org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection, while I can see only 4 threads actually doing database work. Is it possible that you have configured too few database connections? (If the current limit is 4, try 20.) A second point of contention looks like at neo.util.Mutex.aquire(Mutex.java:77) at neo.xredsys.presentation.ArticlePresentationManager.getArticle(ArticlePresentationManager.java:200) at neo.xredsys.presentation.ArticlePresentationManager.getArticle(ArticlePresentationManager.java:169) at neo.xredsys.presentation.ArticlePresentationManager.getArticle(ArticlePresentationManager.java:149) But this may be a property of the software you use and harder to change. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat w/apr data lost in http post request?
Taylan Develioglu wrote: I would like to correct this, it seems to only happen with IE6/7.. maybe old firefox 2.0 We recently observed a similar problem. When IE 6/7/8 make a form POST, they often send the header in one TCP packet and the body in another. A flaky networking component at our site did not forward the second packet to the Tomcat server. Effect: Tomcat 6.0.18 waited 20s, then proceeded to reply to the request *without parameters*. Presumably it decided that the connection had timed out, the content-length it had received in the header was wrong and that the real content-length was zero :-) As far as I know, splitting header and body of POST requests into separate TCP packets is a peculiarity of IE browsers. This observation was made using normal HTML forms, but it may well apply to AJAX POST requests as well. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Make ETags take gzip compression into account
The Apache folks are about to fix the problem that ETags are the same for compressed and uncompressed versions of a resource: https://issues.apache.org/bugzilla/show_bug.cgi?id=39727 Tomcat 6.0.18 suffers from the same problem. The effect is that if a caching proxy holds a gzipped version of a resource and is asked by a client for an unzipped version, it requests one from the server with the ETag of the cached version. The server sees that the ETag of the version it would send out is the same as that of the version the cache already holds and tells the cache that its version is OK (response status code 304). In the case of a Squid cache, this results in a gzipped version to be sent to the client, and this breaks in IE6 and IE7 when they are configured to use the HTTP 1.0 protocol. Squid has been provided with a work-around option for this problem: http://www.squid-cache.org/Versions/v2/2.6/cfgman/broken_vary_encoding.html but we should not rely on caches world-wide to provide a work-around for a Tomcat bug. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Make ETags take gzip compression into account
Mark Thomas wrote: Please create a bugzilla entry to make sure we don't forget about this. Done: https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 Unfortunately, I copy/pasted the description from the news posting and now have additional line breaks in the text. Regards, Oliver Schoett - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: jvm cowardly refuses to print a thread dump
Martin Gainty wrote: so the solution is put all updates/inserts to the arraylist into a synchronized method? You must synchronize all read and write methods, because nothing may run in parallel with a write method, and so read methods must be prevented from executing if a write method runs already. The only exception is if you can ensure that the ArrayList is read-only at some point in your program (e. g., after a setup phase). Arguing that the size() function cannot loop does not help, because the size function could be called internally in an infinite loop (this would be visible in the call stack). Regards, Oliver Schoett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x?
andre John Mas wrote:
Hi,
We are currently experiencing session issues with our customer's
Tomcat server, in a production environment. Basically what is
happening is that, despite the idle time-out being set for 20 minutes
we are seeing sessions that have been idle (have not been accessed)
for over 3 hours. The net result is that the Tomcat server needs to
get restarted.
We are currently investigating the reason why, but are currently in
the dark on how we should continue our analysis. If anyone has any
ideas they would be much appreciated.
There is a race condition when Tomcat 5.0 maintains the accessCount
attribute of a session, see
https://issues.apache.org/bugzilla/show_bug.cgi?id=37356
Tomcat does not invalidate sessions after session-timeout period has
passed.
This bug is fixed in Tomcat 5.5 and 6. We have seen it causing sessions
to hang around forever in production servers.
Furthermore there is a concurrency bug accessing the session attributes:
https://issues.apache.org/bugzilla/show_bug.cgi?id=36541
session getAttribute/setAttribute and removeAttribute are NOT Thread
safe.
Both are fixed in the patch below for Tomcat 5.0
Regards,
Oliver Schoett
---
dist/jakarta-tomcat-5.0.25-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
2004-05-17 20:10:50.0 +0200
+++
jakarta-tomcat-5.0.25-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
2008-09-25 14:53:15.046667200 +0200
@@ -31,6 +31,8 @@
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashMap;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
import java.util.Iterator;
import javax.servlet.ServletContext;
@@ -116,7 +118,7 @@
/**
* The collection of user data attributes associated with this Session.
*/
-protected HashMap attributes = new HashMap();
+protected Map attributes = new ConcurrentHashMap();
/**
@@ -280,6 +282,11 @@
*/
protected transient int accessCount = 0;
+/**
+ * Object used to synchronize accesses to accessCount
+ */
+private final transient Object accessCountLock = new Object();
+
// - Session Properties
@@ -555,8 +562,10 @@
return false;
}
-if (accessCount 0) {
-return true;
+synchronized (accessCountLock) {
+if (accessCount 0) {
+return true;
+}
}
if (maxInactiveInterval= 0) {
@@ -597,7 +606,9 @@
evaluateIfValid();
-accessCount++;
+synchronized (accessCountLock) {
+accessCount++;
+}
}
@@ -608,7 +619,9 @@
public void endAccess() {
isNew = false;
-accessCount--;
+synchronized (accessCountLock) {
+accessCount--;
+}
}
@@ -687,7 +700,9 @@
}
}
}
-accessCount = 0;
+synchronized (accessCountLock) {
+accessCount = 0;
+}
setValid(false);
// Remove this session from our manager's active sessions
@@ -802,7 +817,9 @@
id = null;
lastAccessedTime = 0L;
maxInactiveInterval = -1;
-accessCount = 0;
+synchronized (accessCountLock) {
+accessCount = 0;
+}
notes.clear();
setPrincipal(null);
isNew = false;
@@ -1329,7 +1346,7 @@
// Deserialize the attribute count and attribute values
if (attributes == null)
-attributes = new HashMap();
+attributes = new ConcurrentHashMap();
int n = ((Integer) stream.readObject()).intValue();
boolean isValidSave = isValid;
isValid = true;
@@ -1341,9 +1358,9 @@
if (debug= 2)
log( loading attribute ' + name +
' with value ' + value + ');
-synchronized (attributes) {
+// OS no longer needed: synchronized (attributes) {
attributes.put(name, value);
-}
+// OS no longer needed: }
}
isValid = isValidSave;
@@ -1388,9 +1405,9 @@
ArrayList saveValues = new ArrayList();
for (int i = 0; i keys.length; i++) {
Object value = null;
-synchronized (attributes) {
+// OS no longer needed: synchronized (attributes) {
value = attributes.get(keys[i]);
-}
+// OS no longer needed: }
if (value == null)
continue;
else if ( (value instanceof Serializable)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jvm cowardly refuses to print a thread dump
Leon Rosenberg wrote: On Fri, Dec 5, 2008 at 9:50 AM, Oliver Schoett [EMAIL PROTECTED] wrote: Martin Gainty wrote: so the solution is put all updates/inserts to the arraylist into a synchronized method? You must synchronize all read and write methods, because nothing may run in parallel with a write method, and so read methods must be prevented from executing if a write method runs already. The only exception is if you can ensure that the ArrayList is read-only at some point in your program (e. g., after a setup phase). Arguing that the size() function cannot loop does not help, because the size function could be called internally in an infinite loop (this would be visible in the call stack). Oliver, I'm very sorry but i really don't see your point. The only possible need to synchronize access to ArrayList.size is when you a) access the list from different threads and b) need the result to be exact. Neither was the fact in my original post, in fact, as we already resolved it, the vm was getting out of old gen space and afterwards just behaving weird. Three points: (1) In the absence of call stack information, we do not know whether the size() calls showing up in the thread dumps come from the application or are internal calls from some other ArrayList function that may be in an infinite loop. (2) That size() cannot loop may be a property of the current implementation; it is not guaranteed by the API. (3) In general, when you query the size, you then want to do something according to the value you got. Unless there is a synchronizaton block around the size call and the subsequent action that guarantees that there are no intervening changes to the ArrayList, the size call is useless, as the ArrayList may change arbitrarily between the size call and the action. Thus in general, even harmless query functions will appear inside synchronized sections together with the actions that use the result value. (The only exception I see is where the result value is just used for information and does not control any action). Regards, Oliver Schoett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jvm cowardly refuses to print a thread dump
Leon Rosenberg wrote: You should consider using synchronized lists :-) (for example Vector). Does not help :-) If you do not put sync. brackets around Check some property (e. g., size()); Do something according to the property value you lose, because the property may have changed already when the second line is executed. You need the sync. brackets to preserve the state between checking some property and acting on the result. Regards, Oliver Schoett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jvm cowardly refuses to print a thread dump
Leon Rosenberg wrote: But back to the ArrayList, how high is the probability of having ArrayList.size() twice in the similar call-tree in one ThreadDump? Very likely you have unsynchronized accesses to the ArrayList, which from time to time send one of the threads involved into an infinite tight loop inside an ArrayList access function. A way to confirm this is to take two thread dumps a minute apart; if you find the *same* threads in the same ArrayList access functions, they loop infinitely. Regards, Oliver Schoett - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat mixes sessions?
Eero Nevalainen wrote: After that, it's just a matter of getting the username from the session-stored object for subsequent queries. How do you store the session ID in the client browser? I have seen a similar problem with a login page that handed out Session IDs in the URLs contained in the page. The page was sent out with Cache-control: no-cache, but no Expires: header. The Cache-control: header was introduced in HTTP 1.1, whereas in HTTP 1.0, the only way to control caching is the Expires: header. A HTTP 1.0 proxy cache thus had no usable caching directive and applied its default caching policy. As a result, users behind such a proxy could obtain the same session ID and see each other's data. Moral: when using Cache-control:, always use Expires: as well for HTTP 1.0 caches. Regards, Oliver Schoett - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to increase Tomcat webserver speed?
keglius wrote: I performed tests on members area and found that in most cases all pages are loaded within 4-10 seconds. The slowest pages (e.g. reports to view longer period time data) sometimes takes 20-180 seconds to load. How can I increase this speed? The obvious approach is to find out where this time is actually spent. The safest approach is to proceed naively from the outside in, as follows. First measure the loading performance of your Web page with Firebug (Firefox Plugin). I will show you which web requests are responsible for the slowdown. Assuming that server response times are responsible for the slowdown (as opposed to the data transfer to the browser), do a real-time profile of the server to find out where the time is spent, e. g. with the Eclipse TPTP or the Netbeans Profiler. Using real-time profiling, you can detect whether the culprits are computations on the server or back-end calls (e. g., to the data base). If server computations are the problem, the profiler will tell you the cause of the problem. If the problem is in the back-end calls, there are two possibilities: (a) The back-end calls consume a lot of time on the back-end server. In this case you must look at the back-end server. If it is a data base server, data base / query optimization must be performed. (b) The data base calls do not consume a lot of time on the back-end server, but their sheer number causes the delays. This requires a redesign of the back-end queries, such that the data is fetched with fewer calls. For example, I have reviewed an application that performed 15.000 DB calls to construct the response to a common user request. No matter how efficient the calls on the data base, the latency of the 15.000 calls will cause a response time in the tens of seconds, at least. Thus, you can find out which of the four most common performance problems is responsible for your delays: (1) Web performance, i. e., too many HTTP requests from the browser (not likely the case here), (2) app server performance, i. e., too many computations, (3) back end performance, i. e., too much work on the back end (e. g., the data base), (4) back end call latency, i. e., too many separate back end calls. It would be premature to start optimizing one of these before having identified the main cause of the problem. Regards, Oliver Schoett - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
