Re: Tomcat catalina.out log is not rolling using log4j DailyRollingFileAppender
Joleen,
On 11/19/15 3:19 PM, Joleen Barker wrote:
> I want to say up front that I am not a developer and know enough to brake
> some stuff. lol
Lots of "only admins" on this list. Welcome.
> I have a software package from a vendor that ships the tomcat web server
> with it. Below are my environment details:
>
> 1) The tomcat version that is running is v8.0.26.0
> 2) The OS is a Centos v7 UNIX VM
> 3) Java JDK I have installed that Tomcat is using is 1.8.0_60
> 4) The vendor has the $CATALINA_HOME and CATALINA_BASE as the same location
> which is /server
> 5) The /server directory is the place where the /lib,
> /bin, /conf, and etc.directory's are found.
Thanks for providing all that information up front.
> 6) Due to the catalina.out file growing too large with the default
> juli.AsyncFileHandler using the logging.properties file that was found in
> the $CATALINA_HOME/conf directory. I changed it to use the log4j logging.
> Here are the steps I did to make this happen which I found on Tomcat 8 web
> site:
>
> a. Downloaded log4j-1.2.17.jar and placed it in $CATALINA_HOME/lib
> b. Downloaded from the Tomcat extras web page for Tomcat 8 the
> tomcat-juli-adapters.jar and the tomcat-juli.jar.
> c. Deleted the old tomcat-juli.jar out of the $CATALINA_HOME/bin
> directory.
> d. Placed the new tomcat-juli.jar file and the
> tomcat-juli-adapters.jar file in to the $CATALINA_HOME/bin directory.
> e. Deleted the old logging.properties file from the
> $CATALINA_HOME/conf directory.
>f. Created the log4j.properties file in the $CATALINA_HOME/lib
> directory and copied the settings that are shown on the Tomcat 8 logging
> web page that has been there for Tomcat 7 logging web page too that
> everyone is familiar with. Here is the url just incase:
> https://tomcat.apache.org/tomcat-8.0-doc/logging.html
>
> I know the log4j.properties files is being used as I made 2 changes to the
> config file that were taken. One changes was to actually verify the
> log4j.properties file was being used, which was changed the word INFO to
> OFF for localhost file messages being written by editing the following line
> at the bottom of the log4j.properties file:
>
> log4j.logger.org.apache.catalina,core.ConainerBase.[Catalina].[localhost] =
> OFF, LOCALHOST
>
> The other change I made was I changed the file name in the following line
> to read catalina.out instead of catalina:
> log4j.appender,CATALINA.File = ${catalina.base}/logs/catalina.out
>
> The reason I did this was I thought the daily roll that was supposed to
> take place at midnight would occur on the file that was named catalina and
> not on the file that was named catalina.out. All the INFO messages being
> written to the file named catalina were also being written to the
> catalina.out file which was the one I wanted to roll daily anyway so I
> thought this change would be fine.
>
> I stopped tomcat and cleared all the logs out and left the server to run
> over night. (It is still running now) and it appears the roll did not take
> place. What I woke up to was everything you see below found in the
> $CATALINA_HOME/logs directory except for the one file written today which
> was due to me logging in to the web application that the vendor supports so
> I could verify I could still login and use the software:
>
> -rw-r--r--. root root 33003 Nov 18 21:03 catalina.out
> -rw-r--r--. root root 0 Nov 18 21:03 host-manager
> -rw-r--r--. root root 0 Nov 18 21:03 localhost
> -rw-r--r--. root root 0 Nov 18 21:03
> localhost_access_log.2015-11-18.txt
> -rw-r--r--. root root2498 Nov 19 13:23
> localhost_access_log.2015-11-19.txt
> -rw-r--r--. root root 0 Nov 18 21:03 manager
>
> I don't know what I am missing from the configs to make the catalina.out
> file roll each day at midnight. Some help would be greatly appreciated.
You did a great investigation and (nearly) all the steps you took were
reasonable. Unfortunately, switching from JULI to Log4j isn't going to
fix this problem, and neither of those packages will save you from the
catalina.out non-rotation problem. (See below)
> Also, no I cannot contact the vendor as they just tell me to hire a
> professional. So I am the professional.
Wow. I wouldn't pay them any more money for anything. :(
> And, no I don't want to use the RollingFileAppender as I need the roll over
> to be based on day and not the size of catalina.out.
>
> I do see when the application starts and in the catalina.out it records the
> following which I don't know if it should read something else for the log4j
> logging to be used:
>
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>
> I'm digging and don't know where else to look and am probably not looking
> in the right places.
>
> Any Help is greatly appreciated. I think I am close.
The trick is that catalina.out isn't managed by any Java-based logger...
catalina.out
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: Source IP filtering on some URLs before Container-managed authentication
On 20.11.2015 17:00, Ognjen Blagojevic wrote: Andre, Chris, On 20.11.2015 9:30, André Warnier (tomcat) wrote: On 19.11.2015 21:26, Christopher Schultz wrote: I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. Or, you could switch from container-based AAA, to application-based AAA. You can create a servlet filter which "wraps" your application(s), and in it apply any rules you want. This is totally portable, not Tomcat-specific, and doesn't require any change to server.xml for instance (nor to your application). Thank you both for looking into this. Ok, so it is a choice, either - move RemoteAddrFilter to become a Realm in front of Authenticator Valve, or - move Authenticator valve to become a Filter behind RemoteAddrFilter. To avoid having to redo what others have already done, you may also want to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams see : element --> remote-addr (for instance) (I'm not saying that urlrewrite fills /all/ your needs, but you could combine urlrewrite with some simple code of your own, to fill all your needs. (snip)). This part I don't get. What is the added value of using urlrewrite compared to RemoteAddrFilter? It is basically the same functionality? Well, you can use a lot more conditions in urlrewrite filter, such as a client IP + URL patterns + lots more. And you can combine them using the type="next". Your original post said "My webapp have a set of resources, let's call that set R. Some of those resources need to be accessed only from certain source IP addresses, let's call that subset R'. And some subset of R' (let's call it R'') needs authentication." So if I get this correctly, for R'' you have 3 requirements : - a URL matching R'' (check with "request-url" or "request-uri") - a remote IP (check with "remote_addr") - an authenticated user (check with "remote_user" not blank) and if it does not match the last 2, return "not found" or "forbidden" or a login page (or anything else that strikes your fancy) then, (with "next"="or") for R' you have 2 requirements : - a URL matching R' (check with "request-url" or "request-uri") - a remote IP (check with "remote_addr") and if it does not match the last, return "not found" or "forbidden" or a login page (or anything else that strikes your fancy) and for the rest, nothing, which is what urlrewrite will do by default : let the request through. Note that I haven't really tried the above. It just looks as if it might fill your needs. If you do not know urlrewrite yet, it is worth investigating anyway; it is a nice piece of work, useful in many circumstances. The above is just an expression of my general view of things. I interpret 12.2 and 12.3 of the servlet spec as saying that container-based authentication is meant to match general cases, and if you want more specific things, you should probably move to application-level authentication (which can be part of your application, and if based on servlet filters, should be portable to other containers)(which Valves are not). And if you are anyway going in that direction, re-using already-developed and tested stuff like urlrewrite (if possible), is probably less expensive overall, than starting from scratch. Note also that urlrewrite is open-source, under a BSD license. So you can also re-use parts of the code (or just get inspiration from it), if you want to turn your own more specific filter. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REMOTE_USER mod_jk
Am 19.11.2015 um 14:32 schrieb Teresa Fasano: With Apache/2.2.15 the REMOTE_USER is passed to the application (Jboss), while with Apache/2.4.6 is lost. In the log of the application we see this error: "REMOTE_USER variable not assigned." If you have a test system, you can set JkLogLevel to debug. On that log level, you should be able to see the REMOTE_USER forwarding in the mod_jk logs. First check how the line looks when using HTTPD 2.2. Then check, whether that info is present when using 2.4. If "yes", then your problem is on the Tomcat (configuration, webapp) side. If it is not present, then HTTPD 2.4 for some reason does not set REMOTE_USER and you have to check your 2.4 integration. Regards, Rainer - 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.
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: Source IP filtering on some URLs before Container-managed authentication
Andre, Chris, On 20.11.2015 9:30, André Warnier (tomcat) wrote: On 19.11.2015 21:26, Christopher Schultz wrote: I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. Or, you could switch from container-based AAA, to application-based AAA. You can create a servlet filter which "wraps" your application(s), and in it apply any rules you want. This is totally portable, not Tomcat-specific, and doesn't require any change to server.xml for instance (nor to your application). Thank you both for looking into this. Ok, so it is a choice, either - move RemoteAddrFilter to become a Realm in front of Authenticator Valve, or - move Authenticator valve to become a Filter behind RemoteAddrFilter. To avoid having to redo what others have already done, you may also want to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams see : element --> remote-addr (for instance) (I'm not saying that urlrewrite fills /all/ your needs, but you could combine urlrewrite with some simple code of your own, to fill all your needs. (snip)). This part I don't get. What is the added value of using urlrewrite compared to RemoteAddrFilter? It is basically the same functionality? -Ognjen - 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.
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?
Re: Source IP filtering on some URLs before Container-managed authentication
On 19.11.2015 21:26, Christopher Schultz wrote: Ognjen, On 11/19/15 10:14 AM, Ognjen Blagojevic wrote: My webapp have a set of resources, let's call that set R. Some of those resources need to be accessed only from certain source IP addresses, let's call that subset R'. And some subset of R' (let's call it R'') needs authentication. I have a reqirement to check source IP address before authentication. Right now, R' is specified in web.xml RemoteAddrFilter s, and R'' is specified in web.xml s. The problem is, filters are executed after container-managed authentication, so login form is presented to the user before RemoteAddrFilter kicks in, and check source IP address. That is not what I need. Users outside trusted IP ranges should not be able to even know about the protected resources, let alone to guess passwords. RemoteAddrValve, on the other hand, is called before container-managed authentication, but it does not allow specifying s. What would be a good solution for the above requirement? Extend RemoteAddrValve with the ability to specify s? I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. -chris Or, you could switch from container-based AAA, to application-based AAA. You can create a servlet filter which "wraps" your application(s), and in it apply any rules you want. This is totally portable, not Tomcat-specific, and doesn't require any change to server.xml for instance (nor to your application). Servlet Spec 3.0 has this to say : 13.3 Programmatic Security Programmatic security is used by security aware applications when declarative security alone is not sufficient to express the security model of the application. To avoid having to redo what others have already done, you may also want to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams see : element --> remote-addr (for instance) (I'm not saying that urlrewrite fills /all/ your needs, but you could combine urlrewrite with some simple code of your own, to fill all your needs. Servlet filters are "stackable"). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
