Call for help about the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
Hello everyone, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26, the following is the detail of stack information. Nov 29, 2009 12:41:16 AM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, terminating thread Exception in thread SIGTERM handler java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:574) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Terminator$1.handle(Terminator.java:35) at sun.misc.Signal$1.run(Signal.java:195) at java.lang.Thread.run(Thread.java:595) I think that maybe it's because there are two many threads and I want to set the JAVA_OPTS (-Xss=2048 -Xss:Set thread stack size).But I am not sure. Can someone give me some advice, thanks in advance. -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 2009年11月30日 6:55 To: Tomcat Users List Subject: Re: Tomcat 5.17 crashes too often Rocco Scappatura wrote: ... Pid wrote... Wait, so you're running HTTPD + Tomcat? And you have PHP running inside Tomcat, instead of running inside HTTPD? Why aren't you using mod_php? Because I need to apply a JSP filter to the PHP page too.. If I demand the processing of php page to HTTPD I can't apply the JSP filter to that page. Just to provide you with even more options then : as far as I know, you can run PHP as an output filter in Apache httpd. So you could forward the request to Tomcat for the JSP part and, on the Tomcat response, apply your PHP output filter in Apache on the way back. As a matter of general application design however, I must say that I find this combination rather on the heavy side. I mean Java /and/ PHP. What is it that you absolutely have to do in Java, and in PHP, that you cannot substitute by just one of them ? - 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: AJP with HTTPD - Buffer Size on long URLs
The RFC specs a maximum URL size of 4k. That should be enough for everybody. Note that you can mix and match as required: Use the URL portion of your request to identify the target of the request, and put the additional data in the POST body. -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: zaterdag 28 november 2009 13:11 To: Tomcat Users List Subject: Re: AJP with HTTPD - Buffer Size on long URLs Nilesh Bansal wrote: Using ProxyIOBufferSize as 32192 totally worked even though the documentation suggests otherwise. I am using httpd 2.2.14 with Tomcat 6.0.16. Thank you for the tip, now I can again use my long urls. This may work for now, but someone should tell you that sending large amounts of data in a HTTP GET request is not such a good idea. It will get you in trouble sooner or later, for various reasons. You should use a POST request for that kind of thing. This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP with HTTPD - Buffer Size on long URLs
Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? As per my own memory, it is not as clear as that. But in various places, it warns against too long URLs, not so much because of the httpd server itself, but because intermediate agents may have lower limits (proxies, firewalls, connectors..) The Java Servlet Spec may also have something to say about this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP with HTTPD - Buffer Size on long URLs
Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? RFC2068 (old HTTP/1.1 spec) This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Call for help about the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
On 30/11/2009 08:04, Peter Chen wrote: Hello everyone, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26, the following is the detail of stack information. Nov 29, 2009 12:41:16 AM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, terminating thread Exception in thread SIGTERM handler java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:574) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Terminator$1.handle(Terminator.java:35) at sun.misc.Signal$1.run(Signal.java:195) at java.lang.Thread.run(Thread.java:595) I think that maybe it's because there are two many threads and I want to set the JAVA_OPTS (-Xss=2048 -Xss:Set thread stack size).But I am not sure. Can someone give me some advice, thanks in advance. Sure. When requesting help from the list, for each problem, the first email you send should be a new email and not an edited reply to someone elses thread - which is referred to as 'thread hijacking'. Please start over, be sure to include your OS and JVM version. p -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 2009年11月30日 6:55 To: Tomcat Users List Subject: Re: Tomcat 5.17 crashes too often Rocco Scappatura wrote: ... Pid wrote... Wait, so you're running HTTPD + Tomcat? And you have PHP running inside Tomcat, instead of running inside HTTPD? Why aren't you using mod_php? Because I need to apply a JSP filter to the PHP page too.. If I demand the processing of php page to HTTPD I can't apply the JSP filter to that page. Just to provide you with even more options then : as far as I know, you can run PHP as an output filter in Apache httpd. So you could forward the request to Tomcat for the JSP part and, on the Tomcat response, apply your PHP output filter in Apache on the way back. As a matter of general application design however, I must say that I find this combination rather on the heavy side. I mean Java /and/ PHP. What is it that you absolutely have to do in Java, and in PHP, that you cannot substitute by just one of them ? - 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
Call for help about the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
Hi everyone, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. Nov 29, 2009 12:41:16 AM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, terminating thread Exception in thread SIGTERM handler java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:574) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Terminator$1.handle(Terminator.java:35) at sun.misc.Signal$1.run(Signal.java:195) at java.lang.Thread.run(Thread.java:595) Has anyone met this problem? Please give me some advice, thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Basic and Form Authentication
Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. Any words of wisdom? Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Call for help about the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
Pid wrote: On 30/11/2009 09:39, Peter Chen wrote: Hi everyone, ... Please stop replying to Andre's message in the Tomcat 5.17 crashes too often thread and just deleting the subject line contents of the message. You may well be completely ignored after this. Peter, on a list server such as the one managing this user help list, and also in email clients, there are identifiers in each message, apart from the subject line of the message. These identifiers help the server and the client to keep together the messages that belong to the same original subject. When you just hit reply to an existing message, and retype the subject, these identifiers are still there, and your new message then is classified as an anwer to the other previous messages, even if you have changed the subject and the content. That makes it difficult to follow, for people who display list messages in threads, where all related messages come together in a group. Suddenly, there is a message there that seems related to the previous group, but has a different subject and talks of something else. That is what is called hijacking an existing thread (like when someone hijacks a plane and re-directs it somewhere else than where the passengers wanted to go). So, to start a new subject, you have to create a totally new message, and send it to the list address. This way, the message gets its own thread, which everyone can then follow logically. Later, you can hit reply to keep answering inside the same new thread. Ok ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
Hi, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. Nov 29, 2009 12:41:16 AM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, terminating thread Exception in thread SIGTERM handler java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:574) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Terminator$1.handle(Terminator.java:35) at sun.misc.Signal$1.run(Signal.java:195) at java.lang.Thread.run(Thread.java:595) Has anyone met this problem? Please give me some advice, thanks in advance.
Re: Basic and Form Authentication
Anthony Jay wrote: Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? There is a rather extensive description available here : http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html and it also points you to the relevant section of the Servlet Specification (2.4 or 2.5), section SRV 12.1 and following. From reading it in diagonals, to me it seems possible to do that, if the URLs for the two types of servlets above can be distinguished. But you may want to wait for a more authoritative answer than mine. The above is all about container-based security. There is another philosophy available, namely servlet-filter based security, which may do what you want. The expert on that is Christopher, who will be having a look here in a few hours. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
Peter Chen wrote: Hi, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. ... SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, ... Has anyone met this problem? Please give me some advice, thanks in advance. Well, it seem that you are running out of memory. The helpful thing to do then, would be to provide some information about how much memory is being given to your JVM to run in. Such as : how much memory does your system have, and what are the memory-related parameters used to start the JVM in which your Tomcat runs. And maybe the output of a ps or top like command, showing how much memory is really being used by Java. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
2009/11/30 Peter Chen peter.c...@aicent.com: I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, terminating thread Exception in thread SIGTERM handler java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:574) at java.lang.Shutdown.runHooks(Shutdown.java:128) at java.lang.Shutdown.sequence(Shutdown.java:173) at java.lang.Shutdown.exit(Shutdown.java:218) at java.lang.Terminator$1.handle(Terminator.java:35) at sun.misc.Signal$1.run(Signal.java:195) at java.lang.Thread.run(Thread.java:595) OK, so this seems to happen at a very particular point: when you're shutting down your server via SIGTERM (so killing the process). Something has registered a shutdown hook, and the call to create the thread to run the hooks is failing. Does this always happen, or is it intermittent? If it always happens, presumably we'll very quickly know if we've found a fix, as you can start the server, stop it, and see that the problem doesn't happen. If it always happens, does increasing the amount of heap memory assigned to the JVM help? It might do if the JVM's very low on heap memory. Does *de*creasing the amount of heap memory help? It might do if the JVM's very low on non-heap memory, as creating a new thread requires space for things like the thread's stack, which are not part of the heap. What options are you starting the JVM with, and how much RAM do you have on the box? I'm particularly interested in your heap and stack sizes. What connector options do you have set in your conf/server.xml? I'm particularly interested in the number of threads you have configured, and hence how much heap and non-heap memory is being used for threads. Sorry to request so much information, but OOMEs aren't always the easiest to debug! - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, ... Has anyone met this problem? Please give me some advice, thanks in advance. Well, it seem that you are running out of memory. That, or the underlying VM implementation just throws that exception because it's close enough to the real problem. So the OS reports sorry, there's plenty memory but I cannot start your thread because that would allocate some other resource that is running out, and the VM translates this to OutOfMemoryError because a SorryICannotStartYourThreadError isn't defined. Much like running out of GDI resources in an AWT application would throw OutOfMemoryError, simply because the Java VM cannot translate the information from the OS because in the Java world, these things don't exist. M. disclaimer: My message ends here This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Anthony Jay wrote: Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? The Servlet spec does not support this. There is a maximum of one login method allowed per web app. That doesn't you doing more, but you have to provide all of the authentication plumbing yourself. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
On Monday 30 November 2009 10:57:04 Peter Chen wrote: Hi, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. Nov 29, 2009 12:41:16 AM org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, While Andre is right that system memory size and JVM parameters are important, this is not the usual OOM that heap space is full. Java is not able to create a OS level thread for a new Java thread. The most common cause seems to be that there is not enough memory to allocate for the thread stack, either because there is not enough system memory available, or the memory limit for the java process is reached. You might be able to increase the memory limit for the process, if OS permits that and you have enough physical memory. If the limit is indeed physical memory, cou can of course increase that or try to move other processes away from the machine. Otherwise you need to provide java with enough memory for the new thread. One approach is to reduce the stack size. There is a -Xss switch to java, but I don't know Solaris, so I'm not sure this works or is sufficient. Possibly the OS has also to be configured to use/allow a smaller stack size. Another approach is to reduce the other memory usage of the java process, by reducing heap (or perhaps permgen) size, so java can use more of its permitted memory for thread stacks instead of heap. See http://www.egilh.com/blog/archive/2006/06/09/2811.aspx and the links in the article. A completely different cause might be that Solaris imposes a limit of the number of threads, regardless of the memory/stack size, per process. Perhaps a Solaris expert has more info. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to access JNDI resources on Tomcat level
Hi, I am facing problem with configuring JNDI DataSources for Josso project in Tomcat 6. Getting the following errors in tomcat log when i am trying to access the application. Defined resource in conf/Catalina/localhost/webapp.xml. And res-reference in the application's web.xml. Nov 30, 2009 7:48:52 AM org.josso.gateway.identity.service.store.db.DataSourceIdentityStore getDataSource SEVERE: Error during DB connection lookup javax.naming.NameNotFoundException: Name DefaultDS is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) Steps Followed: 1. Defined DataSource within GlobalNamingResources Resource name=/DefaultDS auth=Container type=javax.sql.DataSource description=SSO DataSource username=josso password=josso driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@md1npddev10:1521:jdaj factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory maxActive=8 maxIdle=4/ 2. Added res-reference in web.xml 3. Defined resource in conf/Catalina/localhost/webapp.xml Resource name=/DefaultDS auth=Container type=javax.sql.DataSource description=SSO DataSource username=josso password=josso driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@md1npddev10:1521:jdaj factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory maxActive=8 maxIdle=4/ 4. In josso-gateway-db-stores.xml db-istore:datasource-store id=josso-identity-store dsJndiName=java:comp/env/DefaultDS userQueryString=SELECT NAME FROM JOSSO_USER WHERE LOGIN = ? rolesQueryString=SELECT ROLE FROM JOSSO_USER_ROLE WHERE LOGIN = ?; credentialsQueryString=SELECT LOGIN AS USERNAME, PASSWORD FROM JOSSO_USER WHERE LOGIN = ? userPropertiesQueryString=SELECT NAME, VALUE FROM JOSSO_USER_PROPERTY WHERE LOGIN = ? resetCredentialDml=UPDATE JOSSO_USER SET PASSWORD = ? WHERE LOGIN = ? relayCredentialQueryString=SELECT LOGIN FROM JOSSO_USER WHERE #?# = ? / 5. When i try to access the example partner application (/partner), getting the following error: Error : Error During Lookup Name DefaultDS is not bound in this Context I am using Josso 1.8.0 with tomcat 6.0.18. Please help me out to proceed further. Quick response is highly appreciable. Thanks in Advance. Mikolaj Rydzewski-2 wrote: Mikolaj Rydzewski wrote: Now, I want to setup Josso single sign on system (www.josso.org) and force it to use JNDI DataSources as well. With no luck. Here's the solution for anyone interested (addition to typical josso setup): * define DataSource within GlobalNamingResources (e.g. jdbc/users) * add JNDI support to josso webapp (e.g. and ResourceLink to META-INF/context.xml and resource-ref to WEB-INF/web.xml) * reference DataSource from josso-gateway-config.xml using java:comp/env/jdbc/users as its JNDI name Enjoy ;-) -- Mikolaj Rydzewski m...@ceti.pl - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Quoted from: http://old.nabble.com/How-to-access-JNDI-resources-on-Tomcat-level-tp19672443p19689928.html Mikolaj Rydzewski-2 wrote: Christopher Schultz wrote: * add JNDI support to josso webapp (e.g. and ResourceLink to META-INF/context.xml and resource-ref to WEB-INF/web.xml) Note that this is not required for Realms. See http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html#Context+versus+GlobalNamingResources I'm exposing DataSource to josso webapp, not the Realm. So I need this. Lack of such configuration was causing my initial problems. -- Mikolaj Rydzewski m...@ceti.pl - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- View this message in context: http://old.nabble.com/How-to-access-JNDI-resources-on-Tomcat-level-tp19672443p26574958.html Sent from the Tomcat - User mailing list
Re: FarmWarDeployer Tomcat 6.0.18 on REL
See Thread at: http://www.techienuggets.com/Detail?tx=83985 Posted on behalf of
a User
I have the same issue, seems there is something wrong with this object, and you
do have an error message in your logs, it's SEVERE: FarmWarDeployer can only
work as host cluster subelement!.
According to Apache, they have an issue ...
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-deployer.html
-David
In Response To:
I've clustered 2 seperate servers together, and i've enabled the
FarmWarDeployer on each. I can see that the servers are talking to each other
in the logs, but I cannot get apps deployed to the farm to propagate across the
cluster. I'm not seeing any error messages in the logs. Any help/suggestions
would be greatly appreciated.
Here is the output from catalina.out
May 6, 2009 2:02:10 PM org.apache.tomcat.util.digester.SetPropertiesRule begin
WARNING: [SetPropertiesRule]{Server/Service/Engine/Realm} Setting property
'debug' to '99' did not find a matching property.
May 6, 2009 2:02:10 PM org.apache.catalina.core.AprLifecycleListener init
INFO: Loaded APR based Apache Tomcat Native library 1.1.16.
May 6, 2009 2:02:10 PM org.apache.catalina.core.AprLifecycleListener init
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true].
May 6, 2009 2:02:11 PM org.apache.coyote.http11.Http11AprProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-10.49.64.68-8080
May 6, 2009 2:02:11 PM org.apache.coyote.ajp.AjpAprProtocol init
INFO: Initializing Coyote AJP/1.3 on ajp-10.49.64.68-8009
May 6, 2009 2:02:11 PM org.apache.coyote.http11.Http11AprProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-10.49.64.68-8443
May 6, 2009 2:02:11 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 917 ms
May 6, 2009 2:02:11 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
May 6, 2009 2:02:11 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
May 6, 2009 2:02:11 PM org.apache.catalina.ha.tcp.SimpleTcpCluster start
INFO: Cluster is about to start
May 6, 2009 2:02:11 PM org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/10.49.64.68:5000
May 6, 2009 2:02:11 PM org.apache.catalina.tribes.membership.McastServiceImpl
setupSocket
INFO: Setting cluster mcast soTimeout to 500
May 6, 2009 2:02:11 PM org.apache.catalina.tribes.membership.McastServiceImpl
waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start
level:4
May 6, 2009 2:02:11 PM org.apache.catalina.ha.tcp.SimpleTcpCluster memberAdded
INFO: Replication member
added:org.apache.catalina.tribes.membership.MemberImpl[tcp://{10, 49, 64,
77}:5000,{10, 49, 64, 77},5000, alive=13087,id={-3 -128 -85 -120 118 -106 77 -4
-74 -119 108 -114 77 -1 -24 -113 }, payload={}, command={}, domain={}, ]
May 6, 2009 2:02:12 PM org.apache.catalina.tribes.membership.McastServiceImpl
waitForMembers
INFO: Done sleeping, membership established, start level:4
May 6, 2009 2:02:12 PM org.apache.catalina.tribes.membership.McastServiceImpl
waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start
level:8
May 6, 2009 2:02:12 PM org.apache.catalina.tribes.io.BufferPool getBufferPool
INFO: Created a buffer pool with max size:104857600 bytes of
type:org.apache.catalina.tribes.io.BufferPool15Impl
May 6, 2009 2:02:13 PM org.apache.catalina.tribes.membership.McastServiceImpl
waitForMembers
INFO: Done sleeping, membership established, start level:8
May 6, 2009 2:02:13 PM org.apache.catalina.ha.deploy.FarmWarDeployer start
SEVERE: FarmWarDeployer can only work as host cluster subelement!
May 6, 2009 2:02:13 PM org.apache.coyote.http11.Http11AprProtocol start
INFO: Starting Coyote HTTP/1.1 on http-10.49.64.68-8080
May 6, 2009 2:02:13 PM org.apache.coyote.ajp.AjpAprProtocol start
INFO: Starting Coyote AJP/1.3 on ajp-10.49.64.68-8009
May 6, 2009 2:02:14 PM org.apache.coyote.http11.Http11AprProtocol start
INFO: Starting Coyote HTTP/1.1 on http-10.49.64.68-8443
May 6, 2009 2:02:14 PM org.apache.catalina.startup.Catalina start
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AJP with HTTPD - Buffer Size on long URLs
From: Looijmans, Mike [mailto:mike.looijm...@oce.com] Subject: RE: AJP with HTTPD - Buffer Size on long URLs Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? RFC2068 (old HTTP/1.1 spec) Citing an obsoleted RFC is a bit odd. Regardless, the actual wording from section 3.2.1 of 2068 and 2616 (the superseding document) is: The HTTP protocol does not place any a priori limit on the length of a URI. Followed shortly by: A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). (Note the SHOULD, not MUST.) There is also a warning note: Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. No mention of a 4K limit anywhere that I can find. - 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
Re: Newbie Question
Thanks a lot for your reply guyz...I will give it a shot... Thanks, Chinmoy On Fri, Nov 27, 2009 at 5:41 PM, Mark Thomas ma...@apache.org wrote: Chinmoy Chakraborty wrote: Hi All, I am trying to understand basic architecture of tomcat server and also started to look into the code. What should me my starting point (also source code wise) to understand basic workflow of tomcat server? Try the architecture section of the Tomcat docs. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Easy Way to Upgrade Tomcat Versions?
Hi All, I have been thinking about upgrading my Tomcat 6.0.16 instance to the latest 6.0.20. I have been thinking about the best way to do that. I have modified several config and shell files and suppose I could just copy those to the 6.0.20 instance, but then I began to wonder if I could just update the Tomcat specific files in my current install location. Is it acceptable as an upgrade method to just copy the 6.0.20/lib/*.jar files into the existing 6.0.16/lib directory? Basically, just overwrite the existing Tomcat 6.0.16 libraries with the newer 6.0.20 libraries. Is this an acceptable way to upgrade? What are the potential issues with this method? Thanks in advance. Thomas email: tcm...@yahoo.com
Re: How to access JNDI resources on Tomcat level
On 30/11/2009 13:46, vramanaj wrote: Hi, I am facing problem with configuring JNDI DataSources for Josso project in Tomcat 6. Getting the following errors in tomcat log when i am trying to access the application. Defined resource in conf/Catalina/localhost/webapp.xml. And res-reference in the application's web.xml. Nov 30, 2009 7:48:52 AM org.josso.gateway.identity.service.store.db.DataSourceIdentityStore getDataSource SEVERE: Error during DB connection lookup javax.naming.NameNotFoundException: Name DefaultDS is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) Steps Followed: 1. Defined DataSource within GlobalNamingResources Resource name=/DefaultDS Try using jdbc/DefaultDS. I don't believe you're allowed to start the name with a / character. auth=Container type=javax.sql.DataSource description=SSO DataSource username=josso password=josso driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@md1npddev10:1521:jdaj factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory maxActive=8 maxIdle=4/ 2. Added res-reference in web.xml 3. Defined resource in conf/Catalina/localhost/webapp.xml If you've defined it in the global resources, you don't need to redefine it here, just use: ResourceLink global=jdbc/DefaultDS name=jdbc/DefaultDS type=javax.sql.DataSource/ p Resource name=/DefaultDS auth=Container type=javax.sql.DataSource description=SSO DataSource username=josso password=josso driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@md1npddev10:1521:jdaj factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory maxActive=8 maxIdle=4/ 4. In josso-gateway-db-stores.xml db-istore:datasource-store id=josso-identity-store dsJndiName=java:comp/env/DefaultDS userQueryString=SELECT NAME FROM JOSSO_USER WHERE LOGIN = ? rolesQueryString=SELECT ROLE FROM JOSSO_USER_ROLE WHERE LOGIN = ?; credentialsQueryString=SELECT LOGIN AS USERNAME, PASSWORD FROM JOSSO_USER WHERE LOGIN = ? userPropertiesQueryString=SELECT NAME, VALUE FROM JOSSO_USER_PROPERTY WHERE LOGIN = ? resetCredentialDml=UPDATE JOSSO_USER SET PASSWORD = ? WHERE LOGIN = ? relayCredentialQueryString=SELECT LOGIN FROM JOSSO_USER WHERE #?# = ? / 5. When i try to access the example partner application (/partner), getting the following error: Error : Error During Lookup Name DefaultDS is not bound in this Context I am using Josso 1.8.0 with tomcat 6.0.18. Please help me out to proceed further. Quick response is highly appreciable. Thanks in Advance. Mikolaj Rydzewski-2 wrote: Mikolaj Rydzewski wrote: Now, I want to setup Josso single sign on system (www.josso.org) and force it to use JNDI DataSources as well. With no luck. Here's the solution for anyone interested (addition to typical josso setup): * define DataSource within GlobalNamingResources (e.g. jdbc/users) * add JNDI support to josso webapp (e.g. and ResourceLink to META-INF/context.xml and resource-ref to WEB-INF/web.xml) * reference DataSource from josso-gateway-config.xml using java:comp/env/jdbc/users as its JNDI name Enjoy ;-) -- Mikolaj Rydzewskim...@ceti.pl - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Quoted from: http://old.nabble.com/How-to-access-JNDI-resources-on-Tomcat-level-tp19672443p19689928.html Mikolaj Rydzewski-2 wrote: Christopher Schultz wrote: * add JNDI support to josso webapp (e.g. and ResourceLink to META-INF/context.xml and resource-ref to WEB-INF/web.xml) Note that this is not required for Realms. See http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html#Context+versus+GlobalNamingResources I'm exposing DataSource to josso webapp, not the Realm. So I need this. Lack of such configuration was causing my initial problems. -- Mikolaj Rydzewskim...@ceti.pl - To start a new
Re: AJP with HTTPD - Buffer Size on long URLs
Caldarale, Charles R wrote: From: Looijmans, Mike [mailto:mike.looijm...@oce.com] Subject: RE: AJP with HTTPD - Buffer Size on long URLs Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? RFC2068 (old HTTP/1.1 spec) Citing an obsoleted RFC is a bit odd. Regardless, the actual wording from section 3.2.1 of 2068 and 2616 (the superseding document) is: The HTTP protocol does not place any a priori limit on the length of a URI. Followed shortly by: A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). (Note the SHOULD, not MUST.) There is also a warning note: Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. No mention of a 4K limit anywhere that I can find. Right. +1. My point here (toward Mike) was that one should avoid propagating rumors or incorrect information, on a list that is read by unsuspecting users which may then believe that this is the ultimate truth. This being said, the specs do not set a specific limit to a URI length, but it is certain that any server software has a practical one, if only to avoid some types of DoS attacks. So my point to the original poster, was to recommend the use of a POST rather than a GET, if the application is such that it already now exceeds 8K for a URI. In addition, even if one knows how many individual input fields there may be in a form which sends such a URI, and how long each field is in principle, it is much harder to predict how long a URI this will actually generate once URI-escaping has taken place, and each non-ASCII character has been replaced by a triplet of bytes. There is no such arbitrary limit (or if there is, it is MUCH higher) for the body of a POST. In addition, at least for the body of a POST, there is a possibility of indicating the character set of the data, which in fact there is not for data contained in a URI. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Easy Way to Upgrade Tomcat Versions?
On 30/11/2009 16:02, Thomas Moorer wrote: Hi All, I have been thinking about upgrading my Tomcat 6.0.16 instance to the latest 6.0.20. I have been thinking about the best way to do that. I have modified several config and shell files and suppose I could just copy those to the 6.0.20 instance, but then I began to wonder if I could just update the Tomcat specific files in my current install location. Is it acceptable as an upgrade method to just copy the 6.0.20/lib/*.jar files into the existing 6.0.16/lib directory? Basically, just overwrite the existing Tomcat 6.0.16 libraries with the newer 6.0.20 libraries. Is this an acceptable way to upgrade? What are the potential issues with this method? Thanks in advance. Thomas email: tcm...@yahoo.com There's no incremental upgrade process, but it's usually inadvisable to copy jar files over the top of the old ones, do so at your own risk. bin/setenv.sh is a good location to do custom config for the shell scripts. I usually copy that straight over, but rewrite server.xml context.xml. p - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Easy Way to Upgrade Tomcat Versions?
-Original Message- From: Pid [mailto:p...@pidster.com] Sent: Monday, November 30, 2009 10:17 AM To: users@tomcat.apache.org Subject: Re: Easy Way to Upgrade Tomcat Versions? On 30/11/2009 16:02, Thomas Moorer wrote: Hi All, I have been thinking about upgrading my Tomcat 6.0.16 instance to the latest 6.0.20. I have been thinking about the best way to do that. I have modified several config and shell files and suppose I could just copy those to the 6.0.20 instance, but then I began to wonder if I could just update the Tomcat specific files in my current install location. Is it acceptable as an upgrade method to just copy the 6.0.20/lib/*.jar files into the existing 6.0.16/lib directory? Basically, just overwrite the existing Tomcat 6.0.16 libraries with the newer 6.0.20 libraries. Is this an acceptable way to upgrade? What are the potential issues with this method? Thanks in advance. Thomas email: tcm...@yahoo.com There's no incremental upgrade process, but it's usually inadvisable to copy jar files over the top of the old ones, do so at your own risk. bin/setenv.sh is a good location to do custom config for the shell scripts. I usually copy that straight over, but rewrite server.xml context.xml. This is why people should use CATALINA_HOME/CATALINA_BASE style configuration. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Easy Way to Upgrade Tomcat Versions?
Am Mon, 30 Nov 2009 08:02:41 -0800 (PST) schrieb Thomas Moorer tcm...@yahoo.com: I have been thinking about upgrading my Tomcat 6.0.16 instance to the latest 6.0.20. I have been thinking about the best way to do that. I have modified several config and shell files and suppose I could just copy those to the 6.0.20 instance, but then I began to wonder if I could just update the Tomcat specific files in my current install location. Usually (!) it should be enough if you copy the files from conf/ and bin/ (and your application, of course) to the new apache-tomcat-tree. Is it acceptable as an upgrade method to just copy the 6.0.20/lib/*.jar files into the existing 6.0.16/lib directory? It depends on how clean your installation is. If you have put additional jars into the apache-tomcat/lib/ - directory in the past this might be the better way. Of course this isn't good practice because application specific jars should be installed unter webapps/application/WEB-INF/lib/. Running Unix/Linux I prefer another practice. In the home-dir of the tomcat-User I create a skeleton similar to the following: ~/tomcat ~/tomcat/bin ~/tomcat/webapps ~/tomcat/webapps/bsps - ../default/webapps/examples ~/tomcat/webapps/docs - ../default/webapps/docs ~/tomcat/webapps/manager - ../default/webapps/manager ~/tomcat/webapps/j4p ~/tomcat/webapps/probe ~/tomcat/webapps/ROOT - ../../ROOT ~/tomcat/temp ~/tomcat/conf ~/tomcat/conf/Catalina ~/tomcat/work ~/tomcat/work/Catalina ~/tomcat/lib - default/lib ~/tomcat/logs - ../logs ~/tomcat/default - /opt/apache-tomcat-6.0.20 ~/logs ~/ROOT Under /opt I install the Tomcat-versions out of the... tar.gz-archive: /opt /opt/apache-tomcat-6.0.18 /opt/apache-tomcat-6.0.18/conf /opt/apache-tomcat-6.0.18/webapps /opt/apache-tomcat-6.0.18/bin /opt/apache-tomcat-6.0.18/lib /opt/apache-tomcat-6.0.18/temp /opt/apache-tomcat-6.0.18/work /opt/apache-tomcat-6.0.18/logs /opt/apache-tomcat-6.0.20 /opt/apache-tomcat-6.0.20/conf /opt/apache-tomcat-6.0.20/webapps /opt/apache-tomcat-6.0.20/bin /opt/apache-tomcat-6.0.20/lib /opt/apache-tomcat-6.0.20/temp /opt/apache-tomcat-6.0.20/work /opt/apache-tomcat-6.0.20/logs ... After this preparation changing to another tomcat-version is just a deletion and re-creation of the symbolic link default ( ~/tomcat/default - /opt/apache-tomcat-6.0.20 ) and you roll back to an older version the same way. In this setup your configuration and scripting under tomcat/conf/ and tomcat/bin/ is left untouched and the factory-installation of tomcat under /opt is left untouched as well. By setting links under tomcat/ to default/xyz/ you tell your installation to take the factory-default and by replacing the links to a separate directory (like tomcat/conf/) you can customize your installation. Of course you have to pay attention that your customized directories stay compatible if you made a Tomcat-update by exchanging the links as described above but usually there is no need to change something. Maybe this principle works under MS-Windows as well. I read that MS is offering symbolic links since WinXP-SP2 but I have not much experience with their OS. Regards, Tobias. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Importing CERTIFICATE into Java Keystore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen, On 11/20/2009 3:05 AM, Stephen . wrote: I got the LDAP connection working on my IDM. Test Connection Succeeded Glad to hear it. However, when I try to create a new User on the LDAP Resource, I get the following error : javax.naming.CommunicationException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Do you have an idea what this could mean? This means that your client doesn't trust the server's SSL certificate. How are you configuring your LDAP resource? You have not yet posted that, so it's hard to help, here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUGMMACgkQ9CaO5/Lv0PCv2wCbBODzpoquP5eA38U+OnB3yH/v h9QAoMLZGgjzGZ+8r/4SkJ43lxkI9Fai =U+CG -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 11/30/2009 4:53 AM, Anthony Jay wrote: Is is possible to have an application that serves content protected by BASIC and FORM based auth? As Mark points out, the servlet spec says not in the same webapp. Tomcat implements the servlet specification and no more, so you are out of luck, there. I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. I would strongly advise you to separate your webapps: one webapp for your XML-based API and the other for human interaction. Don't forget that your human UI could make use of the XML API behind the scenes. This is typically called drinking your own Cool-Aid. If it's possible for you to do so, you could put your shared singleton/static classes into a shared ClassLoader. What kinds of things are you using that you would need to share across webapps? Could those things be converted into services that both webapps could share? Note that an XML service whose URL contains a jsessionid parameter will be associated with the indicated session. You could use such a URL to avoid the FORM authentication (but getting the session id is, of course, an issue unresolved by this). Finally, you could go out on your own and implement your own authentication mechanism. Securityfilter is a simple, filter-based authentication and authorization mechanism that you could hack-up to do this type of thing. Actually, you could use it out-of-the-box and just use a Filter configured /in front/ of it to trick sf into trusting a Principal configured by your Filter (which comes from the request's HTTP AUTH data). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUHsEACgkQ9CaO5/Lv0PD/jACeKCyBSKRnZtnso5EzEPROUMXO i74An09m3QZY0GTl47KplbdCSu/NG1wr =t+z3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP with HTTPD - Buffer Size on long URLs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike, On 11/30/2009 3:10 AM, Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. That should be enough for everybody. ...along with 640k of regular memory. I'll let you read André's and Chuck's harangues about your dubious recollection of the HTTP specification. On a related note, Apache httpd (used by the OP, so definitely relevant, here) has a configuration option for limiting the length of the first-line of the request from a client: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline The default limit in 2.0 and 2.2 is 8190 (an seemingly strange number unless you account for the CR LF end-of-line marker required by the specification (in section 2.2, since you asked). Presumably, httpd uses fgets and the default buffer size of 8190 gives them a round-numbered buffer size... though for no particular reason. Since Apache httpd will choke after 8177 characters of URI (8190 - 13 required characters for GET and the HTTP version identifier), the OP would be wise to change this setting in httpd.conf. Or switch to POST, which is probably the right answer, here. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUItcACgkQ9CaO5/Lv0PB6oQCfdpF6kZpqyrglITbfEisLK4cO MDcAoJE5HOrvzVuQpTOFNGXHT40RiQt/ =PIjv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Easy Way to Upgrade Tomcat Versions?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tobias, On 11/30/2009 1:30 PM, Tobias Crefeld wrote: Am Mon, 30 Nov 2009 08:02:41 -0800 (PST) schrieb Thomas Moorer tcm...@yahoo.com: I have been thinking about upgrading my Tomcat 6.0.16 instance to the latest 6.0.20. I have been thinking about the best way to do that. I have modified several config and shell files and suppose I could just copy those to the 6.0.20 instance, but then I began to wonder if I could just update the Tomcat specific files in my current install location. Usually (!) it should be enough if you copy the files from conf/ and bin/ (and your application, of course) to the new apache-tomcat-tree. That's a great way to a) downgrade your install or b) destroy your install. Let's see what's in the bin/ directory of a standard Tomcat install: 1. bootstrap.jar - Looks important! Should you really clobber this? 2. tomcat-*.jar - Same here! 3. tomcat6*.exe - Hope there aren't any bugs in the old version! 4. *.sh / *.bat - Same here! This may sound silly until you realize that even the shell scripts are updated across minor versions sometimes. There was a bug where setting the logger via a system property resulted in a mangled command-line that failed to properly launch the JVM. This was fixed with a tweak to the shell script that starts Tomcat. If you copied that script from your old installation, you'd be upgrading in the sense that a lot of the code would be new, but the scripts would still be broken, along with everything else. The only thing in bin/ that it's safe to blindly copy to a new Tomcat install is bin/setenv.sh (or bin\setenv.bat) and that's because Tomcat does not come packaged with such a file. It depends on how clean your installation is. If you have put additional jars into the apache-tomcat/lib/ - directory in the past this might be the better way. Of course this isn't good practice because application specific jars should be installed unter webapps/application/WEB-INF/lib/. The exception to this rule is, of course, JDBC drivers. I'm sure there are other examples as well. Running Unix/Linux I prefer another practice. In the home-dir of the tomcat-User I create a skeleton similar to the following: ~/tomcat ... OMG are you a Linux distro package maintainer? After this preparation changing to another tomcat-version is just a deletion and re-creation of the symbolic link default ( ~/tomcat/default - /opt/apache-tomcat-6.0.20 ) and you roll back to an older version the same way. There is a much easier way: use the CATALINA_BASE environment variable. Maybe this principle works under MS-Windows as well. I read that MS is offering symbolic links since WinXP-SP2 but I have not much experience with their OS. Such tricks are unnecessary if you use the ingenious mechanism provided (and preferred) by the Tomcat devs. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUJOgACgkQ9CaO5/Lv0PC6hwCfaJrD/fBgupdXaYyXchFnVMlk xIgAn1FtYOpQp/XbDlLDpY+5l558sO36 =lsW/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Char Encoding text streams on Tomcat 5.5 and Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juha, On 11/28/2009 12:31 PM, Juha Laiho wrote: Dan Bagley wrote: In the failing environment I have the following env settings LANG=en_GB.UTF-8 the successful env is set to LANG=en_UK I'm pretty certain that is the reason for the differences you're seeing. Try starting the Tomcat in the failing environment with LANG set equal to that in your working environment. You don't need to change system overall values, it's enough to have the setting in setenv.sh in the tomcat bin directory (setenv.sh file does not exist by default, you'll need to create it yourself). Tomcat uses the spec-complaint default of ISO-8859-1 for POST requests with no character set included in the Content-Type header. The value for file.encoding (which is presumably gathered from LANG, or from the user's control panel settings or whatever) should be irrelevant. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUJhIACgkQ9CaO5/Lv0PCX2wCfZvnDvS09/V630FJVlRdg0MCO 5ycAoJzJbhFMeZniNnlUktWe4Mkr0K+O =Lnww -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Char Encoding text streams on Tomcat 5.5 and Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/27/2009 11:05 AM, André Warnier wrote: A bit more detail : in java, if you open a text input stream without specifying in which encoding it is, it will default to the platform encoding, which in this case is the locale setting of the process which runs the Java JVM which runs tomcat. Yes! This is likely to be half of the problem. That applies also to webapps which read posted input, unless you are careful. No! The default encoding for servlets is ISO-8859-1 unless the client specifies the encoding (which many do not). The value for file.encoding is not used here, unless there is a horrendous bug in Tomcat. You will not see this issue with XML input, because XML contains either an explicit charset declaration, or defaults to UTF-8. Yes! So the XML parser always knows. Not always. If your webapp is already reading from an incorrectly-encoded reader (say, because the client is supplying UTF-8 characters but didn't tell the server and the server is assuming ISO-8859-1) and you pass that reader on to an XML parser, the XML parser may die trying to read bytes from the reader (it's actually the reader that dies) or it may complain that an invalid character has been read. I predict the problem is: 1) The client is using file.encoding which is /not/ ISO-8859-1 2) The client is not supplying the encoding in the Content-Type header 3) The server is drawing the conclusion that ISO-8859-1 should be used - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUJ2AACgkQ9CaO5/Lv0PB1xACeL8lXhPhnH3Jv3dkDPgVyy4ry 9fYAnRCIvd9qeOkErvl+mRDSwyjdV8WC =HZnr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, On 11/28/2009 8:03 AM, Pid wrote: On 28/11/2009 12:56, André Warnier wrote: ;-) I just wanted, once, to use a subject line with capitals and an exclamation mark. It seems however that in this particular case, neither Tomcat nor Apache httpd follow the rules, when they default to the .. default virtual host in the case where they cannot find a match between the Host: header and one of their defined virtual hosts. Doesn't the following say that they MUST return a 400 status ? http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2 An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request My interpretation is in line with André's, here. The server in question /does/ differentiate resources based upon the host, so: An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) MUST use the following rules for determining the requested resource on an HTTP/1.1 request: 1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header field value in the request MUST be ignored. 2. If the Request-URI is not an absoluteURI, and the request includes a Host header field, the host is determined by the Host header field value. 3. If the host as determined by rule 1 or 2 is not a valid host on the server, the response MUST be a 400 (Bad Request) error message. It's that last one that's the kicker: it basically precludes the use of default hosts. On the other hand, the use of a default seems completely reasonable. The use of a default host simply implies that /all/ hosts are valid for the server in question. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUKU8ACgkQ9CaO5/Lv0PA15gCgrE1v9+L0YweYzPeg4+JuQ3ln IiUAoJq5fEvDUK83Id7pDEJZDXHPSuRT =GOfT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/29/2009 2:00 PM, Warnier wrote: But is is interesting to see how in the end, a document such as RFC2616 which is meant to specify a relatively strict set of rules, and of which I am sure the phrasing is examined carefully and repeatedly (it being after all a revision of an earlier document on the same topic), still leaves areas open to interpretation, or downright inconsistent. Agreed. In certain circumstances, I believe Apache httpd to be (somewhat?) non-spec-compliant. For instance, Apache httpd chokes on URIs like: http://host/path/to/resource;parameter=value httpd believes that, contrary to the HTTP spec, the ; is a part of the resource and not a separator between the resource locator and a parameter to that resource. This is the reason we have hacks like mod_rewrite and mod_jk's JkStripSession setting to allow httpd to work properly with URIs containing ;jsessionid= The section of the spec in this case is RFC 2396: Generic URI Syntax (http://www.ietf.org/rfc/rfc2396.txt), section 3.3: The path may consist of a sequence of path segments separated by a single slash / character. Within a path segment, the characters /, ;, =, and ? are reserved. Each path segment may include a sequence of parameters, indicated by the semicolon ; character. The parameters are not significant to the parsing of relative references. Unfortunately, there is wiggle-room, here: what does a path segment parameter mean? Apache httpd has chosen to interpret path segment parameters as part of a resource's physical path on a filesystem: https://issues.apache.org/bugzilla/show_bug.cgi?id=42860 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksULAEACgkQ9CaO5/Lv0PDfwQCgnioa6Rc32LP90TIfQUPfz6ZR dPcAniwmKBVu+irtyGk4aDQplj7/LuzX =W2o5 -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 solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 11/30/2009 5:37 AM, André Warnier wrote: Peter Chen wrote: Hi, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. ... SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, ... Has anyone met this problem? Please give me some advice, thanks in advance. Well, it seem that you are running out of memory. Looks more like he's hit his per-process thread limit. The clue is in the stack trace: Exception in thread SIGTERM handler java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) What's amusing is that it's happening in the signal handler, so who knows why the JVM shutdown was happening in the first place. It might be helpful to know what the OP's Connector configuration is, and what resource limits are being applied to this process (see ulimit on UNIX, or whatever the MS-Windows equivalent is). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksULU4ACgkQ9CaO5/Lv0PDjfwCgrWMxl7BpVALvxGEzVaTYZqlR A8cAnArOXwNgEqq4PxgXrxfUJ6215tDx =kYaX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Use java 1.5 apps with tomcat 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 To whom it may concern, On 11/26/2009 5:47 AM, Jimmy Spam wrote: I'm using opensuse official package. Maybe I should try the official tomcat build and test it. The programmers says that they need jre 1.5 since his apps doesn't have tested on jre 1.6. Our programmers are dinosaurs. If they could, they continue using cobol. Tell them that Sun no longer supports Java 1.5 and it's time to get with the program. How hard is it to test your app with 1.6? $ JAVA_HOME=/opt/jdk1.6.0_14 ant test Right?! You do have unit tests, right? ;) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUL+8ACgkQ9CaO5/Lv0PBTrACguJP5Fb0JDT+m7sVTe6+cnIY/ ddMAmgNd5chK1F0C4uIpMKlel1kxeqqD =HW/M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Preventing httpd from accessing WEB-INF contents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonathan, On 11/25/2009 11:13 AM, Jonathan Mast wrote: Can someone please provide the magical httpd config-cantation that will block httpd from accessing anything in WEB-INF directories? Directory /path/to/webapp/WEB-INF Order deny,allow Deny from all /Directory I need something that will be apply globally How about: DirectoryMatch .*/WEB-INF Order deny,allow Deny from all /DirectoryMatch and can't be overridden by VirtualHost directives This might not be possible. Any part of httpd.conf can override any other part, I think. You can make it so that .htaccess files can't override the Order and Deny directives, though. Note that you'll probably want to protect META-INF as well. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUNy8ACgkQ9CaO5/Lv0PAvNwCgr1MuY9z65FqtjckGGJqftmDO CBgAniX+ta69krZ8mEQ6mVmW42/GBUMI =vCxT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Char Encoding text streams on Tomcat 5.5 and Linux
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, That applies also to webapps which read posted input, unless you are careful. No! The default encoding for servlets is ISO-8859-1 unless the client specifies the encoding (which many do not). The value for file.encoding is not used here, unless there is a horrendous bug in Tomcat. Well, just make a simple test : (I don't really know how to handle JSP pages, I only do servlets and filters, otherwise I'd do it myself). - create a simple html form with a UTF-8 charset, with a simple text input box. Give it a method=POST. - create a simple webapp which just echoes the input box content - then start Tomcat alternatively under a UTF-8 locale, then an ISO-8859-1 locale, type some accented characters in your input box, and submit the form. I'm curious about the horrendous bug, because I have seen phenomenons like this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to access JNDI resources on Tomcat level
Still getting the same error after changing Data Source name to 'jdbc/DefaultDS'. Added resource link in webapp.xml. Error : Error During Lookup Name jdbc is not bound in this Context Are there any extra customizations required for Josso+Tomcat6? Pid Ster wrote: On 30/11/2009 13:46, vramanaj wrote: Hi, I am facing problem with configuring JNDI DataSources for Josso project in Tomcat 6. Getting the following errors in tomcat log when i am trying to access the application. Defined resource in conf/Catalina/localhost/webapp.xml. And res-reference in the application's web.xml. Nov 30, 2009 7:48:52 AM org.josso.gateway.identity.service.store.db.DataSourceIdentityStore getDataSource SEVERE: Error during DB connection lookup javax.naming.NameNotFoundException: Name DefaultDS is not bound in this Context at org.apache.naming.NamingContext.lookup(NamingContext.java:770) at org.apache.naming.NamingContext.lookup(NamingContext.java:153) Steps Followed: 1. Defined DataSource within GlobalNamingResources Resource name=/DefaultDS Try using jdbc/DefaultDS. I don't believe you're allowed to start the name with a / character. auth=Container type=javax.sql.DataSource description=SSO DataSource username=josso password=josso driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@md1npddev10:1521:jdaj factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory maxActive=8 maxIdle=4/ 2. Added res-reference in web.xml 3. Defined resource in conf/Catalina/localhost/webapp.xml If you've defined it in the global resources, you don't need to redefine it here, just use: ResourceLink global=jdbc/DefaultDS name=jdbc/DefaultDS type=javax.sql.DataSource/ p Resource name=/DefaultDS auth=Container type=javax.sql.DataSource description=SSO DataSource username=josso password=josso driverClassName=oracle.jdbc.OracleDriver url=jdbc:oracle:thin:@md1npddev10:1521:jdaj factory=org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory maxActive=8 maxIdle=4/ 4. In josso-gateway-db-stores.xml db-istore:datasource-store id=josso-identity-store dsJndiName=java:comp/env/DefaultDS userQueryString=SELECT NAME FROM JOSSO_USER WHERE LOGIN = ? rolesQueryString=SELECT ROLE FROM JOSSO_USER_ROLE WHERE LOGIN = ?; credentialsQueryString=SELECT LOGIN AS USERNAME, PASSWORD FROM JOSSO_USER WHERE LOGIN = ? userPropertiesQueryString=SELECT NAME, VALUE FROM JOSSO_USER_PROPERTY WHERE LOGIN = ? resetCredentialDml=UPDATE JOSSO_USER SET PASSWORD = ? WHERE LOGIN = ? relayCredentialQueryString=SELECT LOGIN FROM JOSSO_USER WHERE #?# = ? / 5. When i try to access the example partner application (/partner), getting the following error: Error : Error During Lookup Name DefaultDS is not bound in this Context I am using Josso 1.8.0 with tomcat 6.0.18. Please help me out to proceed further. Quick response is highly appreciable. Thanks in Advance. Mikolaj Rydzewski-2 wrote: Mikolaj Rydzewski wrote: Now, I want to setup Josso single sign on system (www.josso.org) and force it to use JNDI DataSources as well. With no luck. Here's the solution for anyone interested (addition to typical josso setup): * define DataSource within GlobalNamingResources (e.g. jdbc/users) * add JNDI support to josso webapp (e.g. and ResourceLink to META-INF/context.xml and resource-ref to WEB-INF/web.xml) * reference DataSource from josso-gateway-config.xml using java:comp/env/jdbc/users as its JNDI name Enjoy ;-) -- Mikolaj Rydzewskim...@ceti.pl - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Quoted from: http://old.nabble.com/How-to-access-JNDI-resources-on-Tomcat-level-tp19672443p19689928.html Mikolaj Rydzewski-2
RE: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26
The memory given to the JVM is $JAVA_OPTS -Xms512m -Xmx1024m The memory of the Solaris system is: Memory size: 4096 Megabytes The result of executing command ulimit -a is as follows: -bash-3.00$ ulimit -a core file size(blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files(-n) 256 pipe size (512 bytes, -p) 10 stack size(kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes(-u) 29995 virtual memory(kbytes, -v) unlimited -bash-3.00$ -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 2009年11月30日 18:38 To: Tomcat Users List Subject: Re: How to solve the problem java.lang.OutOfMemoryError: unable to create new native thread in Tomcat5.5.26 Peter Chen wrote: Hi, I meet one problem of OutOfMemoryError when I am running the Tomcat5.5.26. The OS is Solaris 10 sparc, and the JVM version is 1.5.0.12, and following is the detail of stack information. ... SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to create new native thread) executing org.apache.tomcat.util.net.leaderfollowerworkerthr...@958b36, ... Has anyone met this problem? Please give me some advice, thanks in advance. Well, it seem that you are running out of memory. The helpful thing to do then, would be to provide some information about how much memory is being given to your JVM to run in. Such as : how much memory does your system have, and what are the memory-related parameters used to start the JVM in which your Tomcat runs. And maybe the output of a ps or top like command, showing how much memory is really being used by Java. - 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: AJP with HTTPD - Buffer Size on long URLs
I stand corrected. What I do recall is that in the 1999's I was forced to build an HTTP/1.1 server from scratch (in objective-C) and, when faced with the question at what point in reading the URI should I give up and decide this is not a HTTP request?, I found 4k to be the 'correct' answer. Since RFC2068 was the basis for that server, I was lazy and assumef that that's where it originated. Anyway, when creating arbitrary long URIs, you can be sure that at some point any HTTP server will give up, because it is more or less forced to store the URI in precious RAM. Probably the 4k limit was intended as the maximum size you can expect a HTTP server to accept, anything beyond that is at your own peril. The SHOULD return 414 is easily explained: If it stops reading the URL, it has no knowledge of the client's intended protocol yet, it is not aware of the other headers in the request, and as such the server may not be able to determine whether the client really expects a HTTP response at all. So the safe thing to do is just close the connection and give up. Having said that, there is a very clear distinction between GET and POST requests. The main difference is that POST requests in general have a side-effect, and cannot be expected to return the same result twice. For example, POST /mything might return created a file the first time, and file already exists the second time. M. !-- -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: maandag 30 november 2009 15:54 To: Tomcat Users List Subject: RE: AJP with HTTPD - Buffer Size on long URLs From: Looijmans, Mike [mailto:mike.looijm...@oce.com] Subject: RE: AJP with HTTPD - Buffer Size on long URLs Looijmans, Mike wrote: The RFC specs a maximum URL size of 4k. Where precisely did you find that ? RFC2068 (old HTTP/1.1 spec) Citing an obsoleted RFC is a bit odd. Regardless, the actual wording from section 3.2.1 of 2068 and 2616 (the superseding document) is: The HTTP protocol does not place any a priori limit on the length of a URI. Followed shortly by: A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). (Note the SHOULD, not MUST.) There is also a warning note: Note: Servers should be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations may not properly support these lengths. No mention of a 4K limit anywhere that I can find. - Chuck This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
