Re: FW: Question on Tomcat JDBC Connection Pool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Wes, On 8/18/14, 1:05 PM, Wes Clark wrote: One of the primary conditions for which we want to mark the connection for death is when a rollback fails with an exception. An example of this kind of error is a network error. Won't this happen automatically? If the network connection dies, the server should auto-rollback the transaction. The JDBC connection will fail due to the same reason and the pool will re-establish a new Connection. Are you sure you have to manage this yourself? We do this with: PooledConnection pooledConnection = conn.unwrap(PooledConnection.class); pooledConnection.setDiscarded(true); I think I'll modify my code so that if an exception is thrown, instead of unconditionally evicting the connection from the pool, run the validation query right then and only evict if it fails. This won't catch intermittent network errors, which seems like the only really valid use case for you. - -chris -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, August 12, 2014 8:28 PM To: Tomcat Users List Subject: Re: Question on Tomcat JDBC Connection Pool Wes, On 8/12/14, 5:26 PM, Wes Clark wrote: (If the answer differs between Tomcat 7 and Tomcat 8, please note that.) When a SQL exception occurs, often the database connection will be broken and should be evicted from the pool. I'm interested in what kind of SQLException you'd get that you'd consider permanently fatal to the pooled connection. You can always rollback any transaction you've started and failed to complete. In our code, we call this marking the connection for death. We do this because we don't want to set the testOnReturn attribute to true to minimize the load on the database server. We set testOnIdle which will eventually find and evict stale connections, but maybe not fast enough for a bad connection which is returned to the pool. My question is whether the test on return is done on the same thread as the user, or on a different thread that belongs to the connection pool. I haven't looked at the code, but I'd be surprised if it happens in a separate thread. That is, I would expect that the application thread would be used. If the latter, we wouldn't have to catch the fact that SQL exception has occurred and make sure the connection is evicted from the pool, and maybe would be okay with the extra load on the database server as long as the user time is not affected. The pool will remove the connection from itself without your intervention, regardless of what thread does that check. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJT816FAAoJEBzwKT+lPKRYnwAP/1jUCMUMcjLWJ1h56qCqY3R0 x2OYgMhC9zyy6tpQDvlvDVBjNQA2ioED7CDyVytmCQg2m6C11YC/loitQrGGfq/S Q4KwXEXKlPLsmyYRF1LeE6CYzu0loj1BtiYet9sQuDPKIGEnGxTgS1/0jfiQurKC 57KCDUO3DOeXsnXy8a5lWyrLHGYB1VGa6oRGLoiRcDEKKHKKc0hW+6xOL2LjAkVH EtS1Q9EpO4EzbXXDnCuoWD4jkZ3r6Csjz6aHRUdXO0/fqZKNQDpJnLASfQMVoe73 8AkzHHl2X4H/n7loReWw66BysnHtc6kX9M6sK/xjVUHtZJBYGMIBUQ4gbTymvN1v au1Re28wwaYFrVPGW997X+NAuRqhff9mV4Xfk3yVREo+RVnCZWzsAYW9M1HBJ5/m hjki8uglRfS3befn9ph13igtFcD+df8kXMylL0/JldBbxf+gNAYdWx40/oClZ9PV e3AFLClN3i2tJh/0/+3Z2eTVss+F+eNkAVqQkmpO/uQ0xtOO9EsNUOdYFuqndnTK VgQCGrJXn1MQ2bW6i5H+Y8JXiRmUSPR2K169AGYBBu8yY8bWcjTmOUJ5xVGrm8mA sZ5xUPYQQpHDBP5p03xxi+OtWjMrZjZB6t1TZK0enAv3ni5XFoml7sNukHWhqg4h bgMrFIWeOUz3QQLoyIm2 =GLlP -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
FW: Question on Tomcat JDBC Connection Pool
One of the primary conditions for which we want to mark the connection for death is when a rollback fails with an exception. An example of this kind of error is a network error. We do this with: PooledConnection pooledConnection = conn.unwrap(PooledConnection.class); pooledConnection.setDiscarded(true); I think I'll modify my code so that if an exception is thrown, instead of unconditionally evicting the connection from the pool, run the validation query right then and only evict if it fails. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, August 12, 2014 8:28 PM To: Tomcat Users List Subject: Re: Question on Tomcat JDBC Connection Pool -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Wes, On 8/12/14, 5:26 PM, Wes Clark wrote: (If the answer differs between Tomcat 7 and Tomcat 8, please note that.) When a SQL exception occurs, often the database connection will be broken and should be evicted from the pool. I'm interested in what kind of SQLException you'd get that you'd consider permanently fatal to the pooled connection. You can always rollback any transaction you've started and failed to complete. In our code, we call this marking the connection for death. We do this because we don't want to set the testOnReturn attribute to true to minimize the load on the database server. We set testOnIdle which will eventually find and evict stale connections, but maybe not fast enough for a bad connection which is returned to the pool. My question is whether the test on return is done on the same thread as the user, or on a different thread that belongs to the connection pool. I haven't looked at the code, but I'd be surprised if it happens in a separate thread. That is, I would expect that the application thread would be used. If the latter, we wouldn't have to catch the fact that SQL exception has occurred and make sure the connection is evicted from the pool, and maybe would be okay with the extra load on the database server as long as the user time is not affected. The pool will remove the connection from itself without your intervention, regardless of what thread does that check. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJT6ttIAAoJEBzwKT+lPKRYpn0QAK3wm+qkT/VTZ3JDsB3EqUIf +LKOmDZ2szUgzL0VOScl0jksXzcyYIvLqt/OmmU6dKBTDuxgNO5j7rZBRFzcHfi2 c2cL3fXzUYWTS6y825cokYkX/rQJJJ2WM6QDhracFN3SIMdDO7E7YOjudbk5VEOf QoEMLX7V1uvnR1H1JWyE9QJKIdof1oYpIeiQtDi64PmC6u+gPuLN1512ZGxZpZfV JUvqJe4rkW+bDWiqhC5O3RE0HbsqLRn+/0YR98drIWQpTZhsymIBXfTtbm0OAFgv oQN6JKjUPFqoFTJ/l/lGSjqICQCapgarntuPhTks9bJ9e0fK/ljwq4UXb07sxZ5T huVGQkIkxfjBCslVPmwg9ffzcz6ZiJ9iySAoQL5IfAM7KSbIvsXNRBbGEOlJ1jWq 45CZfalqrtfOw36zFmGHgtmdXSAJJTUQxbCBQ1QXhxqT/QnJErFLXEdyH4/qm/Q6 obtCmSOgoWkiGiap3bCXsI2zWDyX3nRjncraJy04YtFH5aXTgBj/ww9dsToi0N9e kUT3UnMFJT1A1kPKZQ5H4pd8UtbbqKALUrWZhkeceOvHY2gVXse8YPPM5fiIl/E+ guZUQp3/d45csKp/uxxUNmjB5CU8d43O9c6aV/YX5Im6slMC4xsRuFolZJwBb0uA lZ/GiIrzyfMpmPcoyVrp =p9Od -END PGP SIGNATURE-
Re: FW: question on clustering Tomcat 7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles, On 3/16/12 8:43 PM, charles didonato wrote: I have two tomcat instances on 1 machine, each with a different AJP connector port and manager application port. I have Apache webserver for load balancing. When I undeploy my web app from one of the tomcat instances, it does not fail over to the other tomcat in the cluster and I get a 404 error. I am using a Simple TCP cluster. I have attached my server.xml. Can someone please tell me what I am missing? mod_jk fail-over doesn't work that way: if you want to un-deploy a webapp from one member of the cluster, you'll have to tell mod_jk to disable the member first, then let users die off, then undeploy the webapp. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9nP04ACgkQ9CaO5/Lv0PCjpACgnzTPJhSLJsCcfVCo89z/niNt OF8AnjfBG/jU8WLUeQtYzmJpzRxrjocP =k+68 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
FW: question on clustering Tomcat 7.0
I have two tomcat instances on 1 machine, each with a different AJP connector port and manager application port. I have Apache webserver for load balancing. When I undeploy my web app from one of the tomcat instances, it does not fail over to the other tomcat in the cluster and I get a 404 error. I am using a Simple TCP cluster. I have attached my server.xml. Can someone please tell me what I am missing? Thanks Charlie ?xml version='1.0' encoding='utf-8'? !-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to You under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- Note: A Server is not itself a Container, so you may not define subcomponents such as Valves at this level. Documentation at /docs/config/server.html -- Server port=8004 shutdown=SHUTDOWN !-- Security listener. Documentation at /docs/config/listeners.html Listener className=org.apache.catalina.security.SecurityListener / -- !--APR library loader. Documentation at /docs/apr.html -- Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / !--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -- Listener className=org.apache.catalina.core.JasperListener / !-- Prevent memory leaks due to use of particular java/javax APIs-- Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / !-- Global JNDI resources Documentation at /docs/jndi-resources-howto.html -- GlobalNamingResources !-- Editable user database that can also be used by UserDatabaseRealm to authenticate users -- Resource name=UserDatabase auth=Container type=org.apache.catalina.UserDatabase description=User database that can be updated and saved factory=org.apache.catalina.users.MemoryUserDatabaseFactory pathname=conf/tomcat-users.xml / /GlobalNamingResources !-- A Service is a collection of one or more Connectors that share a single Container Note: A Service is not itself a Container, so you may not define subcomponents such as Valves at this level. Documentation at /docs/config/service.html -- Service name=Catalina !--The connectors can use a shared executor, you can define one or more named thread pools-- !-- Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=150 minSpareThreads=4/ -- !-- A Connector represents an endpoint by which requests are received and responses are returned. Documentation at : Java HTTP Connector: /docs/config/http.html (blocking non-blocking) Java AJP Connector: /docs/config/ajp.html APR (HTTP/AJP) Connector: /docs/apr.html Define a non-SSL HTTP/1.1 Connector on port 8080 -- !-- Connector port=8081 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / -- !-- A Connector using the shared thread pool-- Connector executor=tomcatThreadPool port=8082 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / !-- Define a SSL HTTP/1.1 Connector on port 8443 This connector uses the JSSE configuration, when using APR, the connector should be using the OpenSSL style configuration described in the APR documentation -- !-- Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true clientAuth=false sslProtocol=TLS / -- !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8008 protocol=AJP/1.3 redirectPort=8443 / !-- An Engine represents the entry point (within Catalina) that processes every request. The Engine implementation for Tomcat stand alone analyzes the HTTP headers included with the request, and passes them on to the appropriate Host (virtual host). Documentation at /docs/config/engine.html -- !-- You should set jvmRoute to support load-balancing via AJP ie : -- Engine name=Catalina defaultHost=localhost jvmRoute=jvm1
Re: FW: question regarding 'mod_jk: error flushing'
Alright, thanks for your explanation! Are the mod_jk: error flushing messages more or less harmless? If so, I prefer sticking to 1.2.6 for the moment. Durk Hi Durk, the flushing has been changed in May 2005 around the time of version 1.2.13 or 1.2.14. Previously there were a lot of calls to ap_rflush() during the writing of responses. Because that produced many problems (not only log messages) concerning performance and memory requirements, these calls have been made optional. So updating to 1.2.19 really changes the flushing behaviour (and the log statement is not there any longer). The old behaviour (lots of flushing, but without the annoying log messages) can be configured with newer mod_jk with JkOptions +FlushPackets. That should only be necessary, if your application has complex timing requirements. Per default the switch is off. Regards, Rainer Durk Strooisma schrieb: Hi Durk, are you really talking about mod_jk? Yep, the package apache2-jakarta-tomcat-connectors contains (from the included README file): 1. mod_jk + Ajp13Connector 2. mod_jk2 + CoyoteConnector + JkCoyoteHandler 3. mod_webapp + WarpConnector 2 is experimental, 3 is deprected, we're using option 1; mod_jk. If yes: which version of nod_jk are you using? It would be nice, if you could check version 1.2.19. It was kinda hard to figure out the version... I've grepped in /usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev. Source for the apache2-jakarta-tomcat-connectors package was a tarball called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30 seems to be the version of connector bundle. I found the jk-version in jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h, which shows: 1.2.6, just as expected. Replacing this version with 1.2.9 isn't quite easy considering maintenance. The version that came with the SUSE-distribution ensures stability/compatibility (at least I may hope so considering it's an enterprise grade distro) and is easier maintainable (security updates just come with the update tool). Well, I COULD do some tests with other versions of mod_jk on the testing system, but as long as the issue doesn't harm the functionality of the web applications, I'm hesitating a little in investing my time and downtime of the system. But then again, IF a new version of mod_jk would eliminate the error messages, we still don't know why or what it actually was. Durk Regards, Rainer Durk Strooisma wrote: Hi all! I'm wondering the same. I've got four servers (two production machines and their testing counter parts) running SUSE Linux Enterprise Server 9 with Apache 2, Tomcat 5, and ModJK. Below the relevant packages are shown: apache2 2.0.49-27.59 apache2-prefork 2.0.49-27.59 apache2-jakarta-tomcat-connectors 5.0.19-29.1 jakarta-tomcat5.0.19-29.1 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one production system (and its testing system as well), but everything seems to work fine... The other production system isn't affected. It's kind of annoying that there's no timestamp shown in the error message. Debugging is really tough this way. I'm wondering what it means and whether it's harmless or not. Like Kevin states, nowhere on the internet this question seems to answered. Thanks in advance! Durk Hello there, Does anyone know what is this 'mod_jk: error flushing' about? I am using Tomcat 5.0, Apache and Mod_JK in production environment and keep getting this error in error log. I do google search and find lots of persons asking this question but no answer. Can anybody having experience with this shed a light on what it might be and how to resolve it? Thanks a lot, Kevin Song - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel. 0228/98549-0 Fax 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Germany Tel. +49/228/98549-0 Fax +49/228/98549-50 www.kippdata.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: FW: question regarding 'mod_jk: error flushing'
Thanks for looking into the source code. Well as long as no functional or performance problems arise in our web applications it seems to be okay. But, of course, the error messages are not really satifying. Anyway, I'll keep in mind that versions of mod_jk from 1.2.14 and above will not be able to produce these error messages anymore. Thanks again, Durk I'm afraid I can't tell for sure. I browsed a little through the apache code but not deep enough. The call has been removed after a discussion more or less based on no other module calls flush like mod_jk, just remove it. I didn't find a reliable source of information, when ap_rflush() is needed and under which circumstances it does not return with success. But frankly I limited the search in case of time when I noticed, that the whole construction is gone in mod_jk since more than a year. Regards, Rainer Durk Strooisma wrote: Alright, thanks for your explanation! Are the mod_jk: error flushing messages more or less harmless? If so, I prefer sticking to 1.2.6 for the moment. Durk Hi Durk, the flushing has been changed in May 2005 around the time of version 1.2.13 or 1.2.14. Previously there were a lot of calls to ap_rflush() during the writing of responses. Because that produced many problems (not only log messages) concerning performance and memory requirements, these calls have been made optional. So updating to 1.2.19 really changes the flushing behaviour (and the log statement is not there any longer). The old behaviour (lots of flushing, but without the annoying log messages) can be configured with newer mod_jk with JkOptions +FlushPackets. That should only be necessary, if your application has complex timing requirements. Per default the switch is off. Regards, Rainer Durk Strooisma schrieb: Hi Durk, are you really talking about mod_jk? Yep, the package apache2-jakarta-tomcat-connectors contains (from the included README file): 1. mod_jk + Ajp13Connector 2. mod_jk2 + CoyoteConnector + JkCoyoteHandler 3. mod_webapp + WarpConnector 2 is experimental, 3 is deprected, we're using option 1; mod_jk. If yes: which version of nod_jk are you using? It would be nice, if you could check version 1.2.19. It was kinda hard to figure out the version... I've grepped in /usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev. Source for the apache2-jakarta-tomcat-connectors package was a tarball called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30 seems to be the version of connector bundle. I found the jk-version in jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h, which shows: 1.2.6, just as expected. Replacing this version with 1.2.9 isn't quite easy considering maintenance. The version that came with the SUSE-distribution ensures stability/compatibility (at least I may hope so considering it's an enterprise grade distro) and is easier maintainable (security updates just come with the update tool). Well, I COULD do some tests with other versions of mod_jk on the testing system, but as long as the issue doesn't harm the functionality of the web applications, I'm hesitating a little in investing my time and downtime of the system. But then again, IF a new version of mod_jk would eliminate the error messages, we still don't know why or what it actually was. Durk Regards, Rainer Durk Strooisma wrote: Hi all! I'm wondering the same. I've got four servers (two production machines and their testing counter parts) running SUSE Linux Enterprise Server 9 with Apache 2, Tomcat 5, and ModJK. Below the relevant packages are shown: apache2 2.0.49-27.59 apache2-prefork 2.0.49-27.59 apache2-jakarta-tomcat-connectors 5.0.19-29.1 jakarta-tomcat5.0.19-29.1 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one production system (and its testing system as well), but everything seems to work fine... The other production system isn't affected. It's kind of annoying that there's no timestamp shown in the error message. Debugging is really tough this way. I'm wondering what it means and whether it's harmless or not. Like Kevin states, nowhere on the internet this question seems to answered. Thanks in advance! Durk Hello there, Does anyone know what is this 'mod_jk: error flushing' about? I am using Tomcat 5.0, Apache and Mod_JK in production environment and keep getting this error in error log. I do google search and find lots of persons asking this question but no answer. Can anybody having experience with this shed a light on what it might be and how to resolve it? Thanks a lot, Kevin Song - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail:
Re: FW: question regarding 'mod_jk: error flushing'
Hi Durk, are you really talking about mod_jk? Yep, the package apache2-jakarta-tomcat-connectors contains (from the included README file): 1. mod_jk + Ajp13Connector 2. mod_jk2 + CoyoteConnector + JkCoyoteHandler 3. mod_webapp + WarpConnector 2 is experimental, 3 is deprected, we're using option 1; mod_jk. If yes: which version of nod_jk are you using? It would be nice, if you could check version 1.2.19. It was kinda hard to figure out the version... I've grepped in /usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev. Source for the apache2-jakarta-tomcat-connectors package was a tarball called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30 seems to be the version of connector bundle. I found the jk-version in jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h, which shows: 1.2.6, just as expected. Replacing this version with 1.2.9 isn't quite easy considering maintenance. The version that came with the SUSE-distribution ensures stability/compatibility (at least I may hope so considering it's an enterprise grade distro) and is easier maintainable (security updates just come with the update tool). Well, I COULD do some tests with other versions of mod_jk on the testing system, but as long as the issue doesn't harm the functionality of the web applications, I'm hesitating a little in investing my time and downtime of the system. But then again, IF a new version of mod_jk would eliminate the error messages, we still don't know why or what it actually was. Durk Regards, Rainer Durk Strooisma wrote: Hi all! I'm wondering the same. I've got four servers (two production machines and their testing counter parts) running SUSE Linux Enterprise Server 9 with Apache 2, Tomcat 5, and ModJK. Below the relevant packages are shown: apache2 2.0.49-27.59 apache2-prefork 2.0.49-27.59 apache2-jakarta-tomcat-connectors 5.0.19-29.1 jakarta-tomcat5.0.19-29.1 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one production system (and its testing system as well), but everything seems to work fine... The other production system isn't affected. It's kind of annoying that there's no timestamp shown in the error message. Debugging is really tough this way. I'm wondering what it means and whether it's harmless or not. Like Kevin states, nowhere on the internet this question seems to answered. Thanks in advance! Durk Hello there, Does anyone know what is this 'mod_jk: error flushing' about? I am using Tomcat 5.0, Apache and Mod_JK in production environment and keep getting this error in error log. I do google search and find lots of persons asking this question but no answer. Can anybody having experience with this shed a light on what it might be and how to resolve it? Thanks a lot, Kevin Song - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel. 0228/98549-0 Fax 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Germany Tel. +49/228/98549-0 Fax +49/228/98549-50 www.kippdata.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: question regarding 'mod_jk: error flushing'
Hi Durk, the flushing has been changed in May 2005 around the time of version 1.2.13 or 1.2.14. Previously there were a lot of calls to ap_rflush() during the writing of responses. Because that produced many problems (not only log messages) concerning performance and memory requirements, these calls have been made optional. So updating to 1.2.19 really changes the flushing behaviour (and the log statement is not there any longer). The old behaviour (lots of flushing, but without the annoying log messages) can be configured with newer mod_jk with JkOptions +FlushPackets. That should only be necessary, if your application has complex timing requirements. Per default the switch is off. Regards, Rainer Durk Strooisma schrieb: Hi Durk, are you really talking about mod_jk? Yep, the package apache2-jakarta-tomcat-connectors contains (from the included README file): 1. mod_jk + Ajp13Connector 2. mod_jk2 + CoyoteConnector + JkCoyoteHandler 3. mod_webapp + WarpConnector 2 is experimental, 3 is deprected, we're using option 1; mod_jk. If yes: which version of nod_jk are you using? It would be nice, if you could check version 1.2.19. It was kinda hard to figure out the version... I've grepped in /usr/lib/apache2/mod_jk.so for '1.2', and it came up with 1.2.6-dev. Source for the apache2-jakarta-tomcat-connectors package was a tarball called jakarta-tomcat-connectors-4.1.30-src.tar.gz. 4.1.30 seems to be the version of connector bundle. I found the jk-version in jakarta-tomcat-connectors-4.1.30-src/jk/native/common/jk_version.h, which shows: 1.2.6, just as expected. Replacing this version with 1.2.9 isn't quite easy considering maintenance. The version that came with the SUSE-distribution ensures stability/compatibility (at least I may hope so considering it's an enterprise grade distro) and is easier maintainable (security updates just come with the update tool). Well, I COULD do some tests with other versions of mod_jk on the testing system, but as long as the issue doesn't harm the functionality of the web applications, I'm hesitating a little in investing my time and downtime of the system. But then again, IF a new version of mod_jk would eliminate the error messages, we still don't know why or what it actually was. Durk Regards, Rainer Durk Strooisma wrote: Hi all! I'm wondering the same. I've got four servers (two production machines and their testing counter parts) running SUSE Linux Enterprise Server 9 with Apache 2, Tomcat 5, and ModJK. Below the relevant packages are shown: apache2 2.0.49-27.59 apache2-prefork 2.0.49-27.59 apache2-jakarta-tomcat-connectors 5.0.19-29.1 jakarta-tomcat5.0.19-29.1 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one production system (and its testing system as well), but everything seems to work fine... The other production system isn't affected. It's kind of annoying that there's no timestamp shown in the error message. Debugging is really tough this way. I'm wondering what it means and whether it's harmless or not. Like Kevin states, nowhere on the internet this question seems to answered. Thanks in advance! Durk Hello there, Does anyone know what is this 'mod_jk: error flushing' about? I am using Tomcat 5.0, Apache and Mod_JK in production environment and keep getting this error in error log. I do google search and find lots of persons asking this question but no answer. Can anybody having experience with this shed a light on what it might be and how to resolve it? Thanks a lot, Kevin Song - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- kippdata informationstechnologie GmbH Bornheimer Str. 33a 53111 Bonn Tel. 0228/98549-0 Fax 0228/98549-50 www.kippdata.de === kippdata informationstechnologie GmbH Bornheimer Str. 33a D-53111 Bonn Germany Tel. +49/228/98549-0 Fax +49/228/98549-50 www.kippdata.de - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: question regarding 'mod_jk: error flushing'
Hi all! I'm wondering the same. I've got four servers (two production machines and their testing counter parts) running SUSE Linux Enterprise Server 9 with Apache 2, Tomcat 5, and ModJK. Below the relevant packages are shown: apache2 2.0.49-27.59 apache2-prefork 2.0.49-27.59 apache2-jakarta-tomcat-connectors 5.0.19-29.1 jakarta-tomcat5.0.19-29.1 Since June 2006 I'm getting lots of mod_jk: Error flushing \n on one production system (and its testing system as well), but everything seems to work fine... The other production system isn't affected. It's kind of annoying that there's no timestamp shown in the error message. Debugging is really tough this way. I'm wondering what it means and whether it's harmless or not. Like Kevin states, nowhere on the internet this question seems to answered. Thanks in advance! Durk Hello there, Does anyone know what is this 'mod_jk: error flushing' about? I am using Tomcat 5.0, Apache and Mod_JK in production environment and keep getting this error in error log. I do google search and find lots of persons asking this question but no answer. Can anybody having experience with this shed a light on what it might be and how to resolve it? Thanks a lot, Kevin Song - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Question
QUMAS is the only global compliance company offering a complete solution to regulated industries. Recognized as the world leader in Enterprise Compliance Management. 8 Website: www.qumas.com * Address:Cleve Business Park, Monahan Road, Cork, Ireland (Office:+353-21-491 5100 +177 ( Fax: +353-21-432 0394 From: Miriam Keating Sent: 05 October 2006 17:02 To: 'users@tomcat.apache.org' Subject: FW: Question Importance: High QUMAS is the only global compliance company offering a complete solution to regulated industries. Recognized as the world leader in Enterprise Compliance Management. 8 Website: www.qumas.com * Address:Cleve Business Park, Monahan Road, Cork, Ireland (Office:+353-21-491 5100 +177 ( Fax: +353-21-432 0394 From: Miriam Keating Sent: 05 October 2006 16:59 To: 'users@tomcat.apache.org' Subject: Question Importance: High To whom it may concern, I am connecting to LDAP using Tomcat 5.5.12 and everything is fine. However, when I change over to Tomcat 5.5.16, I can no longer connect to LDAP because of a binding error. The error I see is included in this email. The cause of my problem is due to a change made to the JNDIRealm class, the getUserByPattern(). The change made ( I dont think) has not been documented in the change log html. Two lines of code have been removed from the above class and method. Basically, can you tell me why the change was made and also can you tell me is there a complimentary change I need to make to my code, to get the LDAP to work. Any help you can give me would be really appreciated. Regards Miriam QUMAS is the only global compliance company offering a complete solution to regulated industries. Recognized as the world leader in Enterprise Compliance Management. 8 Website: www.qumas.com * Address:Cleve Business Park, Monahan Road, Cork, Ireland (Office:+353-21-491 5100 +177 ( Fax: +353-21-432 0394 [05/Oct/2006 15:40:35 IST] ERROR [/qprocess]:837 - Exception performing authentication javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C0905FF, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece remaining name 'qtest\fmccarthy' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3025) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737) at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1291) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:213) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:121) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:109) at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:123) at org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:992) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:956) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:882) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:808) at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595)- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: question regarding 'mod_jk: error flushing'
Hello there, Does anyone know what is this 'mod_jk: error flushing' about? I am using Tomcat 5.0, Apache and Mod_JK in production environment and keep getting this error in error log. I do google search and find lots of persons asking this question but no answer. Can anybody having experience with this shed a light on what it might be and how to resolve it? Thanks a lot, Kevin Song
