-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Bill,
On 3/4/14, 4:16 PM, Bill Davidson wrote: > On 3/4/2014 11:22 AM, Christopher Schultz wrote: >> >> Aah, sorry, I had missed that. So, the only change was Tomcat? >> No upgrade to mod_jk or anything like that? OpenSSL upgrade? >> Upgraded Java on the client? Everything else *absolutely* the >> same? > > Exact same httpd, including mod_jk. Same files. Same directory. > httpd was not touched at all. > > I just tried reverting to Tomcat 6 and the problem is still there, > so it keeps getting weirder. > >> If you aren't using SSL at all in Tomcat, then Tomcat isn't >> likely to be the problem, here. > > I'm thinking that now too. Good ;) I don't want to point fingers, but I don't see anything in your description that really points to Tomcat, so... >> Can other command-line tools connect -- take the applet out of >> the picture? Try something like curl, wget, or even OpenSSL's >> s_client tool. s_client will give you lots of good information >> about the SSL connection state, too. > > The applet is the only thing that's having the problem. > Everything else works (and this is a massive app). > > We've also seen the applet work for some people, all of whom were > using IE but not others who may be using IE, Firefox or Chrome. > > We've played with TLS/SSL settings in IE and Firefox. That can > change the error message but it still fails. > > Again, it works fine when connecting directly to Apache httpd and > bypassing the load balancer. We've been forced to open up direct > access to the ports for that so that our customers can print. We > don't like that because we lose the advantages of load balancing > and the SSL load is now on our web servers instead of the > expensive dedicated hardware that's supposed to be doing that for > us. > > My current suspicion is that the load balancer hardware is going > bad. That would really suck. Those things are expensive. > It has two server pools. One is to cover customers in one > hemisphere (mostly Australia) and one for the other hemisphere > (mostly US/GB/IE). We only updated the servers in the pool for the > eastern hemisphere to Tomcat 7. We have the two different pools so > that we can have down time during low activity periods. Good call. Lots of people just throw-together a solution and hope they don't have any downtime. > It's just weird that it happened to start having this problem > right after we upgraded to Tomcat 7 and only on the pool that got > upgraded to Tomcat 7. > > Rebooting the load balancer involves kicking everyone off of both > pools, which means that no matter when we do it, it will be during > some non-trivial number of customers prime activity time. > > We should have gotten completely different load balancers for each > pool. Sigh. Mr. CEO, can I please have $25,000-$50,000? Well... then you'd need a balancer for each balancer ;) Can you reproduce this issue yourself on your own computer (running the applet locally)? If so, what version of Java is running? Java recently made some changes to the SSL code that make it a much bigger pain in the neck to make HTTPS connections for instance. I haven't seen any "Remote host closed connection during handshake" but presumably that could happen under the right failed-negotiation conditions. If things aren't working after rolling-back to Tomcat 6, I think it's clear the problem isn't Tomcat 7, but it may still be Tomcat-related in one way or another (i.e. mod_jk upgrade, config change, etc.)... but not likely. It might be instructive to see what happens at the protocol level between the lb and httpd for a successful and failed connection (which might be tough... if you can't connect successfully *at all*, now). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFkSgAAoJEBzwKT+lPKRYNToQAIk9MaWgyhvZtmGbQIgTdDsN lY2tCqU7R5N9JU83cgy8VXPZ+2U9vN3eB/lNqo6++IUNQASKhkSg0C7OL/nyaD6E e1ePea3V/6cfH+IHeI9nxwVwbkkAGlMwRO0vcW5HmDXdfyTIiT6+4UpnqT2aw71F 9zKVD20M7VdgUpIhIIfYfLs5996euODpu/dy0evKUeQJRwFd2HilZEDdxmMtgzRs 5qWxNfzgRs5IKQma9LDtHboaixlINx/qI04BRnShI6ZAP31+FpYnrYElBpB+PhR9 JeUBpbjPwmhcThVeFaLVnb5lg7GsZGpJah7YQDoGfMNix9Nwryt69LHWRFlv6rR7 65hLobRJIYIme6+sUEy8BjY4uidBo/w+7wtn4jBmPxGNCAtL5TeMCCIaII8p76vD Uu9+R6TXJUCGYRb6E3fRvBuv9xPH/o26QvJHvfTwJrf/A8PW39rh1mIe1S3uw+f1 wOfIAmeSgN3ZsW8Ixe0xUykl42TvkbpP3z9qx6XxZCb0tqiawaG87939tkoB2rEB 2eF8mNzVyoW2yubf6amwXFkzRP62/PIAnA7nLfX+FL+PSU8ctOzuHG3AnvY4l0RS RpzzoEKIJQE0AToqkg5wEu9y2lrOdYMsbAXjAhAYUOumMbpPe5J4PdwgGZ/Ldb7h xYWZdG2p52sR84xXV7KZ =tIeu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
