Re: Fwd: Tomcat Thread Log
Ah que estas en el de puertos también. Ahora te quito no te preocupes. El 09/04/15 a las 14:59, Christopher Schultz escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mukund, On 4/8/15 11:33 PM, Mukundaraman Valakumaresan wrote: I have deployed an application in Apache tomcat 7.0.59. When I copy the war to webapps folder and start tomcat. Tomcat hangs and I coudln't see the admin screen as well for the first 30 minutes. Without this war, tomcat starts fine shows the admin screen immediately. Through google, I check a posts, which asked me to take a thread dump. I use Sprint, Hibernate and Mysql. From the thread dump, I could see that and could also see that the problem with the connectivity to MySQL. But I am not sure where exactly the problem lies and what needs to be fixed. Any help is appreciated!! Thanks http-bio-8080-exec-1 daemon prio=10 tid=0x7fa11400c800 nid=0xa49 runnable [0x7fa124c87000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.jav a:113) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNec essary(ReadAheadInputStream.java:160) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.jav a:188) - - locked 0xbaadb0d0 (a com.mysql.jdbc.util.ReadAheadInputStrea m) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2428) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2882) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2871) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3414) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2536) - locked 0xcfa6a1f8 (a java.lang.Object) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2465) at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1383) - locked 0xcfa6a1f8 (a java.lang.Object) at com.mysql.jdbc.ConnectionImpl.buildCollationMapping(ConnectionImpl.jav a:823) at com.mysql.jdbc.ConnectionImpl.initializePropsFromServer(ConnectionImpl .java:3350) at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2045) - locked 0xcfa6a1f8 (a java.lang.Object) at com.mysql.jdbc.ConnectionImpl.init(ConnectionImpl.java:718) at com.mysql.jdbc.JDBC4Connection.init(JDBC4Connection.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo rAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo nstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java: 282) at java.sql.DriverManager.getConnection(DriverManager.java:571) at java.sql.DriverManager.getConnection(DriverManager.java:187) at org.springframework.jdbc.datasource.DriverManagerDataSource.getConnect ionFromDriverManager(DriverManagerDataSource.java:173) at org.springframework.jdbc.datasource.DriverManagerDataSource.getConnect ionFromDriver(DriverManagerDataSource.java:164) at org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getC onnectionFromDriver(AbstractDriverBasedDataSource.java:153) at org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getC onnection(AbstractDriverBasedDataSource.java:119) at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionPro viderImpl.getConnection(DatasourceConnectionProviderImpl.java:139) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProvider JdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:279) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServ icesImpl.java:124) at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.confi gureService(StandardServiceRegistryImpl.java:111) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeS ervice(AbstractServiceRegistryImpl.java:234) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService( AbstractServiceRegistryImpl.java:206) at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.j ava:1885) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java :1843) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java :1928) at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSes sionFactory(LocalSessionFactoryBuilder.java:252) at
Access ServletContext from Session in new websocket implementation
Hi, I'm trying to upgrade websocket application which is using Tomcat 7 to Tomcat 8.0.20(Which supports javax.websocket v1) In the current implementation we have extended the WebSocketServlet Is there a way that I can access the servletContext in the new websocket implementation? As I understand I get the Session and msg @OnMessage Thanks Best Regards /Thusitha --
Re: Rendering JSP files through Apache
On 09/04/2015 19:50, George Sexton wrote: Chris On 4/9/2015 10:06 AM, Christopher Schultz wrote: Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. Quoting Servlet Specification 3.0, section 4.1 Servlet context, it says: /A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext.// / My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. Can you help me understand why that's not the case? It only applies to requests that reach the WebContainer (in this case Tomcat). What happens before that in terms of reverse proxies is out of scope for the Servlet spec. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/9/2015 3:06 PM, George Sexton wrote: On 4/9/2015 12:58 PM, Caldarale, Charles R wrote: From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. That's true only when the request is processed by the servlet container. If the request is handled elsewhere, clearly the servlet spec clause doesn't apply. The problem is then that as a system, the container isn't compliant. No, it's the *system* that is broken. The container itself is doing exactly what it is being told to do. If you're not telling it to do the correct things, that's on you, not on the container. What you're in essence saying is that the compliance of the system isn't a concern. My belief is that as a system, the end result has to be compliant because my application is deployed on a system. If the system breaks the application, then it's not compliant. I suppose it's like eating an apple. At what point does the apple become you? Once it's inside you, when your body can start processing it. Just like the request must get inside the container for it to be processed IAW the spec. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/9/2015 10:06 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 4/9/15 10:52 AM, George Sexton wrote: On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind What I'm saying is that having httpd handle request for .html and everything else handled by the servlet container violates section 4.1 of Java Servlet Specification 3.0. The issue is not the servlet handling the request for .html. The issue is that if the deployment descriptor has an explicit mapping for /context/foo.html, and the web app is never presented with the request because it's being done at the higher level of Apache httpd, then it breaks the web app. httpd is given the request for /context/foo.html, and there is no corresponding file, and the web app is broken. You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. . - -chris -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Configure Tomcat 7 using Apache 2.4.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrew, On 4/8/15 3:07 PM, Leggio, Andrew wrote: Thank you for responding. I changed the mod_proxy_ajp.c to mod_proxy_ajp.so which is the module that is being loaded. Now my html pages are rendering fine; however, when I go the jsp pages it's not even putting an entry in the tomcat access log. Did you configure an access log? Where/how? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJnXeAAoJEBzwKT+lPKRYNqcQALHudFc29EAqs6BzqDTf8GJD LRGRWsdta5DVKmj9vbYOsohkm2yE+ZWspUCu18dYlUnec3AG3XSJEw0IIzpaqE0X Cv0dAx/joXHyPY2RH2cQmBZLOauSzghPG0KOYsZ2TgxcL0njChbR0+gyfjzqhK6O ggfdLP5sIbgcv+XcPqlnbJKLyh0MkDyrxBAU3fKFzjrncWi6NBZvjZBLZHtOF38e roYcOmuB+O7lDW3a9BxO2flM4VgIT8z1Q+ys5NQexbDUECaqwnLkiDv3zjSoPFKI OpcFYG2myn6N8ssHHxdr9aI4K8gnCN9lA41QfrQIKrFRPxRm9X35R8SQuFpq8f2q bhptAvOZFbwz3RK13ns71zTtUd8vdA9AVygecf3FWNWgVP2F6VCGSMLDwA9Il0C+ JzBg1yit+5isDscNqh6Tvc88zXj5prHOElojg9EO+pGOOS14kbsFzhd7h2tpih57 QpnaEkVFYE12L1sh/KvIa4GwbmK4wlLGVQ9YMz9T5RHpNMu2SH6Evjs9GfzGrfo7 u+7FJzVH272JEtlDWt0LWeoQ2lWXfuS0v3sF3LCnjKsDqrzPCKD2jW322AUcvEwF sfZjQiOlTUocjFNr12pskRuChpgdEwvq0E7WIYAeeqXv+MB/pjolCLWJzuLS69nH +oD1TSM0o3xMmpQjR/VT =DAkU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
Chris On 4/9/2015 10:06 AM, Christopher Schultz wrote: Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. Quoting Servlet Specification 3.0, section 4.1 Servlet context, it says: /A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext.// / My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. Can you help me understand why that's not the case? It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJqOHAAoJEBzwKT+lPKRYL6cQAKELJ476ux4/+UM1KcLMSWtR hh1Ft/uiU9vS2dhTvLZuRNCdzBHNL61Xq599CfHmFgBiKke68bEej9mjWaa8QqLc lHi2uEzO8OtXvR0OO/6hTtF3H1bxGh0OFE51BZ7J6mBXzZxzxmpee8HKs5EfrPpR PnbETVAJzzBOpduW6/m4UKNflcna5Cm0CATQVHyrKAm1PX3/3s3o0jF82PITW8ad dRBSt3IxxhjiOjvB119CGAyx3OlxqRCpvDZXerjhKP7lFxKN1VpbaaR27CRnM+RX /OPMUI0Mj8dVjnYZSc92lFbVRykYJf7ItTMpVQEYYG992gGKWRRwhPXVxDyUpMzq r0W6rCs3NV20OjUTS3peYACdDNzp8Etk2TT3T9SfowXv+6DUbIyDrBD/sHXrHw3l NAaraRIQzsUjvRITYIdK2np4EBHsnwZBP7Do5YjJclYDq4QUsnjfLDD/Y3jfpNs8 +zVJa9lNaJktKPCzN5hy1mMc+cKLZd2Z+wa58+YkiCAr4uffBAqMZ8bOCoWdSqa5 bowJ1/XT4DI13Ji36AliiVJIUcEk2pYy58kqD1c/12asO5BgETI4BdGfT9AI3bBE qcJPkNH5VKb9G6+It2LJvGEpZhxCr2vZRVluTlUcymgFtNu5KZAhO4OAn4p5Ch78 LDSuJI5jc5NsbeMHFLMS =Fb2W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
RE: Rendering JSP files through Apache
From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. That's true only when the request is processed by the servlet container. If the request is handled elsewhere, clearly the servlet spec clause doesn't apply. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/9/2015 12:18 PM, George Sexton wrote: On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For And the line above clearly states Web server. Now the next question is, what is a Web server? - From a browser's point of view, that's whatever serves up a URL that select. - From a systems point of view, that can be: 1. a paired hardware load balancer that handles SSL plus 2. a group of Apache web servers that handles PHP, Perl, etc. plus 3. A collection of Tomcat servlet containers for JSP / Servlets, etc. plus 4. A database farm - From a component point of view, that can be: 1. hardware load balancers 2. multiple Apache HTTPD servers 3. possible authentication / authorization servers 4. multiple Apache Tomcat servers 5. multiple database servers (SQL, noSQL, etc.) - From my reading, the specification only applies to item 4 in the components view. Other than that, it's up to the systems architect to get it right. example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... . . . just my two cents /mde/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVJtLqAAoJEEFGbsYNeTwtmUkH/RFIPAZZHOXsLSOAT4PEl6Lm RMuLnGWztFMR9ITc6DIikjRV2JIas3If8sCucE85LM/+3GWHDp1/HIJuXB073exZ sWp2GSlS1ZYloyqnHGBq31783LdM/xpj0yrTlWWSYN7iVwxD+fd5dAxBYaFqxoxd kh6DEQUld1ELBku2bXSf/4EcPFgPvhkGjvxbot1DQYO+CurHoFGRAnyrsQ17LJ3m Hzm7fo7If1Gowm5EqNhjqPoSIpz8QHvZG0hZSZxg+B260D6RLbcdqpGuFLOZeOjA WcJy+5dYydOxiF+pIFsA14OmEtPvxQsgQMOdTasskiubY60YcQXzvqZfe/7GnBU= =1PCa -END PGP SIGNATURE- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrew, On 4/8/15 8:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. Okay. Just curious: why? How do I accomplish this? - From your other thread, it looks like you have solved this problem. Are you still in fact having trouble? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJncCAAoJEBzwKT+lPKRYcdYP/ieIeV/dyE2N7ymFYso6jy8g UElbANv+2n3KwqfCe+ikDQJBOfXyVwxt1NesDC3vkwFHvvYqNJuMQgJNuDS2HpJz KXAGYDJBIEokj6lcWrhs2bYzDpKwdN7ldUM70wXG4OZ/yrXvrhtHSKnikfGtJoyW EWj1/HnHL21j7Hvzp3uHVrWMUDJbFDf+1BvIJJ/kA5orJ5fy01Tk0s+/BGeMkWuk BotBaokxN4ttX7Z5VFfczEDYkfZ2OlmpaKDURaD2uyITaXy8KQ3SNdViLpyxdBaT 2Nh7cio1wCVfkn4FxkDps9Y9eBTRBHWKfZNyrV9xIPMSGc3soInQ0uWvGTTXyJAd O6LahC/sA2fpT5MIayXUrjNQHOd3gUudrRPRD4O75JRTjPgg05tLiqZcYWkyDD91 BLriXIudPDbTt/Tw6Zq0PXrmTiIPSzdCLUNeznJWJuknhul86vYRs5luFORS1byu lBIZNZq4us5bmHHk9ufME37uwV+P2f5bZAZBOv25XYszNgc1m0PdJxN/A+dOomPJ Q+G52pKRXn+nNV/P2zZ9kZNC09ZnH8FnkzLXHnP9GVzAP2+OQ/klZJWDV3JxAkH7 JES4imdhADRypTntI34rqeN7vYSzQm7WTrbqHDyyXTK6WBtsytipf+dNiWfa10rL ntPsrfPnR9xmRlnEZ4C2 =IXuZ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Performance question...
Looks like we have two potential root causes. 1. Spring Framework 4.0.0 and jdk 1.7.0_51 are used which might be one of the root causes according to a Spring Framework bug.. The fix is to upgrade the Spring Framework version.2. The codecache is too small in 1.7.0_51 and leads to performance/cpu utilization issues. The fix is to try increasing to 4x the default size, setup printing out codecashe size when app server stopped. Also in 1.7.0_80 this was fixed and in 1.8 the default codecache size was increased by 4x. Regards,-Tony From: Linus Brimstedt linus.brimst...@viskan.se To: PerfGuru myunipor...@yahoo.com; users users@tomcat.apache.org Sent: Tuesday, April 7, 2015 5:55 PM Subject: Re: Performance question... Hello Try to do a java thread dump and check the stuck threads (possibly by comparing with the output of the tomcat server status page). Hopefully this will give you a clue about what the threads are doing at that time. If the application uses a database, you may see that they are stuck waiting for the dB reply. It could also be that it's waiting for disk (perhaps you have too much logging enabled) etc. How do you simulate your users and do you have proper timing between requests of each users? If a real user on average take 10 seconds between requests and you have a timing of 1 second between requests in your load test, you are simulating 10x the load you think.. Br L On 7 Apr 2015 18:56, PerfGuru myunipor...@yahoo.com.invalid wrote: Hi All,We are noticing when running a simple load test of 25 virtual users that our Tomcat server is running at 40% CPU and transactions are taking over 40 seconds. We setup a test where we focused (in a loop) one of the longer response time requests. The access logs show the log response time and the developers have monitoring via their own logs where they record response times for queries and other things but do not show the response times as being nearly as long as the access logs indicate.We connected up visualvm 1.3.7 remotely and using the sampler the only method response time above 2 seconds on average was the TaskQuery.take() which was over 100 seconds for some reason.We are using some version of 7.x for tomcat and also for the jdk. The tomcat config file is shown below. We are in the process of setting up visualvm on the unix server where Tomcat is running so we can use local mode for visualvm instead of remote. Any ideas/thoughts appreciated.-Tony Connector port=25500 secure=true compressableMimeType=text/html,text/xml noCompressionUserAgents=gozilla, traviata compression=on disableUploadTimeout=true connectionTimeout=2 acceptCount=100 redirectPort=8443 enableLookups=false minSpareThreads=25 maxThreads=512 maxHttpHeaderSize=8192/
Re: Rendering JSP files through Apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 4/9/15 10:52 AM, George Sexton wrote: On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind . - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJqOHAAoJEBzwKT+lPKRYL6cQAKELJ476ux4/+UM1KcLMSWtR hh1Ft/uiU9vS2dhTvLZuRNCdzBHNL61Xq599CfHmFgBiKke68bEej9mjWaa8QqLc lHi2uEzO8OtXvR0OO/6hTtF3H1bxGh0OFE51BZ7J6mBXzZxzxmpee8HKs5EfrPpR PnbETVAJzzBOpduW6/m4UKNflcna5Cm0CATQVHyrKAm1PX3/3s3o0jF82PITW8ad dRBSt3IxxhjiOjvB119CGAyx3OlxqRCpvDZXerjhKP7lFxKN1VpbaaR27CRnM+RX /OPMUI0Mj8dVjnYZSc92lFbVRykYJf7ItTMpVQEYYG992gGKWRRwhPXVxDyUpMzq r0W6rCs3NV20OjUTS3peYACdDNzp8Etk2TT3T9SfowXv+6DUbIyDrBD/sHXrHw3l NAaraRIQzsUjvRITYIdK2np4EBHsnwZBP7Do5YjJclYDq4QUsnjfLDD/Y3jfpNs8 +zVJa9lNaJktKPCzN5hy1mMc+cKLZd2Z+wa58+YkiCAr4uffBAqMZ8bOCoWdSqa5 bowJ1/XT4DI13Ji36AliiVJIUcEk2pYy58kqD1c/12asO5BgETI4BdGfT9AI3bBE qcJPkNH5VKb9G6+It2LJvGEpZhxCr2vZRVluTlUcymgFtNu5KZAhO4OAn4p5Ch78 LDSuJI5jc5NsbeMHFLMS =Fb2W -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 4/9/2015 12:58 PM, Caldarale, Charles R wrote: From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache My reading of it says that any request that matches a known context path must be routed to the web application. It seems pretty cut and dried to me. That's true only when the request is processed by the servlet container. If the request is handled elsewhere, clearly the servlet spec clause doesn't apply. The problem is then that as a system, the container isn't compliant. What you're in essence saying is that the compliance of the system isn't a concern. My belief is that as a system, the end result has to be compliant because my application is deployed on a system. If the system breaks the application, then it's not compliant. I suppose it's like eating an apple. At what point does the apple become you? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
On 4/9/2015 3:03 PM, George Sexton wrote: On 4/9/2015 10:06 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George, On 4/9/15 10:52 AM, George Sexton wrote: On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. ?? The servlet spec doesn't apply to environments, only containers. If the OP wants to have Apache httpd serve static files and proxy dynamic requests, that's perfectly reasonable. It's also easy to do. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. ? Why would a servlet have a problem handling a request for a .html file? The DefaultServlet was designed with that explicit purpose in mind What I'm saying is that having httpd handle request for .html and everything else handled by the servlet container violates section 4.1 of Java Servlet Specification 3.0. The issue is not the servlet handling the request for .html. The issue is that if the deployment descriptor has an explicit mapping for /context/foo.html, and the web app is never presented with the request because it's being done at the higher level of Apache httpd, then it breaks the web app. httpd is given the request for /context/foo.html, and there is no corresponding file, and the web app is broken. You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fedora 20 Yum and tomcat setup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Salam, On 4/8/15 5:24 PM, Salam Y. Elias wrote: I downloaded 8.0.21, created three directories, each one with its own Tomcat, chnaged some ports in server.xml and all 3 applications are running like a charm. If you have a complete Tomcat installation for each one, you should read RUNNING.txt under the Advanced section for how to use a single Tomcat installation to run multiple separate Tomcat instances. It will make upgrades (and downgrades) much easier for you. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVJnZCAAoJEBzwKT+lPKRY18gQAJQ/bOPosR9+1NfQhIcTzBXh JM5MZYNLivkzh/49VGH3tQh6l2nUoULbTIsNXLb8dJ4QujTu4TBfR4gFH9blFb3R Bsuvuvbk+KamxvLkOdskvRieq6u6Vtnj5jeeqMC7QGwML/w8CRgE1mqQCVmuzU08 bnu2K9kmaecLcegoBFU6pyuLidRvW7rZyA09c7IwOLy7sRTCtADxwQiuzzV6hfLl se81U6IGwyzIznpqTXvl1zaXHwPPxW7jS+ncz9BfdNhgJr5rtKJW8ocftBbxYTrM hPhhd1/S/zS5LCY4wRD/t7SbEKX+tr1UfsZNeLyrPQJvuIpYOcvdmrcz6/Qc5f05 iG1jtgilxWMhHTN0/EoO0YSzAu9/zXoWSLKu+aGe29WZOx+K2nlsapxtDw9E/j7/ coRafwoqNIKiWUPRcS4PVMaG7lHARpbJS2bVQPqM9XHG66cP0anab6bQFcOFtl7I VMDMYw08+qgAUMbtALuKuAHT+OHdjcRxx/cxeOl+qMJAoIGgHHijN80N06t6EU1x 87X3GHxFyRjnT/olMfnYGFT82E9Kn3g9XocgUSVhSuzqG3fnu9K9v4JIKF0PsaYu ZdTmGHGMUzATUE6D6U34MCuE822iR5XNONOxxGS0awzm72pUHMCJfecvemoDHC0W 9z7Ihuk8pb2coLZXDOFD =nser -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Rendering JSP files through Apache
On 09/04/2015 20:18, George Sexton wrote: On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. with my Servlet Expert Group member hat on You are misunderstanding the specification. The specification only applies to requests that reach the Servlet Container. (You can safely replace 'Web Server' above with 'Servlet Container' in the text you quote). If you want to be picky about it, even once you reach the Servlet container that quote is not 100% accurate. The container is required (by the HTTP spec that is referenced from the Servlet spec) to reject mal-formed requests with a 400 response before they are passed to a Web Application even if enough of the request is well-formed to determine the intended Web Application. As others have already stated: - The Servlet specification does not care if you put a reverse proxy in front of the Servlet Container. - The Servlet specification does not care if a reverse proxy routes requests that the Servlet Container could correctly handle elsewhere. Once you insert a reverse proxy (or a load-balancer, or a firewall, or...) you have a larger system and it is up to the designer of that system to ensure that the components of the system work together as desired. Yes, it is possible to break an application by inserting a reverse proxy but that is just a broken system, not an specification compliance issue. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat Thread Log
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mukund, On 4/8/15 11:33 PM, Mukundaraman Valakumaresan wrote: I have deployed an application in Apache tomcat 7.0.59. When I copy the war to webapps folder and start tomcat. Tomcat hangs and I coudln't see the admin screen as well for the first 30 minutes. Without this war, tomcat starts fine shows the admin screen immediately. Through google, I check a posts, which asked me to take a thread dump. I use Sprint, Hibernate and Mysql. From the thread dump, I could see that and could also see that the problem with the connectivity to MySQL. But I am not sure where exactly the problem lies and what needs to be fixed. Any help is appreciated!! Thanks http-bio-8080-exec-1 daemon prio=10 tid=0x7fa11400c800 nid=0xa49 runnable [0x7fa124c87000] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.jav a:113) at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNec essary(ReadAheadInputStream.java:160) at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.jav a:188) - - locked 0xbaadb0d0 (a com.mysql.jdbc.util.ReadAheadInputStrea m) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2428) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2882) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2871) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3414) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2536) - locked 0xcfa6a1f8 (a java.lang.Object) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2465) at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1383) - locked 0xcfa6a1f8 (a java.lang.Object) at com.mysql.jdbc.ConnectionImpl.buildCollationMapping(ConnectionImpl.jav a:823) at com.mysql.jdbc.ConnectionImpl.initializePropsFromServer(ConnectionImpl .java:3350) at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2045) - locked 0xcfa6a1f8 (a java.lang.Object) at com.mysql.jdbc.ConnectionImpl.init(ConnectionImpl.java:718) at com.mysql.jdbc.JDBC4Connection.init(JDBC4Connection.java:46) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructo rAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo nstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:406) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java: 282) at java.sql.DriverManager.getConnection(DriverManager.java:571) at java.sql.DriverManager.getConnection(DriverManager.java:187) at org.springframework.jdbc.datasource.DriverManagerDataSource.getConnect ionFromDriverManager(DriverManagerDataSource.java:173) at org.springframework.jdbc.datasource.DriverManagerDataSource.getConnect ionFromDriver(DriverManagerDataSource.java:164) at org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getC onnectionFromDriver(AbstractDriverBasedDataSource.java:153) at org.springframework.jdbc.datasource.AbstractDriverBasedDataSource.getC onnection(AbstractDriverBasedDataSource.java:119) at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionPro viderImpl.getConnection(DatasourceConnectionProviderImpl.java:139) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProvider JdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:279) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServ icesImpl.java:124) at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.confi gureService(StandardServiceRegistryImpl.java:111) at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeS ervice(AbstractServiceRegistryImpl.java:234) at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService( AbstractServiceRegistryImpl.java:206) at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.j ava:1885) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java :1843) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java :1928) at org.springframework.orm.hibernate4.LocalSessionFactoryBuilder.buildSes sionFactory(LocalSessionFactoryBuilder.java:252) at org.springframework.orm.hibernate4.LocalSessionFactoryBean.buildSessio nFactory(LocalSessionFactoryBean.java:377) at
Re: Rendering JSP files through Apache
On 4/8/2015 6:15 PM, Leggio, Andrew wrote: This contains both HTML and JSP. I would like the HTML to be handled through Apache and JSP pages to be handled by TOMCAT. How do I accomplish this? Just my two cents, but any server that works the way you want is not compliant with the servlet specification. It states that all requests for a context must be passed to the container. What you're suggesting is what GoDaddy does. The problem is that if you map requests for things like css, javascript, or even .html pages to a servlet, then it breaks. Bad idea. This is a Linux environment with Apache version 2.4.6 and Tomcat version 7. Thanks Andrew J. Leggio | MBIA Services Corporation | Assistant Vice President | Phone P (914) 765-3206 | Fax ( (914) 765-3095 | andrew.leg...@mbia.com -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, April 08, 2015 5:34 PM To: Tomcat Users List Subject: Re: Rendering JSP files through Apache Leggio, Andrew wrote: I have the following being used in my conf file: IfModule mod_proxy_ajp.so ProxyPass / ajp://localhost:8009/ /IfModule Does this actually direct jsp files to use Tomcat? That is a funny way of putting it. What the above does - if everything else is installed and configured correctly - is proxying *all* HTTP requests originally directed to Apache httpd (including requests for any JSP page), toward a Tomcat supposedly running on the same host, and supposedly listening on port 8009. Now whether this is actually what is happening or not, is anyone's guess so far. Chances are that this is not happening though, since otherwise you probably would not be asking what's wrong. The question is also : if you are going to proxy all requests from Apache httpd to Tomcat anyway, then why do you think that you need Apache httpd ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- This e-mail, including any attachments, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of any part of this e-mail is strictly prohibited; please contact the sender and permanently delete the original and any copies of it. -- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- George Sexton *MH Software, Inc.* Voice: 303 438 9585 http://www.mhsoftware.com
Re: Rendering JSP files through Apache
On 4/9/2015 3:18 PM, George Sexton wrote: On 4/9/2015 1:10 PM, David kerber wrote: You can argue about whether it's smart to map servlets into .html, but again my reading of the spec is that unequivocally, if the request path matches a deployed context, the request must be routed to the context/container. Then your reading is incorrect. The spec only applies to requests that reach the container in the first place. If something else handles it before it reaches the container, the spec is not applicable. Allow me to re-quote the spec: A ServletContext is rooted at a known path within a Web server. For example, a servlet context could be located at http://www.mycorp.com/catalog. All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. The spec explicitly includes the phrase known path within a web server and it explicitly also states All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext. I don't see any conditionals that would allow violation of this. Arguing otherwise is really not supported by the language. There is no violation of this if a request never reaches the container in the first place. The spec only applies to the servlet container itself, not to the overall system of which it might be a part. There are a lot of legitimate reasons to map static resources into servlets. Things like images, graphs, CSS files, Javascript files, etc. Certainly, and that's what I do. But it's for convenience and ease of configuration, not because it's what the spec requires. Other people have other needs... - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Rendering JSP files through Apache
From: George Sexton [mailto:geor...@mhsoftware.com] Subject: Re: Rendering JSP files through Apache The problem is then that as a system, the container isn't compliant. What you're in essence saying is that the compliance of the system isn't a concern. My belief is that as a system, the end result has to be compliant because my application is deployed on a system. If the system breaks the application, then it's not compliant. I think you're way, way off base. The servlet spec does not, in any way, attempt to define the semantics of a system; it is explicitly confined to the actions of a servlet container. If a system administrator chooses to deploy multiple components within a system, it's up to that admin, not the servlet spec, to decide which components are involved in any given flow. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Anonymous ldap search request after authentication blocked by acls
Hi,
I have setup Tomcat to authenticate users against openldap. I want
roles to be retrieved from the user record itself.
Realm className=org.apache.catalina.realm.JNDIRealm
connectionURL=ldap://127.0.0.1:389;
userPattern=uid={0},ou=users,dc=admin,dc=company,dc=com
userRoleName=ou
/
Authentication did not work initially because of an openldap acl I had in place.
access to *
by self write
by anonymous auth
by *
I checked the network trace in wireshark. The acl did not prevent the
bind to succeed. However, it blocked the anonymous search request
Tomcat performs after the bind.
...
2572015-04-09 09:59:51.614162127.0.0.1127.0.0.1LDAP
80bindResponse(11) success
2582015-04-09 09:59:51.614311127.0.0.1127.0.0.1LDAP
134searchRequest(12) ROOT baseObject
2592015-04-09 09:59:51.614416127.0.0.1127.0.0.1LDAP
116searchResEntry(12) ROOT
2602015-04-09 09:59:51.614436127.0.0.1127.0.0.1LDAP
80searchResDone(12) success [1 result]
What is the reason of this final search request? Should I change my
acl? Or is Tomcat wrong doing this last search request?
This is with Tomcat 7.0.53.
Thanks.
--
Philippe Anctil
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
