You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Simon Callan <si...@infoshare-is.com> on 2015/11/20 17:13:19 UTC
Tomcat hanging when acting as GWT server.
Hi,
We are running GWT 2.5.1, Tomcat 7.0.56 and 7.0.65 on windows server 2008, IE 10, configured to serve web pages over SSL.
The user can run our web-app and it will happily run until the user closes the web-browser, or logs out from the app.
However, immediately after starting the web-app, the tomcat home page becomes unresponsive, and after the user has logged out or restarted the browser, the web-app does not respond.
The only way to recover is to restart tomcat.
If we run tomcat in non-SSL mode, there is no problem.
The server.xml file appears to be pretty standard, with the SSL connector:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreFile="<file>" keystorePass="<pw>"/>
If we try dumping the threads, all we get is a "Console CTRL+BREAK event signaled" message in the logfile.
The following are partial logs from Tomcat. As you can see, everything looks fine, and manually comparing them with a working system shows no obvious differences.
Simon
**stdout**
16:13:57,936 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to Logger[ROOT]
16:13:57,936 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
16:13:57,951 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@5528416b - Registering current configuration as safe fallback point
2015-11-18 16:13:57,951 DEBUG localhost-startStop-1 clearcoreauth - Starting session listener.
2015-11-18 16:13:57,967 DEBUG localhost-startStop-1 clearcorexuafilter - Method call: init
2015-11-18 16:13:57,967 DEBUG localhost-startStop-1 clearcorexuafilter - Method exit: init
**catalina**
Nov 18, 2015 4:13:57 PM org.apache.catalina.startup.TldConfig execute
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
...
INFO: Deploying web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\manager
Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\manager has finished in 110 ms
Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\ROOT
Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deployment of web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\ROOT has finished in 78 ms
Nov 18, 2015 4:13:58 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-0.0.0.0-8443"]
Nov 18, 2015 4:13:58 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-bio-8009"]
Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 8068 ms
**localhost_access_log**
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/login.jsp HTTP/1.1" 200 3438
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/images/logo.gif HTTP/1.1" 200 808
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/spinner.js HTTP/1.1" 200 1118
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/defaultlogin.css HTTP/1.1" 200 1504
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /favicon.ico HTTP/1.1" 200 21630
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:08 +0000] "GET /clearcore/images/sprites.gif HTTP/1.1" 200 7111
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "POST /clearcore/ClearCore/Login HTTP/1.1" 302 -
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/index.jsp;jsessionid=05FF9853857C40F9E0B3198B3E55DC3A HTTP/1.1" 200 2374
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/ClearCore.css HTTP/1.1" 200 10967
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/ClearCore/ClearCore.nocache.js HTTP/1.1" 200 6004
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/ClearCore/gwt/clean/clean.css HTTP/1.1" 200 29325
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:13 +0000] "GET /clearcore/ClearCore/E60ECA106C49CC447903262AD44A210E.cache.html HTTP/1.1" 200 823732
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:14 +0000] "POST /clearcore/ClearCore/CCService HTTP/1.1" 200 819
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:14 +0000] "GET /clearcore/ClearCore/clear.cache.gif HTTP/1.1" 200 43
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/deferredjs/E60ECA106C49CC447903262AD44A210E/2.cache.js HTTP/1.1" 200 484
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/images/lblgrad2.png HTTP/1.1" 200 197
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/gwt/clean/images/thumb_vertical.png HTTP/1.1" 200 231
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/gwt/clean/images/hborder.png HTTP/1.1" 200 1995
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/deferredjs/E60ECA106C49CC447903262AD44A210E/1.cache.js HTTP/1.1" 200 1331282
0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:16 +0000] "POST /clearcore/ClearCore/CCService HTTP/1.1" 200 335
________________________________
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?
Re: Tomcat hanging when acting as GWT server.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Simon,
On 11/25/15 12:55 PM, Simon Callan wrote:
> 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.
It's BouncyCastle that isn't recognizing that curve, not Tomcat. Tomcat
doesn't perform any of its own crypto; instead, it delegates to the JVM.
Here, you appear to have configured BC for crypto instead of using the
built-in JSSE provider.
> Is this likely to be an issue with the security certificate that we are using?
Probably not, but it's possible there is some incompatibility between
your certificate and the algorithms you are trying to use. For instance,
you can't use DSA cipher suites with an RSA key...
> I have checked, and we have the "Unlimited Strength Java
> Cryptography Extension Policy Files" installed, so that should not be
> an issue.
Since you are using BouncyCastle, that "unlimited strength Java
Cryptography Extension Policy Files" is probably irrelevant.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat hanging when acting as GWT server.
Posted by Simon Callan <si...@infoshare-is.com>.
>>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat hanging when acting as GWT server.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Simon,
On 11/20/15 11:43 AM, Simon Callan wrote:
> Christopher,
>
> Hopefully some useful answers.
>
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Sent: 20 November 2015 16:22
>
>> On 11/20/15 11:13 AM, Simon Callan wrote:
>>> We are running GWT 2.5.1, Tomcat 7.0.56 and 7.0.65 on windows server
>>> 2008, IE 10, configured to serve web pages over SSL.
>>>
>>> The user can run our web-app and it will happily run until the user
>>> closes the web-browser, or logs out from the app.
>>>
>>> However, immediately after starting the web-app, the tomcat home page
>>> becomes unresponsive, and after the user has logged out or restarted
>>> the browser, the web-app does not respond.
>>>
>>> The only way to recover is to restart tomcat.
>
>> I'm going to have to clarify a few things, here.
>>
>> First, you say that the user can use the web app without any problems.
>> Then you say that as soon as the web application starts, it becomes unresponsive.
>> So, which is it: does the web application "run happily" or does is it unresponsive from the outset?
>>
>> 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.
> 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).
> 3. The user can continue using the web-app.
In the first tab?
> 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?
> 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?
> Is it possible to kill the code that processes GET requests without affecting POST messages?
No.
>>> If we run tomcat in non-SSL mode, there is no problem.
>
>> Do you mean if the user uses HTTP instead of HTTPS, all is well? Or does it really depend upon whether TLS is enabled *at all*?
>
> 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.
>>> The following are partial logs from Tomcat. As you can see, everything
>>> looks fine, and manually comparing them with a working system shows no
>>> obvious differences.
>
>> No obvious differences between what and what?
>
> Maybe I should say, no significant differences that I noticed between the logs taken from a working system, and the logs from the system that shows this error.
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...
>> Did your CTRL-BREAK produce a thread dump? I don't see it anywhere...
>
> No, all we got was the "Console CTRL+BREAK event signaled" message in the logfile.
That's odd. CTRL-BREAK on Windows should dump a stack trace of all
threads to the console. Try this when Tomcat isn't responding:
http://wiki.apache.org/tomcat/HowTo#How_do_I_obtain_a_thread_dump_of_my_running_webapp_.3F
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat hanging when acting as GWT server.
Posted by Simon Callan <si...@infoshare-is.com>.
Some additional information.
If we configure Tomcat to accept both HTTP and HTTPs connections, the HTTP connection remains working, even after the HTTPS one has broken.
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?
RE: Tomcat hanging when acting as GWT server.
Posted by Simon Callan <si...@infoshare-is.com>.
Christopher,
Hopefully some useful answers.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Sent: 20 November 2015 16:22
> On 11/20/15 11:13 AM, Simon Callan wrote:
> > We are running GWT 2.5.1, Tomcat 7.0.56 and 7.0.65 on windows server
> > 2008, IE 10, configured to serve web pages over SSL.
> >
> > The user can run our web-app and it will happily run until the user
> > closes the web-browser, or logs out from the app.
> >
> > However, immediately after starting the web-app, the tomcat home page
> > becomes unresponsive, and after the user has logged out or restarted
> > the browser, the web-app does not respond.
> >
> > The only way to recover is to restart tomcat.
> I'm going to have to clarify a few things, here.
>
> First, you say that the user can use the web app without any problems.
> Then you say that as soon as the web application starts, it becomes unresponsive.
> So, which is it: does the web application "run happily" or does is it unresponsive from the outset?
>
> 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.
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.
3. The user can continue using the web-app.
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.
It’s as though the RPC ("POST /clearcore/ClearCore/CCService HTTP/1.1") commands are working fine, but the normal page GET is failing.
Is it possible to kill the code that processes GET requests without affecting POST messages?
> > If we run tomcat in non-SSL mode, there is no problem.
> Do you mean if the user uses HTTP instead of HTTPS, all is well? Or does it really depend upon whether TLS is enabled *at all*?
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.
>> The following are partial logs from Tomcat. As you can see, everything
>> looks fine, and manually comparing them with a working system shows no
>> obvious differences.
> No obvious differences between what and what?
Maybe I should say, no significant differences that I noticed between the logs taken from a working system, and the logs from the system that shows this error.
> Did your CTRL-BREAK produce a thread dump? I don't see it anywhere...
No, all we got was the "Console CTRL+BREAK event signaled" message in the logfile.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat hanging when acting as GWT server.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Simon,
On 11/20/15 11:13 AM, Simon Callan wrote:
> We are running GWT 2.5.1, Tomcat 7.0.56 and 7.0.65 on windows server
> 2008, IE 10, configured to serve web pages over SSL.
>
> The user can run our web-app and it will happily run until the user
> closes the web-browser, or logs out from the app.
>
> However, immediately after starting the web-app, the tomcat home
> page becomes unresponsive, and after the user has logged out or
> restarted the browser, the web-app does not respond.
>
> The only way to recover is to restart tomcat.
I'm going to have to clarify a few things, here.
First, you say that the user can use the web app without any problems.
Then you say that as soon as the web application starts, it becomes
unresponsive. So, which is it: does the web application "run happily" or
does is it unresponsive from the outset?
Then, after the user logs-out (from the either completely responsive or
completely non-responsive web application), the web application becomes
(or remains) unresponsive?
> If we run tomcat in non-SSL mode, there is no problem.
Do you mean if the user uses HTTP instead of HTTPS, all is well? Or does
it really depend upon whether TLS is enabled *at all*?
> The server.xml file appears to be pretty standard, with the SSL connector:
>
> <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
> maxThreads="150" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS" keystoreFile="<file>" keystorePass="<pw>"/>
Looks fine, though if you explicitly use an <Executor>, you get better
control over threading. That's not your problem, here, though.
> If we try dumping the threads, all we get is a "Console CTRL+BREAK
> event signaled" message in the logfile.
>
> The following are partial logs from Tomcat. As you can see,
> everything looks fine, and manually comparing them with a working
> system shows no obvious differences.
No obvious differences between what and what?
> **stdout**
>
> 16:13:57,936 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to Logger[ROOT]
> 16:13:57,936 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
> 16:13:57,951 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@5528416b - Registering current configuration as safe fallback point
> 2015-11-18 16:13:57,951 DEBUG localhost-startStop-1 clearcoreauth - Starting session listener.
> 2015-11-18 16:13:57,967 DEBUG localhost-startStop-1 clearcorexuafilter - Method call: init
> 2015-11-18 16:13:57,967 DEBUG localhost-startStop-1 clearcorexuafilter - Method exit: init
>
> **catalina**
>
> Nov 18, 2015 4:13:57 PM org.apache.catalina.startup.TldConfig execute
> INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
> ...
> INFO: Deploying web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\manager
> Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.HostConfig deployDirectory
> INFO: Deployment of web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\manager has finished in 110 ms
> Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.HostConfig deployDirectory
> INFO: Deploying web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\ROOT
> Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.HostConfig deployDirectory
> INFO: Deployment of web application directory C:\Program Files\Apache Software Foundation\Tomcat 7.0_Tomcat7.0.65\webapps\ROOT has finished in 78 ms
> Nov 18, 2015 4:13:58 PM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["http-bio-0.0.0.0-8443"]
> Nov 18, 2015 4:13:58 PM org.apache.coyote.AbstractProtocol start
> INFO: Starting ProtocolHandler ["ajp-bio-8009"]
> Nov 18, 2015 4:13:58 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 8068 ms
>
> **localhost_access_log**
>
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/login.jsp HTTP/1.1" 200 3438
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/images/logo.gif HTTP/1.1" 200 808
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/spinner.js HTTP/1.1" 200 1118
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /clearcore/defaultlogin.css HTTP/1.1" 200 1504
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +0000] "GET /favicon.ico HTTP/1.1" 200 21630
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:08 +0000] "GET /clearcore/images/sprites.gif HTTP/1.1" 200 7111
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "POST /clearcore/ClearCore/Login HTTP/1.1" 302 -
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/index.jsp;jsessionid=05FF9853857C40F9E0B3198B3E55DC3A HTTP/1.1" 200 2374
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/ClearCore.css HTTP/1.1" 200 10967
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/ClearCore/ClearCore.nocache.js HTTP/1.1" 200 6004
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +0000] "GET /clearcore/ClearCore/gwt/clean/clean.css HTTP/1.1" 200 29325
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:13 +0000] "GET /clearcore/ClearCore/E60ECA106C49CC447903262AD44A210E.cache.html HTTP/1.1" 200 823732
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:14 +0000] "POST /clearcore/ClearCore/CCService HTTP/1.1" 200 819
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:14 +0000] "GET /clearcore/ClearCore/clear.cache.gif HTTP/1.1" 200 43
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/deferredjs/E60ECA106C49CC447903262AD44A210E/2.cache.js HTTP/1.1" 200 484
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/images/lblgrad2.png HTTP/1.1" 200 197
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/gwt/clean/images/thumb_vertical.png HTTP/1.1" 200 231
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/gwt/clean/images/hborder.png HTTP/1.1" 200 1995
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:15 +0000] "GET /clearcore/ClearCore/deferredjs/E60ECA106C49CC447903262AD44A210E/1.cache.js HTTP/1.1" 200 1331282
> 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:16 +0000] "POST /clearcore/ClearCore/CCService HTTP/1.1" 200 335
Did your CTRL-BREAK produce a thread dump? I don't see it anywhere...
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org