Amazon EC2 Tomcat 7.0.85 not starting up due to some memory issue
Hi All, For some reason my application hosted on ec2 is just not starting up. I know I never had any memory issues in last 1 year or so. I see below trace in catalina.out file. I am not sure if I need to add swap space or file permission is an issue here. Something changed in ec2 that is causing this error.I think they auto updated the tomcat version as well from 7.0.82 to 7.0.85. I seriously need some suggestions. I also need some suggestion as how to prevent bots from trying to access manager app. May 14, 2018 8:44:46 PM org.apache.catalina.realm.LockOutRealm filterLockedAccounts WARNING: An attempt was made to authenticate the locked user "admin" May 14, 2018 8:44:46 PM org.apache.catalina.realm.LockOutRealm filterLockedAccounts WARNING: An attempt was made to authenticate the locked user "admin" May 14, 2018 8:44:47 PM org.apache.catalina.realm.LockOutRealm filterLockedAccounts WARNING: An attempt was made to authenticate the locked user "admin" May 14, 2018 8:44:47 PM org.apache.catalina.realm.LockOutRealm filterLockedAccounts WARNING: An attempt was made to authenticate the locked user "admin" May 14, 2018 8:44:47 PM org.apache.catalina.realm.LockOutRealm filterLockedAccounts WARNING: An attempt was made to authenticate the locked user "admin" java.util.logging.ErrorManager: 4 java.io.FileNotFoundException: /usr/share/tomcat7/logs/catalina.2018-05-15.log (Permission denied) at java.io.FileOutputStream.open0(Native Method) at java.io.FileOutputStream.open(FileOutputStream.java:270) at java.io.FileOutputStream.(FileOutputStream.java:213) at org.apache.juli.FileHandler.openWriter(FileHandler.java:498) at org.apache.juli.FileHandler.publish(FileHandler.java:272) at java.util.logging.Logger.log(Logger.java:738) at java.util.logging.Logger.doLog(Logger.java:765) at java.util.logging.Logger.logp(Logger.java:1042) at org.apache.juli.logging.DirectJDKLog.log(DirectJDKLog.java:185) at org.apache.juli.logging.DirectJDKLog.error(DirectJDKLog.java:151) at org.apache.catalina.valves.AccessLogValve.open(AccessLogValve.java:1220) at org.apache.catalina.valves.AccessLogValve.rotate(AccessLogValve.java:1015) at org.apache.catalina.valves.AccessLogValve.log(AccessLogValve.java:1155) at org.apache.catalina.valves.AccessLogValve.log(AccessLogValve.java:991) at org.apache.catalina.core.AccessLogAdapter.log(AccessLogAdapter.java:51) at org.apache.catalina.core.ContainerBase.logAccess(ContainerBase.java:1386) at org.apache.catalina.core.ContainerBase.logAccess(ContainerBase.java:1393) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:490) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) May 15, 2018 12:15:03 AM org.apache.catalina.valves.AccessLogValve open SEVERE: Failed to open access log file [/usr/share/tomcat7/logs/localhost_access_log.2018-05-15.txt] java.io.FileNotFoundException: /usr/share/tomcat7/logs/localhost_access_log.2018-05-15.txt (Permission denied) at java.io.FileOutputStream.open0(Native Method) at java.io.FileOutputStream.open(FileOutputStream.java:270) at java.io.FileOutputStream.(FileOutputStream.java:213) at org.apache.catalina.valves.AccessLogValve.open(AccessLogValve.java:1212) at org.apache.catalina.valves.AccessLogValve.rotate(AccessLogValve.java:1015) at org.apache.catalina.valves.AccessLogValve.log(AccessLogValve.java:1155) at org.apache.catalina.valves.AccessLogValve.log(AccessLogValve.java:991) at org.apache.catalina.core.AccessLogAdapter.log(AccessLogAdapter.java:51) at org.apache.catalina.core.ContainerBase.logAccess(ContainerBase.java:1386) at org.apache.catalina.core.ContainerBase.logAccess(ContainerBase.java:1393) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:490) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Java HotSpot(TM) 64-Bit
Re: acceptCount with NIO and Tomcat 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Максим, On 5/11/18 10:21 PM, Максим Гумеров wrote: >> >> On 11/05/18 18:21, Максим Гумеров wrote: >>> Hi! I am running Tomcat 8 as part of Spring Boot application. >>> As usual, acceptCount defaults to 100 and maxThreads to 200. >>> According to >>> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#NIO_specif ic_ >> >>> configuration >>> I am expecting Tomcat to accept 200 "long" requests (each >>> taking say 20 seconds to complete), then accept 100 more >>> connections but not start reading from them, and then reject >>> any connection requests beyond that. That's why this is the >>> expected behavior: acceptCount = "The maximum >> queue >>> length for incoming connection requests when all possible >>> request processing threads are in use. Any requests received >>> when the queue is >> full >>> will be refused." So, when first 200 requests are all taken by >>> 200 processing threads, next 100 will go to the queue and >>> subsequent will be ignored. At least that's how it reads to >>> me. >>> >>> But what I actually see on my Mac is, tomcat successfully >>> accepts a >> little >>> short of 1000 such connections (I just didn't try more >>> connections) made within 5 seconds. It processes no more than >>> 200 requests at a time, but does not reject connections after >>> 300th one, as one would expect. >>> >>> What's the explanation for that? Can the quoted documentation >>> be >> imprecise >>> or outdated? Or am I missing something in it? >> >> acceptCount for NIO is passed in to >> ServerSocket.bind(SocketAddress,int) as the 2nd parameter >> (backlog). The Javadoc for that method says: >> >> The backlog argument is the requested maximum number of >> pending connections on the socket. Its exact semantics are >> implementation specific. In particular, an implementation may >> impose a maximum length or may choose to ignore the parameter >> altogether. >> >> It looks like it is being ignored in your JVM. >> >> Mark >> > > Thank you, this looks like one possible explanation. Maybe someone > else will show me some other. > > But, considering what you say, isn't that a documentation > deficiency? They shouldn't write "acceptCount is the length of > connection queue" if it's just a hint. Or, they could just add a > note that actual queue length may be chosen by implementation > instead. Also, they shouldn't write " up to the configured maximum > (the value of the acceptCount attribute)", better formulation is > "up to connection queue size (based on acceptCount attribute)". > What's written there now simply contradicts the implementation, > right? It looks like the "introduction" section of this page is misleading: https://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Introduction It documents the reality for BIO, but not for NIO connectors, which are *much* more complicated. I think that complexity is not necessary in the introduction, but it would be good to adjust that language to be more clear. How about something like this for that third paragraph: " Each type of connector (BIO, NIO, NIO2, and APR) have different strategies for handling incoming connections, but, in general, Tomcat will accept concurrent connections until the connector's `maxConnections` setting has been reached. Any connections received in addition to that may be queued in the OS's TCP/IP stack, with the `acceptCount` attribute giving hints to the OS as to the size of that queue. Any connections received on top of those will receive a "Connection Refused" response, until earlier connections are processed to completion and resources are available to accept more connections. Requests are processed with a thread pool which processes *connections* in the order in which they are received. Note that multiple requests can be made through each connection, so *requests* are not necessary processed in a "fair order". The BIO and APR connectors cannot be made to be fair, while the NIO and NIO2 connectors can in fact be made to process requests "fairly". " - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlr67u0ACgkQHPApP6U8 pFgHxhAAsh9Do5rPH7t8Ow3KNIfaZxJIsG5Xz1XXAfQ3Nm5aog31MBmgdjnXeUDV tZJEi60bHv1jOzSYlGX2JmWPH9dIkfWx1cZn12fML8dpWs6J9v41mGXiPj6+ARYY aa9UKcZgPWfPZbN5voclwcRTbANy66n6yyfiMrFbFtAJMPWueEemaH83CeaLKc0b sC4OoLcEBRq352GwwjqzO2C8K0N3sc+J13Yk7MVkRMqBHlTIwnClCm5+k2eRQOZd M1aNvcLXzIH1QRPK1TjP1VtqpX1V6aM8o2et+pvWc23tFAyR1+/Z1v/VsKDy9BrK brL4vQo5ahqjASVbdL20qSMNRyzBS1stuisVZ3nYJaMO/2kN6XWhUV/zIk3UCiza 4CVeu6oMhO/pvOqSQaCnfP2YAUrLgTVuyNqjxCgYvlpRQInz9Io5sWgY3b8Lh57Q u/B9Y3mvv9KwfAKcYw7Gjhjf5g0aFddx5e+DoYZGTOnpdUfwNE8feQIz+cLezAAR dXvLRJ82I7hBmehdRszuH3fgTr4xDceMxMPTmp2fxd6Hl5A0MPslG5Z7Y7mZemAI 16yTnQ1FIeRIx/SIPDJaor9pBPnRKP21VcdMNMpqOJZXphW5grd1LQh1Clk43Vrs 3kjn8mV6xXWTWSkvwiYOzkvFlCDOw6p4FkFoG+nqKTv0n/Xdyqk= =pPN5 -END PGP
SSO using Reverse Proxy from IIS to Apache Tomcat 8.0.22 (Use Windows Authentication NTLM)
Hi Team, We are trying to do implement SSO using windows integrated authentication (NTLM) on Apache Tomcat 8.0.22 for Rest API calls. We are following "Windows Authentication How To" --> Reverse Proxies --> Microsoft IIS. We configured ISAPI_Redirect.dll for reverse proxy. But facing some issues with it, can you please help us with the below : 1. Our application (Siebel) listens to HTTP protocol but seems like ISAPI_Redirect reverse proxy uses AJP connector Protocol, Is there any document which can help us configure reverse proxy with HTTP protocol? 2. We are using Windows Authentication NTLM approach (We cannot use Kerberos as per the company guidelines), are there any known issue using WIA with Apache 3. Please suggest if there is any better approach to achieve SSO for Rest calls using Windows Integrated Authentication on windows server. Any help would be very much appreciated, thanks again for your time. Thanks & Regards, Suraj Agrawal -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
How to Properly Map Servlets and JSP Anchor Links?
I have a simple Maven servlet/jsp application that I deploy to a local
Tomcat 9 (via Eclipse). JSP pages are stored under the root folder (
src\main\webapp\*.jsp) which when Maven installs a WAR, they go under the
root folder (MyAppContext\*.jsp along side MyAppContext\META-INF\ and
MyAppContext\WEB-INF\).
The servlets' URL patterns are annotated for each servlet, e.g. /doactionone,
/doactiontwo, etc. Most servlets perform the dispatching to various JSP
pages, but I do have a direct anchor link on one.
I wanted to move these JSP pages into their own respective directory, so I
moved them to src\main\webapp\jsp\*.jsp folder, and when the Maven install
is run, they get placed under MyAppContext\jsp\.
The only entry I have in web.xml is a welcome file that after relocating
the JSP files, it points to jsp\doactionone.jsp which loads that
corresponding JSP page. This page contains a simple form:
...
...
The submission on this page actually calls the right servlet (the one
defined with doactionone URL pattern). I also have a link that takes the
user to the second page (doactiontwo.jsp).
However, when I navigate to that second page via this link, which has
another simple form (see below), and perform the submission (post), I see
in browser's debugging that the URL request is
http://localhost:8080/MyAppContext/jsp/doactiontwo which, for obvious
reason, would return a 404 status (and get no hit to this servlet's doPost()
(or doGet()) methods either).
...
...
If I try to modify the second servlet's URL pattern to /jsp/doactiontwo, I
can hit the servlet, but when doactiontwo actually dispatches/forwards the
request after processing to the first servlet (doactionone) with:
RequestDispatcher rd = request.getRequestDispatcher("doactionone.jsp");
rd.forward(request, response);
when it gets loaded, when hover over the URL on the first page that
initially was pointing to the second JSP page (), now actually points to:
jsp/jsp/doactiontwo.jsp
The funny part is that the source code of doactionone.jsp still shows it as
jsp/doactiontwo.jsp, but hovering over it shows
http://localhost:8080/MyAppContext/jsp/jsp/doactiontwo, and when clicked,
it obviously results in 404 status.
Can somebody explain why, first of all, the submission on the second JSP
page requires the servlet to have a pattern of /jsp/doactiontwo to work
rather than /doactiontwo? And is there a better way around to actually
design this back and forth so an issue like this doesn't arise?
And second, why when the second servlet processes the request and
dispatches/forwards it to the first page, the URL now contains two jsp/'s
for the anchor link?
