Re: Tomcat hanging when acting as GWT server.
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.(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.(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 >
RE: Tomcat hanging when acting as GWT server.
>>> 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.(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
Re: Tomcat hanging when acting as GWT server.
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: > > maxThreads="150" scheme="https" secure="true" >clientAuth="false" sslProtocol="TLS" keystoreFile="" > keystorePass=""/> Looks fine, though if you explicitly use an , 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 +] "GET > /clearcore/login.jsp HTTP/1.1" 200 3438 > 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET > /clearcore/images/logo.gif HTTP/1.1" 200 808 > 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET > /clearcore/spinner.js HTTP/1.1" 200 1118 > 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET > /clearcore/defaultlogin.css HTTP/1.1" 200 1504 > 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET /favicon.ico > HTTP/1.1" 200 21630 > 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:08 +] "GET > /clearcore/images/sprites.gif HTTP/1.1" 200 7111 > 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +] "POST >
RE: Tomcat hanging when acting as GWT server.
Christopher,
Hopefully some useful answers.
> From: Christopher Schultz [mailto:ch...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
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: 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 +] "GET /clearcore/login.jsp HTTP/1.1" 200 3438 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET /clearcore/images/logo.gif HTTP/1.1" 200 808 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET /clearcore/spinner.js HTTP/1.1" 200 1118 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET /clearcore/defaultlogin.css HTTP/1.1" 200 1504 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:00 +] "GET /favicon.ico HTTP/1.1" 200 21630 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:08 +] "GET /clearcore/images/sprites.gif HTTP/1.1" 200 7111 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +] "POST /clearcore/ClearCore/Login HTTP/1.1" 302 - 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +] "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 +] "GET /clearcore/ClearCore.css HTTP/1.1" 200 10967 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:12 +] "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 +] "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 +] "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 +] "POST /clearcore/ClearCore/CCService HTTP/1.1" 200 819 0:0:0:0:0:0:0:1 - - [18/Nov/2015:16:13:14 +] "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 +] "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 +] "GET
Re: Tomcat hanging when acting as GWT server.
Simon,
On 11/20/15 11:43 AM, Simon Callan wrote:
> Christopher,
>
> Hopefully some useful answers.
>
>> From: Christopher Schultz [mailto:ch...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat hanging when acting as GWT server.
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?
