tomcat-users.xml on Tomcat6
Hello, I've failed login on manager webapp and host-manager webapp. I've add the manager and admin role on tomcat-users.xml [/etc/tomcat6/tomcat-users.xml]. The status is HTTP Status 500. ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin / user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=za password=za roles=manager / user username=ki password=ki roles=admin / /tomcat-users I am using Debian Lenny (Testing). -- Zaki Akhmad - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat cluster fails and generates tons of logs
Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire and generate a ton of logs repeating the following: Aug 25, 2009 11:44:10 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) That's the only thing that it shows. The other node in the cluster is still active at this time. There's nothing to do but to restart. The large amount of logs has caused disk space issues more than a couple of times too. Does anybody have any idea what's wrong here? Thanks! Wong
Re: tomcat-users.xml on Tomcat6
Zaki Akhmad schrieb: I've failed login on manager webapp and host-manager webapp. I've add the manager and admin role on tomcat-users.xml [/etc/tomcat6/tomcat-users.xml]. The status is HTTP Status 500. What's the message in the error log? Did you restart Tomcat? Did you read the doc concerning the MemoryRealm? http://localhost:8080/docs/realm-howto.html#MemoryRealm The usual expert advice on this list is to avoid the prepackaged Tomcat and install the real one that can be downloaded from the Apache site. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat-users.xml on Tomcat6
Zaki Akhmad wrote: Hello, I've failed login on manager webapp and host-manager webapp. I've add the manager and admin role on tomcat-users.xml [/etc/tomcat6/tomcat-users.xml]. The status is HTTP Status 500. That does not look like a login error, it looks like a server error. What does the Tomcat log say ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat cluster fails and generates tons of logs
CS Wong schrieb: Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire Could you elaborate on what going haywire means? Below, you write: [The NoSuchElementException is] the only thing that it shows. The other node in the cluster is still active at this time. There's nothing to do but to restart. The large amount of logs has caused disk space issues more than a couple of times too. So is that server not active any more? Unresponsive? Hyperactive writing to the log file? Looping? and generate a ton of logs repeating the following: Aug 25, 2009 11:44:10 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) I only found this, which seems to have led you here: http://stackoverflow.com/questions/1326336/ Maybe it is helpful to others who know about Tomcat internals. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Embedded tomcat not displaying page content
Hi All, I've the following configuration: 1. Embedded tomcat (catalina-5.5.9.jar) 2. JSF pages (jsf-api-1.1.01.jar) 3. Java 6 My server starts up fine and listens on the configured port number. However, when i request for a page, it displays a blank html page as following htmlhead/body/body/html I used to run the server on java 5 all this while. Now there has been a request to upgrade to java 6 and am stuck with the problem. There are no errors, no exceptions to help me proceed. Any place to look for tomcat logs I hope that someone has walked this path before... -- View this message in context: http://www.nabble.com/Embedded-tomcat-not-displaying-page-content-tp25129955p25129955.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 cluster fails and generates tons of logs
Hi Michael, The logs are the bit that went haywire. The applications at this point still work but often, there's not enough time to troubleshoot much else. The logs can increase by 5-6GB in a matter of an hour or so and hence, we often just kill the service (normal shutdown.sh doesn't respond any more at this point, we have to kill -9 it) in panic and delete the logs before the entire server goes kaboom. This time, I managed to tail out some of the logs, for which I pasted an extract (same repeating pattern of errors): Aug 25, 2009 11:44:02 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Wong On Tue, Aug 25, 2009 at 3:36 PM, Michael Ludwig m...@as-guides.com wrote: CS Wong schrieb: Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire Could you elaborate on what going haywire means? Below, you write: [The NoSuchElementException is] the only thing that it shows. The other node in the cluster is still active at this time. There's nothing to do but to restart. The large amount of logs has caused disk space issues more than a couple of times too. So is that server not active any more? Unresponsive? Hyperactive writing to the log file? Looping? and generate a ton of logs repeating the following: Aug 25, 2009 11:44:10 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) I only found this, which seems to have led you here: http://stackoverflow.com/questions/1326336/ Maybe it is helpful to others who know about Tomcat internals. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat integration with Ldap
Hello,
I am trying to configure a JNDI Realm in my tomcat server and access the URL
given in the examples http://localhost:8080/jsp-examples/security/protected/
The user Id and password I am entering is getting authenticated , but I am
still not able to login, I get redirected to the error page with the following
error message
HTTP Status 403 - Access to the requested resource has been denied
I have configured the realm in server.xml as follows:
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
contextFactory=com.sun.jndi.ldap.LdapCtxFactory
connectionURL=ldap://10.116.10.118:1389;
connectionName=tomcat
connectionPassword=tomcat
roleBase=cn=SingleSignOn,cn=groups,dc=test,dc=com
roleName=cn
roleSearch=uniqueMember={0}
roleSubtree=true
userBase=cn=users,dc=test,dc=com
userPassword=userPassword
userPattern=uid={0},cn=users,dc=test,dc=com
userSearch=uid={0} /
and I have added the same under security/protected/META-INF/context.xml as
follows:
?xml version=1.0 encoding=UTF-8?
Context path=/jsp-examples/*
Realm className=org.apache.catalina.realm.JNDIRealm debug=99
contextFactory=com.sun.jndi.ldap.LdapCtxFactory
connectionURL=ldap://10.116.10.118:1389;
connectionName=cn=root
connectionPassword=password
roleBase=cn=SingleSignOn,cn=groups,dc=test,dc=com
roleName=cn
roleSearch=uniqueMember={0}
roleSubtree=true
userBase=cn=users,dc=test,dc=com
userPassword=userPassword
userPattern=uid={0},cn=users,dc=test,dc=com
userSearch=uid={0} /
/Context
The web.xml is as follows
security-constraint
web-resource-collection
web-resource-nameProtected Area/web-resource-name
!-- Define the context-relative URL(s) to be protected --
url-pattern/protected/*/url-pattern
/web-resource-collection
auth-constraint
!-- Anyone with one of the listed roles may access this area --
role-nameSingleSignOn/role-name
/auth-constraint
/security-constraint
!-- Default login configuration uses form-based authentication --
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/protected/login.jsp/form-login-page
form-error-page/protected/error.jsp/form-error-page
/form-login-config
/login-config
!-- Security roles referenced by this web application --
security-role
role-nameSingleSignOn/role-name
/security-role
If I check the logs I get the following information
2009-08-25 11:45:35 JNDIRealm[Catalina]: Connecting to URL
ldap://10.116.10.118:1389
2009-08-25 11:50:24 JNDIRealm[Catalina]: lookupUser(itadmin)
2009-08-25 11:50:24 JNDIRealm[Catalina]:
dn=uid=itadmin,cn=users,dc=test,dc=com
2009-08-25 11:50:27 JNDIRealm[Catalina]: retrieving attribute userPassword
2009-08-25 11:50:27 JNDIRealm[Catalina]: validating credentials
2009-08-25 11:50:27 JNDIRealm[Catalina]: Username itadmin successfully
authenticated
2009-08-25 11:50:27 JNDIRealm[Catalina]:
getRoles(uid=itadmin,cn=users,dc=test,dc=com)
2009-08-25 11:50:27 JNDIRealm[Catalina]: Searching role base
'cn=SingleSignOn,cn=groups,dc=test,dc=com' for attribute 'cn'
2009-08-25 11:50:27 JNDIRealm[Catalina]: With filter expression
'uniqueMember=uid=itadmin,cn=users,dc=test,dc=com'
2009-08-25 11:50:27 JNDIRealm[Catalina]: retrieving values for attribute cn
2009-08-25 11:50:27 JNDIRealm[Catalina]: Returning 1 roles
2009-08-25 11:50:27 JNDIRealm[Catalina]: Found role SingleSignOn
I tried various combinations but everytime I get the access deined error page.
I googled for the JNDIRealm class source, but I am not able to understand the
concept of ROLE here. What exactly is being looked for in role based
authentication? Is there any way the roles can be surpassed? How the the
j_security_check work? How can we enhance its debugging level?
Cheers :)
Varsha
No one can go back and make a brand new start.
Anyone can start from now and make a brand new
ending...
P Please do not print this email unless it is absolutely necessary. Spread
environmental awareness
DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates.
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of HCL or its affiliates.
Any form of
Jakarta Connector 1.2.28 with Windows Server 2008 32bit, IIS 7.0
Michael Wall Nordic Edge AB Mobile: +46 (0)70 250 83 20 Business card: www.nordicedge.se/mwall Visit us on the web at: www.nordicedge.se __ -- Forwarded message -- From: Michael Wall mw...@nordicedge.se Date: Tue, Aug 25, 2009 at 1:05 PM Subject: Jakarta Connector 1.2.28 with Windows Server 2008 32bit, IIS 7.0 To: users@tomcat.apache.org Hello Can anyone help me found out a solution on this problem? I have tried to use Jakarta Connector 1.2.28 with Windows Server 2008 32bit, for SSO through IIS 7.0 The message I get from IIS is: HTTP Error 500.0 - Internal Server Error Calling GetFilterVersion on ISAPI filter C:\ajp\bin\isapi_redirect.dll failed Have basically followed the guide in: http://www.jboss.org/community/wiki/UsingModjk12WithJBossAndIIS7 even if I not have jboss ( only tomcat) I have checked up the permissions in IIS/Explorer/Registry. Regards / Michael Wall Michael Wall Nordic Edge AB Mobile: +46 (0)70 250 83 20 Business card: www.nordicedge.se/mwall Visit us on the web at: www.nordicedge.se __
Re: Problem closing datasource when used as JNDI resource
Since you don't seem to be able to google yourself, here is the link. http://www.mail-archive.com/users@tomcat.apache.org/msg65149.html Mohammed Bin Mahmood wrote: Hi Chris, You mentioned about the published filter that can close datasource. I wonder if you have any idea about that. Is it provided by tomcat or some other Thanks, Mohammed. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, August 24, 2009 7:48 PM To: Tomcat Users List Subject: Re: Problem closing datasource when used as JNDI resource Mohammed, On 8/24/2009 12:49 AM, Mohammed Bin Mahmood wrote: Hi Chris, 3. There is a published filter that can close the DataSource for you. Do you have any idea about the filter that can close the Datasource? What? -chris - 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 -- Mark Shifman MD. Ph.D. Yale Center for Medical Informatics Phone (203)737-5219 mark.shif...@yale.edu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JNDI-Datasource: what happens if the database is not ready when Tomcat starts?
Hi, I am looking into using the JNDI/Datasource facility in Tomcat 5.5 to connect to a mySQL 5.0 database on a Windows 2003 server. Both Tomcat and mySQL run as services. What happens if the Tomcat service starts before mySQL? Does Tomcat wait for a while for the DB to be ready? Does it launch the apps or wait until the DB is ready? Thanks Fred
Re: JNDI-Datasource: what happens if the database is not ready when Tomcat starts?
Fred Janon wrote: I am looking into using the JNDI/Datasource facility in Tomcat 5.5 to connect to a mySQL 5.0 database on a Windows 2003 server. Both Tomcat and mySQL run as services. What happens if the Tomcat service starts before mySQL? Does Tomcat wait for a while for the DB to be ready? Does it launch the apps or wait until the DB is ready? It depends on DataSource implementation and configuration. AFAIK Tomcat uses repackaged commons-dbcp - http://commons.apache.org/dbcp/ -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat cluster fails and generates tons of logs
what version of Tomcat, and we will get it fixed On 08/25/2009 12:22 AM, CS Wong wrote: Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire and generate a ton of logs repeating the following: Aug 25, 2009 11:44:10 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) That's the only thing that it shows. The other node in the cluster is still active at this time. There's nothing to do but to restart. The large amount of logs has caused disk space issues more than a couple of times too. Does anybody have any idea what's wrong here? Thanks! Wong - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual Hosts and manager application.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wesley, On 8/24/2009 5:20 PM, Wesley Acheson wrote: Off topic is it wrong to reply to two emails like this in one mail (for threading purposes?) While not wrong, it is kind of confusing. There's no particular reason not to reply to messages individually. Your apps will be deployed at least twice, maybe more. Why don't you use just use the manager webapp from where it gets installed by default (in CATALINA_HOME/server/webapps/manager)? Its being deployed once per host. I need more than one because the standard manager install only works for one host. Right, I get it. But, since the manager app is also sitting in Tomcat's webapps directory, which has auto-deploy turned-on for your localhost Host, it will deployed there as well. I'm not sure there's really a problem with that (it's just another deployment, under a different Host), but I just wanted to point out that it /will/ be deployed twice in your configuration, when you are trying to really have it only deploy once (for testing). This is similar to the instructions at http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html A default Tomcat installation includes the manager. To add an instance of the Manager web application Context to a new host install the manager.xmlcontext configuration file in the $CATALINA_BASE/conf/[enginename]/[hostname] folder. Here is an example: Context path=/manager debug=0 privileged=true docBase=/usr/local/kinetic/tomcat6/server/webapps/manager /Context Somebody boned those instructions: the path attribute should not be set. If you have Tomcat configured to support multiple virtual hosts (websites) you would need to configure a Manager for each. Yup, and it's as easy as duplicating the manager.xml file into each of your conf/Catalina/[hostname] directories. You shouldn't have to do anything else at all (except maybe modify the ResourceLink to point to maybe another type of user database. I did a direct copy [of manager.xml]. I only started changing it after I ran into the problem even then I don't think I changed it much. What problems were you having? Those mentioned in your original post (like Document base .../apache-tomcat-6.0.20/./manager does not exist)? The only reason I can think of to get that odd error would be to mess with the docBase in the manager.xml file itself. Otherwise, I'm at a loss. I might suggest wiping your TC install and starting again, step-by-step. It's possible that you're broken something else somewhere and we'll have a tough time finding it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqT9YAACgkQ9CaO5/Lv0PCS1QCghtkCCglzZj19CqywFXyRipb6 EAYAnifZVMGkJb5IkzjTnOEKE6LCaRqG =7s1B -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 4 start up as (/sbin/service)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sunil, On 8/25/2009 1:24 AM, sunil chandran wrote: Now can i stop tomcat service and take a backup of tomcat 4 directory. Then install the new tomcat4.1.40 in the same location. That way i need not change the directory location in any files too. right? so once i install tomcat4.1.40 in the same location (where previous tomcat4 was running) the script/etc/init.d/tomcat4 will run the new tomcat4.1.40? That might work. Since Tomcat doesn't install any files in /etc, I don't think installing a new version of Tomcat or uninstalling the old one will remove them. I would allow Tomcat to install itself into .../apache-tomcat-4.1.40 instead of trying to make the directory names match. You might confuse yourself by having a 4.1.40 install in a directory named 4.1.24. You could also use the magic of symlinks like this: /usr/local/tomcat - /usr/local/apache-tomcat-4.0.40 Then, all your scripts can point to /usr/local/tomcat and not a specific version. You could always read the scripts to find out what's going on. I suspect they are quite simple. At this point, if you don't know what to do, perhaps you should get someone else to perform this upgrade. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqT9jwACgkQ9CaO5/Lv0PA2/ACePaJtVt4cMz+td19qVzkclWjK yWYAn25Inu0ooDvEzRiS8qDdU5jjr7C4 =YIiJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: SSL with multiple Tomcat instances
Sal, Thanks so much for the reply. I think the server.xml reference is correct. Here is the connector segment from that instance: Connector port=8443 address=172.18.19.16 maxThreads=600 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=conf/webui.keystore/ We are using 8443 instead of 443 and have iptables set up to reroute any outside traffic that comes in on 443 to 8443. The other instance uses 172.18.19.15 and the default keystore (~/.keystore). As far as I can tell, that is all working OK. Here is what I get from the command openssl s_client -connect webui.ashland.edu:8443: CONNECTED(0003) depth=2 /C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu i:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com 1 s:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es 2 s:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es --- Server certificate -BEGIN CERTIFICATE- MIIGMzCCBZygAwIBAgIDExqhMA0GCSqGSIb3DQEBBQUAMIIBEjELMAkGA1UEBhMC RVMxEjAQBgNVBAgTCUJhcmNlbG9uYTESMBAGA1UEBxMJQmFyY2Vsb25hMSkwJwYD VQQKEyBJUFMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgcy5sLjEuMCwGA1UEChQl Z2VuZXJhbEBpcHNjYS5jb20gQy5JLkYuICBCLUI2MjIxMDY5NTEuMCwGA1UECxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEuMCwGA1UEAxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GCSqGSIb3 DQEJARYRZ2VuZXJhbEBpcHNjYS5jb20wHhcNMDkwODIwMDczNDQ0WhcNMTEwODIw MDczNDQ0WjCBgzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE9oaW8xEDAOBgNVBAcT B0FzaGxhbmQxGzAZBgNVBAoTEkFzaGxhbmQgVW5pdmVyc2l0eTEaMBgGA1UECxMR QWRtaW5pc3RyYXRpdmUgSVQxGjAYBgNVBAMTEXdlYnVpLmFzaGxhbmQuZWR1MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDBbiTihyoSVlDyVkIoMu97eZxKJrv e0SvdhRO5JIG9O5ov82Pa4NtE2xYPvjMOk20ffEs76m/pAUz3CLao4UxjjpfhxNp 1Y2gQc+0u22R6pPmaPHk2hUEBTCGdHaCVHJ0LwFb+mN4lnZg1dntM7KouKMBGAiV AL9HzMAtoRjiQQIDAQABo4IDITCCAx0wCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBkAwCwYDVR0PBAQDAgP4MBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQW BBQwuRGoE8SxdjtLQPKJoHffiYQeizAfBgNVHSMEGDAWgBQOB2DUOckbW12QeyPI 0jSdSppGOTAJBgNVHREEAjAAMBwGA1UdEgQVMBOBEWdlbmVyYWxAaXBzY2EuY29t MHIGCWCGSAGG+EIBDQRlFmNPcmdhbml6YXRpb24gSW5mb3JtYXRpb24gTk9UIFZB TElEQVRFRC4gQ0xBU0VBMSBTZXJ2ZXIgQ2VydGlmaWNhdGUgaXNzdWVkIGJ5IGh0 dHBzOi8vd3d3Lmlwc2NhLmNvbS8wLwYJYIZIAYb4QgECBCIWIGh0dHBzOi8vd3d3 Lmlwc2NhLmNvbS9pcHNjYTIwMDIvMEMGCWCGSAGG+EIBBAQ2FjRodHRwczovL3d3 dy5pcHNjYS5jb20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3JsMEYGCWCG SAGG+EIBAwQ5FjdodHRwczovL3d3dy5pcHNjYS5jb20vaXBzY2EyMDAyL3Jldm9j YXRpb25DTEFTRUExLmh0bWw/MEMGCWCGSAGG+EIBBwQ2FjRodHRwczovL3d3dy5p cHNjYS5jb20vaXBzY2EyMDAyL3JlbmV3YWxDTEFTRUExLmh0bWw/MEEGCWCGSAGG +EIBCAQ0FjJodHRwczovL3d3dy5pcHNjYS5jb20vaXBzY2EyMDAyL3BvbGljeUNM QVNFQTEuaHRtbDCBgwYDVR0fBHwwejA5oDegNYYzaHR0cDovL3d3dy5pcHNjYS5j b20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3JsMD2gO6A5hjdodHRwOi8v d3d3YmFjay5pcHNjYS5jb20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3Js MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuaXBzY2Eu Y29tLzANBgkqhkiG9w0BAQUFAAOBgQBWxO6m/tvgkW9Ig55akiS9qeUA9pAmPv3O nvNnVOuEkaEFJTBKHRbV1QfijXg2Dnj8oQymSaDO7uZAJ6+anvuZCyySBDNzKDDq FCeMTYPGwaatm7pzCpEB624pFSTh7lTRaXVkWm8H6MAqrnUOCKduwxxwkd99Hc6M rsRvZa8n7Q== -END CERTIFICATE- subject=/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu issuer=/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com --- No client certificate CA names sent --- SSL handshake has read 4351 bytes and written 332 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit SSL-Session: Protocol : TLSv1 Cipher: EDH-RSA-DES-CBC3-SHA Session-ID: 4A93F78D22EC7D121452193F531141E5E54860B0FCCC566D5A462F5D5ADC7CAD Session-ID-ctx: Master-Key: AE497F11ACFA4088628F39AFCD30CD04A3F4EA0FAE7C4423338C3AEE22C40F791C6DC110A73F0082FC7870140BDA4560 Key-Arg
Re: Tomcat cluster fails and generates tons of logs
I've taken a look at the code. The fix for this is easy, but it doesn't explain why it happens. This is a concurrency issue, but if you're not running the latest tomcat version, then it could already have been fixed. best Filip On 08/25/2009 01:55 AM, CS Wong wrote: Hi Michael, The logs are the bit that went haywire. The applications at this point still work but often, there's not enough time to troubleshoot much else. The logs can increase by 5-6GB in a matter of an hour or so and hence, we often just kill the service (normal shutdown.sh doesn't respond any more at this point, we have to kill -9 it) in panic and delete the logs before the entire server goes kaboom. This time, I managed to tail out some of the logs, for which I pasted an extract (same repeating pattern of errors): Aug 25, 2009 11:44:02 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Wong On Tue, Aug 25, 2009 at 3:36 PM, Michael Ludwigm...@as-guides.com wrote: CS Wong schrieb: Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire Could you elaborate on what going haywire means? Below, you write: [The NoSuchElementException is] the only thing that it shows. The other node in the cluster is still active at this time. There's nothing to do but to restart. The large amount of logs has caused disk space issues more than a couple of times too. So is that server not active any more? Unresponsive? Hyperactive writing to the log file? Looping? and generate a ton of logs repeating the following: Aug 25, 2009 11:44:10 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) I only found this, which seems to have led you here: http://stackoverflow.com/questions/1326336/ Maybe it is helpful to others who know about Tomcat internals. -- Michael Ludwig - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 301 redirect
I have my application running on tomcat 5.5, it only has static pages. I removed some page from my application and want to redirect any request to deleted resource to homepage. Can someone point me how this can be done. -- View this message in context: http://www.nabble.com/Tomcat-301-redirect-tp25139277p25139277.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 301 redirect
On Tue, Aug 25, 2009 at 10:59 AM, Murtuzakhanmurt...@gmail.com wrote: I have my application running on tomcat 5.5, it only has static pages. I removed some page from my application and want to redirect any request to deleted resource to homepage. Can someone point me how this can be done. A custom 404 page would be the easiest, I'd think. -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Idea to simplify deployments
Hello,
The deployment approach currently used for web application and
enterprise application is slightly annoying. If I deploy five
applications to a servlet engine,
I will package the same libs 5 times and copy them to my server.
Packing them into the shared library folder of the application server is
not a solution to this problem but a workaround with a lot of unwanted
consequences.
My proposal is to just allow adding a simple text file into the lib
folder of WAR or EAR archives instead of adding jar files. This file
describes which libs, the application server should load from a local
directory or an HTTP connection when starting the application.
Here is a sample content of such a libraries.properties file. Optionally
a system variable can be used as well.
${java.repository}/foo.jar
${java.repository}/bar.jar
${java.repository}/bazz.jar
file://home/bar/manualcopied.jar
htt://anotherserver/xyz.jar
Jars are no longer included with the application but I basically fill a
repository on my server using Maven or Apache Ivy or copy and paste.
Then I reference those libraries in the libraries.properties file.
What do you think about the idea?
As reference, I published the idea on my blog.
http://www.laliluna.de/blog/2009/08/21/better_java_application_packaging_jsr_277_java_module_system.html
I posted this message to the Jetty user list as well.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 301 redirect
I only want to re-link old uri to home page and any request which does not
exist to error page. I added
error-page
error-code404/error-code
location/404.jsp/location
/error-page
to web.xml and used below code which I found after google but
request.getRequestURI() returns 404.jsp rather then the old-page.html, so it
did not redirect the request.
%
//get the requested URI
String requestedLocation = request.getRequestURI();
//variable to store new location, if it exists
String newLocation;
/*
do a database lookup (or other means to match up the requested URI with
one you wish to redirect).
*/
if (requestedLocation.equals(/myApp/old-page.html))
{
/*add some code in here to set the newLocation variable to a valid page*/
newLocation = http://localhost:8080/myApp/;;
//send HTTP 301 status code to browser
response.setStatus(response.SC_MOVED_PERMANENTLY);
//send user to new location
response.setHeader(Location, newLocation);
}
%
--
View this message in context:
http://www.nabble.com/Tomcat-301-redirect-tp25139277p25139686.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 301 redirect
On Tue, Aug 25, 2009 at 11:26 AM, Murtuzakhanmurt...@gmail.com wrote: I only want to re-link old uri to home page and any request which does not exist to error page. I added error-page error-code404/error-code location/404.jsp/location /error-page to web.xml and used below code which I found after google but request.getRequestURI() returns 404.jsp rather then the old-page.html, so it did not redirect the request. The Servlet Spec is your friend :-) SRV.8.4.2 Forwarded Request Parameters /* that's the section in 2.5, anyway */ -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Idea to simplify deployments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian, On 8/25/2009 2:20 PM, Sebastian Hennebrueder wrote: My proposal is to just allow adding a simple text file into the lib folder of WAR or EAR archives instead of adding jar files. This file describes which libs, the application server should load from a local directory or an HTTP connection when starting the application. Tomcat is almost certainly not going to do this unless the Java Servlet Specification adopts this practice. You can implement your own ClassLoader that consults a file for its CLASSPATH and instruct Tomcat to use that if you'd like. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqUYcMACgkQ9CaO5/Lv0PDaNQCgsc7b0KoU9/NYAfkU8S1sjAbA g/MAn3MCvUOU6vIjlWXebPb566QEKLA9 =Jifq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Trying to configure mod_jk
Greetings I have been trying to get this to work for hours and I am stuck. I am trying to configure mod_jk and it works to a point, that is up until the back end app does a redirect, the redirected url is passed all the way back to the browser, then the browser goes directly against the app server bypassing my apache and mod_jk. Is there a way to make mod_jk fix this redirected url so that is gets pointed back at my proxy server? Any help greatly appreciated Thanks troy CONFIDENTIALITY NOTICE: This communication, including any attachments, may contain confidential information and is intended only for the individual or entity to whom it is addressed. Any review, dissemination, or copying of this communication by anyone other than the intended recipient is strictly prohibited. If you are not the intended recipient, please notify us immediately by reply email to priv...@ifmc.org and delete or destroy all copies of the original message and any attachments thereto. Email sent to or from the Iowa Foundation for Medical Care or any of its member companies may be retained as required by law or regulation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Multiple data centers and redundency?
Hi, I have been asked to look into a solution that would involve a few different data centres each with their own set of load balanced Tomcat servers. The requirement is for the users not to lose their session if one data center goes down. I have never had to work on something this large and have no idea to what extent this can be achieved with Tomcat. My initial thoughts would be for each data center to have a session pool, which is synced with each other, so if ever a Tomcat server or data center goes down they can check in the pool to see if it exists and then reuse that. It would mean extra communication behind the scene, but I see no other way go about it. Any help would be appreciated. André-John - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple data centers and redundency?
Hi, I have just been given some more information. The architecture would involve a DNS server perodically giving out a DNS address for one DNS server and then an address for the other. Each data centre would have multiple hosts, each running multiple tomcats. The load balancer would take the incoming request and send it to one of the tomcat instances, using a cookie to send the request back to the same tomcat instance. I see there is clustering available with Tomcat, but I don't see how this works across data centers, if at all. André-John On 25-Aug-2009, at 20:30, Andre-John Mas wrote: Hi, I have been asked to look into a solution that would involve a few different data centres each with their own set of load balanced Tomcat servers. The requirement is for the users not to lose their session if one data center goes down. I have never had to work on something this large and have no idea to what extent this can be achieved with Tomcat. My initial thoughts would be for each data center to have a session pool, which is synced with each other, so if ever a Tomcat server or data center goes down they can check in the pool to see if it exists and then reuse that. It would mean extra communication behind the scene, but I see no other way go about it. Any help would be appreciated. André-John - 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: Tomcat cluster fails and generates tons of logs
Thanks, Filip. I'm running 6.0.14 right now. Would you have any idea whether any changes in the code since then would have fixed something like this? I can try to push for an upgrade to 6.0.20 but the app owners would probably want to know whether it would be fixed for sure since they have to go through a rather troublesome round of testing which takes up quite a bit of time. It helps that they know that the problem won't reoccur once this has been done. Thanks, Wong On Tue, Aug 25, 2009 at 11:35 PM, Filip Hanik - Dev Lists devli...@hanik.com wrote: I've taken a look at the code. The fix for this is easy, but it doesn't explain why it happens. This is a concurrency issue, but if you're not running the latest tomcat version, then it could already have been fixed. best Filip On 08/25/2009 01:55 AM, CS Wong wrote: Hi Michael, The logs are the bit that went haywire. The applications at this point still work but often, there's not enough time to troubleshoot much else. The logs can increase by 5-6GB in a matter of an hour or so and hence, we often just kill the service (normal shutdown.sh doesn't respond any more at this point, we have to kill -9 it) in panic and delete the logs before the entire server goes kaboom. This time, I managed to tail out some of the logs, for which I pasted an extract (same repeating pattern of errors): Aug 25, 2009 11:44:02 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Wong On Tue, Aug 25, 2009 at 3:36 PM, Michael Ludwigm...@as-guides.com wrote: CS Wong schrieb: Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire Could you elaborate on what going haywire means? Below, you write: [The NoSuchElementException is] the only thing that it shows. The other node in the cluster is still active at this time. There's nothing to do but to restart. The large amount of logs has caused disk space issues more than a couple of times too. So is that server not active any more? Unresponsive? Hyperactive writing to the log file? Looping? and generate a ton of logs repeating the following: Aug 25, 2009 11:44:10 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320)
Re: Multiple data centers and redundency?
On Tue, Aug 25, 2009 at 5:38 PM, Andre-John Masaj...@sympatico.ca wrote: ... The architecture would involve a DNS server perodically giving out a DNS address for one DNS server and then an address for the other. Huh? I see there is clustering available with Tomcat, but I don't see how this works across data centers, if at all. You might want to research distributed load balancing -- it's been a while since I've had to deal with it, so the hardware options have doubtless changed. (Cisco's Remote Director was pretty much the only game in town at the time.) -- Hassan Schroeder hassan.schroe...@gmail.com twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Multiple data centers and redundency?
On 25-Aug-2009, at 20:52, Hassan Schroeder wrote: On Tue, Aug 25, 2009 at 5:38 PM, Andre-John Masaj...@sympatico.ca wrote: ... The architecture would involve a DNS server perodically giving out a DNS address for one DNS server and then an address for the other. Huh? Teaches me to proof read. The DNS server gives the IP address of the load balancer of one data center, with TTL of 30 seconds, and then hands out the IP address of the load balancer of the other data center. I don't have the exact details, but this is what I have been told. One thing that I wonder is how we can be sure that the browser tries the data center that is has been previously been using if the address has been purged from the local DNS cache, but the client is still meant to be in session. Not really a Tomcat issue, though I would be curious if there are any Tomcat related case studies in this vane. I see there is clustering available with Tomcat, but I don't see how this works across data centers, if at all. You might want to research distributed load balancing -- it's been a while since I've had to deal with it, so the hardware options have doubtless changed. (Cisco's Remote Director was pretty much the only game in town at the time.) Thanks for the pointer, I will see what I can find. André-John - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat cluster fails and generates tons of logs
A brief look through svn log http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaRequest.java; turns up this: r618823 | fhanik | 2008-02-06 07:29:56 +0800 (Wed, 06 Feb 2008) | 3 lines Remove synchronization on the DeltaRequest object, and let the object that manages the delta request (session/manager) to handle the locking properly, using the session lock There is a case with a non sticky load balancer where using synchronized and a lock (essentially two locks) can end up in a dead lock This is the only one where the commit comments seem to indicate anything related to my issue. Given that 6.0.14 was released on 14 Aug 2007 ( http://www.mail-archive.com/annou...@apache.org/msg00386.html), it may be applicable. Would just like to know your opinion, is it likely that this is the issue I'm facing? Thanks! Wong On Wed, Aug 26, 2009 at 8:48 AM, CS Wong lilw...@gmail.com wrote: Thanks, Filip. I'm running 6.0.14 right now. Would you have any idea whether any changes in the code since then would have fixed something like this? I can try to push for an upgrade to 6.0.20 but the app owners would probably want to know whether it would be fixed for sure since they have to go through a rather troublesome round of testing which takes up quite a bit of time. It helps that they know that the problem won't reoccur once this has been done. Thanks, Wong On Tue, Aug 25, 2009 at 11:35 PM, Filip Hanik - Dev Lists devli...@hanik.com wrote: I've taken a look at the code. The fix for this is easy, but it doesn't explain why it happens. This is a concurrency issue, but if you're not running the latest tomcat version, then it could already have been fixed. best Filip On 08/25/2009 01:55 AM, CS Wong wrote: Hi Michael, The logs are the bit that went haywire. The applications at this point still work but often, there's not enough time to troubleshoot much else. The logs can increase by 5-6GB in a matter of an hour or so and hence, we often just kill the service (normal shutdown.sh doesn't respond any more at this point, we have to kill -9 it) in panic and delete the logs before the entire server goes kaboom. This time, I managed to tail out some of the logs, for which I pasted an extract (same repeating pattern of errors): Aug 25, 2009 11:44:02 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Wong On Tue, Aug 25, 2009 at 3:36 PM, Michael Ludwigm...@as-guides.com wrote: CS Wong schrieb: Periodically, I'm getting problems with my Tomcat 6 cluster (2 nodes). One of the nodes would just go haywire Could you elaborate on what going haywire means?
processing precedence for mod_jk config?
Hi, I have been working on a web-app that has been running under tomcat 6 alone for a while. I am now configuring Apache to do some rewrite rules with domains and then forward on to tomcat, which is working. However, even with a directory deny rule in apache conf to block the web-inf and meta-inf directories, requests to it are still getting passed to tomcat. I confirmed these were working by disabling mod_jk and restarting, and got the apache forbidden error. When I have mod_jk running, it passes requests to meta-inf/context.xml to tomcat which then returns a 404 result. It's sort of the same thing but not what I want. If I put in a JkUnMount to those directories, then apache is returning a forbidden error. My environment : - CentOS4 Tomcat 6.0.20 Apache 2.0.52 (this is what the packaging utils wanted to install, 2.2.x isn't available) mod_jk-1.2.28 workers.properties : worker.list=worker1 worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=9009 mod_jk.conf : LoadModulejk_module modules/mod_jk.so JkWorkersFile /etc/httpd/conf.d/workers.properties JkShmFile /var/log/httpd/mod_jk.shm JkLogFile /var/log/httpd/mod_jk.log JkLogLevelinfo JkLogStampFormat [%a %b %d %H:%M:%S %Y] JkMount /* worker1 JkUnMount /*.ico worker1 JkUnMount /*.jpg worker1 JkUnMount /*.gif worker1 JkUnMount /*.png worker1 JkUnMount /*.js worker1 JkUnMount /META-INF/* worker1 # without this, apache directory directive to return a forbidden error doesn't happen JkUnMount /WEB-INF/* worker1 # and this JkMountCopy all mod_jk.conf is included via the directive in httpd.conf : Include conf.d/*.conf which happens right after the LoadModule directives. And in the virtual host directive to force a forbidden error : Directory /home/www/web/ROOT/META-INF AllowOverride none Order deny,allow Deny from all Satisfy all /Directory Directory /home/www/web/ROOT/WEB-INF AllowOverride none Order deny,allow Deny from all Satisfy all /Directory Are the JkMount directives taking precedence over apache's Directory directives? I have another web server running mod_jk-1.2.15, tomcat 5.5, apache 2.0.52 and I don't have this issue. Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: processing precedence for mod_jk config?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris, On 8/25/2009 9:37 PM, Chris Cheshire wrote: However, even with a directory deny rule in apache conf to block the web-inf and meta-inf directories, requests to it are still getting passed to tomcat. That's because they aren't being treated as directories in those cases. Try using a Location instead of a Directory and see if that works. I think mod_jk takes the first crack at serving files, and then allows Apache to continue with the rest of its possibilities. So, if your mod_jk mappings also map those directories, they're going to be sent to Tomcat. If I put in a JkUnMount to those directories, then apache is returning a forbidden error. Sound like that's what you want to do, anyway, right? JkMount /* worker1 What types of URLs do you actually want Tomcat to process? For instance, I use Struts 1.x, j_security_check-style security, and a few JSPs, so I only mount /*.do, /*.jsp, and /j_security_check. If you have similar requirements, maybe you could tighten-up your JkMount directives. JkUnMount /META-INF/* worker1 # without this, apache directory directive to return a forbidden error doesn't happen Right. Instead, you get a 404 from Tomcat (which isn't so bad, honestly). Directory /home/www/web/ROOT/META-INF AllowOverride none Order deny,allow Deny from all Satisfy all /Directory Whatever else you do, you should leave this configuration in Apache httpd.conf, even if it's not actually doing anything. Later, if someone modifies your configuration, this might provide backup protection for you. Try Location in addition to the Directory, but you might just need the JkUnMount (or more specific JkMount directives). Are the JkMount directives taking precedence over apache's Directory directives? I have another web server running mod_jk-1.2.15, tomcat 5.5, apache 2.0.52 and I don't have this issue. What are the differences in configuration, then? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqUmiEACgkQ9CaO5/Lv0PA62QCffb1r57B/7TqmOqX/SRViHhCC XNwAoLRDndH7GY5rx5b3SO35MnsdFNBg =A9SR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat cluster fails and generates tons of logs
hi Wong, yes, that one does implement a higher level of thread safety, and most likely would resolve your problem. With 6.0.20, there is a regression where tomcat nodes on the same host wont discover each other https://issues.apache.org/bugzilla/show_bug.cgi?id=47308 Filip On 08/25/2009 07:22 PM, CS Wong wrote: A brief look through svn log http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaRequest.java; turns up this: r618823 | fhanik | 2008-02-06 07:29:56 +0800 (Wed, 06 Feb 2008) | 3 lines Remove synchronization on the DeltaRequest object, and let the object that manages the delta request (session/manager) to handle the locking properly, using the session lock There is a case with a non sticky load balancer where using synchronized and a lock (essentially two locks) can end up in a dead lock This is the only one where the commit comments seem to indicate anything related to my issue. Given that 6.0.14 was released on 14 Aug 2007 ( http://www.mail-archive.com/annou...@apache.org/msg00386.html), it may be applicable. Would just like to know your opinion, is it likely that this is the issue I'm facing? Thanks! Wong On Wed, Aug 26, 2009 at 8:48 AM, CS Wonglilw...@gmail.com wrote: Thanks, Filip. I'm running 6.0.14 right now. Would you have any idea whether any changes in the code since then would have fixed something like this? I can try to push for an upgrade to 6.0.20 but the app owners would probably want to know whether it would be fixed for sure since they have to go through a rather troublesome round of testing which takes up quite a bit of time. It helps that they know that the problem won't reoccur once this has been done. Thanks, Wong On Tue, Aug 25, 2009 at 11:35 PM, Filip Hanik - Dev Lists devli...@hanik.com wrote: I've taken a look at the code. The fix for this is easy, but it doesn't explain why it happens. This is a concurrency issue, but if you're not running the latest tomcat version, then it could already have been fixed. best Filip On 08/25/2009 01:55 AM, CS Wong wrote: Hi Michael, The logs are the bit that went haywire. The applications at this point still work but often, there's not enough time to troubleshoot much else. The logs can increase by 5-6GB in a matter of an hour or so and hence, we often just kill the service (normal shutdown.sh doesn't respond any more at this point, we have to kill -9 it) in panic and delete the logs before the entire server goes kaboom. This time, I managed to tail out some of the logs, for which I pasted an extract (same repeating pattern of errors): Aug 25, 2009 11:44:02 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:188) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:91) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Wong On
Re: Tomcat cluster fails and generates tons of logs
ok, we'll try this out then. One question about the regression, would it occur if the 2 nodes are in different Solaris containers (both having different IPs) but on the same physical host? Thanks a lot! Wong On Wed, Aug 26, 2009 at 10:39 AM, Filip Hanik - Dev Lists devli...@hanik.com wrote: hi Wong, yes, that one does implement a higher level of thread safety, and most likely would resolve your problem. With 6.0.20, there is a regression where tomcat nodes on the same host wont discover each other https://issues.apache.org/bugzilla/show_bug.cgi?id=47308 Filip On 08/25/2009 07:22 PM, CS Wong wrote: A brief look through svn log http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaRequest.java turns up this: r618823 | fhanik | 2008-02-06 07:29:56 +0800 (Wed, 06 Feb 2008) | 3 lines Remove synchronization on the DeltaRequest object, and let the object that manages the delta request (session/manager) to handle the locking properly, using the session lock There is a case with a non sticky load balancer where using synchronized and a lock (essentially two locks) can end up in a dead lock This is the only one where the commit comments seem to indicate anything related to my issue. Given that 6.0.14 was released on 14 Aug 2007 ( http://www.mail-archive.com/annou...@apache.org/msg00386.html), it may be applicable. Would just like to know your opinion, is it likely that this is the issue I'm facing? Thanks! Wong On Wed, Aug 26, 2009 at 8:48 AM, CS Wonglilw...@gmail.com wrote: Thanks, Filip. I'm running 6.0.14 right now. Would you have any idea whether any changes in the code since then would have fixed something like this? I can try to push for an upgrade to 6.0.20 but the app owners would probably want to know whether it would be fixed for sure since they have to go through a rather troublesome round of testing which takes up quite a bit of time. It helps that they know that the problem won't reoccur once this has been done. Thanks, Wong On Tue, Aug 25, 2009 at 11:35 PM, Filip Hanik - Dev Lists devli...@hanik.com wrote: I've taken a look at the code. The fix for this is easy, but it doesn't explain why it happens. This is a concurrency issue, but if you're not running the latest tomcat version, then it could already have been fixed. best Filip On 08/25/2009 01:55 AM, CS Wong wrote: Hi Michael, The logs are the bit that went haywire. The applications at this point still work but often, there's not enough time to troubleshoot much else. The logs can increase by 5-6GB in a matter of an hour or so and hence, we often just kill the service (normal shutdown.sh doesn't respond any more at this point, we have to kill -9 it) in panic and delete the logs before the entire server goes kaboom. This time, I managed to tail out some of the logs, for which I pasted an extract (same repeating pattern of errors): Aug 25, 2009 11:44:02 AM org.apache.catalina.ha.session.DeltaRequest reset SEVERE: Unable to remove element java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:788) at java.util.LinkedList.removeFirst(LinkedList.java:134) at org.apache.catalina.ha.session.DeltaRequest.reset(DeltaRequest.java:201) at org.apache.catalina.ha.session.DeltaRequest.execute(DeltaRequest.java:195) at org.apache.catalina.ha.session.DeltaManager.handleSESSION_DELTA(DeltaManager.java:1364) at org.apache.catalina.ha.session.DeltaManager.messageReceived(DeltaManager.java:1320) at org.apache.catalina.ha.session.DeltaManager.messageDataReceived(DeltaManager.java:1083) at org.apache.catalina.ha.session.ClusterSessionListener.messageReceived(ClusterSessionListener.java:87) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:916) at org.apache.catalina.ha.tcp.SimpleTcpCluster.messageReceived(SimpleTcpCluster.java:897) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:264) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:110) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:79) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:241) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:225) at
Re: tomcat-users.xml on Tomcat6
On Tue, Aug 25, 2009 at 2:28 PM, André Warniera...@ice-sa.com wrote: That does not look like a login error, it looks like a server error. What does the Tomcat log say ? Here's the log: [1]/var/log/tomcat6/localhost.2009-08-***. [2]/var/log/tomcat6/catalina.2009-08-. -- Zaki Akhmad [1] Aug 26, 2009 9:47:40 AM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() Aug 26, 2009 9:47:40 AM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() Aug 26, 2009 9:47:51 AM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Aug 26, 2009 9:47:51 AM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Aug 26, 2009 9:48:25 AM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextDestroyed() Aug 26, 2009 9:48:25 AM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextDestroyed() Aug 26, 2009 9:48:33 AM org.apache.catalina.core.ApplicationContext log INFO: ContextListener: contextInitialized() Aug 26, 2009 9:48:33 AM org.apache.catalina.core.ApplicationContext log INFO: SessionListener: contextInitialized() Aug 26, 2009 9:49:18 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet HTMLHostManager threw exception java.security.AccessControlException: access denied (java.util.PropertyPermission java.runtime.version read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) at java.security.AccessController.checkPermission(AccessController.java:553) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at java.lang.System.getProperty(System.java:669) at org.apache.catalina.manager.host.HTMLHostManagerServlet.list(HTMLHostManagerServlet.java:367) at org.apache.catalina.manager.host.HTMLHostManagerServlet.doGet(HTMLHostManagerServlet.java:104) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:269) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:537) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:301) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:636) Aug 26, 2009 9:49:26 AM org.apache.catalina.core.ApplicationContext log SEVERE: StandardWrapper.Throwable java.security.AccessControlException: access denied (java.util.PropertyPermission catalina.base read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:342) at java.security.AccessController.checkPermission(AccessController.java:553) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at
Re: SSL with multiple Tomcat instances
Don, No problem. You're seeing valid output and yes a Root certificate is self-signed. As per the TLS protocol, it's optional and doesn't need to be there for things to function. What's strange is it's the same output as the webadvisor instance, outside of the FQDN entries of course. When you connect in browsers are you using https://webui.ashland.edu or are you using https://webui.ashland.edu:8443? (I realize you state that you have iptables running to redirect traffic, but you shouldn't really need to do that, unless you have something dire need for Tomcat to be on anything but 443) I'm curious to see what 443's output is. Could you also use s_client to connect to both the FQDN and the IP (using port 443 and 8443), so that we can rule out a DNS issue? --Sal On 08/25/2009 10:49 AM, Don Prezioso wrote: Sal, Thanks so much for the reply. I think the server.xml reference is correct. Here is the connector segment from that instance: Connector port=8443 address=172.18.19.16 maxThreads=600 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreFile=conf/webui.keystore/ We are using 8443 instead of 443 and have iptables set up to reroute any outside traffic that comes in on 443 to 8443. The other instance uses 172.18.19.15 and the default keystore (~/.keystore). As far as I can tell, that is all working OK. Here is what I get from the command openssl s_client -connect webui.ashland.edu:8443: CONNECTED(0003) depth=2 /C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/ST=Ohio/L=Ashland/O=Ashland University/OU=Administrative IT/CN=webui.ashland.edu i:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com 1 s:/C=ES/ST=Barcelona/L=Barcelona/O=IPS Certification Authority s.l./o=gene...@ipsca.com C.I.F. B-B62210695/OU=ipsCA CLASEA1 Certification Authority/CN=ipsCA CLASEA1 Certification Authority/emailaddress=gene...@ipsca.com i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es 2 s:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es i:/C=ES/ST=BARCELONA/L=BARCELONA/O=IPS Seguridad CA/OU=Certificaciones/CN=IPS SERVIDORES/emailaddress=...@mail.ips.es --- Server certificate -BEGIN CERTIFICATE- MIIGMzCCBZygAwIBAgIDExqhMA0GCSqGSIb3DQEBBQUAMIIBEjELMAkGA1UEBhMC RVMxEjAQBgNVBAgTCUJhcmNlbG9uYTESMBAGA1UEBxMJQmFyY2Vsb25hMSkwJwYD VQQKEyBJUFMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgcy5sLjEuMCwGA1UEChQl Z2VuZXJhbEBpcHNjYS5jb20gQy5JLkYuICBCLUI2MjIxMDY5NTEuMCwGA1UECxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEuMCwGA1UEAxMl aXBzQ0EgQ0xBU0VBMSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEgMB4GCSqGSIb3 DQEJARYRZ2VuZXJhbEBpcHNjYS5jb20wHhcNMDkwODIwMDczNDQ0WhcNMTEwODIw MDczNDQ0WjCBgzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBE9oaW8xEDAOBgNVBAcT B0FzaGxhbmQxGzAZBgNVBAoTEkFzaGxhbmQgVW5pdmVyc2l0eTEaMBgGA1UECxMR QWRtaW5pc3RyYXRpdmUgSVQxGjAYBgNVBAMTEXdlYnVpLmFzaGxhbmQuZWR1MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDBbiTihyoSVlDyVkIoMu97eZxKJrv e0SvdhRO5JIG9O5ov82Pa4NtE2xYPvjMOk20ffEs76m/pAUz3CLao4UxjjpfhxNp 1Y2gQc+0u22R6pPmaPHk2hUEBTCGdHaCVHJ0LwFb+mN4lnZg1dntM7KouKMBGAiV AL9HzMAtoRjiQQIDAQABo4IDITCCAx0wCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBkAwCwYDVR0PBAQDAgP4MBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1UdDgQW BBQwuRGoE8SxdjtLQPKJoHffiYQeizAfBgNVHSMEGDAWgBQOB2DUOckbW12QeyPI 0jSdSppGOTAJBgNVHREEAjAAMBwGA1UdEgQVMBOBEWdlbmVyYWxAaXBzY2EuY29t MHIGCWCGSAGG+EIBDQRlFmNPcmdhbml6YXRpb24gSW5mb3JtYXRpb24gTk9UIFZB TElEQVRFRC4gQ0xBU0VBMSBTZXJ2ZXIgQ2VydGlmaWNhdGUgaXNzdWVkIGJ5IGh0 dHBzOi8vd3d3Lmlwc2NhLmNvbS8wLwYJYIZIAYb4QgECBCIWIGh0dHBzOi8vd3d3 Lmlwc2NhLmNvbS9pcHNjYTIwMDIvMEMGCWCGSAGG+EIBBAQ2FjRodHRwczovL3d3 dy5pcHNjYS5jb20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3JsMEYGCWCG SAGG+EIBAwQ5FjdodHRwczovL3d3dy5pcHNjYS5jb20vaXBzY2EyMDAyL3Jldm9j YXRpb25DTEFTRUExLmh0bWw/MEMGCWCGSAGG+EIBBwQ2FjRodHRwczovL3d3dy5p cHNjYS5jb20vaXBzY2EyMDAyL3JlbmV3YWxDTEFTRUExLmh0bWw/MEEGCWCGSAGG +EIBCAQ0FjJodHRwczovL3d3dy5pcHNjYS5jb20vaXBzY2EyMDAyL3BvbGljeUNM QVNFQTEuaHRtbDCBgwYDVR0fBHwwejA5oDegNYYzaHR0cDovL3d3dy5pcHNjYS5j b20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3JsMD2gO6A5hjdodHRwOi8v d3d3YmFjay5pcHNjYS5jb20vaXBzY2EyMDAyL2lwc2NhMjAwMkNMQVNFQTEuY3Js MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuaXBzY2Eu Y29tLzANBgkqhkiG9w0BAQUFAAOBgQBWxO6m/tvgkW9Ig55akiS9qeUA9pAmPv3O nvNnVOuEkaEFJTBKHRbV1QfijXg2Dnj8oQymSaDO7uZAJ6+anvuZCyySBDNzKDDq
Db connection issue due to firewall
Hello, We use a db datasource for one of our applications. The issue is that there is a firewall between tomcat server 5.5 db server (ORACLE 9i), that cuts pool connections after 1 hour of ideal time. We've tried several configuration using : validationQuery testOnBorrow testOnReturn testWhileIdle timeBetweenEvictionRunsMillis numTestsPerEvictionRun minEvictableIdleTimeMillis But that does not solve the problem Could you please give me some advices about the way I have to configure this to get it working ? Best Regards, Chandra
RE: Problem closing datasource when used as JNDI resource
Hi Chris, Yes, that is a listener for the context, where as I am using a listener for a server. Any how if you see the archive, my first mail gives the reference of the same thread. I guess I have to live with that (Server life cycle listener) :-( Thanks again, Mohammed. -Original Message- From: Mark Shifman [mailto:mark.shif...@yale.edu] Sent: Tuesday, August 25, 2009 5:47 PM To: Tomcat Users List Subject: Re: Problem closing datasource when used as JNDI resource Since you don't seem to be able to google yourself, here is the link. http://www.mail-archive.com/users@tomcat.apache.org/msg65149.html Mohammed Bin Mahmood wrote: Hi Chris, You mentioned about the published filter that can close datasource. I wonder if you have any idea about that. Is it provided by tomcat or some other Thanks, Mohammed. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Monday, August 24, 2009 7:48 PM To: Tomcat Users List Subject: Re: Problem closing datasource when used as JNDI resource Mohammed, On 8/24/2009 12:49 AM, Mohammed Bin Mahmood wrote: Hi Chris, 3. There is a published filter that can close the DataSource for you. Do you have any idea about the filter that can close the Datasource? What? -chris - 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 -- Mark Shifman MD. Ph.D. Yale Center for Medical Informatics Phone (203)737-5219 mark.shif...@yale.edu - 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: Problem closing datasource when used as JNDI resource
Sorry Chris I meant to address Mark in my previous mail. Thanks, Mohammed. -Original Message- From: Mohammed Bin Mahmood [mailto:moham...@sustainlane.com] Sent: Wednesday, August 26, 2009 9:32 AM To: 'Tomcat Users List' Subject: RE: Problem closing datasource when used as JNDI resource Hi Chris, Yes, that is a listener for the context, where as I am using a listener for a server. Any how if you see the archive, my first mail gives the reference of the same thread. I guess I have to live with that (Server life cycle listener) :-( Thanks again, Mohammed. -Original Message- From: Mark Shifman [mailto:mark.shif...@yale.edu] Sent: Tuesday, August 25, 2009 5:47 PM To: Tomcat Users List Subject: Re: Problem closing datasource when used as JNDI resource Since you don't seem to be able to google yourself, here is the link. http://www.mail-archive.com/users@tomcat.apache.org/msg65149.html Mohammed Bin Mahmood wrote: Hi Chris, You mentioned about the published filter that can close datasource. I wonder if you have any idea about that. Is it provided by tomcat or some other Thanks, Mohammed. -Original Message- - 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
