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
