>>> Then, after the user logs-out (from the either completely responsive
>>> or completely non-responsive web application), the web application becomes
>>> (or remains) unresponsive?
>>
>> What I mean by this is:
>> 1. User starts web-app, and uses it normally.
>Do you mean that the user starts using the web application? It's rare for a
>user to start (e.g. launch, deploy, etc.) a
> web application. I'm trying to parse-out the difference between the web
> application starting up in Tomcat versus
> a user logging-into it -- the two are radically different things.
The user opens the application home page in the web browser.
>> 2. In a separate tab, the user tries to go to the tomcat home page, or the
>> tomcat manager.
> IE displays the standard "This page can't be displayed" error message.
> Immediately, or is there a time lag? Do you get an HTTP response, or a
> failure to connect?
> MSIE is terrible at telling users what is really going on. Get a protocol
> analyzer if necessary
> (e.g. fiddler, or whatever plug-ins are available for MSIE).
It's fast enough that I cannot see any visible lag.
>> 3. The user can continue using the web-app.
> In the first tab?
Yes.
>> 4. The user closes the web browser and restarts it or logs out from the
>> web-app,
> and goes to the web-app start page. IE displays the standard "This page can't
> be displayed" error message.
> So at this point, nobody can connect?
Correct.
>> It’s as though the RPC ("POST /clearcore/ClearCore/CCService HTTP/1.1")
>> commands are working fine, but the normal page GET is failing.
> After the web application is deployed (launched in Tomcat, before any web
> browser has tried to connect),
> can you login to the Tomcat manager? It is something that GWT/your
> application is doing that locks you out
> of the Tomcat manager? Or is the manager actually never available?
The tomcat manager works perfectly before we start using out application.
Having investigated further, if you have the tomcat manager already open in a
tab when you start the application in another tab, the manager seems to keep
running. As long as you don’t open a new tab, it all seems fine.
>> Is it possible to kill the code that processes GET requests without
>> affecting POST messages?
> No.
That's what I thought.
>> If we configure tomcat to use HTTPS on port 8443, we get the error. If we
>> leave tomcat in the standard HTTP port 8080 settings, everything is fine. >>
>> We haven't tried having both HTTP and HTTPS configured simultaneously.
> That's certainly odd.
We have now tried both HTTP and HTTPS, and the HTTP connection has no issues,
even after running our application.
> Is there a working system? I noticed that you have two different Tomcat
> versions.
> Does one of them work and the other does not? You didn't mention that this
> was only affecting one system...
The different versions of tomcat all show the same issue. We have this issue on
two systems, and only two systems. We have not been able to reproduce this on
any other system we have access to.
Having investigated further, I appear to have provoked tomcat into producing a
pair of exception backtraces in the log files:
25-Nov-2015 17:28:21.642 SEVERE [http-nio-8443-exec-7]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.Handshaker.checkThrown(Unknown Source)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(Unknown Source)
at sun.security.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:351)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:208)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1476)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.ECDHCrypt.<init>(Unknown Source)
at sun.security.ssl.ServerHandshaker.setupEphemeralECDHKeys(Unknown Source)
at sun.security.ssl.ServerHandshaker.trySetCipherSuite(Unknown Source)
at sun.security.ssl.ServerHandshaker.chooseCipherSuite(Unknown Source)
at sun.security.ssl.ServerHandshaker.clientHello(Unknown Source)
at sun.security.ssl.ServerHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker$1.run(Unknown Source)
at sun.security.ssl.Handshaker$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Unknown Source)
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:301)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:359)
... 7 more
Caused by: java.security.InvalidAlgorithmParameterException: unknown curve
name: 1.2.840.10045.3.1.7
at org.bouncycastle.jce.provider.JDKKeyPairGenerator$EC.initialize(Unknown
Source)
... 20 more
25-Nov-2015 17:28:21.642 SEVERE [http-nio-8443-exec-1]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.Handshaker.checkThrown(Unknown Source)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(Unknown Source)
at sun.security.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:351)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:208)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1476)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.ECDHCrypt.<init>(Unknown Source)
at sun.security.ssl.ServerHandshaker.setupEphemeralECDHKeys(Unknown Source)
at sun.security.ssl.ServerHandshaker.trySetCipherSuite(Unknown Source)
at sun.security.ssl.ServerHandshaker.chooseCipherSuite(Unknown Source)
at sun.security.ssl.ServerHandshaker.clientHello(Unknown Source)
at sun.security.ssl.ServerHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker$1.run(Unknown Source)
at sun.security.ssl.Handshaker$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Unknown Source)
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:301)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:359)
... 7 more
Caused by: java.security.InvalidAlgorithmParameterException: unknown curve
name: 1.2.840.10045.3.1.7
at org.bouncycastle.jce.provider.JDKKeyPairGenerator$EC.initialize(Unknown
Source)
... 20 more
Trying to extract relevant information, gives me:
java.lang.RuntimeException: Could not generate DH keypair
caused by java.lang.RuntimeException: Could not generate DH keypair
caused by java.security.InvalidAlgorithmParameterException: unknown curve name:
1.2.840.10045.3.1.7
This suggests that we are using an (elliptical?) curve that tomcat does not
recognise. Is this likely to be an issue with the security certificate that we
are using?
I have checked, and we have the "Unlimited Strength Java Cryptography Extension
Policy Files" installed, so that should not be an issue.
Simon
________________________________
Infoshare is registered in England and Wales.
Registered Office: Infoshare Ltd, Millennium House, 21 Eden Street, Kingston
upon Thames, KT1 1BL | Registered Number: 2877612 | VAT Number: GB 678 1443 10
The content of this e-mail (and any attachment to it) is confidential. Any
views or opinions do not represent the views or opinions of Infoshare Ltd. If
you have received this e-mail in error please notify the sender and delete it.
You may not use, copy or disclose the information in any way. Infoshare Ltd
monitors incoming and outgoing e-mails.
Please consider the environment. Do you really need to print this email?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
