Re: Status of mod_jk-1.2.38
On Wed, Jan 8, 2014 at 8:45 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 08.01.2014 18:25, Martin Knoblauch wrote: Hi, happy New year. Should be still early enough for this :-) I have one short question: what is the status of mod_jk-1.2.38? It has been over a year since 1.2.37 and I am just curious. I am specially interested in an official fix for *Bug 53762*https://issues.apache.org/bugzilla/show_bug.cgi?id=53762. The patch mentioned there works, but cannot be used due to an only official releases policy at the customer site. I did some more changes lately due to a user request which need some more testing. I expect that we'll do the 1.2.38 release during the next 4-8 weeks. I have to ask Mladen about the status of his IPv6 changes though. Cool. Thanks for the info. On a related note: is mod_jk still the preferred way for HA and load-balancing tomcats? Are there better ways? Our environment is currently httpd/mod_jk/tomcat on Linux. Better or worse depend on your requirements. I think mod_jk is still working very well and has some unique advantages. OK, good to know. I have no actual issues using mod_jk. It is working well and does what we need. Just the release frequency is a bit low, which is not really a technical thing. But then maybe mod_jk is perfect :-) anyway, do you (or someone on the list) happen to know a good comparison/discussion of the available options? Cheers Martin -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
Menu is not working for since Tomcat 7.0.42
Hello, We have a web application which has menus and sub menus which are basically divs. On clicking on menu we are showing the sub menus. This happens through AJAX request. The application was working fine till Tomcat 7.0.41. But since 7.0.42 it stopped working. We are using jdk 7. We did not change anything between 7.0.41 and 7.0.42 in our side. Could anyone give me pointer regarding the issue? Thanks in advance. Chinmoy
Re: Menu is not working for since Tomcat 7.0.42
On Jan 9, 2014, at 5:11 AM, Chinmoy Chakraborty cch...@gmail.com wrote: Hello, We have a web application which has menus and sub menus which are basically divs. On clicking on menu we are showing the sub menus. This happens through AJAX request. The application was working fine till Tomcat 7.0.41. But since 7.0.42 it stopped working. We are using jdk 7. We did not change anything between 7.0.41 and 7.0.42 in our side. Could anyone give me pointer regarding the issue? No way to say what's happening here. Some tips on troubleshooting. 1.) Look at the logs. Do you see any error messages? 2.) Look at the result of your AJAX request. You can use Firebug or Chrome Dev Tools. See what request is being sent to the server and the response. Are these what you'd expect? Note, if the request never returns (i.e. hangs), see #4. 3.) Look at the access logs on Tomcat. Locate the AJAX request that's being sent. See what response was generated (i.e. 200, 4xx, 5xx). 4.) If requests are hanging, take three thread dumps while waiting on the hung request. These will show what the server is doing. 5.) Look at the CPU usage on your machine. Do you see higher than normal CPU usage? 6.) Indicate if you're going through a proxy or if connections go directly to Tomcat. After investigating further, if you've not discovered the problem, report back with more details. Dan Thanks in advance. Chinmoy - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Menu is not working for since Tomcat 7.0.42
Date: Thu, 9 Jan 2014 15:41:21 +0530 Subject: Menu is not working for since Tomcat 7.0.42 From: cch...@gmail.com To: users@tomcat.apache.org Hello, We have a web application which has menus and sub menus which are basically divs. On clicking on menu we are showing the sub menus. This happens through AJAX request. The application was working fine till Tomcat 7.0.41. But since 7.0.42 it stopped working. We are using jdk 7. We did not change anything between 7.0.41 and 7.0.42 in our side. Could anyone give me pointer regarding the issue? MGImpossible... until you show us the code you are running MGZip up (server.xml and web.xml) jsps, java code,templates..the works..put on dropbox and send the link Thanks in advance. Chinmoy
RE: Menu is not working for since Tomcat 7.0.42
From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Subject: Re: Menu is not working for since Tomcat 7.0.42 On Jan 9, 2014, at 5:11 AM, Chinmoy Chakraborty cch...@gmail.com wrote: The application was working fine till Tomcat 7.0.41. But since 7.0.42 it stopped working. We are using jdk 7. 1.) Look at the logs. Do you see any error messages? Besides this and Dan's other excellent suggestions, tell us exactly what you mean by stopped working. Does your server catch fire? Or something less dramatic? - 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: Packet misses in Tomcat
-Original Message- From: Divyaprakash Y Sent: 08 January 2014 14:35 To: Tomcat Users List Subject: RE: Packet misses in Tomcat -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 08 January 2014 02:52 To: Tomcat Users List Subject: Re: Packet misses in Tomcat Christopher, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/7/14, 5:09 AM, André Warnier wrote: I do not pretend to know your system, nor your application, nor that the following is a definite explanation. But on the base of the currently available data, I would say : - it is quite unlikely that Tomcat 7 is randomly dropping requests. If it was, then I would imagine that this list would be overflowing with cries for help. There is quite a bit of traffic on this list related to Tomcat 7, but I don't recall seeing any significant number of issues mentioning dropped requests. - it also doesn't seem, from your wireshark-related observations, that the requests are being lost outside of Tomcat. - so I would say at this point, that the most likely place for requests to disappear is in your own application. It seems that Tomcat is not logging the request in its access log, so it's more likely that the request is either malformed to such an extent that Tomcat rejects the request altogether or that the request never reaches Tomcat. ... Hi. Of course I am going essentially by what the OP provided earlier as information, and he has not provided much details on the disappearing requests themselves, or on the channel through which these requests were reaching Tomcat. But one thing that he did mention, is that these requests are similar - and even in general the same - as other requests which do get processed normally. As per his own words : For the query regarding All requests, all requests do not disappear. More importantly, sometimes all requests reach the application when I POST same set of requests. To give a rough picture, 1-2 requests fail in a set of 45-50 requests and this behaviour varies [The request which failed in my one test cycle succeeds in another cycle]. If we take this at face value, then it should not be so that these requests are so malformed that Tomcat discards them without further ado. Also - but maybe I'm wrong there - I would expect, if Tomcat discards a request for being malformed - that something would appear in the Tomcat error log. But according to the OP it doesn't. Finally - and there is a bit of an assumption on my part here - I assume that when the OP says that he sees the request with Wireshark (prior to it disappearing in Tomcat), he was running Wireshark on the Tomcat host itself. That would make it unlikely that another external component is at play. All of the above led me to suspect that something in the application itself may be playing a role here. Of course, that all does not necessarily prove that some other component than Tomcat is not dropping some packets/requests. -- Clarifications for the missed information: - Wireshark runs on the same machine where Tomcat runs - Channel through which these requests were reaching Tomcat - HTTP Chanel - Can you describe your deployment? Are you accessing Tomcat directly via HTTP? What networking components are between your test client(s) and Tomcat - A war file with a servlet to POST the requests. - There are 2 machines (LAN) where client and servers are installed. Client is used to send the requests to Server. - Disabled the firewall in the server machine - Tomcat will be accessed directly via HTTP - This issue occurs even if I use loopback address/localhost instead of Server IP Address in the request URL (Install both client and server in the same machine). - Tested with both apache-tomcat-7.0.27.exe and apache-tomcat-7.0.42-windows-x86.zip - Also, Windows event logs will not have any entries when the requests getting missed. Strange that this is happening only to me. Overnight run of my application with Jetty Server(1167 requests) did not miss any requests. So I am hoping that application is not contributing to the missing requests. I may be wrong here. Is there any way to get more logs on request processing in Tomcat? Thanks. I tried same setup today with the BIO connector, everything worked flawlessly. Will there be any issue with the APR connector(earlier setup) or are there any extra configurations which I missed in my server.xml? Thanks. - DISCLAIMER: This electronic message and any attachments to this electronic message is intended for the exclusive use of the addressee(s) named herein and may contain legally privileged and confidential information. It is the property of Celstream Systems Private Limited. If you are not the intended recipient, you are hereby strictly notified not to copy, forward,
Question on SSL and Pragma in 7.x
I'd like to verify something I think I'm seeing in Tomcat 7.x. Back in Tomcat 6.x and previous, to get around an IE bug with the Pragma header, we would set up an Authenticator valve with securePagesWithPragma set to false. It didn't really matter which Authenticator valve, just having it there would do the job. This was necessary because the SSL connector would set the headers as Pragma: No-cache Cache-Control: no-cache but adding the valve would drop the Pragma header and change the Cache-Control to private. (Not sure it matters, but all this is using native libs on Windows.) Empirical testing seems to show that at 7.x (7.0.42 at least), the default mode for SSL is to only set the Cache-Control to private. It does not add the Pragma header, and therefore there should be no need for the Authenticator valve. (note that all authentication is internal to the application and everything is run over SSL) Am I interpreting all that correctly? If I wanted to add a section that did use Tomcat Auth, would I need/want to add the appropriate Authenticator valve back to the context.xml? For example: Adding javamelody but limited to users from the users.xml file. I would add the following to the web.xml: login-config auth-methodBASIC/auth-method realm-nameMonitoring/realm-name /login-config security-role role-namemonitoring/role-name /security-role security-constraint web-resource-collection web-resource-nameMonitoring/web-resource-name url-pattern/monitoring/url-pattern /web-resource-collection auth-constraint role-namemonitoring/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Is the BasicAuthenticator valve necessary, and what would it do for me? Further notes on why I'm testing this: Our old pre-7 setup used SSLAuthenticator, even though we didn't use client certs just to get the Pragma header dropped. But adding the above config for javamelody had Tomcat refusing the connection to /monitoring because we didn't have client certs. We would get a SSL error page. Jeffrey Janner Sr. Network Administrator jeffrey.jan...@polydyne.commailto:first.l...@polydyne.com PolyDyne Software Inc. Main: 512.343.9100 Direct: 512.583.8930 [cid:image002.png@01CC0FB7.4FF43CE0] Speed, Intelligence Savings in Sourcing
Name log files based on Context name?
I want my log files to be written to a log file with the same name as my
webapp. Users can dynamically re-name my webapp when they run my installer, so
that they can have multiple instances running, so hard-coding the context name
is not a good approach. Is there some environment variable that I can use in
the log file?
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = MirrorSync.
1catalina.org.apache.juli.FileHandler.encoding = UTF-8
I'd like the word MirrorSync to be replaced with the name of the context
where this logging.properties file is loaded from (the logging.properties file
is in my classes/ directory). I tried using ${context} but it just put that
literal value for the log name.
My users are mostly running in Tomcat 6, with a few who have upgraded to 7.
--Jesse Barnum, President, 360Works
http://www.360works.com
Product updates and news on http://facebook.com/360Works
(770) 234-9293
== Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
Re: Name log files based on Context name?
On 09/01/2014 18:48, Jesse Barnum wrote:
I want my log files to be written to a log file with the same name as my
webapp. Users can dynamically re-name my webapp when they run my installer,
so that they can have multiple instances running, so hard-coding the context
name is not a good approach. Is there some environment variable that I can
use in the log file?
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = MirrorSync.
1catalina.org.apache.juli.FileHandler.encoding = UTF-8
I'd like the word MirrorSync to be replaced with the name of the context
where this logging.properties file is loaded from (the logging.properties
file is in my classes/ directory). I tried using ${context} but it just put
that literal value for the log name.
My users are mostly running in Tomcat 6, with a few who have upgraded to 7.
https://issues.apache.org/bugzilla/show_bug.cgi?id=43682
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
PropertyNotFoundException does not work with custom error in web.xml
I have a custom error servlet set up in my webapps web.xml file like so: error-page exception-typejava.lang.RuntimeException/exception-type location/runtimeExceptionHandler/location /error-page In JSTL if a property is spelled incorrectly or doesn't exist, the PropertyNotFoundException will not trigger the error servlet, even though PNFEs extend RuntimeException. Anyone know why this is? Tomcat 7.037 on Win7. TIA Alec
Re: Question on SSL and Pragma in 7.x
On 09/01/2014 18:22, Jeffrey Janner wrote: I'd like to verify something I think I'm seeing in Tomcat 7.x. snip/ Am I interpreting all that correctly? See http://markmail.org/message/2kkq4yxgacgbrwht If I wanted to add a section that did use Tomcat Auth, would I need/want to add the appropriate Authenticator valve back to the context.xml? Only if you need to change the configuration of the Authenticator. Tomcat adds the correct Authenticator automatically based on the auth-method defined in web.xml Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PropertyNotFoundException does not work with custom error in web.xml
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alec, On 1/9/14, 2:28 PM, Tomcat Random wrote: I have a custom error servlet set up in my webapps web.xml file like so: error-page exception-typejava.lang.RuntimeException/exception-type location/runtimeExceptionHandler/location /error-page In JSTL if a property is spelled incorrectly or doesn't exist, the PropertyNotFoundException will not trigger the error servlet, even though PNFEs extend RuntimeException. Anyone know why this is? Tomcat 7.037 on Win7. Does your error handler work in other situations? For example, if you throw RuntimeException from a servlet? How about PropertyNotFoundException from a servlet? What about throwing either of them directly from a dummy JSP? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSzx6EAAoJEBzwKT+lPKRYenkP/2CwWPCsYDGRDn7o5Kgn4AK4 /kvFW8dzy0gUdVWj5t9VnrefqOyVnzGxKXfPTh0z1EFp8OZroe2Fh/r5ojH/nbRB E/ZCNIILNfazxA6QCCo8B30vLkv4IEnzCF4DFswRjECB/4ZuOASL8hBiAzikGiKj ZTRLRePEK/kG0822rbWuy1RmgwDiEAZcDFtcPYUbMY8MoBb913XN0gv7kYnbhNy/ mq1VWVCa7hQtUnjBxcDJwFpcWUqc7zZpJmFW2PcsBo0489OnuhR9lUEGQbZDXeGe SfRZg/Kat2fSs1Rd9vKGMqcP0Q2YgZ1n1HG3lyzbY7q29/6pS0agpdckgdteRydA 5kyyjpI0jQUKiUOic2NdiZYbYE+8m8b1J9JojLBCIl9v7LQ7N6AIkFgktk6XY+Ij BRvKbN3MDt2yHfaxILJ4pGrqHhnS7RUKB9zf+5YNMx3dNntU7AQv9Ky+pJTaWnub LgDrLSnCgGQgHHUibVxKsoVg86R19Tx5ZBEZXzb2IZDTnjdDAW1Xb4qFhxLtaTw5 TlqXyiWA4UiRpgc/3FfCM1SXaaSffRxBJtW14Ead5ugtdbrl6B01UEpUKDhbTjgM pNQFAnR44fpIA28WpHS4OC29c95ZzwlcJsHryMie3kaENzZIVIYalI5atxTI3kUz E9R/OFChkf8RVBwQV+0a =h3AK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Packet misses in Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Divyaprakash, On 1/8/14, 4:06 AM, Divyaprakash Y wrote: -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: 08 January 2014 02:52 To: Tomcat Users List Subject: Re: Packet misses in Tomcat Christopher, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 1/7/14, 5:09 AM, André Warnier wrote: I do not pretend to know your system, nor your application, nor that the following is a definite explanation. But on the base of the currently available data, I would say : - it is quite unlikely that Tomcat 7 is randomly dropping requests. If it was, then I would imagine that this list would be overflowing with cries for help. There is quite a bit of traffic on this list related to Tomcat 7, but I don't recall seeing any significant number of issues mentioning dropped requests. - it also doesn't seem, from your wireshark-related observations, that the requests are being lost outside of Tomcat. - so I would say at this point, that the most likely place for requests to disappear is in your own application. It seems that Tomcat is not logging the request in its access log, so it's more likely that the request is either malformed to such an extent that Tomcat rejects the request altogether or that the request never reaches Tomcat. ... Hi. Of course I am going essentially by what the OP provided earlier as information, and he has not provided much details on the disappearing requests themselves, or on the channel through which these requests were reaching Tomcat. But one thing that he did mention, is that these requests are similar - and even in general the same - as other requests which do get processed normally. As per his own words : For the query regarding All requests, all requests do not disappear. More importantly, sometimes all requests reach the application when I POST same set of requests. To give a rough picture, 1-2 requests fail in a set of 45-50 requests and this behaviour varies [The request which failed in my one test cycle succeeds in another cycle]. If we take this at face value, then it should not be so that these requests are so malformed that Tomcat discards them without further ado. Also - but maybe I'm wrong there - I would expect, if Tomcat discards a request for being malformed - that something would appear in the Tomcat error log. But according to the OP it doesn't. Finally - and there is a bit of an assumption on my part here - I assume that when the OP says that he sees the request with Wireshark (prior to it disappearing in Tomcat), he was running Wireshark on the Tomcat host itself. That would make it unlikely that another external component is at play. All of the above led me to suspect that something in the application itself may be playing a role here. Of course, that all does not necessarily prove that some other component than Tomcat is not dropping some packets/requests. -- Clarifications for the missed information: (I have re-ordered some of your responses so they make more logical sense to me): - There are 2 machines (LAN) where client and servers are installed. Client is used to send the requests to Server. - Wireshark runs on the same machine where Tomcat runs - Tomcat will be accessed directly via HTTP - This issue occurs even if I use loopback address/localhost instead of Server IP Address in the request URL (Install both client and server in the same machine). - A war file with a servlet to POST the requests. What is the client? Is it possible that this is something simple like the TCP backlog queue filling-up and the OS is just discarding requests? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSzx+xAAoJEBzwKT+lPKRYwOgP/RnNfmH+/TUzWy5OUy7f2KUR 3D82ozXMQg4QNpV7jqUlacRb8k10WitXWG2wzC7jO0eyoDbiQlQQTZ0GhPwWKsOo 8Ah7wL3YeFEIy4QV8LcmCDspyzp1vJ64aCgr7z+mW+36g1b2ZvFiCeUunA6r+rBw m5vrRb2zVDprARd1hmdlM+JoApQ05XXbc7ZY79HXMn6D3zDu77s2Hvp5m5t6FDx/ mgqHbk4ILrJKf3/u+5ACVngIvUEHqzcc3tFMLlEzqUffZ5n04z/tK+WvHB19dkIS zp2YWJ30+vkzKSi+49cmM3aigdRFSNlTjba7ipdRhjW8vdsLHRnfiTNU41m1WsHD aXrJZqyzusOTGmOclR+Hgau82tn5lkwiQY2mibjCf3Lw5HDyT+sqNBZam/2iRRtp /oTOHMN+aDAHWTuTy0t8ySOD5CHnQOnGJtdSTqUHNN8dJ4sGn9xmZZ5dhXGdUYF3 5ag+NMmRsvwCiXKS9OJK7azqVwajKNjUeeOhHzbv8tF28jVJ6PMYIcVVMJsZEgcF 96BI3GX8emp8wD8pWMZFmlHpKkZ+svDxFs4Aoqjv1gZI8Qq6D8tyX6p4lZjwXqyH GcxVKYNHY4dZZHsMDHWq1CGxL93xH5FUU22M0nI0eJ6h4znU2uOFXScVEIVkiVih e2HI63On94Yk68jKzQk4 =c+yc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Some questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel, On 1/8/14, 4:18 PM, Daniel Mikusa wrote: On Jan 8, 2014, at 4:06 PM, CyTG cytg@gmail.com wrote: New to list, if these questions are dumb please bare with me, i've searched the documentation and googled howtos and questions without finding specific answers to my questions.. :) .. I've actually been using Tomcat for a while though interfaced and deployed via Maven and different management plugins. I am quite fed up with them now, thus I am here. Question In the documentation : http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html On Deploying on a running Tomcat server, the last line reads this : Note that web application reloading can also be configured in the loader, in which case loaded classes will be tracked for changes. - To me this sounds brilliant, I can drop in a single class and it will get reloaded/hotdeployed in a jiff. Ill make a little filesystem watcher that will copy files around as soon as they're touched in my development workspace.. sort of a poor-mans-jrebel loolalike. The darned thing is i cant find anything on configuring the loader .. I assume they mean ClassLoader and by the loader I assume it is a built-in ClassLoader .. such as WebappClassLoader .. but I cant find anything on cofiguring it towards my needs. Am I blind ? I believe it's referring to this. See the reloadable attribute. http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html but you can just set reloadable on your Context / tag. http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes +1 It's also worth pointing out that Tomcat will reload the entire webapp (including formally shutting-down the old copy, and starting-up a new copy). So, if you have a long shutdown and/or startup process, the jiff will be relative to that. Tomcat will not simply re-load the single Class that you replaced. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSzyAsAAoJEBzwKT+lPKRYuHwP/3rK8bD/8TvtQdGS7uXmbf3Q ds/fZH9KRGiTfWaHJ040/zyIPvR4PZhG3Q7pJjzzU0OOtJxCxDuFpOtyoV52wdA3 3dQvdpyuxPY9JxeATW61R0jmSju+zhh/wHf1siwcV8zHEWMk5NAb6wXm+bc+X7tw /TX2ch47z+peMaWS3bzlw0uvTD82NraRApOS9pijGylJc+YOVAsCIc3q30AoNDxX iFOAYAd6SXvTz8yzYY2ijdLCtlCF+5FrYzoEYooKiuaW4Yp2BWEDQutnXIDdTmR6 ZpZSo6SgexSJbC3j4ozUv8D30X16bOAiLy88356YChj+h7wLzYjcaSKckMXUJ3t6 YpXvo2B1MxXNFEkxrJVRulioTRnH27XTgFGYsU/4KIjNI7Py8HvFqWcY2gpB9XBy TYO9+3NK0tkD2rTJkMpOsd3rqszLoAW6161Ev7tZnzkPYSjJ7oWCg9EkJ3CP31xe 8awRxjIoOL0KSYKFALTwVb/dJxGV8IdgOV9XQ2RF1GvYTXQ8/4Ny6z2Wr8cxJZYm D6FT1XowWoU8mJeeWatcTrAbhAlK+xovKFpRjNw5AoPyXcyW4UPfnu4VB8vcmCZq fAJJiG6oKPRWJyBk7Bbv0zp3M/3oH1mywoVlu32uEGy6jk0NiShqU6PUlWaHgw59 8wMqTat2ZNSE4DGHWwFT =HzbB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SocketException when using localhost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Nancee, On 1/8/14, 4:56 AM, Nancee Riehl wrote: Is this the right mailing-list for my question? Yes! Welcome. I'm writing a JUNIT-Test to test a connection to tomcat 7.0.47 over HTTPS/TLSv1.1 with a corrupted Client-Certificate. When I run my test against a remote tomcat everything works fine, I get an SSLHandshakeException. When I run the same test against a local tomcat I get this error: java.net.SocketException: Software caused connection abort: socket write error Do you have an idea why there are diffrent Exceptions? The configurations and versions of both tomcats are the same. What is the full stack trace? Does the server have any error in its log when the client gets this error? If you don't make arrangements for Java's HttpsURLConnection class, it will choke if the /server/ certificate does not validate (including things like hostname verification). I usually see a different kind of error in these cases, but the real error might be hidden behind something else. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSzyDnAAoJEBzwKT+lPKRYeXgP/2NWfmCotaovqchxNPcgdKTc u7qHVrwbC4O9kB6Mm90Ukit/YrpAsAggBUrHrvrYO4DCD0IcJXs4cl7fQtGQixau o1TdJX9NbVOYyzh1YrygRhs9LOxUFExICbOb61hIJbgWztAAj5Q2zle5EiiJyivt rusU517dS5+S49WCsXHR1X8FBsX+MY36hnFnTLwPoC2ICz1mPBv3/mXsP43dFHPw fI8HXD3mIPTlVwt09lFe5qyFnHYyydJSTE5OazQcNFdkBBiEREQ0/QaS2mBmIp1A RXQgkx1MtXp/1dMZ26A7l07kg3yISFux8mHG3GlhG8HMJTOunzTq80e4Z5v+h5io 47weHo4sWZc8AmtAxbQACrmFNkW/YVj2UGXHQNKo033NeZBv1q3unoQYz2JY4V4z jgJfjoYFYfXmq4yJveZJ3gfdPxM7WL0KM5381h8IU3E9HkExDJvt7fFKAgcFpIj0 3k9nHL7S/dWWx0mA0ZpD0J3vEmk4rNkHan3skr4+vp6x5QOPY3StbH/Jbw2cR7wD H+6FVgZalb0ezTtfIDcT31fQNowKASy2wbqAZPzgftSvQOvurHEKo88rZy94YDL0 IDLPyMQNTRdQ6xAHKPq3FCdHFsc2Zu0BYfyPwUUbDR3TuGkY22fF4gf6z7x24CKq wNOv5T+Naox1JJZL7f/A =y+5F -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Getting 404 before the container starts all servlets
Hello, After upgrading Tomcat from 6.X to 7.X, our AJAX client receives 404 for 10-15 seconds right after startup. I presume the request is accepted and processed before all servlet are initialized, which is not what you would expect. Is this behavior normal for 7.X? Is there a way to configure 7.x to behave like 6.x? Thank you, Adrian Tarau. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Getting 404 before the container starts all servlets
From: Adrian Tarau [mailto:mailingl...@adrian.tarau.org] Subject: Getting 404 before the container starts all servlets After upgrading Tomcat from 6.X to 7.X, our AJAX client receives 404 for 10-15 seconds right after startup. I presume the request is accepted and processed before all servlet are initialized, which is not what you would expect. Is this behavior normal for 7.X? Is there a way to configure 7.x to behave like 6.x? Look at the bindOnInit attribute for Connector elements: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation But be aware of the side effects as discussed in these threads: http://marc.info/?l=tomcat-userm=136386106909331w=2 http://marc.info/?l=tomcat-userm=130549517506701w=2 - 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
