You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bill Davidson <bi...@gmail.com> on 2014/03/04 18:40:15 UTC
Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
We tried to upgrade a production server to Tomcat 7 yesterday and it
broke our printing applet that we use to control a printer in its native
printer language.
This seemed odd to us because it worked perfectly in testing. When we
go direct to our production servers (bypassing the Cisco load balancer
which is doing SSL for us), it also works fine in production.
The only thing that's changed is using Tomcat 7.
We only have one connector in server.xml
<Connector port="8009"
protocol="AJP/1.3"
address="127.0.0.1"
redirectPort="443"
connectionTimeout="600000"
maxThreads="1000"
maxPostSize="5242880"
maxParameterCount="66000" />
The Java console is giving an SSLHandshakeException
v: dump thread stack
x: clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
cache: Initialize resource manager: com.sun.deploy.cache.ResourceProviderImpl@c77c8
basic: Added progress listener: sun.plugin.util.ProgressMonitorAdapter@a2bfd5
basic: Plugin2ClassLoader.addURL parent called for https://myhost.mydomain/myapp/applets/print.jar
security: Accessing keys and certificate in Mozilla user profile: null
security: JSS is not configured
network: Cache entry not found [url: https://myhost.mydomain/myapp/applets/print.jar, version: null]
network: Connecting https://myhost.mydomain/myapp/applets/print.jar with proxy=DIRECT
network: Cache entry not found [url: file:/C:/Program%20Files%20(x86)/Java/jre7/lib/ext/sunec.jar, version: null]
network: Cache entry not found [url: file:/C:/Program%20Files%20(x86)/Java/jre7/lib/ext/sunjce_provider.jar, version: null]
network: Connecting http://myhost.mydomain:443/ with proxy=DIRECT
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(Unknown Source)
... 41 more
Any ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/4/2014 3:13 PM, Mark Eggers wrote:
>
> Hmm, is the applet signed, and is the certificate from a trusted authority?
>
> Oracle recently made some changes to Java which tightened down applet security. They also made some changes in the security policy that block communication on well-known ports unless you create a policy exception.
>
> I got bit by the latter when I moved to 1.7.0_51 on Windows and tried to start up a Derby database.
The applet is signed and runs without warning pop-ups.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Mark Eggers <it...@yahoo.com>.
On 3/4/2014 1:36 PM, Bill Davidson wrote:
> On 3/4/2014 1:24 PM, Christopher Schultz wrote:
>>
>> 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?
>
> That's mostly what I've been doing for the last 24 hours.
>
>> 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.
>>
>
> Hmm. We were building with Java 1.7.0_25 (I think) when it was working and
> now we're building with Java 1.7.0_45. Could that actually be it?
Hmm, is the applet signed, and is the certificate from a trusted authority?
Oracle recently made some changes to Java which tightened down applet
security. They also made some changes in the security policy that block
communication on well-known ports unless you create a policy exception.
I got bit by the latter when I moved to 1.7.0_51 on Windows and tried to
start up a Derby database.
. . . just some random thoughts
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:
> The HttpOnly flag is used by cookies sent by server to the client.
>
> There is no point checking it on request.getCookies(), as browsers do
> not send it back (neither do they send 'path', 'secure' etc.).
Isn't that showing what the server is sending to the client?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
Isn't the applet supposed to send browser cookies regardless of if
Javascript can see them?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/5/2014 2:28 PM, Konstantin Kolinko wrote:
>
> The HttpOnly flag is used by cookies sent by server to the client.
>
> There is no point checking it on request.getCookies(), as browsers do
> not send it back (neither do they send 'path', 'secure' etc.).
>
1. Isn't that what gets sent from the server to the client?
2. Why did it work when going direct without the load balancer?
3. Why did it sometimes work with IE even with the load balancer?
4. Why did it still fail when I reverted to Tomcat 6?
5. Why did it work before this release when we had TLS 1.1/1.2 enabled
in the client JCP? Note that the load balancer is doing all of the SSL and
sending plain HTTP to httpd which is in turn talking AJP to Tomcat. While
our httpd does support HTTPS
6. New data point from last night: One of our support people uninstalled
Firefox and Chrome and the JRE from his Windows 8 laptop and then
reinstalled all of them. All of them worked after that through the load
balancer on his laptop. That was before the changes that we made to the
applet this morning for the cookie.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-03-06 2:11 GMT+04:00 Bill Davidson <bi...@gmail.com>:
> On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
>>Session cookie is HttpOnly in Tomcat 7.
>>
>>If you missed that in migration guide, it is here:
>>http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
>
> I added this to some code that is executed by most requests that we use to
> track operator activity:
>
> Cookie[] cookies = request.getCookies();
> if ( cookies != null ){
> for ( Cookie cookie : cookies ){
> operLog.append("\n").append(cookie.getName())
> .append("=").append(cookie.getValue())
> .append(",
> secure=").append(cookie.getSecure())
> .append(",
> httpOnly=").append(cookie.isHttpOnly());
> }
> }
> m_log.fatal(operLog.toString());
>
> This is what that prints out in the log every time:
>
> JSESSIONID=<a big hex number>, secure=false, httpOnly=false
>
> So no, I don't think that's it. We're set to send on any protocol.
> Moreover, shouldn't the applet be sending httpOnly cookies even
> if they are not visible to Javascript?
>
The HttpOnly flag is used by cookies sent by server to the client.
There is no point checking it on request.getCookies(), as browsers do
not send it back (neither do they send 'path', 'secure' etc.).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/5/2014 12:52 PM, Konstantin Kolinko wrote:
>Session cookie is HttpOnly in Tomcat 7.
>
>If you missed that in migration guide, it is here:
>http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
I added this to some code that is executed by most requests that we use to
track operator activity:
Cookie[] cookies = request.getCookies();
if ( cookies != null ){
for ( Cookie cookie : cookies ){
operLog.append("\n").append(cookie.getName())
.append("=").append(cookie.getValue())
.append(", secure=").append(cookie.getSecure())
.append(", httpOnly=").append(cookie.isHttpOnly());
}
}
m_log.fatal(operLog.toString());
This is what that prints out in the log every time:
JSESSIONID=<a big hex number>, secure=false, httpOnly=false
So no, I don't think that's it. We're set to send on any protocol.
Moreover, shouldn't the applet be sending httpOnly cookies even
if they are not visible to Javascript?
1. Why would it act differently with the load balancer than with a
direct connection?
2. Why would it have continued to fail over the load balancer after
we reverted to Tomcat 6?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-03-06 0:30 GMT+04:00 Bill Davidson <bi...@gmail.com>:
> The Java version wasn't it. Recompiled and redeployed with 1.7.0_25
> and it had no effect.
>
> The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
> JCP on the client side and clicked "Restore Security Prompts" in the JCP.
>
> There was also a problem with JSESSIONID not being sent to the server
> which was causing the applets call to the server to get a missing sesssion
> exception. I don't know how that changes when it's the exact same jar
> file that worked before. We put some code into the applet to force the
> JSESSIONID to be sent and now it works; as long as TLS 1.1/1.2 are disabled.
>
Session cookie is HttpOnly in Tomcat 7.
If you missed that in migration guide, it is here:
http://tomcat.apache.org/migration-7.html#Session_cookie_configuration
> Sigh. We still haven't identified what caused this in the first place and
> we're running out of ideas.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
The Java version wasn't it. Recompiled and redeployed with 1.7.0_25
and it had no effect.
The SSL handshake problem went away when we disabled TLS 1.1/1.2 in the
JCP on the client side and clicked "Restore Security Prompts" in the JCP.
There was also a problem with JSESSIONID not being sent to the server
which was causing the applets call to the server to get a missing sesssion
exception. I don't know how that changes when it's the exact same jar
file that worked before. We put some code into the applet to force the
JSESSIONID to be sent and now it works; as long as TLS 1.1/1.2 are disabled.
Sigh. We still haven't identified what caused this in the first place and
we're running out of ideas.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/4/2014 1:24 PM, Christopher Schultz wrote:
>
> 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?
That's mostly what I've been doing for the last 24 hours.
> 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.
>
Hmm. We were building with Java 1.7.0_25 (I think) when it was working and
now we're building with Java 1.7.0_45. Could that actually be it?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
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.
> 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.
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.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Bill,
On 3/4/14, 2:14 PM, Bill Davidson wrote:
> On 3/4/2014 11:01 AM, Christopher Schultz wrote:
>> On 3/4/14, 1:26 PM, Bill Davidson wrote:
>>> I realized that I forgot a lot of info:
>>>
>>> Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25
>>>
>>> It worked fine with Tomcat 6.0.37
>>>
>>> The applet is bit-for-bit identical. It's built with Java 1.1
>>> compatibility mode.
>>>
>>> It's some sort of combination of the load balancer and Tomcat 7
>>> not getting along with each other, but there's nothing to
>>> indicate that in catalina.out or mod_jk.log or error.log.
>> So you have client (applet) -> Cisco LB -> Tomcat? Or, are there
>> other components in the mix? Does Cisco LB speak AJP13?
>
> See above. I have Apache httpd 2.2.25 in there. It's the same
> httpd I was using with Tomcat 6.
>
>>
>> What component is handling the SSL handshake on the server side?
>
> Apache httpd.
>
>> Just to clarify, the applet works when connecting /directly/ to
>> Tomcat - -- without the load-balancer in between? How can the
>> client (applet) connect directly to Tomcat if you only have an
>> AJP connector?
>
> I don't think it can connect directly to Tomcat. Only have the
> AJP connector and it's only enabled on the loopback, which the load
> balancer has no access to.
>
> Only httpd can talk to Tomcat; by design.
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?
If you aren't using SSL at all in Tomcat, then Tomcat isn't likely to
be the problem, here.
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.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTFifwAAoJEBzwKT+lPKRY2CYP/RmfLmBtQfQfWkwYq/bmdhEy
wW4/JqcP+q6tJHHWwZy5Ns6q88ojMzOaTHUEAVDf2at//GAYqhDo9zhfd/sVrdlj
2fdI7Bwo+m6YuvuM4MsBKCorhQtfwlLhYziUFFOthR4tbM/J1KQA7Xi0Zst6O0B+
gmfSEv4+boa6UvUATUg5qNFI5CWUQ7HM9Zft9uNbQRwm8sAOLXbojRc2SCX8ZOK4
vJnSc+mULrJflK9B/+IN4EqbK0sDwSkflBCr8SIqYIhT+k2zcAXrJn3wx9ft3Vru
xK5U/9tut6/WZ+VO+z1ND36kO9+/jwvQCMNZWGT+0oPKe2qBvI0PRn1V47TE+8sG
6ZjY1MZjsGFBoCH0ujWORP0Hwv3Cw/yf4YLznipfgl326+15uqGNnbNXqPU/cQU7
7+1UE1S5gnmOHv8rf+yz+CoIChP3Acyyv402GcyOcxB4LKWfk8RWhkITC1ihS0v4
C90cwPf0awEKcAMv0371QSXX/KNbg3NAmssP44e/8CUQopTfnfQ6Z6N9jQbxf/8h
eW/TTY7lh81mrpypzYoShIkbktzPYMLkAzNBqP/I29XwJxG+unf93pTXiCrjrJCq
ZLemxOij6N3Ffzkx0xbYJlpL9cMugenV0cCrYi81AkDpsN6uVjaw8840hVRTzvcq
W/KSNdTJJLmqT1G8o+DY
=RYpm
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/4/2014 11:01 AM, Christopher Schultz wrote:
> On 3/4/14, 1:26 PM, Bill Davidson wrote:
>> I realized that I forgot a lot of info:
>>
>> Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25
>>
>> It worked fine with Tomcat 6.0.37
>>
>> The applet is bit-for-bit identical. It's built with Java 1.1
>> compatibility mode.
>>
>> It's some sort of combination of the load balancer and Tomcat 7 not
>> getting along with each other, but there's nothing to indicate that
>> in catalina.out or mod_jk.log or error.log.
> So you have client (applet) -> Cisco LB -> Tomcat? Or, are there other
> components in the mix? Does Cisco LB speak AJP13?
See above. I have Apache httpd 2.2.25 in there. It's the same httpd
I was using with Tomcat 6.
>
> What component is handling the SSL handshake on the server side?
Apache httpd.
> Just to clarify, the applet works when connecting /directly/ to Tomcat
> - -- without the load-balancer in between? How can the client (applet)
> connect directly to Tomcat if you only have an AJP connector?
I don't think it can connect directly to Tomcat. Only have the AJP connector and
it's only enabled on the loopback, which the load balancer has no access to.
Only httpd can talk to Tomcat; by design.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Bill,
On 3/4/14, 1:26 PM, Bill Davidson wrote:
> On 3/4/2014 9:40 AM, Bill Davidson wrote:
>> We tried to upgrade a production server to Tomcat 7 yesterday and
>> it broke our printing applet that we use to control a printer in
>> its native printer language.
>>
>> This seemed odd to us because it worked perfectly in testing.
>> When we go direct to our production servers (bypassing the Cisco
>> load balancer which is doing SSL for us), it also works fine in
>> production.
>>
>> The only thing that's changed is using Tomcat 7.
>>
>> We only have one connector in server.xml
>>
>> <Connector port="8009" protocol="AJP/1.3" address="127.0.0.1"
>> redirectPort="443" connectionTimeout="600000" maxThreads="1000"
>> maxPostSize="5242880" maxParameterCount="66000" />
>>
>
> I realized that I forgot a lot of info:
>
> Tomcat 7.0.47 on RHEL 5.10 Apache httpd 2.2.25
>
> It worked fine with Tomcat 6.0.37
>
> The applet is bit-for-bit identical. It's built with Java 1.1
> compatibility mode.
>
> It's some sort of combination of the load balancer and Tomcat 7 not
> getting along with each other, but there's nothing to indicate that
> in catalina.out or mod_jk.log or error.log.
So you have client (applet) -> Cisco LB -> Tomcat? Or, are there other
components in the mix? Does Cisco LB speak AJP13?
What component is handling the SSL handshake on the server side?
Just to clarify, the applet works when connecting /directly/ to Tomcat
- -- without the load-balancer in between? How can the client (applet)
connect directly to Tomcat if you only have an AJP connector?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTFiLuAAoJEBzwKT+lPKRYZmkQAJupzPC7OcI3UA7xpESGq86z
60O1Usjcn/vdAotfB5GrpWQYaOPmjGuAvHS+LnNt2MkwrxA9UEaJjsTy2y1Fyszl
wQ1W4fzAcnAOnXu5QSjpkQYkQEEq/52LD00TwnlAgBOPGc3EtfnTGm0XAaqcLQA+
F4fFOmxRFHq3tppckL6BRjgeWk0NGIiznPzWl+p37JRm4XmDoQxg5J7lcTpzaZzn
jPVTXuKZRqfzl0fnXRZ4bJxqVEm/RNeus/xHWVsctPiAy0Mo5PZgVUOoLoFH0Z5f
3q3T2BpnvCvRwYi6c+SF6NeA1/wqluid3HqHO6I4SD/f/9PBjHoxOxWygQTXlnST
k3Ux/LfBWeAC//tY7a6b++cVc83v8EMFY4j1x5WHvVkXtFaLn5Pbwr2hfkGIpSqQ
X6j83Ab4MrjeRCBP3F7vllV9f7sr0trPGNATs7vLOBqP57FGFmEaW5ogKqEAtR/9
yLzuvBcj7jT12n1yHk1cbNPFFDKHifaXHmxt4qJOQLfI7AXIC6ISCdbtjv0XGIF6
ozqRsFDvB/D/xXp57nGrBbanN9qr+XooK+Wu97jVtvjvaW4UnPfRxQoCwrKxsNCS
Pz/swqhho6HUIMP/LQueWRGy9prOckqUmTQ+VjJE/BO/gC9FWh+co2f5aq2063Gl
kebB/efHZ0JhsG+b7UuO
=IEW4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Bill Davidson <bi...@gmail.com>.
On 3/4/2014 9:40 AM, Bill Davidson wrote:
> We tried to upgrade a production server to Tomcat 7 yesterday and it
> broke our printing applet that we use to control a printer in its native
> printer language.
>
> This seemed odd to us because it worked perfectly in testing. When we
> go direct to our production servers (bypassing the Cisco load balancer
> which is doing SSL for us), it also works fine in production.
>
> The only thing that's changed is using Tomcat 7.
>
> We only have one connector in server.xml
>
> <Connector port="8009"
> protocol="AJP/1.3"
> address="127.0.0.1"
> redirectPort="443"
> connectionTimeout="600000"
> maxThreads="1000"
> maxPostSize="5242880"
> maxParameterCount="66000" />
>
I realized that I forgot a lot of info:
Tomcat 7.0.47 on RHEL 5.10
Apache httpd 2.2.25
It worked fine with Tomcat 6.0.37
The applet is bit-for-bit identical. It's built with Java 1.1 compatibility mode.
It's some sort of combination of the load balancer and Tomcat 7 not getting
along with each other, but there's nothing to indicate that in catalina.out or
mod_jk.log or error.log.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 vs. Tomcat 7 vs Cisco Load Balancer vs Java Applet
Posted by Utkarsh Dave <ut...@gmail.com>.
Did you try generating / regenerating your certificated.
Once done put it under your security directory within your jdk home
On Tue, Mar 4, 2014 at 11:10 PM, Bill Davidson <bi...@gmail.com> wrote:
> We tried to upgrade a production server to Tomcat 7 yesterday and it
> broke our printing applet that we use to control a printer in its native
> printer language.
>
> This seemed odd to us because it worked perfectly in testing. When we
> go direct to our production servers (bypassing the Cisco load balancer
> which is doing SSL for us), it also works fine in production.
>
> The only thing that's changed is using Tomcat 7.
>
> We only have one connector in server.xml
>
> <Connector port="8009"
> protocol="AJP/1.3"
> address="127.0.0.1"
> redirectPort="443"
> connectionTimeout="600000"
> maxThreads="1000"
> maxPostSize="5242880"
> maxParameterCount="66000" />
>
> The Java console is giving an SSLHandshakeException
>
> v: dump thread stack
> x: clear classloader cache
> 0-5: set trace level to <n>
> ----------------------------------------------------
> cache: Initialize resource manager: com.sun.deploy.cache.
> ResourceProviderImpl@c77c8
> basic: Added progress listener: sun.plugin.util.
> ProgressMonitorAdapter@a2bfd5
> basic: Plugin2ClassLoader.addURL parent called for
> https://myhost.mydomain/myapp/applets/print.jar
> security: Accessing keys and certificate in Mozilla user profile: null
> security: JSS is not configured
> network: Cache entry not found [url: https://myhost.mydomain/myapp/
> applets/print.jar, version: null]
> network: Connecting https://myhost.mydomain/myapp/applets/print.jar with
> proxy=DIRECT
> network: Cache entry not found [url: file:/C:/Program%20Files%20(
> x86)/Java/jre7/lib/ext/sunec.jar, version: null]
> network: Cache entry not found [url: file:/C:/Program%20Files%20(
> x86)/Java/jre7/lib/ext/sunjce_provider.jar, version: null]
> network: Connecting http://myhost.mydomain:443/ with proxy=DIRECT
> javax.net.ssl.SSLHandshakeException: Remote host closed connection during
> handshake
> at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
> at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown
> Source)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown
> Source)
> at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
> at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
> at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
> at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
> at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown
> Source)
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown
> Source)
> at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown
> Source)
> at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown
> Source)
> at sun.plugin2.applet.Plugin2ClassLoader$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown
> Source)
> at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
> at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
> at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown
> Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.io.EOFException: SSL peer shut down incorrectly
> at sun.security.ssl.InputRecord.read(Unknown Source)
> ... 41 more
>
> Any ideas?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>