Fwd: Tomcat Session Id generation Overriding!!
Dear Friends,
Tomcat is using ManagerBase generateSessionId() to generate session Id. But
I want a generation mechnism where each sessionId will be unique in whole
tomcat. Right now it is unique in a single context. But I want uniqueness
will be among all context running under the tomcat. How can I do that (In a
easieast way)??
Still now I have written a class which has extended the
org.apache.session.standardManager class. Then I have changed the code
slightly. But I don't know whether any sideeffect will be there or not??
Please look on my
code
package com.myproject.session;
import java.util.HashSet;
import java.util.Set;
import org.apache.catalina.Session;
import org.apache.catalina.session.StandardManager;
public class MySessionManager extends StandardManager {
public static SetString unquieSessionIdset = new HashSetString();
@Override
public void remove(Session session) {
unquieSessionIdset.remove(session.getIdInternal());
super.remove(session);
}
@Override
protected synchronized String generateSessionId() {
byte random[] = new byte[16];
String jvmRoute = getJvmRoute();
String result = null;
// Render the result as a String of hexadecimal digits
StringBuffer buffer = new StringBuffer();
do {
int resultLenBytes = 0;
if (result != null) {
buffer = new StringBuffer();
duplicates++;
}
while (resultLenBytes this.sessionIdLength) {
getRandomBytes(random);
random = getDigest().digest(random);
for (int j = 0;
j random.length resultLenBytes this.sessionIdLength;
j++) {
byte b1 = (byte) ((random[j] 0xf0) 4);
byte b2 = (byte) (random[j] 0x0f);
if (b1 10)
buffer.append((char) ('0' + b1));
else
buffer.append((char) ('A' + (b1 - 10)));
if (b2 10)
buffer.append((char) ('0' + b2));
else
buffer.append((char) ('A' + (b2 - 10)));
resultLenBytes++;
}
}
if (jvmRoute != null) {
buffer.append('.').append(jvmRoute);
}
result = buffer.toString();
} while (sessions.containsKey(result) ||
!unquieSessionIdset.add(result));
return (result);
}
}
Can You please tell me whether it will have any other problem or not?? Or
can you give any alternative solution??
Actually I kept the existing code. With that I addeda a static set. And I am
keeping the generated session in set also. While generating Id I am trying
to add that to set. if successfully added then I will return that key.
Thanks
Arnab Ghosh
Re: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection
On 08/01/2010 23:07, Robin Wilson wrote: OK, I made the following changes (1 at a time) to 'server.xml', and retested: Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false processExpiresFrequency=1 notifyListenersOnReplication=true/ No discernable difference was noted on the retest (NOTE: I have measured the sessions vs. the number of 'threads requesting pages', and I think that the sessions are actually expiring - just _much_ slower than my load generator is creating them. So I'm creating 100,000 sessions in 'n' time period, and in that same time period only 6,000 are being expired and removed (the ratio seems pretty constant - ~94% of the sessions created are staying around). Then I made this change to 'server.xml': Engine name=tomcat backgroundProcessorDelay=1 defaultHost=localhost Again, no discernable difference in behavior. So, new question - is there a way to tell Tomcat to clear out larger numbers of sessions at once? (Assuming they are past their inactivity duration period?) Even when I shut off the load generators, it only clears the sessions at a rate of a few thousand every second. Given it works when the load is reduced, it looks like the expiration logic is correct. One thing that would give you a bit more information is setting the log level for org.apache.catalina.session.ManagerBase to debug. I wonder if you are simply creating sessions faster than the single background thread can clear them out. If that is the case, how realistic is your load? I'm happy to try a fix a genuine issue but I don't think there is much benefit in making changes to address an artificial problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat Session Id generation Overriding!!
On 09/01/2010 11:01, Arnab Ghosh wrote: Dear Friends, Tomcat is using ManagerBase generateSessionId() to generate session Id. But I want a generation mechnism where each sessionId will be unique in whole tomcat. Right now it is unique in a single context. But I want uniqueness will be among all context running under the tomcat. How can I do that (In a easieast way)?? Do you understand what the odds are of generating a duplicated session? Assuming the random number generator is a good one, if you had one million current sessions in Tomcat, the odds of the next session being a duplicate are one in 3.4E32. If you were generating a thousand new sessions every second you would see a duplicate on average every 1.1E22 years. Even if the random number generator was terrible (it isn't) any only generated 128 bits of randomness rather than 256 you would still only see a duplicate on average every 580 years. Even if my maths is off by a few orders of magnitude, I really don't think this is an issue to worry about. Still now I have written a class which has extended the org.apache.session.standardManager class. Then I have changed the code slightly. But I don't know whether any sideeffect will be there or not?? It won't work in a clustered environment. Breaking scalability in this way is a much bigger issue than the very rare chance of a duplicated session. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to deploy java app. on Tomcat's virtual domains residing outside CATALINA_HOME?
On 09/01/2010 06:25, Leon Kolchinsky wrote: Hello All, I've installed Apache httpd +mod_jk and tomcat with multiple virtual hosts Used primarily those 2 manuals http://www.alwayssunny.com/blog/?p=174 This one looks pretty good although I wouldn't use the ApacheConfig listener. http://www.howtoforge.com/apache2_tomcat5_mod_jk_p2 I'd ignore this one. Now I need to deply java application called Sakai (http://source.sakaiproject.org/release/2.6.1/artifacts/sakai-bin-2.6.1.tgz) That is a 280MB download so it would help if you told us what was in it. They all talking about downloading the archive into $CATALINA_HOME and then unpacking the archive. Then start up Tomcat - http://confluence.sakaiproject.org/display/DOC/Install+Guide+-+Binary+Install+(2.6) When I extract sakai-bin-2.6.1.tgz into /srv/myserver029 (Vitual domain's DocumentRoot) and restart tomcat and apache I'm getting - HTTP Status 404 - / CATALINA_HOME != httpd document root I'm not surprised it didn't work. Here are some of my configs realted to apache httpd+tomcat+virt domains integration: You are using the same location for httpd document root and Host appBase and web application's docBase. That is never going to work. appBase must *never* be the same as docBase. I suggest you read this: http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html I strongly recommend that http DocumentRoot is never the same as a web applications docBase. You have to be very carefully do to create a whole bunch of security issues. It is much easier just not to do this. I suggest you follow the Tomcat virtual hosting how-to and get that working with Sakai and then worry about adding httpd to the mix. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection
On 09.01.2010 12:13, Mark Thomas wrote: On 08/01/2010 23:07, Robin Wilson wrote: OK, I made the following changes (1 at a time) to 'server.xml', and retested: Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false processExpiresFrequency=1 notifyListenersOnReplication=true/ No discernable difference was noted on the retest (NOTE: I have measured the sessions vs. the number of 'threads requesting pages', and I think that the sessions are actually expiring - just _much_ slower than my load generator is creating them. So I'm creating 100,000 sessions in 'n' time period, and in that same time period only 6,000 are being expired and removed (the ratio seems pretty constant - ~94% of the sessions created are staying around). Then I made this change to 'server.xml': Engine name=tomcat backgroundProcessorDelay=1 defaultHost=localhost Again, no discernable difference in behavior. So, new question - is there a way to tell Tomcat to clear out larger numbers of sessions at once? (Assuming they are past their inactivity duration period?) Even when I shut off the load generators, it only clears the sessions at a rate of a few thousand every second. Given it works when the load is reduced, it looks like the expiration logic is correct. One thing that would give you a bit more information is setting the log level for org.apache.catalina.session.ManagerBase to debug. I wonder if you are simply creating sessions faster than the single background thread can clear them out. If that is the case, how realistic is your load? I'm happy to try a fix a genuine issue but I don't think there is much benefit in making changes to address an artificial problem. Seconding Mark: it seems for those 1 second idle timeout sessions you are not using the session at all. So why are you generating a huge number of sessions you are never going to use? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to deploy java app. on Tomcat's virtual domains residing outside CATALINA_HOME?
Hello Mark, Thanks for the link - http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html I don't think that you've read my configs well. CATALINA_HOME != httpd document root That's my case! Where did you got the info that it isn't so? appBase and docBase are also different! And virt. hosts are actually working (please read what I've written). It must be something with Configuring my Contexts as per manual. My appBase is also not under CATALINA_HOME. Sakai is similar to moodle in some way. I'm sorry that it's 250M but I didn't write it. I've been asked to install it on virt. domains Any help please? On Sat, Jan 9, 2010 at 10:46 PM, Mark Thomas ma...@apache.org wrote: On 09/01/2010 06:25, Leon Kolchinsky wrote: Hello All, I've installed Apache httpd +mod_jk and tomcat with multiple virtual hosts Used primarily those 2 manuals http://www.alwayssunny.com/blog/?p=174 This one looks pretty good although I wouldn't use the ApacheConfig listener. http://www.howtoforge.com/apache2_tomcat5_mod_jk_p2 I'd ignore this one. Now I need to deply java application called Sakai (http://source.sakaiproject.org/release/2.6.1/artifacts/sakai-bin-2.6.1.tgz) That is a 280MB download so it would help if you told us what was in it. They all talking about downloading the archive into $CATALINA_HOME and then unpacking the archive. Then start up Tomcat - http://confluence.sakaiproject.org/display/DOC/Install+Guide+-+Binary+Install+(2.6) When I extract sakai-bin-2.6.1.tgz into /srv/myserver029 (Vitual domain's DocumentRoot) and restart tomcat and apache I'm getting - HTTP Status 404 - / CATALINA_HOME != httpd document root I'm not surprised it didn't work. Here are some of my configs realted to apache httpd+tomcat+virt domains integration: You are using the same location for httpd document root and Host appBase and web application's docBase. That is never going to work. appBase must *never* be the same as docBase. I suggest you read this: http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html I strongly recommend that http DocumentRoot is never the same as a web applications docBase. You have to be very carefully do to create a whole bunch of security issues. It is much easier just not to do this. I suggest you follow the Tomcat virtual hosting how-to and get that working with Sakai and then worry about adding httpd to the mix. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to deploy java app. on Tomcat's virtual domains residing outside CATALINA_HOME?
On 09/01/2010 13:42, Leon Kolchinsky wrote: Hello Mark, Thanks for the link - http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html I don't think that you've read my configs well. CATALINA_HOME != httpd document root That's my case! I meant that CATALINA_HOME is not the same as httpd's document root. If the instructions for Sakai say expand it into CATALINA_HOME then you can't expect it to work if you expand it somewhere else. Where did you got the info that it isn't so? Your configuration files. From your httpd.conf: DocumentRoot /srv/myserver029 From your server.xml appBase=/srv/myserver029 appBase and docBase are also different! No they are not. Again, from your server.xml appBase=/srv/sakai26 docBase= docBase is relative to appBase so if docBase= then docBase==appBase And virt. hosts are actually working (please read what I've written). They might look like they are working but I assure you that they are badly broken. It must be something with Configuring my Contexts as per manual. Nope. The problem is your broken configuration. My appBase is also not under CATALINA_HOME. I know. I read your configuration files. That is not an issue for virtual hosting although it may be a problem for the Sakai installation process. Again, if you tell us the structure of that tar.gz we might be able to help. Any help please? See my previous mail. If you choose to ignore the help you are given, then there isn't much point in folks here trying to help you. Mark On Sat, Jan 9, 2010 at 10:46 PM, Mark Thomas ma...@apache.org wrote: On 09/01/2010 06:25, Leon Kolchinsky wrote: Hello All, I've installed Apache httpd +mod_jk and tomcat with multiple virtual hosts Used primarily those 2 manuals http://www.alwayssunny.com/blog/?p=174 This one looks pretty good although I wouldn't use the ApacheConfig listener. http://www.howtoforge.com/apache2_tomcat5_mod_jk_p2 I'd ignore this one. Now I need to deply java application called Sakai (http://source.sakaiproject.org/release/2.6.1/artifacts/sakai-bin-2.6.1.tgz) That is a 280MB download so it would help if you told us what was in it. They all talking about downloading the archive into $CATALINA_HOME and then unpacking the archive. Then start up Tomcat - http://confluence.sakaiproject.org/display/DOC/Install+Guide+-+Binary+Install+(2.6) When I extract sakai-bin-2.6.1.tgz into /srv/myserver029 (Vitual domain's DocumentRoot) and restart tomcat and apache I'm getting - HTTP Status 404 - / CATALINA_HOME != httpd document root I'm not surprised it didn't work. Here are some of my configs realted to apache httpd+tomcat+virt domains integration: You are using the same location for httpd document root and Host appBase and web application's docBase. That is never going to work. appBase must *never* be the same as docBase. I suggest you read this: http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html I strongly recommend that http DocumentRoot is never the same as a web applications docBase. You have to be very carefully do to create a whole bunch of security issues. It is much easier just not to do this. I suggest you follow the Tomcat virtual hosting how-to and get that working with Sakai and then worry about adding httpd to the mix. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to deploy java app. on Tomcat's virtual domains residing outside CATALINA_HOME?
Hello again, Yes instructions for Sakai actually say expand it into CATALINA_HOME. O.K I may be wrong but http://sakai26.dyndns.org/servlets-examples/ is working. I'd like to fix my configuration and I'm opened for suggestions. What should I change in my configs (I think that I gave a full configs and changes I've made to defaults)? I don't have an access to my linux server now but I've downloaded to J: drive on my win. machine it and there is a structure of tar.gz: J:\ common\ components\ licenses\ server\ shared\ webapps\ J:\common\ lib\ J:\common\lib\ commons-logging-1.0.4.jar log4j-1.2.12.jar sakai-dav-common-2.6.1.jar sakai-kernel-common-1.0.12.jar J:\components\ emailtemplateservice-pack\ entitybroker-pack\ localization-bundles-pack\ osp-common-component\ osp-glossary-component\ osp-integration-component\ osp-matrix-component\ osp-portal-component\ osp-presentation-component\ osp-warehouse-component\ osp-wizard-components\ sakai-announcement-pack\ sakai-archive-pack\ sakai-assignment-pack\ sakai-calendar-pack\ sakai-chat-pack\ sakai-citations-pack\ sakai-common-components\ sakai-comp-help\ sakai-comp-scheduler\ sakai-content-providers-pack\ sakai-courier-pack\ sakai-coursemanagement-hibernate-pack\ sakai-gradebook-service-pack\ sakai-gradebooksample-grade-converter\ sakai-import\ sakai-kernel-component\ sakai-mailarchive-pack\ sakai-messageforums-components\ sakai-metaobj-component\ sakai-news-pack\ sakai-podcasts-pack\ sakai-poll-pack\ sakai-portal-render-pack\ sakai-portal-service-pack\ sakai-postem-pack\ sakai-presence-pack\ sakai-presentation-pack\ sakai-privacy-pack\ sakai-profile-components\ sakai-provider-pack\ sakai-reports-components\ sakai-rights-pack\ sakai-roster-components\ sakai-rwiki-pack\ sakai-samigo-pack\ sakai-sample-impl-access-pack\ sakai-search-adapters-pack\ sakai-search-pack\ sakai-sections-pack\ sakai-site-manage-pack\ sakai-syllabus-pack\ sakai-taggable-pack\ sakai-usermembership-pack\ sakai-warehouse-component\ sakai-web-pack\ J:\components\emailtemplateservice-pack\ META-INF\ WEB-INF\ J:\components\emailtemplateservice-pack\META-INF\ maven\ MANIFEST.MF J:\components\emailtemplateservice-pack\META-INF\maven\ org.sakaiproject.emailtemplateservice\ J:\components\emailtemplateservice-pack\META-INF\maven\org.sakaiproject.emailtemplateservice\ emailtemplateservice-pack\ J:\components\emailtemplateservice-pack\META-INF\maven\org.sakaiproject.emailtemplateservice\emailtemplateservice-pack\ pom.properties pom.xml J:\components\emailtemplateservice-pack\WEB-INF\ lib\ components.xml hibernate-hbms.xml spring-hibernate.xml web.xml J:\components\emailtemplateservice-pack\WEB-INF\lib\ commons-codec-1.3.jar easymock-1.2_Java1.3.jar emailtemplateservice-impl-0.3.1.jar freemarker-2.3.11.jar generic-dao-0.9.8.jar J:\components\entitybroker-pack\ META-INF\ WEB-INF\ J:\components\entitybroker-pack\META-INF\ maven\ MANIFEST.MF J:\components\entitybroker-pack\META-INF\maven\ org.sakaiproject.entitybroker\ J:\components\entitybroker-pack\META-INF\maven\org.sakaiproject.entitybroker\ entitybroker-pack\ J:\components\entitybroker-pack\META-INF\maven\org.sakaiproject.entitybroker\entitybroker-pack\ pom.properties pom.xml J:\components\entitybroker-pack\WEB-INF\ lib\ components.xml spring-jdbc.xml web.xml J:\components\entitybroker-pack\WEB-INF\lib\ commons-codec-1.2.jar commons-httpclient-3.1.jar entitybroker-impl-1.3.6.1.jar entitybroker-utils-1.3.6.1.jar generic-dao-0.9.12.jar reflectutils-0.9.11.jar sakai-kernel-util-1.0.12.jar J:\components\localization-bundles-pack\ META-INF\ WEB-INF\ J:\components\localization-bundles-pack\META-INF\ maven\ MANIFEST.MF J:\components\localization-bundles-pack\META-INF\maven\ org.sakaiproject\ J:\components\localization-bundles-pack\META-INF\maven\org.sakaiproject\ localization-bundles-pack\ J:\components\localization-bundles-pack\META-INF\maven\org.sakaiproject\localization-bundles-pack\ pom.properties pom.xml J:\components\localization-bundles-pack\WEB-INF\ lib\ components.xml web.xml J:\components\localization-bundles-pack\WEB-INF\lib\ localization-bundles-2.6.1.jar J:\components\osp-common-component\ META-INF\ WEB-INF\ J:\components\osp-common-component\META-INF\ maven\ MANIFEST.MF J:\components\osp-common-component\META-INF\maven\ org.sakaiproject.osp\ J:\components\osp-common-component\META-INF\maven\org.sakaiproject.osp\ osp-common-component\ J:\components\osp-common-component\META-INF\maven\org.sakaiproject.osp\osp-common-component\ pom.properties pom.xml J:\components\osp-common-component\WEB-INF\ lib\ components.xml web.xml J:\components\osp-common-component\WEB-INF\lib\ commons-beanutils-1.7.0.jar commons-codec-1.2.jar commons-digester-1.6.jar jsf-api-1.1.01.jar jsf-impl-1.1.01.jar osp-common-impl-2.6.1.jar sakai-kernel-util-1.0.12.jar sakai-metaobj-impl-2.6.1.jar sakai-metaobj-tool-lib-2.6.1.jar standard-1.1.2.jar velocity-1.3.1.jar J:\components\osp-glossary-component\ META-INF\
RE: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection
Well, we encounter this problem in our production environment every so often. If we run at sustained load for 2 hours we hit the wall in production. Keep in mind, our production environment has 4 clustered servers, so it takes about 1/4 the amount of load per server to encounter the problem. That being said, I think you are correct, we are creating sessions faster than they can be destroyed. Is there a way to setup the context so that it doesn't automatically create a session? (Keep in mind, we aren't using JSP, we are using Tapestry - and I am not sure how to use Tapestry without a session.) -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Saturday, January 09, 2010 5:13 AM To: Tomcat Users List Subject: Re: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection On 08/01/2010 23:07, Robin Wilson wrote: OK, I made the following changes (1 at a time) to 'server.xml', and retested: Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false processExpiresFrequency=1 notifyListenersOnReplication=true/ No discernable difference was noted on the retest (NOTE: I have measured the sessions vs. the number of 'threads requesting pages', and I think that the sessions are actually expiring - just _much_ slower than my load generator is creating them. So I'm creating 100,000 sessions in 'n' time period, and in that same time period only 6,000 are being expired and removed (the ratio seems pretty constant - ~94% of the sessions created are staying around). Then I made this change to 'server.xml': Engine name=tomcat backgroundProcessorDelay=1 defaultHost=localhost Again, no discernable difference in behavior. So, new question - is there a way to tell Tomcat to clear out larger numbers of sessions at once? (Assuming they are past their inactivity duration period?) Even when I shut off the load generators, it only clears the sessions at a rate of a few thousand every second. Given it works when the load is reduced, it looks like the expiration logic is correct. One thing that would give you a bit more information is setting the log level for org.apache.catalina.session.ManagerBase to debug. I wonder if you are simply creating sessions faster than the single background thread can clear them out. If that is the case, how realistic is your load? I'm happy to try a fix a genuine issue but I don't think there is much benefit in making changes to address an artificial problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection
Thanks. I'll pursue that angle - and see if there is a way, in Tapestry to just not create the session. (If anyone has any suggestions on where I can look for an answer to that - I'm all ears...) -- Robin D. Wilson Director of Web Development KingsIsle Entertainment, Inc. CELL: 512-426-3929 DESK: 512-623-5913 www.KingsIsle.com -Original Message- From: Rainer Jung [mailto:rainer.j...@kippdata.de] Sent: Saturday, January 09, 2010 6:11 AM To: Tomcat Users List Subject: Re: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection On 09.01.2010 12:13, Mark Thomas wrote: On 08/01/2010 23:07, Robin Wilson wrote: OK, I made the following changes (1 at a time) to 'server.xml', and retested: Manager className=org.apache.catalina.ha.session.DeltaManager expireSessionsOnShutdown=false processExpiresFrequency=1 notifyListenersOnReplication=true/ No discernable difference was noted on the retest (NOTE: I have measured the sessions vs. the number of 'threads requesting pages', and I think that the sessions are actually expiring - just _much_ slower than my load generator is creating them. So I'm creating 100,000 sessions in 'n' time period, and in that same time period only 6,000 are being expired and removed (the ratio seems pretty constant - ~94% of the sessions created are staying around). Then I made this change to 'server.xml': Engine name=tomcat backgroundProcessorDelay=1 defaultHost=localhost Again, no discernable difference in behavior. So, new question - is there a way to tell Tomcat to clear out larger numbers of sessions at once? (Assuming they are past their inactivity duration period?) Even when I shut off the load generators, it only clears the sessions at a rate of a few thousand every second. Given it works when the load is reduced, it looks like the expiration logic is correct. One thing that would give you a bit more information is setting the log level for org.apache.catalina.session.ManagerBase to debug. I wonder if you are simply creating sessions faster than the single background thread can clear them out. If that is the case, how realistic is your load? I'm happy to try a fix a genuine issue but I don't think there is much benefit in making changes to address an artificial problem. Seconding Mark: it seems for those 1 second idle timeout sessions you are not using the session at all. So why are you generating a huge number of sessions you are never going to use? Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: When running under high load (via load generating tools), Tomcat 6.0.20 stops expiring sessions until the load subsides; causing thrashing on Garbage Collection
On 09/01/2010 15:50, Robin Wilson wrote: Well, we encounter this problem in our production environment every so often. If we run at sustained load for 2 hours we hit the wall in production. Keep in mind, our production environment has 4 clustered servers, so it takes about 1/4 the amount of load per server to encounter the problem. Fair enough - if the load test is just a quick way of reproducing the problem then it doesn't really matter if it is artificial. That being said, I think you are correct, we are creating sessions faster than they can be destroyed. Is there a way to setup the context so that it doesn't automatically create a session? (Keep in mind, we aren't using JSP, we are using Tapestry - and I am not sure how to use Tapestry without a session.) Unfortunately, that will be under the control of the web application - or in this case Tapestry. The Tapestry users list is probably you best source of info on this. You can configure JSPs not to create sessions by default in web.xml but I'm not sure how much - if at all - that would help you. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Filter Mapping Issue
On 08/01/2010 23:17, Patrick Flaherty wrote: Christopher and Charles. Thanks a lot. I added a ROOT folder off my appBase and cut and pasted everything under that ROOT folder and now I am getting filter mapping hits with my ft.com ! We are not deploying correctly and this sheds all the light on that fact. Curiously I was not able to get to ft.com/WEB-INF/web.xml , I got a 404. But I am able to get to other files off the root as expected. Maybe Tomcat has it's own filter mapping for /WEB-INF/web.xml ? I could not get to any file in /META-INF/* either ? It's not unexpected. The contents of those two directories are protected from external view quite deliberately. p Anyway, thanks again for your patience and help. -P On Jan 8, 2010, at 4:06 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick, On 1/8/2010 3:49 PM, Patrick Flaherty wrote: If I use a host name of ft.com with a appBase of c:/FilterTest then doesn't c:/FilterTest become my web server root for ft.com? As Chuck points out, no: C:\FilterTest\ROOT is the server root for ft.com. Remember, Tomcat isn't a web server: it's an app server. Is seems to work that way for us although it may not be the correct way to deploy a web app. I suspect what's happening is that you have a layout like this: C:\FilterTest C:\FilterTest\WEB-INF C:\FilterTest\WEB-INF\web.xml C:\FilterTest\Proofs C:\FilterTest\Proofs\[content] Tomcat, seeing that a directory called \Proofs exists, is deploying it as it's own web application, and the DefaultServlet is serving all your content correctly. Since /Proofs doesn't have a WEB-INF/web.xml file, your filter is not being created and it's not being called. I'll bet that you can also request this file: http://ft.com/WEB-INF/web.xml Here, Tomcat will serve this file that might be expected to be protected because /WEB-INF looks like a (poorly-named) web application and not a proper deployment descriptor directory in a proper web app. If you deploy an app off of %CATALINAHOME% then doesn't the user have to type http://my.domainname.com/myapp ? I want it to hit my app when I type http://my.domainname.com. That is how it works with our product today. You need to fix your deployments, or nothing is going to make sense. If you want your webapp to be deployed without a leading path (i.e. on / instead of /foo), then you need to name your webapp ROOT.war (or put it in the ROOT subdirectory under your appBase directory). It starting to sound like the complete URL has to be part of %CATALINAHOME%'s path to get a filter hit ? No, this is not true. If your webapp is properly deployed, your relative URIs will be properly mapped and your filter will get called. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktHnmUACgkQ9CaO5/Lv0PCjzQCgvPHG6/1ZwJ0iyZrHj/coqoLW R20AoJJ0RXVvIdMHJ+mofNRo92EvUu0e =8MkQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Uniqueness of a sessionId
On 08/01/2010 20:46, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnab, On 1/8/2010 8:07 AM, Arnab Ghosh wrote: I have an doubt.Tomcat is using *org.apache.catalina.session.ManagerBase* to generate sessionId. Now I wants to know whether this generated key will be unique in all context running under a tomcat service or it will be unique under a particular context?? The servlet specification (rev 2.5, section 7.3) states that a session is to be scoped within a single context. Clearly, session ids should be unique for a single context (webapp). Tomcat supports SSO (single-sign-on) which allows multiple webapps to share a session, so in that case, the session id should be unique across the set of webapps participating in SSO. I'm not sure about clusters, but they wouldn't work very well if session ids generated on one node interfered with session ids created on another node that need to be shared across the cluster. I believe that a node attaches its jvmRoute to the session id such that it becomes unique across the cluster, and is re-written if/when the node is failed-over. For clusters without session stickiness, where any node may receive a request for a particular session, the session ids has better be unique. I don't see any documentation for Tomcat 6 that explicitly states that session ids are unique for the cluster. Do you have a specific concern, or are you just interested in an academic sense? Am not quite sure we've got to the bottom of the problem either. I'm reading all of the posts by the same OP and I'm getting the impression that either their app does something unusual with the ID itself (e.g. is passing it as a unique key between apps) or the OP is confused about sessions generally. p - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktHmbEACgkQ9CaO5/Lv0PA12wCgrWerDoJkpesgju5AqB0qDNwf QCYAnR4mMSFR/XrMZsqejZMIjqA7tgNs =uwly -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk: The worker pick order/scope when sticky_session=false and clusters are grouped by worker.domain
Thank you Rainer, it make me clear! And thank you for your creatation of
worker.domain directive :)
Rainer Jung-3 wrote:
On 05.01.2010 09:44, LiuYan 刘研 wrote:
I'm currently learning Tomcat clustering these days.
I setup 4 Tomcat-6.0.22 instances in Windows XP: server1, server2,
server3,
server4
cluster1: server1 server2 (228.0.0.4:45564)
cluster2: server3 server4 (228.0.0.4:45566)
Apache/2.2.14(win32) is the frontend. mod_jk-1.2.28 is the connector
between
Apache and Tomcats.
Start tomcats, start apache, then I visit
http://localhost/tomcatClusterTest/session-test.jsp 4 times, then I saw
each
tomcat server got a request.
What I expected is: server1 should get request #1,#3. server2 should get
request #2,#4. server3 and server4 should get no request because they are
another cluster and so they do not have the session which is created at
server1.
I read the comments of Bug 32317 - Making mod_jk replication aware
(Clustering Support) from here
https://issues.apache.org/bugzilla/show_bug.cgi?id=32317
I saw the following comment in bug description:
---
- without stickyness to decide to which workers an existing session
is
allowed to be balanced (all workers with the same domain as the worker
given
in
the session id)
No, in the current implementation domains are only used if the lb worker
is configured to use sticky sessions (default).
---
The comment is what I expected, but the test result is unexpected:
server3
server4 which belongs another domain/cluster are picked.
Is it a bug or I misunderand the meaning of the comment above?
workers.properties:
#---
worker.list=LoadBalancer
worker.LoadBalancer.type=lb
worker.LoadBalancer.balance_workers=server1,server2,server3,server4
worker.LoadBalancer.sticky_session=false
Use sticky sessions. Even when doing cluster session replication,
stickyness is usually better. Cluster+sticky only relies on the correct
replication if a node breaks.
worker.server1.host=localhost
worker.server1.port=8109
worker.server1.type=ajp13
worker.server1.lbfactor=1
worker.server1.domain=cluster1
worker.server2.host=localhost
worker.server2.port=8209
worker.server2.type=ajp13
worker.server2.lbfactor=1
worker.server2.domain=cluster1
worker.server3.host=localhost
worker.server3.port=8309
worker.server3.type=ajp13
worker.server3.lbfactor=1
worker.server3.domain=cluster2
worker.server4.host=localhost
worker.server4.port=8409
worker.server4.type=ajp13
worker.server4.lbfactor=1
worker.server4.domain=cluster2
#---
httpd.conf
#---
JkMount /tomcatClusterTest/* LoadBalancer
#...
#---
session-test.jsp
---
%@ page contentType='text/html' pageEncoding='GBK' %
pre style='font-size: 12px;'
%
String sUserName=(String)session.getAttribute (username);
Integer oRequestCounter=(Integer)session.getAttribute (request
counter);
int iRequestCounter = oRequestCounter!=null ? oRequestCounter.intValue()
:
0;
iRequestCounter ++;
session.setAttribute (request counter,
Integer.valueOf(iRequestCounter));
java.sql.Timestamp oSessionCreatedTime = new
java.sql.Timestamp(session.getCreationTime());
java.sql.Timestamp oSessionLastAccessedTime = new
java.sql.Timestamp(session.getLastAccessedTime());
String sSessionID = session.getId ();
java.sql.Timestamp currentTimestamp=new
java.sql.Timestamp(System.currentTimeMillis());
String sInfo =
---\n +
Request: # +iRequestCounter + \n +
Time: + currentTimestamp + \n +
Session:\n +
ID + sSessionID + \n +
Created + oSessionCreatedTime + \n +
Accessed+ oSessionLastAccessedTime + \n +
Attribute: username = + sUserName + \n +
Attribute: request counter = + session.getAttribute (request
counter) + \n +
;
System.out.println (sInfo);
out.println (sInfo);
if (sUserName==null)
{
session.setAttribute (username, MyName +new
java.sql.Time(System.currentTimeMillis()));
}
%
/pre
---
My test result:
server1:
---
Request: # 1
Time: 2010-01-05 16:01:10.687
Session:
ID 7E5BAD3313EF518C189B1237E7475D74.server1
Created2010-01-05 16:01:10.687
Accessed 2010-01-05 16:01:10.687
Attribute: username = null
Attribute: request
Re: Tomcat Filter Mapping Issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick, On 1/8/2010 6:17 PM, Patrick Flaherty wrote: Thanks a lot. I added a ROOT folder off my appBase and cut and pasted everything under that ROOT folder and now I am getting filter mapping hits with my ft.com ! We are not deploying correctly and this sheds all the light on that fact. Proper deployment is always a good idea. Then, everything works properly :) Curiously I was not able to get to ft.com/WEB-INF/web.xml , I got a 404. But I am able to get to other files off the root as expected. Maybe Tomcat has it's own filter mapping for /WEB-INF/web.xml ? I could not get to any file in /META-INF/* either ? If you deployed correctly under webapps/ROOT, then the WEB-INF folder and its contents should be protected by the DefaultServlet and should return a 404: this is expected behavior. If you have webapps/WEB-INF/web.xml, then I'd expect you to be able to successfully request /WEB-INF/web.xml because /WEB-INF looks like a context to Tomcat. It's possible that Tomcat actively protects [appBase]/WEB-INF similar to protecting a real webapp's WEB-INF directory, but it is not required to do so. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktI5vQACgkQ9CaO5/Lv0PBI+wCgkJrpG5w21CEZjYSYDCV6eTJq R6MAmQEO8EWXkoWm2aOjKS+ZZ8e0UqFI =HDIu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Uniqueness of a sessionId
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnab, On 1/9/2010 1:14 AM, Arnab Ghosh wrote: How it will be I create a new manager which will extend standardmanager and then if overload the generateSessionId() method. I will mot change the session Id generation code. Instead of that I will add a new static set and will store all generated sessionId there. I will continue the loop of generating a unique session Id until it get added in that static set (By default it will check a instance map where it used to store all session and sessionId as a key). Technically speaking, that's changing the session id generation code. :) I think if you do this, you're going to just create more trouble for yourself. What's the problem with different sessions in different webapps having the same session id? The sessions don't interfere with each other. The only problem is that they have the same session id. I can't understand why this is a problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktI5+YACgkQ9CaO5/Lv0PBkVgCgpq3fy2qGEaEm20IqSsEgrIQ2 C0QAnRlz+hGllZ7xRdFCvW1Cgb5byWIs =Ka8V -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to deploy java app. on Tomcat's virtual domains residing outside CATALINA_HOME?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leon, On 1/9/2010 9:38 AM, Leon Kolchinsky wrote: Yes instructions for Sakai actually say expand it into CATALINA_HOME. What are the top-level contents for the Sakai tarball? Is it a single directory? I would expect http://source.sakaiproject.org/release/2.6.1/artifacts/sakai-bin-2.6.1.tgz to expand to either a sakai-2.6.1 directory or maybe even webapps/sakai-2.6.1 or something like that. If you want to deploy Sakai onto your myserver029.somedomain.com virtual host, then you need to put the Sakai directory into one of two places: /srv/myserver029/Sakai (for http://myserver029.somedomain.com/Sakai) or /srv/myserver029/ROOT (for http://myserver029.somedomain.com/) You should also remove the Context elements from your conf/server.xml: they will cause nothing but confusion. O.K I may be wrong but http://sakai26.dyndns.org/servlets-examples/ is working. That's because you properly deployed them using these commands: cp -R /opt/tomcat/webapps/jsp-examples /srv/myserver029/ cp -R /opt/tomcat/webapps/servlets-examples /srv/sakai26/ I'd like to fix my configuration and I'm opened for suggestions. What should I change in my configs (I think that I gave a full configs and changes I've made to defaults)? Suggestions: 1. Remove the ApacheConfig Listener (as Mark already suggested) 2. Remove Context elements from conf/server.xml 3. Put Sakai into /srv/myserver029/Sakai or /srv/myserver029/ROOT (or /srv/sakai26/Sakai or /srv/sakai26/ROOT) 4. Eliminate Apache httpd: you're passing-through everything to Tomcat anyway I don't have an access to my linux server now but I've downloaded to J: drive on my win. machine it and there is a structure of tar.gz: [snip] J:\webapps\ access.war authn.war courier.war dav.war direct.war emailtemplateservice-tool.war library.war mailtool.war mercury.war osp-common-tool.war osp-glossary-tool.war osp-jsf-example.war osp-jsf-resource.war osp-matrix-tool.war osp-portal-tool.war osp-portal.war osp-presentation-tool.war osp-wizard-tool.war podcasts.war portal-render.war portal.war providers.war sakai-alias-tool.war sakai-announcement-tool.war sakai-archive-tool.war sakai-assignment-tool.war sakai-authz-tool.war sakai-axis.war sakai-axis2.war sakai-blogger-tool.war sakai-calendar-summary-tool.war sakai-calendar-tool.war sakai-chat-tool.war sakai-citations-tool.war sakai-content-tool.war sakai-fck-connector.war sakai-gradebook-testservice.war sakai-gradebook-tool.war sakai-help-tool.war sakai-jsf-resource.war sakai-login-tool.war sakai-mailarchive-james.war sakai-mailarchive-tool.war sakai-memory-tool.war sakai-message-tool.war sakai-messageforums-tool.war sakai-metaobj-tool.war sakai-news-tool.war sakai-podcasts.war sakai-poll-tool.war sakai-postem-tool.war sakai-presence-tool.war sakai-presentation-tool.war sakai-profile-tool.war sakai-reports-tool.war sakai-reset-pass.war sakai-rights-tool.war sakai-roster-tool.war sakai-rutgers-linktool.war sakai-rwiki-tool.war sakai-sample-tool-jsf.war sakai-sample-tool-servlet.war sakai-scheduler-tool.war sakai-search-tool.war sakai-sections-tool.war sakai-site-manage-group-helper.war sakai-site-manage-group-section-role-helper.war sakai-site-manage-participant-helper.war sakai-site-manage-tool.war sakai-site-pageorder-helper.war sakai-site-tool.war sakai-syllabus-tool.war sakai-tool-tool-su.war sakai-user-tool-admin-prefs.war sakai-user-tool-prefs.war sakai-user-tool.war sakai-usermembership-tool.war sakai-web-tool.war samigo.war savecite.war tool.war web.war wiki.war xsl-portal.war OMG Sakai is deploying 84 webapps into your container. :( I recommend contacting the Sakai community for instructions for how to deploy their application in ways other than their default binary installation procedure. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAktI7aUACgkQ9CaO5/Lv0PDB3ACdEyRsol3SeRFbvdSUCpqd0zFv 1V8Al0T+9q5LkXlCYuiy1L1IOsJW/v0= =7UdY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Nesting servlets with different credentials
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greg, On 1/6/2010 4:09 PM, Greg Allen wrote: I have two servlets, http://localhost:8080/s1 and http://localhost:8080/s2. Both servlets require BASIC authentication. My application will call s1, and then s1 will turn around and call s2. However, the credentials supplied to s2 need to be different than those supplied to s1. Inside of s1, I set up an instance of HttpClient and set the new credentials on it. Here's the code that does it: HostConfiguration config = new HostConfiguration(); HttpClient client = new HttpClient(); config.setHost(m_sHost, m_iPort, m_sProtocol); client.setHostConfiguration(config); Credentials credentials = new UsernamePasswordCredentials(m_sUser, m_sPassword); client.getState().setCredentials(AuthScope.ANY, credentials); client.getParams().setAuthenticationPreemptive(true); I then call client.executeMethod with the appropriate arguments to call into s2. The problem is that the call to s2 does not use the new credentials - it seems to be using the credentials that were used to access s1. In fact, I've removed the setting of the credentials on the client, and the call to s2 still succeeds (although as the wrong user). Your above code seems to look okay to me. Will it run outside of Tomcat - -- just a standalone Java program run directly from the command-line? I'm not sure how the credentials from the original request would be mixed-up with the completely unrelated HTTP connection that you are making using HttpClient. Is it possible that your observations are inaccurate? Perhaps the authentication you are seeing is due to a separate primary request and not this HttpClient-based request. I have verified this behavior by turning on logging in my JDBCRealm. I can see that authentication occurs for the call to s1, but there is no other authentication call made. I expected to see a second authentication for s2, but there was nothing. It appears as though there is some sort of caching going on here that I need to handle/disable. Can anyone shed any light on what is going on, and how to fix it? Tomcat is not interfering with your HttpClient connection. I would try to get it working with a simple Java class first, and then move it back into the servlet environment once it's working properly. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktI72QACgkQ9CaO5/Lv0PDK/gCfQaKHmaAI0eCXpqwoRpK0LhWE 20IAnRHLKMPEOkigfayKtThaoQaOpqEg =rRhz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Filter Mapping Issue
Chris, Although adding ROOT of my appBase fixed my Filter mapping issue, I'm guessing that I need to put every bit of my app (all classes, libs etc ) into that ROOT folder, correct ? So then if I decide to deploy another app in a virtual host say for instance : Host Name : www.domain.com appBase=c:/app123 If that has a folder called proofs that I want filter mapping hits on, do I created a ROOT folder off of my appBase (ie c:/app123/ROOT) and put every bit of my app (all classes, libs etc ) into that ROOT folder ? I'm sorry to belabor the point. I know that adding the ROOT folder fixed my initial problem but I not sure if that is because when only running 1 host it should be called ROOT or is it that every Host needs to have a ROOT folder off of it's appBase and everything should bit of the app should be put in there. It seems the ROOT folder was the key here but before we wanted to add filter mapping app worked fine when appBase is what we deemed to be the web root for the app. It has worked well like that for years. Is there a hard and fast rule about deployment that I'm missing ? (Probably) If there is. it seems to revolve around having a ROOT folder for each app maybe ? Any more enlightenment would be appreciated. Thanks once again. -P On Jan 9, 2010, at 3:28 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick, On 1/8/2010 6:17 PM, Patrick Flaherty wrote: Thanks a lot. I added a ROOT folder off my appBase and cut and pasted everything under that ROOT folder and now I am getting filter mapping hits with my ft.com ! We are not deploying correctly and this sheds all the light on that fact. Proper deployment is always a good idea. Then, everything works properly :) Curiously I was not able to get to ft.com/WEB-INF/web.xml , I got a 404. But I am able to get to other files off the root as expected. Maybe Tomcat has it's own filter mapping for /WEB-INF/web.xml ? I could not get to any file in /META-INF/* either ? If you deployed correctly under webapps/ROOT, then the WEB-INF folder and its contents should be protected by the DefaultServlet and should return a 404: this is expected behavior. If you have webapps/WEB-INF/web.xml, then I'd expect you to be able to successfully request /WEB-INF/web.xml because /WEB-INF looks like a context to Tomcat. It's possible that Tomcat actively protects [appBase]/WEB-INF similar to protecting a real webapp's WEB-INF directory, but it is not required to do so. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktI5vQACgkQ9CaO5/Lv0PBI+wCgkJrpG5w21CEZjYSYDCV6eTJq R6MAmQEO8EWXkoWm2aOjKS+ZZ8e0UqFI =HDIu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
401 Error with Basic Auth and Tomcat
Hello, I'm using the below httpd configuration in order to secure a resource (/reportsvcs_ws) using basic auth. When I hit the url https://host/reportsvcs_ws without authing, I'm prompted as expected but I get a http status code of 401 when accessing the resource. I get the same status code when I do auth prior to accessing the reportsvcs_ws resource. The reportsvcs_ws resource is also using mod_jk to direct the request from apache to tomcat. Any ideas? Of course when I remove the below httpd configuration the resource is accessible. Any ideas on what may be happening? Location /reportsvcs_ws Order allow,deny Allow from all AuthType Basic AuthName Report Service AuthUserFile filepath/usersfile require valid-user /Location -- View this message in context: http://old.nabble.com/401-Error-with-Basic-Auth-and-Tomcat-tp27093791p27093791.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Filter Mapping Issue
2010/1/10 Patrick Flaherty pflah...@rampageinc.com: Chris, Although adding ROOT of my appBase fixed my Filter mapping issue, I'm guessing that I need to put every bit of my app (all classes, libs etc ) into that ROOT folder, correct ? So then if I decide to deploy another app in a virtual host say for instance : Host Name : www.domain.com appBase=c:/app123 If that has a folder called proofs that I want filter mapping hits on, do I created a ROOT folder off of my appBase (ie c:/app123/ROOT) and put every bit of my app (all classes, libs etc ) into that ROOT folder ? I'm sorry to belabor the point. I know that adding the ROOT folder fixed my initial problem but I not sure if that is because when only running 1 host it should be called ROOT or is it that every Host needs to have a ROOT folder off of it's appBase and everything should bit of the app should be put in there. It seems the ROOT folder was the key here but before we wanted to add filter mapping app worked fine when appBase is what we deemed to be the web root for the app. It has worked well like that for years. Is there a hard and fast rule about deployment that I'm missing ? (Probably) If there is. it seems to revolve around having a ROOT folder for each app maybe ? Any more enlightenment would be appreciated. Thanks once again. ROOT (in uppercase) is not a folder, but a web application. It behaves like any other web application (You should remember, that web applications are independent of each other). The only difference is that it is mapped to the URL /. Every host should have a ROOT application. Any requests that cannot be mapped to any other web application will be directed to this one, so that it can show its 404th error page or otherwise process it. (If there is no ROOT application deployed, such requests cannot be processed and will result in a zero-length empty response.) If you have two applications /mywebapp /ROOT then - any request to /myweapp/foo will be processed by mywebapp (and the ROOT one will not see it at all), - any request to /myweapp2/foo will be processed by ROOT (because there is no myweapp2 application to process it). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Filter Mapping Issue
-- From: Konstantin Kolinko knst.koli...@gmail.com Sent: Saturday, January 09, 2010 7:00 PM To: Tomcat Users List users@tomcat.apache.org Subject: Re: Tomcat Filter Mapping Issue 2010/1/10 Patrick Flaherty pflah...@rampageinc.com: Chris, Although adding ROOT of my appBase fixed my Filter mapping issue, I'm guessing that I need to put every bit of my app (all classes, libs etc ) into that ROOT folder, correct ? So then if I decide to deploy another app in a virtual host say for instance : Host Name : www.domain.com appBase=c:/app123 If that has a folder called proofs that I want filter mapping hits on, do I created a ROOT folder off of my appBase (ie c:/app123/ROOT) and put every bit of my app (all classes, libs etc ) into that ROOT folder ? I'm sorry to belabor the point. I know that adding the ROOT folder fixed my initial problem but I not sure if that is because when only running 1 host it should be called ROOT or is it that every Host needs to have a ROOT folder off of it's appBase and everything should bit of the app should be put in there. It seems the ROOT folder was the key here but before we wanted to add filter mapping app worked fine when appBase is what we deemed to be the web root for the app. It has worked well like that for years. Is there a hard and fast rule about deployment that I'm missing ? (Probably) If there is. it seems to revolve around having a ROOT folder for each app maybe ? Any more enlightenment would be appreciated. Thanks once again. ROOT (in uppercase) is not a folder, but a web application. Yes, that is understood. It behaves like any other web application (You should remember, that web applications are independent of each other). The only difference is that it is mapped to the URL /. Your say the ROOT app is mapped to URL / then yes that is understood. Every host should have a ROOT application. Meaning every host should have a ROOT app regardless of whether you are hosting ONE or MORE apps on a host ! Any requests that cannot be mapped to any other web application will be directed to this one, so that it can show its 404th error page or otherwise process it. (If there is no ROOT application deployed, such requests cannot be processed and will result in a zero-length empty response.) If you have two applications /mywebapp /ROOT then - any request to /myweapp/foo will be processed by mywebapp (and the ROOT one will not see it at all), That is what I had. I had the ROOT app off the webapps folder of a default Tomcat install. We then created a virtual host (with a real domain name) where OUR app responded to that domain name. (ie Host Name : www.myapp.com appBase = c:/myapp) Everything in this config has worked for a couple years. The infamous Proofs folder was located in c:/myapp/Proofs which I assume c:/myapp to be the web root for this www.myapp.com host. It seems to have always behaved as such. Am I ok up to this point ? (maybe not ?) Finally we decided a wanted to use Filter Mapping for added security. Filter Mapping would not give us a hit for an URL's of type http://www.myapp.com/Proofs/* (our filter map using /Proofs/*). After suggestions from the forum about moving the app (WEB_INF and all) under a ROOT folder I added to c:/myapp folder which now contains everything for the app under it, viola, Filter Mapping started to work ! I don't know why this was the case but I went with it. - any request to /myweapp2/foo will be processed by ROOT (because there is no myweapp2 application to process it). Do people have secondary app (after ROOT) setup like I described above running with filter mapping functioning ? Seems like maybe a bug to me or a misconfiguration of some sort on my part. Thanks again Konstantin and other. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Uniqueness of a sessionId
Dear Friends, Actually in my app I will be having 100 - 200 separte application/context which will forward request to a separate application / context running under same tomcat. I am doing this using cross-context mechanism. By this way I can reuse the servlets/jsp instances of that context. But if you follow the logic - it will be like this - 1. A new request came to context A. It will create a session and add a cookie jsessionid and will forward to main app. 2. The main app will create a new session using the jessionid added by context A. 3. Now another request came to context B. It will also do the same thing and forward to main app. Here is my doubt. Suppose the jessionid created by context B may exist in main app (may be created and then forwarded by some other context C). Then that request will be using that old session. right?? Still now I haven't faced that problem. But if it happens in production time it will be tough to get the problem. Now first of all I am not sure whether this can happen or not. Because every day there will be 100 contexts and each will be having a minimum 50 sessions. Thanks, Ghosh
RE: Tomcat Filter Mapping Issue
From: Patrick Flaherty [mailto:pflah...@rampageinc.com] Subject: Re: Tomcat Filter Mapping Issue Meaning every host should have a ROOT app regardless of whether you are hosting ONE or MORE apps on a host ! Correct. That is what I had. I had the ROOT app off the webapps folder of a default Tomcat install. No, that ROOT app applied only to the default Host - no others. Each Host has an entirely separate and independent set of webapps. We then created a virtual host (with a real domain name) where OUR app responded to that domain name. (ie Host Name : www.myapp.com appBase = c:/myapp) No, an app is not equivalent to a domain (Host) name. As stated previously by several of us, the ROOT app for the particular Host will handle any requests directed to the Host that do not map to any other apps *for that Host*. Again, each Host is completely independent of the others. Everything in this config has worked for a couple years. The infamous Proofs folder was located in c:/myapp/Proofs which I assume c:/myapp to be the web root for this www.myapp.com host. Whatever you had working appears to have been dumb luck, and dependent on undefined behavior of having an empty docBase (which is illegal). After suggestions from the forum about moving the app (WEB_INF and all) under a ROOT folder I added to c:/myapp folder which now contains everything for the app under it, viola, Filter Mapping started to work ! Because you were finally using a valid configuration. Do people have secondary app (after ROOT) setup like I described above running with filter mapping functioning ? Sure. The filter mapping goes into the WEB-INF/web.xml of the webapp, regardless of the webapp's name. Seems like maybe a bug to me or a misconfiguration of some sort on my part. Misconfiguration, and misunderstanding of the independence of Host elements along with the proper use of appBase and the derivation of each app's docBase. - 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
