RE: Major Minor Version issue when using jersey 2.9 with tomcat7 + java8
Recompiling sources on jdk8 didnt resolve the error? -Original Message- From: "Seshumadhav Chaturvedula" Sent: 16-06-2014 12:15 PM To: "users@tomcat.apache.org" Subject: Major Minor Version issue when using jersey 2.9 with tomcat7 + java8 Resending previous email in plain text: We have a maven project to develop a jersey 2.0 REST service, on Eclipse (kepler) org.glassfish.jersey.containers jersey-container-servlet-core 2.9.1 In conjunction with: - java8 - tomcat7 When deploying the web application (using `$ mvn install && mvn -X tomcat7:redeploy`) we get the below exception: Caused by: java.lang.UnsupportedClassVersionError: org/glassfish/jersey/servlet/init/JerseyServletContainerInitializer : Unsupported major.minor version 51.0 (unable to load class org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2840) 1. I examined the MANIFEST file in the org.glassfish.jersey.containers jar, & (as suspected) it says built on 1.7 JDK 2. Tomcat logs confirm that it uses java8 itself We cannot move back to java8. Is there a way/hack we can get past this error? --- smc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat opening thousands of files
just noticed this, you tried running on tomcat 8, while we are running 7.0.53... Prashant On Mon, Jun 16, 2014 at 1:36 PM, Prashant Deva wrote: > our production instance (which we are running into issues with) has about > 2500 concurrent users. > > Prashant > > > On Mon, Jun 16, 2014 at 1:26 PM, Rossen Stoyanchev < > rstoyanc...@gopivotal.com> wrote: > >> On Mon, Jun 16, 2014 at 4:04 PM, Prashant Deva >> wrote: >> >> > Rossen, >> > Did you use an external queue? >> >> >> Yes I did have the sample configured to use RabbitMQ for broadcasting >> messages. That's running as a separate process though so it shouldn't >> change the output of "lsof". >> >> How many clients were connected at the same time? >> > >> >> In the sample, just one. I also ran a load test with 500 concurrent users >> (1 million messages) and the file descriptor count remains stable (around >> 500). >> >> I'd reverse the question, how many users do you have to run with to >> demonstrate the issue? >> >> Rossen >> > >
Re: Tomcat opening thousands of files
our production instance (which we are running into issues with) has about 2500 concurrent users. Prashant On Mon, Jun 16, 2014 at 1:26 PM, Rossen Stoyanchev < rstoyanc...@gopivotal.com> wrote: > On Mon, Jun 16, 2014 at 4:04 PM, Prashant Deva > wrote: > > > Rossen, > > Did you use an external queue? > > > Yes I did have the sample configured to use RabbitMQ for broadcasting > messages. That's running as a separate process though so it shouldn't > change the output of "lsof". > > How many clients were connected at the same time? > > > > In the sample, just one. I also ran a load test with 500 concurrent users > (1 million messages) and the file descriptor count remains stable (around > 500). > > I'd reverse the question, how many users do you have to run with to > demonstrate the issue? > > Rossen >
Re: Tomcat opening thousands of files
On Mon, Jun 16, 2014 at 4:04 PM, Prashant Deva wrote: > Rossen, > Did you use an external queue? Yes I did have the sample configured to use RabbitMQ for broadcasting messages. That's running as a separate process though so it shouldn't change the output of "lsof". How many clients were connected at the same time? > In the sample, just one. I also ran a load test with 500 concurrent users (1 million messages) and the file descriptor count remains stable (around 500). I'd reverse the question, how many users do you have to run with to demonstrate the issue? Rossen
Re: Tomcat opening thousands of files
Rossen, Did you use an external queue? How many clients were connected at the same time? Prashant On Mon, Jun 16, 2014 at 12:02 PM, Rossen Stoyanchev < rstoyanc...@gopivotal.com> wrote: > I gave this a quick try with the spring-websocket-portfolio sample [1] with > Tomcat 8. The output of the lsof command is just over 200 initially and > then goes up a little but not much (about 10). > > From the client-side I configured the SockJS client to use the WebSocket > transport (i.e. using Tomcat's WebSocket engine on the server side) first > and then tried the iframe-eventsource transport (SSE) which uses Tomcat's > Servlet 3 async request support to stream messages over HTTP. No > difference. > > Prashant you'll need to narrow it down a bit to see what is the key to > reproducing the issue. > > > Rossen > > > [1] https://github.com/rstoyanchev/spring-websocket-portfolio > > > On Mon, Jun 16, 2014 at 1:25 PM, Prashant Deva > wrote: > > > hmm, we are just using spring websockets to send messages. In fact there > is > > only two 'topics' in total, so there isnt much the application is doing > > quite frankly. > > do you think this is a spring issue? > > > > Prashant > > > > > > On Mon, Jun 16, 2014 at 10:10 AM, David kerber > > wrote: > > > > > On 6/16/2014 12:57 PM, Prashant Deva wrote: > > > > > >> I am using Tomcat 7.0.53 with Spring 4 websockets (spring's SockJS > > >> support). > > >> I notice that tomcat opens thousands of files. > > >> > > > > > > Correction: your application opens thousands of files, or leaves them > > > open when it should have closed them. > > > > > > > > > > > > > > > Just running for a few hours I noticed, it opened 16,552 files: > > >> > > >> root@dripcast:~# lsof -p 22691 | wc -l > > >> 16552 > > >> > > >> Our logs are full of this exception thrown tons of times every second: > > >> org.apache.tomcat.util.net.AprEndpoint$Acceptor run > > >> SEVERE: Socket accept failed > > >> org.apache.tomcat.jni.Error: 24: Too many open files > > >> at org.apache.tomcat.jni.Socket.accept(Native Method) > > >> at > > >> > > org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:992) > > >> at java.lang.Thread.run(Thread.java:745) > > >> > > >> > > >> Here is a sample of some of the open files, using lsof. > > >> What can we do to fix this? > > >> > > >> java2056 root *904u sock0,7 0t0 77846 can't > > >> identify protocol > > >> java2056 root *905u IPv6 76695 0t0TCP > > >> dripcast:https->pppoe.95-55-165-198.dynamic.avangarddsl.ru:1376 > > >> (ESTABLISHED) > > >> java2056 root *906u IPv6 74369 0t0TCP > > >> dripcast:https->fibre.backbonetechnology.com:46415 (ESTABLISHED) > > >> java2056 root *907u IPv6 76696 0t0TCP > > >> dripcast:https->outbound.kenshoo.com:14292 (ESTABLISHED) > > >> java2056 root *908u sock0,7 0t0 76697 can't > > >> identify protocol > > >> java2056 root *909u sock0,7 0t0 76698 can't > > >> identify protocol > > >> java2056 root *910u 0,90 7351 > > >> anon_inode > > >> java2056 root *911u 0,90 7351 > > >> anon_inode > > >> java2056 root *912u 0,90 7351 > > >> anon_inode > > >> java2056 root *913u 0,90 7351 > > >> anon_inode > > >> java2056 root *914u 0,90 7351 > > >> anon_inode > > >> java2056 root *915u sock0,7 0t0 76699 can't > > >> identify protocol > > >> java2056 root *916u sock0,7 0t0 76700 can't > > >> identify protocol > > >> java2056 root *917u sock0,7 0t0 76701 can't > > >> identify protocol > > >> java2056 root *918u sock0,7 0t0 76702 can't > > >> identify protocol > > >> java2056 root *919u sock0,7 0t0 77845 can't > > >> identify protocol > > >> java2056 root *920u sock0,7 0t0 76705 can't > > >> identify protocol > > >> java2056 root *921u IPv6 76906 0t0TCP > > >> dripcast:https->c-67-185-79-130.hsd1.wa.comcast.net:61280 > (ESTABLISHED) > > >> java2056 root *922u 0,90 7351 > > >> anon_inode > > >> java2056 root *923u sock0,7 0t0 77847 can't > > >> identify protocol > > >> java2056 root *924u sock0,7 0t0 75196 can't > > >> identify protocol > > >> java2056 root *925u sock0,7 0t0 76907 can't > > >> identify protocol > > >> java2056 root *926u IPv6 76908 0t0TCP > > >> dripcast:https->cdm-75-108-116-63-nixa.mid.suddenlink.net:56996 > > >> (ESTABLISHED) > > >> java2056 root *927u 0,90 7351 > > >> anon_inode > > >> java2056 root *928u IPv6
Re: Decoded URL set on asynchronous request
2014-06-16 22:38 GMT+04:00 Jimmy Royer : > On Sun, Jun 15, 2014 at 8:01 AM, Konstantin Kolinko > wrote: >> 2014-06-09 17:38 GMT+04:00 Konstantin Kolinko : >>> >>> (...) >>> >>> Servlet API javadocs: >>> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html >>> >>> It does not mention explicitly whether getRequestURL() returns a >>> non-decoded or decoded URL, >>> >>> but as our implementation in o.a.c.connector.Request does >>> "url.append(getRequestURI());" I would say that it is expected to >>> return a non-decoded String. >>> >> >> To correct myself here, several notes >> >> 1. getRequestURI() returns just what was sent by the client. >> It is just raw bytes. There is no saying that it is url-encoded. >> It is just that clients do url-encode it to pass it on the wire. >> >> 2. In case of RequestDispatcher.forward(..) the javadoc >> for getRequestURL() says that it "must reflect the path used to obtain >> the RequestDispatcher". >> >> The "history" section of Servlet 3.1 spec (section A.7.3 page 225/240) >> mentions when that method was clarified by adding that requirement. >> >> There is no such requirement for getRequestURI() method. Should its >> value be updated on forwards? The implementation in Tomcat does update >> requestURI on forwards. >> >> 3. If getRequestURL() has to perform an url-encoding of forwarded >> path, it should be noted that url-encoding procedure yields different >> results depending on the character encoding used to convert chars to >> their byte codes. >> >> The usual convention nowadays is to use UTF-8, though I would say >> that it would be more correct to ask the Connector for its URIEncoding >> setting. >> (So that when browser follows a redirect and sends its next request, >> the URL has to be correctly parsed by the Connector. I mean that >> getRequestURL() method is documented as "for creating redirect >> messages".) >> >> In the OP case the trouble was with space characters (%20). > > Just to make it clear and validate my understanding: the space encoding > is part of the URI encoding specification and not related to UTF-8 or other > character encodings. The percentage encoding is a way to escape characters > in the URI. The space characters encoding such as %20 could itself be > encoded in UTF-8 or ASCII. Does that sound right? Yes, that sounds right. BTW, the java.net.URI class in Java 7 is documented to follow RFC 2396 specification. The current specification on URI syntax is RFC 3986. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat opening thousands of files
I gave this a quick try with the spring-websocket-portfolio sample [1] with Tomcat 8. The output of the lsof command is just over 200 initially and then goes up a little but not much (about 10). >From the client-side I configured the SockJS client to use the WebSocket transport (i.e. using Tomcat's WebSocket engine on the server side) first and then tried the iframe-eventsource transport (SSE) which uses Tomcat's Servlet 3 async request support to stream messages over HTTP. No difference. Prashant you'll need to narrow it down a bit to see what is the key to reproducing the issue. Rossen [1] https://github.com/rstoyanchev/spring-websocket-portfolio On Mon, Jun 16, 2014 at 1:25 PM, Prashant Deva wrote: > hmm, we are just using spring websockets to send messages. In fact there is > only two 'topics' in total, so there isnt much the application is doing > quite frankly. > do you think this is a spring issue? > > Prashant > > > On Mon, Jun 16, 2014 at 10:10 AM, David kerber > wrote: > > > On 6/16/2014 12:57 PM, Prashant Deva wrote: > > > >> I am using Tomcat 7.0.53 with Spring 4 websockets (spring's SockJS > >> support). > >> I notice that tomcat opens thousands of files. > >> > > > > Correction: your application opens thousands of files, or leaves them > > open when it should have closed them. > > > > > > > > > > Just running for a few hours I noticed, it opened 16,552 files: > >> > >> root@dripcast:~# lsof -p 22691 | wc -l > >> 16552 > >> > >> Our logs are full of this exception thrown tons of times every second: > >> org.apache.tomcat.util.net.AprEndpoint$Acceptor run > >> SEVERE: Socket accept failed > >> org.apache.tomcat.jni.Error: 24: Too many open files > >> at org.apache.tomcat.jni.Socket.accept(Native Method) > >> at > >> > org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:992) > >> at java.lang.Thread.run(Thread.java:745) > >> > >> > >> Here is a sample of some of the open files, using lsof. > >> What can we do to fix this? > >> > >> java2056 root *904u sock0,7 0t0 77846 can't > >> identify protocol > >> java2056 root *905u IPv6 76695 0t0TCP > >> dripcast:https->pppoe.95-55-165-198.dynamic.avangarddsl.ru:1376 > >> (ESTABLISHED) > >> java2056 root *906u IPv6 74369 0t0TCP > >> dripcast:https->fibre.backbonetechnology.com:46415 (ESTABLISHED) > >> java2056 root *907u IPv6 76696 0t0TCP > >> dripcast:https->outbound.kenshoo.com:14292 (ESTABLISHED) > >> java2056 root *908u sock0,7 0t0 76697 can't > >> identify protocol > >> java2056 root *909u sock0,7 0t0 76698 can't > >> identify protocol > >> java2056 root *910u 0,90 7351 > >> anon_inode > >> java2056 root *911u 0,90 7351 > >> anon_inode > >> java2056 root *912u 0,90 7351 > >> anon_inode > >> java2056 root *913u 0,90 7351 > >> anon_inode > >> java2056 root *914u 0,90 7351 > >> anon_inode > >> java2056 root *915u sock0,7 0t0 76699 can't > >> identify protocol > >> java2056 root *916u sock0,7 0t0 76700 can't > >> identify protocol > >> java2056 root *917u sock0,7 0t0 76701 can't > >> identify protocol > >> java2056 root *918u sock0,7 0t0 76702 can't > >> identify protocol > >> java2056 root *919u sock0,7 0t0 77845 can't > >> identify protocol > >> java2056 root *920u sock0,7 0t0 76705 can't > >> identify protocol > >> java2056 root *921u IPv6 76906 0t0TCP > >> dripcast:https->c-67-185-79-130.hsd1.wa.comcast.net:61280 (ESTABLISHED) > >> java2056 root *922u 0,90 7351 > >> anon_inode > >> java2056 root *923u sock0,7 0t0 77847 can't > >> identify protocol > >> java2056 root *924u sock0,7 0t0 75196 can't > >> identify protocol > >> java2056 root *925u sock0,7 0t0 76907 can't > >> identify protocol > >> java2056 root *926u IPv6 76908 0t0TCP > >> dripcast:https->cdm-75-108-116-63-nixa.mid.suddenlink.net:56996 > >> (ESTABLISHED) > >> java2056 root *927u 0,90 7351 > >> anon_inode > >> java2056 root *928u IPv6 76909 0t0TCP > >> dripcast:https->fibre.backbonetechnology.com:46416 (ESTABLISHED) > >> java2056 root *929u sock0,7 0t0 76910 can't > >> identify protocol > >> java2056 root *930u sock0,7 0t0 76911 can't > >> identify protocol > >> java2056 root *931u IPv6 76912 0t0TCP > >> dripcast:https->outbound.kenshoo.com:1430
Re: Decoded URL set on asynchronous request
On Sun, Jun 15, 2014 at 8:01 AM, Konstantin Kolinko wrote: > 2014-06-09 17:38 GMT+04:00 Konstantin Kolinko : >> >> (...) >> >> Servlet API javadocs: >> http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html >> >> It does not mention explicitly whether getRequestURL() returns a >> non-decoded or decoded URL, >> >> but as our implementation in o.a.c.connector.Request does >> "url.append(getRequestURI());" I would say that it is expected to >> return a non-decoded String. >> > > To correct myself here, several notes > > 1. getRequestURI() returns just what was sent by the client. > It is just raw bytes. There is no saying that it is url-encoded. > It is just that clients do url-encode it to pass it on the wire. > > 2. In case of RequestDispatcher.forward(..) the javadoc > for getRequestURL() says that it "must reflect the path used to obtain > the RequestDispatcher". > > The "history" section of Servlet 3.1 spec (section A.7.3 page 225/240) > mentions when that method was clarified by adding that requirement. > > There is no such requirement for getRequestURI() method. Should its > value be updated on forwards? The implementation in Tomcat does update > requestURI on forwards. > > 3. If getRequestURL() has to perform an url-encoding of forwarded > path, it should be noted that url-encoding procedure yields different > results depending on the character encoding used to convert chars to > their byte codes. > > The usual convention nowadays is to use UTF-8, though I would say > that it would be more correct to ask the Connector for its URIEncoding > setting. > (So that when browser follows a redirect and sends its next request, > the URL has to be correctly parsed by the Connector. I mean that > getRequestURL() method is documented as "for creating redirect > messages".) > > In the OP case the trouble was with space characters (%20). Just to make it clear and validate my understanding: the space encoding is part of the URI encoding specification and not related to UTF-8 or other character encodings. The percentage encoding is a way to escape characters in the URI. The space characters encoding such as %20 could itself be encoded in UTF-8 or ASCII. Does that sound right? Regards, Jimmy Royer >> >> On the other hand I think ServletContext.getRequestDispatcher() >> expects a decoded URI, as it expects a "resource path", not a >> %-encoded URI. >> >> I think it is OK to file an issue into Bugzilla. >> > Best regards, > Konstantin Kolinko > > - > 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: Remote Tomcat webapps bidirectional communication
Hello André, Thank you for your detailed answer, your accurate terminology and the links you sent me. About the scenario I described in my first message: I could make it work. > [André Warnier wrote:] > And note that when one of your servlets issues a HTTP request to another server, Tomcat knows absolutely nothing about it, and there is no Tomcat code involved (on the request-sending side). Ah? Ok. "What" is actually taking care of the HTTP request then? > [André Warnier wrote:] > [...] for creating and sending a HTTP POST request [...] > [...] to create a stand-alone java network server, which just listens for this particular kind of request, and responds by the information that you describe [...] I actually have another scenario in which a C++ executable has to send a HTTP request to a Tomcat Webapp. I would need to build the HTTP request inside the C++ code and then send it to the Tomcat Webapp. I haven't yet looked for a solution... Again thank you and best regards. -- Léa On 2014-06-16 5:51 PM, André Warnier wrote: Lmhelp1 wrote: Hello, My question is about what code to write to allow two remote Tomcat webapps to communicate with one another through the Internet. Let me explain more precisely what I would like to do. (I'm just simplifying a bit the real situation). - I have a Tomcat webapp running on a server in England. - I have another Tomcat webapp running on a server in France. - I have a JSP inside the England webapp. - This JSP contains a form with two fields "First name" and "Last name". - I would like to send these information to the France webapp. - After the England form has been submitted, I can collect the information "First name" and "Last name" in a servlet. Can you tell me what I shall do then to send these information to the France webapp? Is it something like a "response.sendRedirect(..."? How does it have to be written? - Meantime, the France webapp needs to be able to wait for these information and, when they arrive, to get them and do something with them. For example store the "First name" and "Last name" in a database, etc. What kind of a code has to be written in the France webapp? Is it a servlet with a "doGet()" retrieving the information "First name" and "Last name"? - Moreover, when the France webapp has finished it's job, it needs to tell the England webapp that it has finished, send it a file and some information. So the communication has to be bidirectional. Can you please give me some indications on how to start dealing with this? Or maybe a tutorial or an example? This is only vaguely a Tomcat question, in the sense that : - for receiving and processing a HTTP POST request (from a browser usually, but in your case it would be a Tomcat servlet or a program running somewhere else), a normal webapp is what you need. - for creating and sending a HTTP POST request, you will need a library that offers such functions, such as the HTTPClient library, found here : http://projects.apache.org/projects/httpcomponents_client.html There is documentation and examples available at : http://hc.apache.org/index.html. Make sure you read them. Note that any java program could use this, there is nothing special about using it within a java servlet. And note that when one of your servlets issues a HTTP request to another server, Tomcat knows absolutely nothing about it, and there is no Tomcat code involved (on the request-sending side). Note also that for what you describe as the "France webapp" above, that functionality does not necessarily need a Tomcat and a Tomcat webapp. You could use the code of http://projects.apache.org/projects/httpcomponents_core.html to create a stand-alone java network server, which just listens for this particular kind of request, and responds by the information that you describe. Similarly, your "England webapp" does not necessarily need to send the request to the France server as a HTTP request, nor expect a HTTP response. What I believe would be the trickiest part in that kind of application, is to handle the various error scenarios : network down between England and France, French server down, French server taking a (too) long time to respond, French server returning an error, etc.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat opening thousands of files
hmm, we are just using spring websockets to send messages. In fact there is only two 'topics' in total, so there isnt much the application is doing quite frankly. do you think this is a spring issue? Prashant On Mon, Jun 16, 2014 at 10:10 AM, David kerber wrote: > On 6/16/2014 12:57 PM, Prashant Deva wrote: > >> I am using Tomcat 7.0.53 with Spring 4 websockets (spring's SockJS >> support). >> I notice that tomcat opens thousands of files. >> > > Correction: your application opens thousands of files, or leaves them > open when it should have closed them. > > > > > Just running for a few hours I noticed, it opened 16,552 files: >> >> root@dripcast:~# lsof -p 22691 | wc -l >> 16552 >> >> Our logs are full of this exception thrown tons of times every second: >> org.apache.tomcat.util.net.AprEndpoint$Acceptor run >> SEVERE: Socket accept failed >> org.apache.tomcat.jni.Error: 24: Too many open files >> at org.apache.tomcat.jni.Socket.accept(Native Method) >> at >> org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:992) >> at java.lang.Thread.run(Thread.java:745) >> >> >> Here is a sample of some of the open files, using lsof. >> What can we do to fix this? >> >> java2056 root *904u sock0,7 0t0 77846 can't >> identify protocol >> java2056 root *905u IPv6 76695 0t0TCP >> dripcast:https->pppoe.95-55-165-198.dynamic.avangarddsl.ru:1376 >> (ESTABLISHED) >> java2056 root *906u IPv6 74369 0t0TCP >> dripcast:https->fibre.backbonetechnology.com:46415 (ESTABLISHED) >> java2056 root *907u IPv6 76696 0t0TCP >> dripcast:https->outbound.kenshoo.com:14292 (ESTABLISHED) >> java2056 root *908u sock0,7 0t0 76697 can't >> identify protocol >> java2056 root *909u sock0,7 0t0 76698 can't >> identify protocol >> java2056 root *910u 0,90 7351 >> anon_inode >> java2056 root *911u 0,90 7351 >> anon_inode >> java2056 root *912u 0,90 7351 >> anon_inode >> java2056 root *913u 0,90 7351 >> anon_inode >> java2056 root *914u 0,90 7351 >> anon_inode >> java2056 root *915u sock0,7 0t0 76699 can't >> identify protocol >> java2056 root *916u sock0,7 0t0 76700 can't >> identify protocol >> java2056 root *917u sock0,7 0t0 76701 can't >> identify protocol >> java2056 root *918u sock0,7 0t0 76702 can't >> identify protocol >> java2056 root *919u sock0,7 0t0 77845 can't >> identify protocol >> java2056 root *920u sock0,7 0t0 76705 can't >> identify protocol >> java2056 root *921u IPv6 76906 0t0TCP >> dripcast:https->c-67-185-79-130.hsd1.wa.comcast.net:61280 (ESTABLISHED) >> java2056 root *922u 0,90 7351 >> anon_inode >> java2056 root *923u sock0,7 0t0 77847 can't >> identify protocol >> java2056 root *924u sock0,7 0t0 75196 can't >> identify protocol >> java2056 root *925u sock0,7 0t0 76907 can't >> identify protocol >> java2056 root *926u IPv6 76908 0t0TCP >> dripcast:https->cdm-75-108-116-63-nixa.mid.suddenlink.net:56996 >> (ESTABLISHED) >> java2056 root *927u 0,90 7351 >> anon_inode >> java2056 root *928u IPv6 76909 0t0TCP >> dripcast:https->fibre.backbonetechnology.com:46416 (ESTABLISHED) >> java2056 root *929u sock0,7 0t0 76910 can't >> identify protocol >> java2056 root *930u sock0,7 0t0 76911 can't >> identify protocol >> java2056 root *931u IPv6 76912 0t0TCP >> dripcast:https->outbound.kenshoo.com:14309 (ESTABLISHED) >> java2056 root *932u 0,90 7351 >> anon_inode >> java2056 root *933u 0,90 7351 >> anon_inode >> java2056 root *934u 0,90 7351 >> anon_inode >> java2056 root *935u 0,90 7351 >> anon_inode >> java2056 root *936u 0,90 7351 >> anon_inode >> java2056 root *937u sock0,7 0t0 73405 can't >> identify protocol >> java2056 root *938u sock0,7 0t0 73406 can't >> identify protocol >> java2056 root *939u sock0,7 0t0 73407 can't >> identify protocol >> java2056 root *940u sock0,7 0t0 71475 can't >> identify protocol >> java2056 root *941u sock0,7 0t0 74371 can't >> identify protocol >> java2056 ro
Re: Tomcat opening thousands of files
On 6/16/2014 12:57 PM, Prashant Deva wrote: I am using Tomcat 7.0.53 with Spring 4 websockets (spring's SockJS support). I notice that tomcat opens thousands of files. Correction: your application opens thousands of files, or leaves them open when it should have closed them. Just running for a few hours I noticed, it opened 16,552 files: root@dripcast:~# lsof -p 22691 | wc -l 16552 Our logs are full of this exception thrown tons of times every second: org.apache.tomcat.util.net.AprEndpoint$Acceptor run SEVERE: Socket accept failed org.apache.tomcat.jni.Error: 24: Too many open files at org.apache.tomcat.jni.Socket.accept(Native Method) at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:992) at java.lang.Thread.run(Thread.java:745) Here is a sample of some of the open files, using lsof. What can we do to fix this? java2056 root *904u sock0,7 0t0 77846 can't identify protocol java2056 root *905u IPv6 76695 0t0TCP dripcast:https->pppoe.95-55-165-198.dynamic.avangarddsl.ru:1376 (ESTABLISHED) java2056 root *906u IPv6 74369 0t0TCP dripcast:https->fibre.backbonetechnology.com:46415 (ESTABLISHED) java2056 root *907u IPv6 76696 0t0TCP dripcast:https->outbound.kenshoo.com:14292 (ESTABLISHED) java2056 root *908u sock0,7 0t0 76697 can't identify protocol java2056 root *909u sock0,7 0t0 76698 can't identify protocol java2056 root *910u 0,90 7351 anon_inode java2056 root *911u 0,90 7351 anon_inode java2056 root *912u 0,90 7351 anon_inode java2056 root *913u 0,90 7351 anon_inode java2056 root *914u 0,90 7351 anon_inode java2056 root *915u sock0,7 0t0 76699 can't identify protocol java2056 root *916u sock0,7 0t0 76700 can't identify protocol java2056 root *917u sock0,7 0t0 76701 can't identify protocol java2056 root *918u sock0,7 0t0 76702 can't identify protocol java2056 root *919u sock0,7 0t0 77845 can't identify protocol java2056 root *920u sock0,7 0t0 76705 can't identify protocol java2056 root *921u IPv6 76906 0t0TCP dripcast:https->c-67-185-79-130.hsd1.wa.comcast.net:61280 (ESTABLISHED) java2056 root *922u 0,90 7351 anon_inode java2056 root *923u sock0,7 0t0 77847 can't identify protocol java2056 root *924u sock0,7 0t0 75196 can't identify protocol java2056 root *925u sock0,7 0t0 76907 can't identify protocol java2056 root *926u IPv6 76908 0t0TCP dripcast:https->cdm-75-108-116-63-nixa.mid.suddenlink.net:56996 (ESTABLISHED) java2056 root *927u 0,90 7351 anon_inode java2056 root *928u IPv6 76909 0t0TCP dripcast:https->fibre.backbonetechnology.com:46416 (ESTABLISHED) java2056 root *929u sock0,7 0t0 76910 can't identify protocol java2056 root *930u sock0,7 0t0 76911 can't identify protocol java2056 root *931u IPv6 76912 0t0TCP dripcast:https->outbound.kenshoo.com:14309 (ESTABLISHED) java2056 root *932u 0,90 7351 anon_inode java2056 root *933u 0,90 7351 anon_inode java2056 root *934u 0,90 7351 anon_inode java2056 root *935u 0,90 7351 anon_inode java2056 root *936u 0,90 7351 anon_inode java2056 root *937u sock0,7 0t0 73405 can't identify protocol java2056 root *938u sock0,7 0t0 73406 can't identify protocol java2056 root *939u sock0,7 0t0 73407 can't identify protocol java2056 root *940u sock0,7 0t0 71475 can't identify protocol java2056 root *941u sock0,7 0t0 74371 can't identify protocol java2056 root *942u 0,90 7351 anon_inode java2056 root *943u sock0,7 0t0 74372 can't identify protocol java2056 root *944u sock0,7 0t0 74373 can't identify protocol java2056 root *945u sock0,7 0t0 74378 can't identify protocol java2056 root *946u 0,90 7351 anon_inode java2056 root *947u sock0,7 0t0 71476 can't identify protocol java2056 root *948u sock0,7 0t0 74379 can't identify p
Tomcat opening thousands of files
I am using Tomcat 7.0.53 with Spring 4 websockets (spring's SockJS support). I notice that tomcat opens thousands of files. Just running for a few hours I noticed, it opened 16,552 files: root@dripcast:~# lsof -p 22691 | wc -l 16552 Our logs are full of this exception thrown tons of times every second: org.apache.tomcat.util.net.AprEndpoint$Acceptor run SEVERE: Socket accept failed org.apache.tomcat.jni.Error: 24: Too many open files at org.apache.tomcat.jni.Socket.accept(Native Method) at org.apache.tomcat.util.net.AprEndpoint$Acceptor.run(AprEndpoint.java:992) at java.lang.Thread.run(Thread.java:745) Here is a sample of some of the open files, using lsof. What can we do to fix this? java2056 root *904u sock0,7 0t0 77846 can't identify protocol java2056 root *905u IPv6 76695 0t0TCP dripcast:https->pppoe.95-55-165-198.dynamic.avangarddsl.ru:1376 (ESTABLISHED) java2056 root *906u IPv6 74369 0t0TCP dripcast:https->fibre.backbonetechnology.com:46415 (ESTABLISHED) java2056 root *907u IPv6 76696 0t0TCP dripcast:https->outbound.kenshoo.com:14292 (ESTABLISHED) java2056 root *908u sock0,7 0t0 76697 can't identify protocol java2056 root *909u sock0,7 0t0 76698 can't identify protocol java2056 root *910u 0,90 7351 anon_inode java2056 root *911u 0,90 7351 anon_inode java2056 root *912u 0,90 7351 anon_inode java2056 root *913u 0,90 7351 anon_inode java2056 root *914u 0,90 7351 anon_inode java2056 root *915u sock0,7 0t0 76699 can't identify protocol java2056 root *916u sock0,7 0t0 76700 can't identify protocol java2056 root *917u sock0,7 0t0 76701 can't identify protocol java2056 root *918u sock0,7 0t0 76702 can't identify protocol java2056 root *919u sock0,7 0t0 77845 can't identify protocol java2056 root *920u sock0,7 0t0 76705 can't identify protocol java2056 root *921u IPv6 76906 0t0TCP dripcast:https->c-67-185-79-130.hsd1.wa.comcast.net:61280 (ESTABLISHED) java2056 root *922u 0,90 7351 anon_inode java2056 root *923u sock0,7 0t0 77847 can't identify protocol java2056 root *924u sock0,7 0t0 75196 can't identify protocol java2056 root *925u sock0,7 0t0 76907 can't identify protocol java2056 root *926u IPv6 76908 0t0TCP dripcast:https->cdm-75-108-116-63-nixa.mid.suddenlink.net:56996 (ESTABLISHED) java2056 root *927u 0,90 7351 anon_inode java2056 root *928u IPv6 76909 0t0TCP dripcast:https->fibre.backbonetechnology.com:46416 (ESTABLISHED) java2056 root *929u sock0,7 0t0 76910 can't identify protocol java2056 root *930u sock0,7 0t0 76911 can't identify protocol java2056 root *931u IPv6 76912 0t0TCP dripcast:https->outbound.kenshoo.com:14309 (ESTABLISHED) java2056 root *932u 0,90 7351 anon_inode java2056 root *933u 0,90 7351 anon_inode java2056 root *934u 0,90 7351 anon_inode java2056 root *935u 0,90 7351 anon_inode java2056 root *936u 0,90 7351 anon_inode java2056 root *937u sock0,7 0t0 73405 can't identify protocol java2056 root *938u sock0,7 0t0 73406 can't identify protocol java2056 root *939u sock0,7 0t0 73407 can't identify protocol java2056 root *940u sock0,7 0t0 71475 can't identify protocol java2056 root *941u sock0,7 0t0 74371 can't identify protocol java2056 root *942u 0,90 7351 anon_inode java2056 root *943u sock0,7 0t0 74372 can't identify protocol java2056 root *944u sock0,7 0t0 74373 can't identify protocol java2056 root *945u sock0,7 0t0 74378 can't identify protocol java2056 root *946u 0,90 7351 anon_inode java2056 root *947u sock0,7 0t0 71476 can't identify protocol java2056 root *948u sock0,7 0t0 74379 can't identify protocol java2056 root *949u sock0,7 0t0 76929 can't identify protocol java2056 root *950u 0,90 7351 anon
AW: Choosing provider to load pkcs12 keystore for ssl
Hi
Okay, I must have overlooked the "keystoreProvider" attribute completely.
Sorry for that and thanks a lot for the hint.
However that only solved the loading part of the problem.
The certificate is still unusable.
When I try to connect, the browser reports an error.
I set javax.net.debug=all and got the output below.
I notice, that the server and the client cannot agree on the ciphersuite (fatal
error: 40: no cipher suites in common) but I am lost
on what I would need to configure.
I did remove all settings of sslProtocol, sslProtocols and ciphers, as I think
my old defaults will not match a ECC certificate, but
still it does not work.
Any further hint?
Best regards,
Steffen
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for
SSLv2Hello
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for
SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for
SSLv3
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for
SSLv3
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for
SSLv3
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for
TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for
TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for
TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for
TLSv1.1
[Raw read]: length = 5
: 16 03 01 00 99 .
[Raw read]: length = 153
: 01 00 00 95 03 03 34 CF F9 BC B4 23 4E F7 B2 EA ..4#N...
0010: 0A F9 2B C1 24 8C 87 9F E6 C6 94 C8 BC 42 5E 68 ..+.$B^h
0020: 35 5F B3 58 4C 59 00 00 2E C0 2B C0 2F C0 0A C0 5_.XLY+./...
0030: 09 C0 13 C0 14 C0 12 C0 07 C0 11 00 33 00 32 00 3.2.
0040: 45 00 39 00 38 00 88 00 16 00 2F 00 41 00 35 00 E.9.8./.A.5.
0050: 84 00 0A 00 05 00 04 01 00 00 3E FF 01 00 01 00 ..>.
0060: 00 0A 00 08 00 06 00 17 00 18 00 19 00 0B 00 02
0070: 01 00 00 23 00 00 33 74 00 00 00 05 00 05 01 00 ...#..3t
0080: 00 00 00 00 0D 00 12 00 10 04 01 05 01 02 01 04
0090: 03 05 03 02 03 04 02 02 02 .
osiris4-exec-1, READ: TLSv1 Handshake, length = 153
*** ClientHello, TLSv1.2
RandomCookie: GMT: 869202108 bytes = { 180, 35, 78, 247, 178, 234, 10, 249,
43, 193, 36, 140, 135, 159, 230, 198, 148, 200, 188, 66,
94, 104, 53, 95, 179, 88, 76, 89 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA,
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
Lars Engholm Johansen wrote: Our company are running several Tomcat 7.0.52 high volume Ubuntu 12.04 production servers. We are using Tomcat WebSockets (JSR356 implementation) heavily with 100M text messages (100GiB) per day. We monitor webserver health by measuring several key parameters every minute, including tomcat connection count using: mBeanServer.getAttribute(threadPool, "connectionCount"); // threadPool is MBean of "type=ThreadPool" __The problem__ Our sites can run for days without problems, but once in a while the tomcat connection count suddenly starts growing abnormally fast. See this graph: http://imgur.com/s4fOUte netstat shows these TCP connections to be mostly in CLOSE_WAIT state. And if at that moment, you force the JVM that runs Tomcat to do a Garbage Collection, do you still have these numerous connections in CLOSE_WAIT state after the GC completed ? Our sites still functions normally with no cpu spikes during this build up until around 60,000 connections, but then the server refuses further connections and a manual Tomcat restart is required. We have no output in tomcat or our logs at the time when this event occurs. The only sign is when comparing full java thread dump with a dump from a newly launched Tomcat: One of http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 is missing/has died. We have observed this problem at least since Tomcat 7.0.48 and can not find indications in Tomcat 7.0.x change logs that it should have been fixed in newer releases. Any help or advises are appreciated, Best regards, Lars Engholm Johansen Our connector configuration: - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Remote Tomcat webapps bidirectional communication
Lmhelp1 wrote: Hello, My question is about what code to write to allow two remote Tomcat webapps to communicate with one another through the Internet. Let me explain more precisely what I would like to do. (I'm just simplifying a bit the real situation). - I have a Tomcat webapp running on a server in England. - I have another Tomcat webapp running on a server in France. - I have a JSP inside the England webapp. - This JSP contains a form with two fields "First name" and "Last name". - I would like to send these information to the France webapp. - After the England form has been submitted, I can collect the information "First name" and "Last name" in a servlet. Can you tell me what I shall do then to send these information to the France webapp? Is it something like a "response.sendRedirect(..."? How does it have to be written? - Meantime, the France webapp needs to be able to wait for these information and, when they arrive, to get them and do something with them. For example store the "First name" and "Last name" in a database, etc. What kind of a code has to be written in the France webapp? Is it a servlet with a "doGet()" retrieving the information "First name" and "Last name"? - Moreover, when the France webapp has finished it's job, it needs to tell the England webapp that it has finished, send it a file and some information. So the communication has to be bidirectional. Can you please give me some indications on how to start dealing with this? Or maybe a tutorial or an example? This is only vaguely a Tomcat question, in the sense that : - for receiving and processing a HTTP POST request (from a browser usually, but in your case it would be a Tomcat servlet or a program running somewhere else), a normal webapp is what you need. - for creating and sending a HTTP POST request, you will need a library that offers such functions, such as the HTTPClient library, found here : http://projects.apache.org/projects/httpcomponents_client.html There is documentation and examples available at : http://hc.apache.org/index.html. Make sure you read them. Note that any java program could use this, there is nothing special about using it within a java servlet. And note that when one of your servlets issues a HTTP request to another server, Tomcat knows absolutely nothing about it, and there is no Tomcat code involved (on the request-sending side). Note also that for what you describe as the "France webapp" above, that functionality does not necessarily need a Tomcat and a Tomcat webapp. You could use the code of http://projects.apache.org/projects/httpcomponents_core.html to create a stand-alone java network server, which just listens for this particular kind of request, and responds by the information that you describe. Similarly, your "England webapp" does not necessarily need to send the request to the France server as a HTTP request, nor expect a HTTP response. What I believe would be the trickiest part in that kind of application, is to handle the various error scenarios : network down between England and France, French server down, French server taking a (too) long time to respond, French server returning an error, etc.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Problems with excessive connection timeouts
Hi,
my environment is:
OS SuSE SLES11/SP2 64-bit
HTTP frontend: Apache2-2.2.21 (64-bit)
mod_jk: 1.2.37
Problem short: excessive connection timeouts with weird socket ids
Problem long: we frontend 4 Tomcats (7.0.42) using Apache2(2.2.21) and
mod_jk(1.2.37). We are seeing a heavy amount of connection timeouts when
the tomcats are loaded. Surprisingly the logs show socket id "-1", which
should not happen in my opinion, because most actions are guarded by the
IS_VALID_SOCKET macro. Here is one example. The code emmitting the line
should not be reached due to the check in line 1543:
[Mon Jun 16 17:12:05.405 2014] [7233:140275337774848] [info]
ajp_send_request::jk_ajp_common.c (1562): (lpsdm83-1) failed sending
request, socket -1 prepost cping/cpong failure (errno=110)
1543:while (IS_VALID_SOCKET(ae->sd)) {
int err = JK_FALSE;
if (jk_is_socket_connected(ae->sd, l) == JK_FALSE) {
ae->last_errno = errno;
jk_log(l, JK_LOG_DEBUG,
"(%s) failed sending request, "
"socket %d is not connected any more (errno=%d)",
ae->worker->name, ae->sd, ae->last_errno);
ajp_abort_endpoint(ae, JK_FALSE, l);
err = JK_TRUE;
err_conn++;
}
if (ae->worker->prepost_timeout > 0 && !err) {
/* handle cping/cpong if prepost_timeout is set
* If the socket is disconnected no need to handle
* the cping/cpong
*/
if (ajp_handle_cping_cpong(ae,
ae->worker->prepost_timeout, l) == JK_FALSE) {
1562:jk_log(l, JK_LOG_INFO,
"(%s) failed sending request, "
"socket %d prepost cping/cpong failure (errno=%d)",
ae->worker->name, ae->sd, ae->last_errno);
/* XXX: Is there any reason to try other
* connections to the node if one of them fails
* the cping/cpong heartbeat?
* Tomcat can be either too busy or simply dead, so
* there is a chance that all other connections would
* fail as well.
*/
err = JK_TRUE;
err_cping++;
}
}
So, before trying to tell me that I am missing workers.properties and
complete logs, I want to check first whether the "-1" socket ids are to be
expected here or whether there is some kind of bug involved.
Thanks in advance
Martin
--
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
Re: Why is my Tomcat connection getting terminated/closed?!!
On Wed, May 21, 2014 at 5:20 PM, Daniel Mikusa wrote: > On May 21, 2014, at 7:28 AM, Aniket Bhoi wrote: > > > On Tue, May 20, 2014 at 5:28 PM, Daniel Mikusa >wrote: > > > >> On May 20, 2014, at 7:47 AM, Aniket Bhoi wrote: > >> > >>> It has been working perfectly fine thus far.As far as i have analysed > >> there > >>> have been no changes to the firewall or database settings.I will > however > >>> try and implement your suggestion to setup a validation query. > >> > >> 1.) Don’t top post. Reply inline, like this, or at the bottom. This is > >> the convention we follow on this list. > >> > >> 2.) The fact that you have not recently changed your firewall or > database > >> settings doesn’t really mean much. The problem may have not happened > >> before because it just didn’t get triggered. From the db / firewall > side, > >> what commonly causes this is a timeout. The connection is open and idle > >> for too long and either the DB server or firewall disconnects it. > Perhaps > >> the connections just haven’t idled long enough until now. > >> > >> 3.) It’s generally good practice to have a validation query / > testOnBorrow > >> (or one of the other tests) enabled. If you didn’t have this before, > you > >> should consider adding it regardless of the problem. It can help with > >> other things too. > >> > >> Dan > >> > >> > >> I checked the code and the server settings,and We already have > > validation query and testOnBorrow in place. > > I suspect that there’s more to it than this. Perhaps you could share your > configuration? > > > We found out from our data > > management team,that there have been many sleeping connections from the > > tomcat servers to the database. > > This sounds normal to me. A connection pool will maintain idle > connections that do nothing. It sounds like you’re not expecting to see > this? > > > > > Sleeping threads = > > http://dinesql.blogspot.in/2010/07/sql-server-sleeping-status-and.html > > > > We got those connection threads killed just to make sure there the > > connection pool limit isnt breached. > > Do you not trust the connection pool? If you set a limit in the pool, it > won’t go past that. > > > However even after cleaning up those > > connection threads to the DB ,we still gett the same exception. > > Dropping connections from the server side will very likely cause the > exception that you’re reporting. Since you’re dropping the connection > outside of the pool, the pool has no idea that the connection has been > closed. Thus you get the exception you’re reporting. > > Dan > > > > > Aniket > > > >>> > >>> > >>> On Tue, May 20, 2014 at 5:12 PM, Daniel Mikusa >>> wrote: > >>> > On May 20, 2014, at 7:35 AM, Aniket Bhoi > wrote: > > > I have Apache Solr,hosted on my apache Tomcat Server > > > > Details: > > > > Tomcat version: > > Apache Tomcat/6.0.18 > > This is really, really old. You should upgrade. > > > > > OS details > > SUSE Linux Enterprise Server 11 (x86_64) > > VERSION = 11 > > PATCHLEVEL = 1 > > > > While running indexing on this server,It failed. > > > > Log excerpt: > > SEVERE: Can not close connection > > java.sql.SQLException: Already closed. > > Hard to say why this is happening (database server setting, firewall, > >> bad > code, etc.) but something is closing the connection and not telling > the > pool. You can work around this by setting a validation query on your > connection pool and enabling “testOnBorrow”. That will instruct the > >> pool > to check connections before they are given out. Bad connections will > be > closed and replaced, if needed. > > Dan > > > at > > > > >> > org.apache.tomcat.dbcp.dbcp.PoolableConnection.close(PoolableConnection.java:84) > > at > > > > >> > org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.close(PoolingDataSource.java:189) > > at > > > > >> > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.closeResources(Unknown > > Source) > > at > > > > >> > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(Unknown > > Source) > > at > > > > >> > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.access$500(Unknown > > Source) > > at > > > > >> > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator$1.hasNext(Unknown > > Source) > > at > > > org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(Unknown > > Source) > > at > > org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(Unknown > > Source) > > at > > > > >> > org.apache.solr.handler.dataimport.ThreadedEntityProcessorWrapper.nextRow(Unknown > > Source) > > at > > > > >> > org.apache.solr.handler.d
Re: Remote Tomcat webapps bidirectional communication
Hello I think that application to application calls should be implemented with web services (there is much choice but maybe heavy to implement). When implementing such a solution, particularly if trafic goes through internet, you must check that you're using a firewall in order to avoid false requests that could from hackers. A.T. 2014-06-14 23:56 GMT+02:00 Lmhelp1 : > Hello, > > My question is about what code to write to allow two remote Tomcat webapps > to communicate with one another through the Internet. > > Let me explain more precisely what I would like to do. > (I'm just simplifying a bit the real situation). > > - I have a Tomcat webapp running on a server in England. > - I have another Tomcat webapp running on a server in France. > > - I have a JSP inside the England webapp. > - This JSP contains a form with two fields "First name" and "Last name". > - I would like to send these information to the France webapp. > > - After the England form has been submitted, I can collect the information > "First name" and "Last name" in a servlet. > > Can you tell me what I shall do then to send these information to the France > webapp? > Is it something like a "response.sendRedirect(..."? > How does it have to be written? > > - Meantime, the France webapp needs to be able to wait for these information > and, when they arrive, to get them and do something with them. For example > store the "First name" and "Last name" in a database, etc. > > What kind of a code has to be written in the France webapp? > Is it a servlet with a "doGet()" retrieving the information "First name" and > "Last name"? > > - Moreover, when the France webapp has finished it's job, it needs to tell > the England webapp that it has finished, send it a file and some > information. > So the communication has to be bidirectional. > > Can you please give me some indications on how to start dealing with this? > Or maybe a tutorial or an example? > > Thank you and best regards. > -- > Léa Massiot > > - > 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
Connection count explosion due to thread http-nio-80-ClientPoller-x death
Our company are running several Tomcat 7.0.52 high volume Ubuntu 12.04 production servers. We are using Tomcat WebSockets (JSR356 implementation) heavily with 100M text messages (100GiB) per day. We monitor webserver health by measuring several key parameters every minute, including tomcat connection count using: mBeanServer.getAttribute(threadPool, "connectionCount"); // threadPool is MBean of "type=ThreadPool" __The problem__ Our sites can run for days without problems, but once in a while the tomcat connection count suddenly starts growing abnormally fast. See this graph: http://imgur.com/s4fOUte netstat shows these TCP connections to be mostly in CLOSE_WAIT state. Our sites still functions normally with no cpu spikes during this build up until around 60,000 connections, but then the server refuses further connections and a manual Tomcat restart is required. We have no output in tomcat or our logs at the time when this event occurs. The only sign is when comparing full java thread dump with a dump from a newly launched Tomcat: One of http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 is missing/has died. We have observed this problem at least since Tomcat 7.0.48 and can not find indications in Tomcat 7.0.x change logs that it should have been fixed in newer releases. Any help or advises are appreciated, Best regards, Lars Engholm Johansen Our connector configuration:
Re: Major Minor Version issue when using jersey 2.9 with tomcat7 + java8
2014-06-16 10:45 GMT+04:00 Seshumadhav Chaturvedula : > Resending previous email in plain text: > > We have a maven project to develop a jersey 2.0 REST service, on Eclipse > (kepler) > > org.glassfish.jersey.containers > jersey-container-servlet-core > 2.9.1 > > > In conjunction with: > - java8 > - tomcat7 > > When deploying the web application (using `$ mvn install && mvn -X > tomcat7:redeploy`) we get the below exception: > Caused by: java.lang.UnsupportedClassVersionError: > org/glassfish/jersey/servlet/init/JerseyServletContainerInitializer : > Unsupported major.minor version 51.0 (unable to load class > org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer) > at > org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2840) > > 1. I examined the MANIFEST file in the org.glassfish.jersey.containers jar, & > (as suspected) it says built on 1.7 JDK > 2. Tomcat logs confirm that it uses java8 itself > > We cannot move back to java8. Is there a way/hack we can get past this error? 1. What exact version of Tomcat 7.0.x are you using? x=? 2. What exact version of Java 8 are you using? 3. 51.0 = Java 7. There shall be no problem loading that class. (Unless Tomcat 7 is run with Java 6). 4. Full stacktrace for that classloader error, with line numbers = ? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Two Way authentication - Urgent Help
Hi, Yes the problem got fixed the spelling of truststorefile was truststoreFile and truststorepass was truststorePass. Looks fixed for now! On Mon, Jun 16, 2014 at 5:20 AM, Dino Ciuffetti wrote: > Already imported your client.p12 into firefox? > > http://www.utexas.edu/its/help/user-certs/817 > > Il 16/giu/2014 00:22 Grip In ha scritto: > > > > Getting > > > > An error occurred during a connection to localhost:8443. > > SSL peer cannot verify your certificate. > > (Error code: ssl_error_bad_cert_alert) > > > > In firefox on windows 7 with tomcat 7 > > > > Here is what I did as per > > > http://tomcat.10.x6.nabble.com/tomcat-mutual-authentication-doesn-t-work-td2133404.html#a5018750 > > > > 1. "keytool.exe" -genkeypair -keystore tomcat.keystore > > > > 2. "keytool.exe" -genkeypair -keystore client.keystore > > > > 3a. "keytool.exe" -exportcert -keystore client.keystore -file > client.cert > > > > 3b. "keytool.exe" -importcert -keystore server.truststore -file > client.cert > > > > 4. "keytool.exe" -importkeystore -srckeystore client.keystore > > -srcstoretype jks -destkeystore client.p12 -deststoretype pkcs12 > > > > "keytool.exe" -list -keystore tomcat.keystore > > Enter keystore password: > > > > Keystore type: JKS > > Keystore provider: SUN > > > > Your keystore contains 1 entry > > > > mykey, Jun 16, 2014, PrivateKeyEntry, > > Certificate fingerprint (SHA1): > > E7:5E:F8:1F:BC:24:96:E2:D6:87:BF:3A:94:CD:53:14:C6:0E:A6:A5 > > > > "keytool.exe" -list -keystore server.truststore > > Enter keystore password: > > > > Keystore type: JKS > > Keystore provider: SUN > > > > Your keystore contains 1 entry > > > > mykey, Jun 16, 2014, trustedCertEntry, > > Certificate fingerprint (SHA1): > > 81:C9:BF:20:E9:D8:18:7E:E5:F7:54:B1:68:0B:00:65:DB:13:8E:52 > > > > > > My server.xml enteries are > > > > > keystoreFile="path\tomcat.keystore" keystorePass="tomcat" > > truststorefile="path\server.truststore" truststorepass="client" > > maxThreads="1500" scheme="https" secure="true" clientAuth="true" > > sslProtocol="TLS" /> > > > > My tomcat user enteries are > > > > > password="null" roles="admin"/> > > > > > > But could not get the resolution > > > > Please help urgent. >
