[tomcat 7 migartion] cannot load images with jsession id in url
Hi all; I am migrating to tomcat 7 from 6. In tomcat 6 urls like http://68.169.51.83:8080/gallery/wave_surfing_gallery_thumb_652.jpg;jses sionid=A859D830090798F238DABADC713C1327 would load an image but in tomcat 7 I get the following response: The Image . cannot be displayed because it contains errors I noticed there were some changes in configuration (by looking in the migration guide) but I still can't understand how to overcome this. I would appreciate your help. Thanks. Guy Katz NetXplorer Server Team Leader RD Allot Communications * a mind for networks(tm) Tel: + 972 9 761 9288 Fax: + 972 9 744 3626 gk...@allot.com mailto:gk...@allot.com www.allot.com http://www.allot.com ## This message is intended only for the designated recipient(s).It may contain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distribute this message. If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. Thank you. ##
Apache Tomcat 7.0.14
Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* -- Regards, Adarsh
Re: Apache Tomcat 7.0.14
adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 7.0.14
Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Logging level change
Hi, I am changing the log level of tomcat to Level.WARNING. In this case I'm trying to restart tomcat and see the logs, I can see the info level logs like INFO: Server startup in 50516 ms . I guess info level logs should not appear if log level set to warning. Kindly let me know how exactly it behvaes and why am i getting info level logs? -- View this message in context: http://old.nabble.com/Tomcat-Logging-level-change-tp31902405p31902405.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 Logging level change
2011/6/22 Roshni Basu roshni...@gmail.com: I am changing the log level of tomcat to Level.WARNING. In this case I'm trying to restart tomcat and see the logs, I can see the info level logs like INFO: Server startup in 50516 ms . I guess info level logs should not appear if log level set to warning. 1. If you did it correctly then yes, they should not appear. But what exactly did you? Please be specific. 2. Exact Tomcat version, etc. Kindly let me know how exactly it behvaes The sources are all available. java.util.logging documentation is available from Oracle. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 7.0.14
I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-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
Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
On 22/06/2011 14:47, Benson Margulies wrote: The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. Some classes or all classes? If some, which ones? Are some JARs falling foul of WebappClassLoader#validateJarFile()? It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. Unlikely. As long as the class loader is set before the Context starts you should be fine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
On 21/06/2011 22:58, Jess Holle wrote: If I alter JarFactory to always use FileUrlJar, then my startup is around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12. It turns out the issue is the large jars I have in my WEB-INF/lib directory -- and FileUrlJar is still much faster in this case than using UrlJar even with a JNDI URL. Interesting. I'll dig into this some more. Another issue is that WEB-INF/lib is visible to the parent classloader embedding Tomcat and to Tomcat as part of the web application and thus I'm probably getting double scanning -- though really Tomcat should be avoiding this by detecting that the same jar file is involved in both cases. The reasons for the duplication in this classpath are long and historic. Overall I'd rather not try to unwind this now. I'd hope/assume that an annotation on a class, e.g. a filter annotation, would only result in one filter instance irrespective of how many times that class is visible to the classloader(s) in question. That sounds like it might cause trouble. Classes are identified by the combination of name and class loader so the same class loaded in two different class loaders is treated as a different class. If both the web application class loader and its parent class loader can see WEB-INF/lib I can image all sorts of things may go wrong. Given that the JNDI node maps to a file if the web app is expanded -- as mine always is (being deployed originally as an expanded directory in .war layout not as a .ware archive), it seems there should be a back door for Tomcat to notice this and simply use the file location to begin with rather than doing any extra temporary file shenanigans in any case. The JNDI wrapping is nice and all, but shouldn't cause a substantially sub-optimal performance approach when it is clear enough how to attain the appropriate File object. It should be doing that already. I'll double check. Is there any danger -- other than worse performance in use cases I don't have -- in me patching my own Tomcat to always use FileUrlJar? Should this perhaps be a config option? Or possibly a config option based on file size? [FileUrlJar may only be faster for larger jars from what little I know...] That local patch should be safe. In terms of config, I'd like to keep this as automated as possible. More research required. For reference, how big are the JAR files we are talking about here? Cheers, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
Solr has a particularly bizarre class loading environment. The class causes the problem is the FileUploadServlet from commons-fileupload. I doubt that the problem is validation, but I'll check. My experience is that, in the stock Tomcat class, the new context gets called through .start() before the addWebapp function returns, if the container is already running. I made a subclass of Tomcat which accepted a loader as another argument to addWebapp, and sets it before calling addChild on the host. That cured the problem. Would you be interested in a patch containing this additional overload? Or would it make more sense to have a function createWebapp that left out the addChild and left that to the caller? On Wed, Jun 22, 2011 at 10:00 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 14:47, Benson Margulies wrote: The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. Some classes or all classes? If some, which ones? Are some JARs falling foul of WebappClassLoader#validateJarFile()? It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. Unlikely. As long as the class loader is set before the Context starts you should be fine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
On 22/06/2011 15:18, Benson Margulies wrote: Solr has a particularly bizarre class loading environment. The class causes the problem is the FileUploadServlet from commons-fileupload. I doubt that the problem is validation, but I'll check. My experience is that, in the stock Tomcat class, the new context gets called through .start() before the addWebapp function returns, if the container is already running. Ah, if the container is already running then that would explain it. I'm fairly sure (without looking at the code) that any change to the loader will be ignored. I made a subclass of Tomcat which accepted a loader as another argument to addWebapp, and sets it before calling addChild on the host. That cured the problem. Would you be interested in a patch containing this additional overload? Or would it make more sense to have a function createWebapp that left out the addChild and left that to the caller? I'd be happy with either with a slight preference for the second. (I have an aversion to methods that gather more and more parameters over time.) Mark On Wed, Jun 22, 2011 at 10:00 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 14:47, Benson Margulies wrote: The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. Some classes or all classes? If some, which ones? Are some JARs falling foul of WebappClassLoader#validateJarFile()? It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. Unlikely. As long as the class loader is set before the Context starts you should be fine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
On 22/06/2011 15:08, Mark Thomas wrote: On 21/06/2011 22:58, Jess Holle wrote: If I alter JarFactory to always use FileUrlJar, then my startup is around 20 seconds faster, i.e. the speed is fully back to that of 7.0.12. It turns out the issue is the large jars I have in my WEB-INF/lib directory -- and FileUrlJar is still much faster in this case than using UrlJar even with a JNDI URL. Interesting. I'll dig into this some more. OK. I have a patch that I think should fix this generally. It works well for me locally but it would be good to get some real-life data. Are you willing to test it? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Adding a webapp to a running embedded tomcat 7 with an 'improved' class loader results in missing classes?
I agree with your preference. Patch to follow later today. On Wed, Jun 22, 2011 at 10:27 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 15:18, Benson Margulies wrote: Solr has a particularly bizarre class loading environment. The class causes the problem is the FileUploadServlet from commons-fileupload. I doubt that the problem is validation, but I'll check. My experience is that, in the stock Tomcat class, the new context gets called through .start() before the addWebapp function returns, if the container is already running. Ah, if the container is already running then that would explain it. I'm fairly sure (without looking at the code) that any change to the loader will be ignored. I made a subclass of Tomcat which accepted a loader as another argument to addWebapp, and sets it before calling addChild on the host. That cured the problem. Would you be interested in a patch containing this additional overload? Or would it make more sense to have a function createWebapp that left out the addChild and left that to the caller? I'd be happy with either with a slight preference for the second. (I have an aversion to methods that gather more and more parameters over time.) Mark On Wed, Jun 22, 2011 at 10:00 AM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 14:47, Benson Margulies wrote: The equivalent basic scheme worked perfectly fine in tomcat6. In Tomcat7, it looks like: solrContext = tomcat.addWebapp(/solr, solrWebapp.getCanonicalPath()); WebappLoader solrLoader = new WebappLoader(LSHDemoLauncher.class.getClassLoader()); solrContext.setLoader(solrLoader); I am pulling my hair out because some classes sitting in the WEB-INF/lib dir of the solr webapp are not found. I've debugged into the class loader sufficiently to see that the right jars are in the right place. Some classes or all classes? If some, which ones? Are some JARs falling foul of WebappClassLoader#validateJarFile()? It occurs to me that this might be just as silly as that I need to get the class loader set inside of addWebapp so that it is in place before the call to host.addChild(). If anyone happens to have any advice, I'd be grateful, else I'll be going ahead to perform experiments. Unlikely. As long as the class loader is set before the Context starts you should be fine. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Logging level change
Tomcat version is 6.0.9.
Here is my snippet of code:
LogManager logManager = LogManager.getLogManager();
EnumerationString e = logManager.getLoggerNames();
while (e.hasMoreElements())
{
String loggername = e.nextElement();
Logger logger = logManager.getLogger(loggername);
Handler[] handlers = logger.getHandlers();
if (handlers != null handlers.length != 0)
{
for (Handler h : handlers)
{
h.setLevel(Level.WARNING);
}
logger.setLevel(Level.WARNING);
}
}
Konstantin Kolinko wrote:
2011/6/22 Roshni Basu roshni...@gmail.com:
I am changing the log level of tomcat to Level.WARNING. In this case I'm
trying to restart tomcat and see the logs, I can see the info level logs
like INFO: Server startup in 50516 ms .
I guess info level logs should not appear if log level set to warning.
1. If you did it correctly then yes, they should not appear. But what
exactly did you? Please be specific.
2. Exact Tomcat version, etc.
Kindly let me know how exactly it behvaes
The sources are all available.
java.util.logging documentation is available from Oracle.
Best regards,
Konstantin Kolinko
-
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/Tomcat-Logging-level-change-tp31902405p31903978.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 Logging level change
On 22/06/2011 16:03, Roshni Basu wrote:
Tomcat version is 6.0.9.
Here is my snippet of code:
LogManager logManager = LogManager.getLogManager();
EnumerationString e = logManager.getLoggerNames();
while (e.hasMoreElements())
{
String loggername = e.nextElement();
Logger logger = logManager.getLogger(loggername);
Handler[] handlers = logger.getHandlers();
if (handlers != null handlers.length != 0)
{
for (Handler h : handlers)
{
h.setLevel(Level.WARNING);
}
logger.setLevel(Level.WARNING);
}
}
Which is running where exactly?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Logging level change
I have created a java file. And running this. Could you elaborate what
exactly you want to know?
Mark Thomas wrote:
On 22/06/2011 16:03, Roshni Basu wrote:
Tomcat version is 6.0.9.
Here is my snippet of code:
LogManager logManager = LogManager.getLogManager();
EnumerationString e = logManager.getLoggerNames();
while (e.hasMoreElements())
{
String loggername = e.nextElement();
Logger logger = logManager.getLogger(loggername);
Handler[] handlers = logger.getHandlers();
if (handlers != null handlers.length != 0)
{
for (Handler h : handlers)
{
h.setLevel(Level.WARNING);
}
logger.setLevel(Level.WARNING);
}
}
Which is running where exactly?
Mark
-
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/Tomcat-Logging-level-change-tp31902405p31904108.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: Slower start with Tomcat 7.0.14 and higher
On 6/22/2011 9:08 AM, Mark Thomas wrote: Another issue is that WEB-INF/lib is visible to the parent classloader embedding Tomcat and to Tomcat as part of the web application and thus I'm probably getting double scanning -- though really Tomcat should be avoiding this by detecting that the same jar file is involved in both cases. The reasons for the duplication in this classpath are long and historic. Overall I'd rather not try to unwind this now. I'd hope/assume that an annotation on a class, e.g. a filter annotation, would only result in one filter instance irrespective of how many times that class is visible to the classloader(s) in question. That sounds like it might cause trouble. Classes are identified by the combination of name and class loader so the same class loaded in two different class loaders is treated as a different class. If both the web application class loader and its parent class loader can see WEB-INF/lib I can image all sorts of things may go wrong. Well the classloaders are clearly hierarchical, so only one Class instance is loaded. The fact that both ClassLoaders can see the jar does not result in 2 Class objects -- nor should it result in an annotation being applied multiple times. The jars are in fact exactly the same here -- as one of the web app's WEB-INF/lib directories is visible to the parent classloader. It may be possible to move the jars somewhere else so that they're only part of the parent classloader, but that will require more reshuffling of the longstanding configuration. Given that the JNDI node maps to a file if the web app is expanded -- as mine always is (being deployed originally as an expanded directory in .war layout not as a .ware archive), it seems there should be a back door for Tomcat to notice this and simply use the file location to begin with rather than doing any extra temporary file shenanigans in any case. The JNDI wrapping is nice and all, but shouldn't cause a substantially sub-optimal performance approach when it is clear enough how to attain the appropriate File object. It should be doing that already. I'll double check Is there any danger -- other than worse performance in use cases I don't have -- in me patching my own Tomcat to always use FileUrlJar? Should this perhaps be a config option? Or possibly a config option based on file size? [FileUrlJar may only be faster for larger jars from what little I know...] That local patch should be safe. In terms of config, I'd like to keep this as automated as possible. More research required. For reference, how big are the JAR files we are talking about here? They range in size from 48K to 46MB. Only 3 jars are over 25MB in size. -- Jess Holle
Re: Tomcat Logging level change
On 22/06/2011 16:16, Roshni Basu wrote:
I have created a java file. And running this. Could you elaborate what
exactly you want to know?
I want to know how this code is being executed. When does it run? What
triggers it?
Mark
Mark Thomas wrote:
On 22/06/2011 16:03, Roshni Basu wrote:
Tomcat version is 6.0.9.
Here is my snippet of code:
LogManager logManager = LogManager.getLogManager();
EnumerationString e = logManager.getLoggerNames();
while (e.hasMoreElements())
{
String loggername = e.nextElement();
Logger logger = logManager.getLogger(loggername);
Handler[] handlers = logger.getHandlers();
if (handlers != null handlers.length != 0)
{
for (Handler h : handlers)
{
h.setLevel(Level.WARNING);
}
logger.setLevel(Level.WARNING);
}
}
Which is running where exactly?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Servlet input/output streams
My understanding is that I should *not* close the servlet input/output streams (if you don't open them - you shouldn't close them) But what if I have wrapped those streams inside other streams that I want to close? Let's say I have several layers of object streams, cipher streams, compression streams, etc. Will it be ok to call close on the outer-most stream, or do I need to rely on the 'flush' and 'finish' methods on these wrapping streams. What about the potential for memory leaks - or is that mostly just an issue on the inner-most stream that actually does the physical I/O? Thank you for taking the time to read this email.
Re: Tomcat Logging level change
I just run it when I need to change the log level.
Mark Thomas wrote:
On 22/06/2011 16:16, Roshni Basu wrote:
I have created a java file. And running this. Could you elaborate what
exactly you want to know?
I want to know how this code is being executed. When does it run? What
triggers it?
Mark
Mark Thomas wrote:
On 22/06/2011 16:03, Roshni Basu wrote:
Tomcat version is 6.0.9.
Here is my snippet of code:
LogManager logManager = LogManager.getLogManager();
EnumerationString e = logManager.getLoggerNames();
while (e.hasMoreElements())
{
String loggername = e.nextElement();
Logger logger = logManager.getLogger(loggername);
Handler[] handlers = logger.getHandlers();
if (handlers != null handlers.length != 0)
{
for (Handler h : handlers)
{
h.setLevel(Level.WARNING);
}
logger.setLevel(Level.WARNING);
}
}
Which is running where exactly?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
View this message in context:
http://old.nabble.com/Tomcat-Logging-level-change-tp31902405p31904220.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 Logging level change
Basically I have an web application running on tomcat.
Mark Thomas wrote:
On 22/06/2011 16:16, Roshni Basu wrote:
I have created a java file. And running this. Could you elaborate what
exactly you want to know?
I want to know how this code is being executed. When does it run? What
triggers it?
Mark
Mark Thomas wrote:
On 22/06/2011 16:03, Roshni Basu wrote:
Tomcat version is 6.0.9.
Here is my snippet of code:
LogManager logManager = LogManager.getLogManager();
EnumerationString e = logManager.getLoggerNames();
while (e.hasMoreElements())
{
String loggername = e.nextElement();
Logger logger = logManager.getLogger(loggername);
Handler[] handlers = logger.getHandlers();
if (handlers != null handlers.length != 0)
{
for (Handler h : handlers)
{
h.setLevel(Level.WARNING);
}
logger.setLevel(Level.WARNING);
}
}
Which is running where exactly?
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
View this message in context:
http://old.nabble.com/Tomcat-Logging-level-change-tp31902405p31904384.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: Drop message SESSION-EXPIRED inside GET_ALL_SESSIONS
I'm using Tomcat 6.0.0.29 and am also experiencing a similar issue where I am seeing Drop message SESSION-EXPIRED inside GET_ALL_SESSIONS sync phase start date 6/21/11 3:22 PM message date 12/31/69 6:00 PM when I restart a node in the cluster. What concerns me is that the message date is 13/31/69 at 6PM. Have you made any headway on this? On Tue, Jun 14, 2011 at 3:21 PM, John Clark scra...@scratchdrive.com wrote: I am experiencing an issue with my cluster I have been unable to figure out. My cluster contains 4 servers each with 4 instances of Tomcat segregated by mod_jk directives. Server1 Directives: / - tomcat.server1 /app1 - tomcat-app1.server1 /app2 - tomcat-app2.server1 /app3 - tomcat-app3.server1 Server2 Directives: / - tomcat.server2 /app1 - tomcat-app1.server2 /app2 - tomcat-app2.server2 /app3 - tomcat-app3.server2 ... and so on All Tomcat segmentations are clustered and share session data so our users can move between them seamlessly on our application. Here's the scenario I'm experiencing: - User1 logs on to server1 and navigates to tomcat-app1.server1 - tomcat-app1.server1 becomes unresponsive and is removed from the cluster - User1 is moved to tomcat-app1.server2 successfully and experiences no issues. - tomcat-app1.server1 becomes responsive and is added back to the cluster. - tomcat-app1.server1 requests session states and throws the following error in catalina.out: WARNING: Manager [localhost#]: Drop message SESSION-EXPIRED inside GET_ALL_SESSIONS sync phase start date 6/14/11 1:59 PM message date 12/31/69 6:00 PM INFO: Lost Session [A56F0A74DCF2FBA7F179100C3D84A485.app1.server2] at path [] - Load balancer moves User1 back to tomcat-app1.server1 - User1 gets logged out (lost session)
Apache/Tomcat_means...?
Hi, I'm really confused with Apache; Apache/Tomcat; Tomcat. Please correct me if I'm wrong: When I install Apache/Tomcat, I install Apache web sever and Tomcat application sever at the same time.I could do the same thing by installing Apache web sever, and Tomcat application server separatelyThanks in advance, Fred,
Re: Apache/Tomcat_means...?
Apache = Apache Software Foundation. This is the legal organization which has all the wonderful bureaucracy in setting up rules for software development and making sure projects adhere to various countries laws. Tomcat - Actually Apache Tomcat - the implementation of the servlet spec. A project in the Apache software foundation. Apache web server - Also know has Apache httpd - the original project which begat the the Apache software foundation. Many times when Apache is mentioned, the speaker will imply Apache httpd. That being said ... Apache Tomcat and Apache httpd are 2 different products with their own different methods of installation. You may also use Apache Tomcat without needing Apache httpd. The Tomcat FAQ has some more details about that. -Tim On Wed, Jun 22, 2011 at 12:01 PM, Fred fdu...@yahoo.fr wrote: Hi, I'm really confused with Apache; Apache/Tomcat; Tomcat. Please correct me if I'm wrong: When I install Apache/Tomcat, I install Apache web sever and Tomcat application sever at the same time.I could do the same thing by installing Apache web sever, and Tomcat application server separatelyThanks in advance, Fred,
RE: Tomcat Logging level change
From: Roshni Basu [mailto:roshni...@gmail.com] Subject: Re: Tomcat Logging level change I just run it when I need to change the log level. (This is like pulling teeth.) You're providing virtually no useful information here. You run the program where? As a servlet? Standalone? In some listener inside Tomcat? If you run it outside of Tomcat, why do you think it would have any effect on what's going on inside Tomcat? - 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: Apache/Tomcat_means...?
Yes. And someone else please explains better - at a high level: - the functionality where they overlap - the functionality where they differ - what is to be done if they are to be integrated Home page: rs6.risingnet.net/~ddcc Health Info Anytime for Everyone: www.HealthCheck4Me.info Exercise for the Mind: www.SuDoKuChallenge.us Marketing site: www.OntoOO.com Do NOT buy Dell, Mac, Ford, Chrysler Boycott Chinese Products --- On Wed, 6/22/11, Tim Funk funk...@apache.org wrote: From: Tim Funk funk...@apache.org Subject: Re: Apache/Tomcat_means...? To: Tomcat Users List users@tomcat.apache.org Date: Wednesday, June 22, 2011, 9:10 AM Apache = Apache Software Foundation. This is the legal organization which has all the wonderful bureaucracy in setting up rules for software development and making sure projects adhere to various countries laws. Tomcat - Actually Apache Tomcat - the implementation of the servlet spec. A project in the Apache software foundation. Apache web server - Also know has Apache httpd - the original project which begat the the Apache software foundation. Many times when Apache is mentioned, the speaker will imply Apache httpd. That being said ... Apache Tomcat and Apache httpd are 2 different products with their own different methods of installation. You may also use Apache Tomcat without needing Apache httpd. The Tomcat FAQ has some more details about that. -Tim On Wed, Jun 22, 2011 at 12:01 PM, Fred fdu...@yahoo.fr wrote: Hi, I'm really confused with Apache; Apache/Tomcat; Tomcat. Please correct me if I'm wrong: When I install Apache/Tomcat, I install Apache web sever and Tomcat application sever at the same time.I could do the same thing by installing Apache web sever, and Tomcat application server separatelyThanks in advance, Fred,
RE: Tomcat Logging level change
Application is running on tomcat. n828cl wrote: From: Roshni Basu [mailto:roshni...@gmail.com] Subject: Re: Tomcat Logging level change I just run it when I need to change the log level. (This is like pulling teeth.) You're providing virtually no useful information here. You run the program where? As a servlet? Standalone? In some listener inside Tomcat? If you run it outside of Tomcat, why do you think it would have any effect on what's going on inside Tomcat? - 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 -- View this message in context: http://old.nabble.com/Tomcat-Logging-level-change-tp31902405p31904708.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 Logging level change
Its working fine when I set to Fine. In catalina.out i can see fine and info logs butwhen I set to warning, even info level logs appear. n828cl wrote: From: Roshni Basu [mailto:roshni...@gmail.com] Subject: Re: Tomcat Logging level change I just run it when I need to change the log level. (This is like pulling teeth.) You're providing virtually no useful information here. You run the program where? As a servlet? Standalone? In some listener inside Tomcat? If you run it outside of Tomcat, why do you think it would have any effect on what's going on inside Tomcat? - 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 -- View this message in context: http://old.nabble.com/Tomcat-Logging-level-change-tp31902405p31904743.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: Apache/Tomcat_means...?
From: Dennis de Champeaux [mailto:atlantisic...@yahoo.com] Subject: Re: Apache/Tomcat_means...? And someone else please explains better - at a high level: - the functionality where they overlap - the functionality where they differ - what is to be done if they are to be integrated http://en.wikipedia.org/wiki/Apache_Tomcat Perhaps Google isn't available in Atlantis... - 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: crlFile and SunX509 algorithm in Tomcat 7.0.16
Tomcat 6.0.x looks to be OK. There is a copy/paste problem in 7.0.x that I'll fixed shortly. If you are willing to build Tomcat 7.0.x from source (not hard) then it will be easy for you to test the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Logging level change
2011/6/22 Roshni Basu roshni...@gmail.com: Tomcat version is 6.0.9. You know, 6.0.32 is out there... http://tomcat.apache.org/security-6.html Here is my snippet of code: LogManager logManager = LogManager.getLogManager(); EnumerationString e = logManager.getLoggerNames(); It won't work, because the LogManager implementation used by Tomcat (see docs for details) provides isolation for different webapps (class loaders). You code will affect only single webapp, and will have zero effect on anything else. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
On 6/22/2011 10:16 AM, Jess Holle wrote: On 6/22/2011 9:08 AM, Mark Thomas wrote: Another issue is that WEB-INF/lib is visible to the parent classloader embedding Tomcat and to Tomcat as part of the web application and thus I'm probably getting double scanning -- though really Tomcat should be avoiding this by detecting that the same jar file is involved in both cases. The reasons for the duplication in this classpath are long and historic. Overall I'd rather not try to unwind this now. I'd hope/assume that an annotation on a class, e.g. a filter annotation, would only result in one filter instance irrespective of how many times that class is visible to the classloader(s) in question. That sounds like it might cause trouble. Classes are identified by the combination of name and class loader so the same class loaded in two different class loaders is treated as a different class. If both the web application class loader and its parent class loader can see WEB-INF/lib I can image all sorts of things may go wrong. Well the classloaders are clearly hierarchical, so only one Class instance is loaded. The fact that both ClassLoaders can see the jar does not result in 2 Class objects -- nor should it result in an annotation being applied multiple times. The jars are in fact exactly the same here -- as one of the web app's WEB-INF/lib directories is visible to the parent classloader. It may be possible to move the jars somewhere else so that they're only part of the parent classloader, but that will require more reshuffling of the longstanding configuration. I increased the verbosity for the StandardJarScanner logger. Based on that output everything appears ok for our use case. The only duplicated jars we have are in WEB-INF/lib which is already automatically ignored when scanning the classpath. The only issue I found at this level is that both tomcat-juli-adapters.jar and tomcat-juli-adapters.jar are scanned. I'd think that all the Tomcat extras jars should be in Tomcat's out-of-the-box list of jars to be ignored -- unless they actually shouldn't be ignored, of course. That's a rather minor issue, though -- and presumably accounts for very, very little of the startup time. -- Jess Holle
RE: Slower start with Tomcat 7.0.14 and higher
From: Jess Holle [mailto:je...@ptc.com] Subject: Re: Slower start with Tomcat 7.0.14 and higher Well the classloaders are clearly hierarchical, so only one Class instance is loaded. The fact that both ClassLoaders can see the jar does not result in 2 Class objects I think we need some experimentation (or browsing through some really ugly C++ code in the JVM) to verify the above. I have a vague memory of the class dependency resolution being routed through the classloader of the class with the dependency, not the thread's current classloader, thus avoiding downward pointer issues. However, since I've been looking at JVM code since 1.2 days, I can't be sure that's the way it works today without doing some more homework. If dependency resolution does work the way I remember, then it would be possible for the same .class file to be processed by different classloaders in your environment. - 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.
Re: Slower start with Tomcat 7.0.14 and higher
Since delegation is downwards the only issue that should possibly occur is if a class gets loaded in the parent classloader that then needs a class in the child (e.g. web app) classloader. That will fail, of course, but that's ok as this should never occur. On 6/22/2011 12:27 PM, Caldarale, Charles R wrote: From: Jess Holle [mailto:je...@ptc.com] Subject: Re: Slower start with Tomcat 7.0.14 and higher Well the classloaders are clearly hierarchical, so only one Class instance is loaded. The fact that both ClassLoaders can see the jar does not result in 2 Class objects I think we need some experimentation (or browsing through some really ugly C++ code in the JVM) to verify the above. I have a vague memory of the class dependency resolution being routed through the classloader of the class with the dependency, not the thread's current classloader, thus avoiding downward pointer issues. However, since I've been looking at JVM code since 1.2 days, I can't be sure that's the way it works today without doing some more homework. If dependency resolution does work the way I remember, then it would be possible for the same .class file to be processed by different classloaders in your environment. - 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: Slower start with Tomcat 7.0.14 and higher
From: Jess Holle [mailto:je...@ptc.com] Subject: Re: Slower start with Tomcat 7.0.14 and higher Since delegation is downwards Only for the webapp classloader. the only issue that should possibly occur is if a class gets loaded in the parent classloader that then needs a class in the child (e.g. web app) classloader. That will fail, of course, but that's ok as this should never occur. I think it can happen, without detection, if you have the same class directly visible to multiple classloaders - which I recall that you do (but perhaps I misunderstood this statement: the base classloader includes a lot more than CATALINA_BASE/lib. Some of these jars are huge -- and the intent (and effect) is that these are shared by any/all web app instances.). So before pursuing this any further, is the same class visible to more than one classloader in your environment? If not, then there should be no problem, regardless of internal classloader logic. - 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.
Re: Apache Tomcat 7.0.14
Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.**http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://**tomcat.apache.org/tomcat-7.0-** doc/config/http.html#Common_**Attributeshttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests --** --**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apa**che.orghttp://apache.org users-unsubscribe@**tomcat.apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Regards, Adarsh 9972523214
Re: Apache Tomcat 7.0.14
On 22/06/2011 19:03, adarsh thimmappa wrote: Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. The default, out of the box configuration works for me with a single change to use the HTTP NIO connector. There is no issue here. You need to do some further investigations to figure out why it isn't working for you. Mark On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.**http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://**tomcat.apache.org/tomcat-7.0-** doc/config/http.html#Common_**Attributeshttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests --** --**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apa**che.orghttp://apache.org users-unsubscribe@**tomcat.apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-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: Apache Tomcat 7.0.14
From: adarsh thimmappa [mailto:adarsh.tm...@gmail.com] Subject: Re: Apache Tomcat 7.0.14 Can anyone please confirm this is an issue or not. Not directly. Can you get Wireshark (or equivalent) traces of the traffic between the client and the server? You can use those to determine which end is closing the TCP connection first, and whether or not the client is even requesting keep-alive. - 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.
Re: Apache Tomcat 7.0.14
Hi Mark, Let me investigate further. I will definitely get back on this. On Wed, Jun 22, 2011 at 11:37 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 19:03, adarsh thimmappa wrote: Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. The default, out of the box configuration works for me with a single change to use the HTTP NIO connector. There is no issue here. You need to do some further investigations to figure out why it isn't working for you. Mark On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.** http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://**tomcat.apache.org/tomcat-7.0-** doc/config/http.html#Common_**Attributes http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests --** --**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apa**che.org http://apache.org users-unsubscribe@**tomcat.apache.org users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org 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 -- Regards, Adarsh 9972523214
Re: crlFile and SunX509 algorithm in Tomcat 7.0.16
Mark, Thanks for looking into this and working to get the patch in for future versions. It will allow us to use later versions of Tomcat and not be stuck on 7.0.10. If you would like me to test the patch, I can rebuild from patched source and test locally. Martin On Wed, Jun 22, 2011 at 12:46 PM, Mark Thomas ma...@apache.org wrote: Tomcat 6.0.x looks to be OK. There is a copy/paste problem in 7.0.x that I'll fixed shortly. If you are willing to build Tomcat 7.0.x from source (not hard) then it will be easy for you to test the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Slower start with Tomcat 7.0.14 and higher
On 6/22/2011 12:44 PM, Caldarale, Charles R wrote: I think it can happen, without detection, if you have the same class directly visible to multiple classloaders - which I recall that you do (but perhaps I misunderstood this statement: the base classloader includes a lot more than CATALINA_BASE/lib. Some of these jars are huge -- and the intent (and effect) is that these are shared by any/all web app instances.). So before pursuing this any further, is the same class visible to more than one classloader in your environment? If not, then there should be no problem, regardless of internal classloader logic. Overall I'm pretty confident that things are okay here -- especially as we've been using and testing this configuration for quite some time now. -- Jess Holle - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 7.0.14
Hi All, In the entire source file of * org.apache.coyote.http11.Http11NioProtocol* class in *tomcat server 7.0.14*, there are no setters to set any of these properties such as connectionTimeout,socket reuseaddress, keepalivetimeout etc. I compared the same file with the *tomcat server version 6.0.14*, there in the source code, we check for all the attributes entered in the server.xml for connector tag. This logic is removed from in Tomcat 7.0.14. I am not able to figure out this part. I feel there is no provision to mention these attributes for NIO connector. I checked it. For example the connection timeout attribute works perfectly for BIO connector...not for NIO connector. So, i believe the documentation in the link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeshttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslotdoesn't seems to be accurate or I MAY BE WRONG, please share your thoughts on the same. *Any suggestions would be most welcome.* On Wed, Jun 22, 2011 at 11:41 PM, adarsh thimmappa adarsh.tm...@gmail.comwrote: Hi Mark, Let me investigate further. I will definitely get back on this. On Wed, Jun 22, 2011 at 11:37 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 19:03, adarsh thimmappa wrote: Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. The default, out of the box configuration works for me with a single change to use the HTTP NIO connector. There is no issue here. You need to do some further investigations to figure out why it isn't working for you. Mark On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.** http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://**tomcat.apache.org/tomcat-7.0-** doc/config/http.html#Common_**Attributes http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes keepAliveTimeout maxKeepAliveRequests --** --**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apa**che.org http://apache.org users-unsubscribe@**tomcat.apache.org users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org 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 -- Regards, Adarsh 9972523214 -- Regards, Adarsh 9972523214
Re: crlFile and SunX509 algorithm in Tomcat 7.0.16
On 22/06/2011 20:03, Martin Dubuc wrote: Mark, Thanks for looking into this and working to get the patch in for future versions. It will allow us to use later versions of Tomcat and not be stuck on 7.0.10. If you would like me to test the patch, I can rebuild from patched source and test locally. Please. It would be good to get confirmation that it is now working as intended. Mark Martin On Wed, Jun 22, 2011 at 12:46 PM, Mark Thomas ma...@apache.org wrote: Tomcat 6.0.x looks to be OK. There is a copy/paste problem in 7.0.x that I'll fixed shortly. If you are willing to build Tomcat 7.0.x from source (not hard) then it will be easy for you to test the patch. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 7.0.14
You really need to read http://www.catb.org/~esr/faqs/smart-questions.html before folks here just start ignoring your messages. On 22/06/2011 20:59, adarsh thimmappa wrote: Hi All, In the entire source file of * org.apache.coyote.http11.Http11NioProtocol* class in *tomcat server 7.0.14*, there are no setters to set any of these properties such as connectionTimeout,socket reuseaddress, keepalivetimeout etc. I compared the same file with the *tomcat server version 6.0.14*, there in the source code, we check for all the attributes entered in the server.xml for connector tag. This logic is removed from in Tomcat 7.0.14. I am not able to figure out this part. I feel there is no provision to mention these attributes for NIO connector. I checked it. You didn't check very carefully. You missed the inheritance. For example the connection timeout attribute works perfectly for BIO connector...not for NIO connector. Wrong. How may times do I have to say this? This has been tested and it works. There is not a bug here. Clearly, you are doing something wrong. You have been told exactly (by Chuck) what you need to do to investigate this. Your continued insistence that this is a Tomcat bug when there is zero evidence to support that theory and plenty of evidence to refute it is unlikely to be encouraging folks here to help you. So, i believe the documentation in the link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeshttp://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslotdoesn't seems to be accurate Yes, the documentation is accurate. or I MAY BE WRONG, please share your thoughts on the same. OK. Thought 1. There is no need to shout. It is rude and further reduces the chances of people here helping you. Thought 2. There is no may about it. You are wrong. Very wrong. *Any suggestions would be most welcome.* Really? Why would anyone here waste their time providing you with a suggestion when all you have done with the advice you have been given so far is ignore it? Mark On Wed, Jun 22, 2011 at 11:41 PM, adarsh thimmappa adarsh.tm...@gmail.comwrote: Hi Mark, Let me investigate further. I will definitely get back on this. On Wed, Jun 22, 2011 at 11:37 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 19:03, adarsh thimmappa wrote: Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. The default, out of the box configuration works for me with a single change to use the HTTP NIO connector. There is no issue here. You need to do some further investigations to figure out why it isn't working for you. Mark On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.** http://tomcat.apache.org/**tomcat-7.0-doc/config/http.** html#Common_Attributeshttp://**tomcat.apache.org/tomcat-7.0-** doc/config/http.html#Common_**Attributes
JULI prefix not recognized?
Hi all;
I sure that is going to turnout to be a stupid question but I've played with
it for two days and made no progress. I can create a JULI handler as long
as I don't apply a prefix, here is the logging.properties file (keeping it
as simple as possible):
THIS WORKS FINE
---
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${user.home}
org.apache.juli.FileHandler.prefix = localhost.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
---
THIS FAILS
---
handlers = 1pae.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
.handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
1pae.org.apache.juli.FileHandler.level = FINE
1pae.org.apache.juli.FileHandler.directory = ${user.home}
1pae.org.apache.juli.FileHandler.prefix = localhost.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
---
THE FOLLOWING ERROR OCCURS ON TOMCAT STARTUP:
---
Can't load log handler 1pae.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.util.logging.LogManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source)
at java.util.logging.LogManager.access$900(Unknown Source)
at java.util.logging.LogManager$RootLogger.addHandler(Unknown Source)
at java.util.logging.LogManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.addLogger(Unknown Source)
at java.util.logging.LogManager$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.clinit(Unknown Source)
at java.util.logging.Logger.getLogger(Unknown Source)
at org.apache.juli.logging.DirectJDKLog.init(DirectJDKLog.java:71)
at
org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:178)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:171)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:243)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:298)
at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:55)
The tomcat-juli.jar is available as demonstrated in the first example that
works. Why is the prefix not being recognized?
Your assistance is greatly appreciated.
TC
--
View this message in context:
http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31907205.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: JULI prefix not recognized?
2011/6/23 throwsCode donmillho...@yahoo.com: I sure that is going to turnout to be a stupid question but I've played with it for two days and made no progress. I can create a JULI handler as long as I don't apply a prefix, here is the logging.properties file (keeping it as simple as possible): Can't load log handler 1pae.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler (...) at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source) at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source) You are using wrong LogManager. You need to use org.apache.juli.ClassLoaderLogManager and not the default one. See how catalina.sh does it. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [tomcat 7 migartion] cannot load images with jsession id in url
2011/6/22 Guy Katz gk...@allot.com: Hi all; I am migrating to tomcat 7 from 6. In tomcat 6 urls like http://68.169.51.83:8080/gallery/wave_surfing_gallery_thumb_652.jpg;jses sionid=A859D830090798F238DABADC713C1327 would load an image but in tomcat 7 I get the following response: The Image . cannot be displayed because it contains errors First you will have to find, what the difference is. - corrupted file (e.g. by transferring a binary file as text over FTP, or using a Writer to serve binary data) - truncated file - wrong response headers E.g. with wget --save-headers If Tomcat 7 were not able to serve images it would have been noted a long ago. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JULI prefix not recognized?
Thanks Konstantin:
I thought the JULI Classes automatically replaced the java.util.logging
Classes with the same name. Thanks for catching that, I'll checkout
catalina.sh and try to figure this out.
TC
throwsCode wrote:
Hi all;
I sure that is going to turnout to be a stupid question but I've played
with it for two days and made no progress. I can create a JULI handler as
long as I don't apply a prefix, here is the logging.properties file
(keeping it as simple as possible):
THIS WORKS FINE
---
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${user.home}
org.apache.juli.FileHandler.prefix = localhost.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
---
THIS FAILS
---
handlers = 1pae.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
.handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
1pae.org.apache.juli.FileHandler.level = FINE
1pae.org.apache.juli.FileHandler.directory = ${user.home}
1pae.org.apache.juli.FileHandler.prefix = localhost.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
---
THE FOLLOWING ERROR OCCURS ON TOMCAT STARTUP:
---
Can't load log handler 1pae.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
java.lang.ClassNotFoundException: 1pae.org.apache.juli.FileHandler
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.util.logging.LogManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.initializeGlobalHandlers(Unknown Source)
at java.util.logging.LogManager.access$900(Unknown Source)
at java.util.logging.LogManager$RootLogger.addHandler(Unknown Source)
at java.util.logging.LogManager$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)
at java.util.logging.LogManager.addLogger(Unknown Source)
at java.util.logging.LogManager$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.clinit(Unknown Source)
at java.util.logging.Logger.getLogger(Unknown Source)
at org.apache.juli.logging.DirectJDKLog.init(DirectJDKLog.java:71)
at
org.apache.juli.logging.DirectJDKLog.getInstance(DirectJDKLog.java:178)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:171)
at org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:243)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:298)
at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:55)
The tomcat-juli.jar is available as demonstrated in the first example that
works. Why is the prefix not being recognized?
Your assistance is greatly appreciated.
TC
--
View this message in context:
http://old.nabble.com/JULI-prefix-not-recognized--tp31907205p31907973.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: Servlet input/output streams
Hi
You may use decorator pattern to decorate the input output stream from
Servlet to a UnclosableInputStream UnclosableOutputStream,
public class UnclosableInputStream extends java.io.FilterInputStream {
public UnclosableInputStream(InputStream inputStream) {
super(inputStream);
}
@Override
public void close() {
// do nothing.
}
}
InputStream inputStream = new
UnclosableInputStream(servlet.getInputStream());
inputStream.read(); // invoke the decorated ServletInputStream.
inputStream.close() // do nothing
Hope it'll helpful for you.
Zijian.
2011/6/22 Ronald Albury ronalb...@gmail.com
My understanding is that I should *not* close the servlet input/output
streams (if you don't open them - you shouldn't close them)
But what if I have wrapped those streams inside other streams that I want
to
close? Let's say I have several layers of object streams, cipher streams,
compression streams, etc. Will it be ok to call close on the outer-most
stream, or do I need to rely on the 'flush' and 'finish' methods on these
wrapping streams.
What about the potential for memory leaks - or is that mostly just an issue
on the inner-most stream that actually does the physical I/O?
Thank you for taking the time to read this email.
Re: Tomcat Logging level change
So what exactly I can use to make it work in 6.0.9? Konstantin Kolinko wrote: 2011/6/22 Roshni Basu roshni...@gmail.com: Tomcat version is 6.0.9. You know, 6.0.32 is out there... http://tomcat.apache.org/security-6.html Here is my snippet of code: LogManager logManager = LogManager.getLogManager(); EnumerationString e = logManager.getLoggerNames(); It won't work, because the LogManager implementation used by Tomcat (see docs for details) provides isolation for different webapps (class loaders). You code will affect only single webapp, and will have zero effect on anything else. Best regards, Konstantin Kolinko - 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/Tomcat-Logging-level-change-tp31902405p31908461.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: Apache Tomcat 7.0.14
Ok..Thanks. On Thu, Jun 23, 2011 at 3:02 AM, Mark Thomas ma...@apache.org wrote: You really need to read http://www.catb.org/~esr/faqs/smart-questions.html before folks here just start ignoring your messages. On 22/06/2011 20:59, adarsh thimmappa wrote: Hi All, In the entire source file of * org.apache.coyote.http11.Http11NioProtocol* class in *tomcat server 7.0.14*, there are no setters to set any of these properties such as connectionTimeout,socket reuseaddress, keepalivetimeout etc. I compared the same file with the *tomcat server version 6.0.14*, there in the source code, we check for all the attributes entered in the server.xml for connector tag. This logic is removed from in Tomcat 7.0.14. I am not able to figure out this part. I feel there is no provision to mention these attributes for NIO connector. I checked it. You didn't check very carefully. You missed the inheritance. For example the connection timeout attribute works perfectly for BIO connector...not for NIO connector. Wrong. How may times do I have to say this? This has been tested and it works. There is not a bug here. Clearly, you are doing something wrong. You have been told exactly (by Chuck) what you need to do to investigate this. Your continued insistence that this is a Tomcat bug when there is zero evidence to support that theory and plenty of evidence to refute it is unlikely to be encouraging folks here to help you. So, i believe the documentation in the link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot doesn't seems to be accurate Yes, the documentation is accurate. or I MAY BE WRONG, please share your thoughts on the same. OK. Thought 1. There is no need to shout. It is rude and further reduces the chances of people here helping you. Thought 2. There is no may about it. You are wrong. Very wrong. *Any suggestions would be most welcome.* Really? Why would anyone here waste their time providing you with a suggestion when all you have done with the advice you have been given so far is ignore it? Mark On Wed, Jun 22, 2011 at 11:41 PM, adarsh thimmappa adarsh.tm...@gmail.comwrote: Hi Mark, Let me investigate further. I will definitely get back on this. On Wed, Jun 22, 2011 at 11:37 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 19:03, adarsh thimmappa wrote: Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. The default, out of the box configuration works for me with a single change to use the HTTP NIO connector. There is no issue here. You need to do some further investigations to figure out why it isn't working for you. Mark On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote: adarsh thimmappa wrote: Hi All, I am using Apache Tomcat 7.0 (7.0.14 version) server. I have a requirement such that Once i make a HTTP request, and get back the response, i want to keep that connection alive indefinitely. What is the configuration i need to make on the server side. By default, client uses HTTP/1.1 protocol version to make HTTP requests. I know that in HTTP/1.1, the Connection is kept alive by default. I am testing this setup on localhost. *Any help or suggestions will be appreciated.* Maybe reading the on-line documentation ? http://tomcat.apache.org/tomcat-7.0-doc/config/http.**
Re: Apache Tomcat 7.0.14
Hi Mark, I would be sorry if that was aggressive. I was testing the NIO connector and was monitoring the TCP connections between the client(Here the client is Apache MINA based) and the tomcat server(tomcat 7.0.14) through the tool (CurrPorts v1.91 - Monitoring Opened TCP/IP network ports / connections). I observed that the TCP connection suddenly disappears after the response is sent. I will put the logging in DEBUG or much more finer details mode, i will check whether will it be helpful in finding out the issue with my setup. Once again, thank you for your time. On Thu, Jun 23, 2011 at 9:43 AM, adarsh thimmappa adarsh.tm...@gmail.comwrote: Ok..Thanks. On Thu, Jun 23, 2011 at 3:02 AM, Mark Thomas ma...@apache.org wrote: You really need to read http://www.catb.org/~esr/faqs/smart-questions.html before folks here just start ignoring your messages. On 22/06/2011 20:59, adarsh thimmappa wrote: Hi All, In the entire source file of * org.apache.coyote.http11.Http11NioProtocol* class in *tomcat server 7.0.14*, there are no setters to set any of these properties such as connectionTimeout,socket reuseaddress, keepalivetimeout etc. I compared the same file with the *tomcat server version 6.0.14*, there in the source code, we check for all the attributes entered in the server.xml for connector tag. This logic is removed from in Tomcat 7.0.14. I am not able to figure out this part. I feel there is no provision to mention these attributes for NIO connector. I checked it. You didn't check very carefully. You missed the inheritance. For example the connection timeout attribute works perfectly for BIO connector...not for NIO connector. Wrong. How may times do I have to say this? This has been tested and it works. There is not a bug here. Clearly, you are doing something wrong. You have been told exactly (by Chuck) what you need to do to investigate this. Your continued insistence that this is a Tomcat bug when there is zero evidence to support that theory and plenty of evidence to refute it is unlikely to be encouraging folks here to help you. So, i believe the documentation in the link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributes http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot doesn't seems to be accurate Yes, the documentation is accurate. or I MAY BE WRONG, please share your thoughts on the same. OK. Thought 1. There is no need to shout. It is rude and further reduces the chances of people here helping you. Thought 2. There is no may about it. You are wrong. Very wrong. *Any suggestions would be most welcome.* Really? Why would anyone here waste their time providing you with a suggestion when all you have done with the advice you have been given so far is ignore it? Mark On Wed, Jun 22, 2011 at 11:41 PM, adarsh thimmappa adarsh.tm...@gmail.comwrote: Hi Mark, Let me investigate further. I will definitely get back on this. On Wed, Jun 22, 2011 at 11:37 PM, Mark Thomas ma...@apache.org wrote: On 22/06/2011 19:03, adarsh thimmappa wrote: Hi All, Can anyone please confirm this is an issue or not. I have visited this link http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Common_Attributeslot more timesi feel like nothing left w.r.t going back to this link again. If anyone is having configuration which is working for version 7.0.14..for this particular issue please share with me. The default, out of the box configuration works for me with a single change to use the HTTP NIO connector. There is no issue here. You need to do some further investigations to figure out why it isn't working for you. Mark On Wed, Jun 22, 2011 at 7:13 PM, André Warnier a...@ice-sa.com wrote: I don't think that az this stage you should be playing with the socket.* attributes, which refer to the low-level JVM TCP socket, and have quite another meaning and other side-effects. Re-read the description of the keepAliveTimeout attribute instead, which does refer to the HTTP protocol level. As a general rule : the default values for the Connector attributes have generally been chosen to be reasonable and fit the most usual use cases. Only modify them if you have a specific and precise reason to do so, after doing adequate measurements. adarsh thimmappa wrote: Hi Andre, I am using the below Connector tag configuration in the server.xml.I am still facing the same problem. Connector port=80 protocol=org.apache.coyote.**http11.Http11NioProtocol socket.soKeepAlive=true socket.soTimeout=360 maxKeepAliveRequests=-1 redirectPort=8443 / Thanks, Adarsh On Wed, Jun 22, 2011 at 4:18 PM, André Warnier a...@ice-sa.com wrote:
RE: Apache Tomcat 7.0.14
From: adarsh thimmappa [mailto:adarsh.tm...@gmail.com] Subject: Re: Apache Tomcat 7.0.14 I observed that the TCP connection suddenly disappears after the response is sent. Connections don't suddenly disappear - someone (possibly the client) closes it. Again, you need to look at TCP/IP traces of the traffic going both directions to see exactly what's going on. - 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.
