RE: tomcat 6 refuses mod_jk connections after server runs for a couple of days
Christopher, From: Christopher Schultz [ch...@christopherschultz.net] Sent: Friday, February 28, 2014 11:40 AM To: Tomcat Users List Subject: Re: tomcat 6 refuses mod_jk connections after server runs for a couple of days -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Issac, On 2/27/14, 6:23 PM, Isaac Gonzalez wrote: > > -Original Message- From: Konstantin Kolinko > [mailto:knst.koli...@gmail.com] Sent: Thursday, February 27, 2014 > 2:40 PM To: Tomcat Users List Subject: Re: tomcat 6 refuses mod_jk > connections after server runs for a couple of days > > 2014-02-28 2:06 GMT+04:00 Isaac Gonzalez > : >> Hi Christopher(and Konstantin), attached is a couple of thread >> dumps of when we experienced the issue again today. I also >> noticed we get this message right before the problem occurs: Feb >> 27, 2014 12:47:15 PM >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run >> SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to >> create new native thread) executing >> org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, >> terminating thread > > That explains why a connection cannot be accepted. > > I wonder are you hitting an "ulimit" limit, or there is just not > enough free memory to allocate stack area for a new thread (which > size is set by -Xss option to java executable). > > I thought of the ulimit settings and increased it to the upward > limit allowed at the end of last weekend: [root@server ~]# su > tomcat [tomcat@server root]$ ulimit -a core file size > (blocks, -c) 0 data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 file size > (blocks, -f) unlimited pending signals (-i) 62835 > max locked memory (kbytes, -l) 64 max memory size > (kbytes, -m) unlimited open files (-n) 65535 Open-files can sometimes be a problem. This setting looks just fine to me, though. > pipe size(512 bytes, -p) 8 POSIX message queues > (bytes, -q) 819200 real-time priority (-r) 0 stack > size (kbytes, -s) 10240 cpu time > (seconds, -t) unlimited max user processes (-u) 1024 You might want to increase this number. How many processes is "tomcat" running outside of the JVM? This is likely to be the limit you are hitting. Tomcat is only running about 7 processes total, one for each JVM...but nothing else...unless I need to look beyond ps... Don't think this is it...but you never know -Isaac - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOY2AAoJEBzwKT+lPKRYmAwP+wVF9fwj88SOXxWTEKXdbk01 a9slFh4LmnDn0tacrAmA3m47VsndF3ewHwIEF1yP7wNRYf3NXSCzVp0OWuji6ZU1 yfjPpBT3pI8dVPqu9hkWVxkvQxA5xL0sm+9L2BeVBW0QbLs69L0g/v3xt2LwMxvF j/9mZNqW6A177ZG1o5wcdexRhzV2566Z3idWdc8Zp9uISwFdZXdzYxJtTiku9k6q nV3gQ8ICAwI+VGBKc1DwbL6QqUwpY8O7OjmQ5OEJaqHYEXjVNkdgo87oY+2BXRkV 9BW9J1zHLPAi8UhdfumDeqRKBQ7JPRhRLGGrhAHsmmA+G0XzShzU2zY84s5PSGU8 GwNiNZ/NJpTPtYjV5viY3GdWWbyeO9J4VDUBsBbs8k1XN7a44OjmKpRhnVIlQT6z XLYfg3GpWjK8Xdd2L81RB/O6Q2xn9jY5FMik8jh0HgDm38Wf4AeymhVdEaEfVT5Z TdAQECOFeYGDgLHNY7sFr/QQfJkLAFhfNM9xcgDTx4WcUH9V4QMn8S2qjOeFPbgx hqwg+p2au18JMTb+RkmnHAVIcqtiFtUU/dN9Xap/vH+bc8UKimE87brBlnTnD/pk uW0ea5m4f6MDcX2hDSh4+1ZU5uI0ZqTMvcp445UE0GW/4ITu9iauVedvM9fUlVlt fzDyTTTEUHZ10n+yF5XC =kOiz -END PGP SIGNATURE- - 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: tomcat 6 refuses mod_jk connections after server runs for a couple of days
Christopher From: Christopher Schultz [ch...@christopherschultz.net] Sent: Friday, February 28, 2014 11:38 AM To: Tomcat Users List Subject: Re: tomcat 6 refuses mod_jk connections after server runs for a couple of days -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 2/27/14, 5:40 PM, Konstantin Kolinko wrote: > 2014-02-28 2:06 GMT+04:00 Isaac Gonzalez > : >> Hi Christopher(and Konstantin), attached is a couple of thread >> dumps of when we experienced the issue again today. I also >> noticed we get this message right before the problem occurs: Feb >> 27, 2014 12:47:15 PM >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run >> SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to >> create new native thread) executing >> org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, >> terminating thread > > That explains why a connection cannot be accepted. > > I wonder are you hitting an "ulimit" limit, or there is just not > enough free memory to allocate stack area for a new thread (which > size is set by -Xss option to java executable). > > Your thread dumps contain 149 threads each. While it does explain why one (Tomcat) server would become unresponsive, it doesn't really explain why the entire cluster would become unresponsive. Issac, are you using sticky-sessions or anything like that, or does your load-balancing mod_jk configuration choose arbitrarily between a backend server? You initially gave an abridged configuration, so I can't tell. As you indicate below, I am not clustering. There is only one backend tomcat. >> After the "split", did both Tomcats appear to lock-up >> simultaneously, or did only one of them have a problem and the >> other one stayed up? > > Isaac: They all appear to lock-up simultaneously, if users try to > access that JK mount point. > > [...] > > Isaac: I am not load-balancing the tomcat servers...I only have > one...I do "load balance" the apache front end servers via dns > round-robin Oh, you only have a single back-end server? Well, then that why they "all" go down at once, so you seem to have found your problem: the server itself is going down because you don't have enough resources to keep it up. Indeed I have! Seems like I underallocated server memory...the machine had only 8 Gigs with 7 tomcat instances running that all had up to a maximum of 2 gigs of maximum memory heap size, plus OS stuff running, RabbitMQ, and other things. I am wondering though if something else could be the underlying root cause of this issue, or was I simply under allocating memory..such as connections not being closed, either by the client mod_jk connector, or the db connector...We'll see in the next few days I guess thanks again Chris, you and Konstantin pointed me to the issue... -Isaac - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOWeAAoJEBzwKT+lPKRYUxYQAItxQZTOWjubWA32fDwGhcGy Y4cuBDU7OZiw/I4oQTCEY0Uk62eKf6g0dXQL4VqM8j4jz2VLhP10uPDA3c/+CBhU kpVJg2ifLD0YJmUqnxuTHYIdwwvPrPa/PNCAWYJCcDXE1DVEz8HLAoYlQY5oJ5Cf P+wtYTgWqJyzddtB2sjB+YQcVj+83aWkfKuipednSdm0utCPP5PQzPiF7agoP9qt vDB0preG0GFQXTShYqMRKeEt3hu+BdLXugp7kJA5KDMEcSbWyPzefxWl0CtKhcJB d/ntEtoYbR0gWGO4Qajio6NVmw9TWzBf4spbg8scBz8ijE314VNsw6mdT9F55TZZ 43iYSnDAK1dNfs7guqAAk7z5Gf+fChy28zFmOm0lSzs1/o5HHvJFqKse94hzjJW6 R4uCUVktbvoJPfot6zoG3ofsYm+PVcibPOj4Xh0m7nBPKvqTZ5BVyeLBRR/E+KRy O4jJ0DshRnhy3qL9l5uO6h7miIb+GMwjpc3A6lbbITHVDKspaq8kll+m6sAn1ppV Z8PnNysSMTGHY6azjMisZlp4b/i9r+Nc+HabtbjRrt1StfuWrHTeIwQ46n7XcMrr biATXUpo94kM2eGJecP0jtyBrgYwkaz22NtbW3i2l47XQKa/dhhP6IzlgzK8Fmki eKiBf5+iNyhc9dB3adQ2 =Uchz -END PGP SIGNATURE- - 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: Tomcat 7.0.52 issue on our Sun Sparc with SunOS 5.10
Hi Konstantin, Thanks. it did cut the name during the unpacking. I unpacked it using " gunzip -c apache-tomcat-7.0.52.tar.gz |tar xvf - " and there was no warning or error. The original tar.gz file contains: DrawboardContextListener.class DrawboardContextListener.java But after unpacked, their names are cut as follows: -rw-r--r-- 1 root root 890 Feb 13 02:29 DrawboardContextListener.c -rw-r--r-- 1 root root1346 Feb 13 02:31 DrawboardContextListener.j Best Regards, Jay -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Thursday, February 27, 2014 5:13 PM To: Tomcat Users List Subject: Re: Tomcat 7.0.52 issue on our Sun Sparc with SunOS 5.10 2014-02-28 1:56 GMT+04:00 Jay : > Hello, > > We newly installed Solaris 10 with all default settings on our Sun > Sparc machine (sun4u sparc SUNW,UltraAX-i2 64-bit sparcv9 kernel modules). > The OS Version: SunOS hostname 5.10 Generic_147147-26 sun4u sparc > SUNW,UltraAX-i2. > > We downloaded and installed JDK packages as follows: > jdk-7u51-solaris-sparc.z > jdk-7u51-solaris-sparcv9.z > > The Java in the environment: > java version "1.7.0_51" > Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) > Client VM (build 24.51-b03, mixed mode, sharing) > > We downloaded the apache-tomcat-7.0.52.tar.gz and just unpacked it in > /export/home/tester. > Then we started the Tomcat server just using ./startup.sh without > change of any default settings. > The Tomcat is started ok listening at 8080 and we can see the Tomcat > main page on Web Browser at the port 8080. > But there is SEVERE error in the logs as follows: > org.apache.catalina.core.StandardContext listenerStart > SEVERE: Error configuring application listener of class > websocket.drawboard.DrawboardContextListener > > Is anyone aware about this issue? is it a configuration issue or > environment issue? > Will this issue affect the basic Tomcat functions? > Can you please provide any clues or check points? > > Thanks, > Jay > > PS. Here are the outputs from the logs: >() > INFO: Deploying web application directory >/export/home/tester/apache-tomcat-7.0.52/webapps/examples >(...) > java.lang.ClassNotFoundException: > websocket.drawboard.DrawboardContextListener Does the following class file exist in your installation? /export/home/tester/apache-tomcat-7.0.52/webapps/examples/WEB-INF/classes/we bsocket/drawboard/DrawboardContextListener.class I have checked, that it is present in apache-tomcat-7.0.52.tar.gz, but may be you had trouble unpacking it. The *.tar.gz file requires GNU Tar (as mentioned in README file on the download page), because of some long file names. You can download apache-tomcat-7.0.52.zip instead. 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: OT? : Connectors not needed?
2014-02-28 23:00 GMT+04:00 Jeffrey Janner : > While working through a migration, I discovered something interesting. > Apparently you don't need any working connectors for a functioning (?) Tomcat > instance. > Setup: Tomcat 7.0.51, Java 1.7.0_51, Windows 2008 R2 64-bit > Config had only two both with the address= and port= parameters > set. > I had yet to add the referenced IP address to any network adapter when I > started the Tomcat service. > The service came up, logged the failure to bind to the address/port > assignments, and then deployed the webapps. > So I had a functional application running, but no way to connect to test > against it. > I suppose one would expect this to happen, and I don't know if a lack of > running connectors could be detected and a shutdown instituted, but it just > seemed a little odd. This behaviour is configurable via a system property. The default behaviour is to let Tomcat to start up, because of 1. backwards compatibility concerns, 2. you can connect via JMX and configure/start/stop connectors as necessary. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Prashant, On 2/28/14, 7:54 AM, Prashant Kadam wrote: > thanks Mark and Konstantin for your reply > > If you create the simplest possible JSP that demonstrates the > issue (start with the one you have and remove as much as you can) > and then post that JSP here, we can take a look. > >>> as you can see in stacktrace, there are many jsps forwarding >>> request to > another jsp, i am not sure how can I post jsp code. also one > observation is, there is a struts action forward in between means > jsp-> struts action -> jsp , If I remove this action call and > include jsp directly in jsp then its working ... whether something > wrong with tiles or struts or tomcat .. ? If you are doing a lot of JSP forwarding, you could be generating a lot of useless whitespace that is all being sent to the output buffer. Once that buffer fills up, the response headers will be sent to the client and and response is therefore committed. If my analysis is correct, the difference between the Tomcat versions probably comes down to some small change in the way JSPs are compiled which may generate more whitespace if you haven't been careful. Take a look at all the JSPs that are participating in the request -- you should be able to inspect them to see why they might be generating whitespace. Remember, newlines are whitespace ;) I can see from your stack trace that you are using *includes*. Is there some other error that is occurring before this one? Does it happen on every request to this resource? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOt7AAoJEBzwKT+lPKRY6fYP+wWFNBtLRjUi1m6NPPpxajyp NBp0SZ5TIBs9c1fwAq3oKjodMDsgGMo59HApJpzHYyQhwuKHez3VLdGPss4aeq50 +Yc/UNhuMor31JWkPHzy05oSEFOQeKFn8Trw//OJ8m2giZSopt/05E8NRu9MIpUw +9eEsetJHs0502XCEFQ206/6MLxleGLA/sM5HTWJHg0NJczobTsHo40myy201Y1j Q7tO/gsyRzwljbHf0XByTTYUQNaNCaTzH0ydLiVeWCaPfxCpF4DXzrzdBu+BrL8U n5BlaizxMp9vd5DPucbRZidC0ihQpcaMjBAXnwg3OtbltX5EsMEYOfgD/TQXh5PC PFTPRm21OaybgNj13hNOOfmOCDw5AAA+znyVPFl4Ao+z67w0jIgSre49HMXfzYJQ a2pcDzCUuvbtXl22LJBVcnqlISLETiShulRzvAF5OiYwe2bJS4fOdWNSB8Nn7L7A +x//HxvTOem1dG5CaFRkCxvnkvK30e4LNCwY0AfErt3eKahHj0rJA+w/qiodTg2U bzh8kgRv+9v0fqV3RKVV/nO7WFRlyN6QIalCvLKPC+9CdajvBPUVC+gZgizs4pjT osHuIcGPmXMzycj1FfXzym5ucdy/WlJPUIBtliA4XnJ/RdBu1WfdB0c6rruiNflW vp1dKzQjPx5Zv58BU2l1 =pI9J -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP2 connection pool leak?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Felipe, On 2/28/14, 1:22 PM, Felipe Jaekel wrote: > Hi, > > Today I tried to migrate my production server from 7.0.50 to > 8.0.3. > > After about 3 hours running I start to get JDBC > exceptions(stacktrace below) and the server stops responding. > Looking at Amazon RDS monitoring it shows the connection limit > reached 97%. Restarted the server and after about the same time the > same problem happened. > > With 7.0.50 the highest value reached was 60%, so I think that the > connection pool may be leaking. > > I understand that DBCP2 isn't final yet. I just like to know if > that is a known issue, so I'll return to Tomcat 7. As always, you should make sure that your own code is handling your JDBC resources properly. It's possible that DBCP2 is less forgiving than earlier versions when it comes to sloppy resource management. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOi8AAoJEBzwKT+lPKRYFtYQAK8yQ89mYW2+jMKiiYZG+CF6 fFHtUhnddZvuZcIwyw3pVwNosruEjL49X0gkChcQ1vwQQeUrcw4HOvEfBBjynwds dZuO+Fan0BCiDk+I1AcgIf4EnL5O6gMF02031kB7OhDv3AZQFqtfmP+zuoWMSsel K27x3ri2lFMa3IvPD+kVf6ZSjejKNe6D5s3k5Gl1Lmo5cqH8y2cK1pI9RliUZvcG ukgrIEV5giDi/MdFcycv8Up4f+5lWe9YEGz2iqHbuTSp9iHWOgS3Bfy+fkUr8wVz UN0QUPvHGWwg+VqpYB7SxwimJyV/1foS1zKt6y35R35va9doZ8WQsM944FkwUFl9 oSNkG0JRyE/4ZXZ2KYsoa1zQ/R1tScSgGQKHcUYGfHWqruuNDnTD0WVvoixlqe2A NZGLjQFsu0xeNhPJKtTYuvRsFaGqK/+VEhp8RkKyEwzFIKh2NoyimYHChR0f5S0D ULxlHOW0qWCeXTBvG58u/Q9O67hKQVn1B2iFl7OWIXGYez8+jQacRHVlslUSiEvM fem2Lzpo+RDu3XjWDLdRhNnzIsUTUpcgqm4+y3aATL5i1ZDDZdeLag2aMC+L0w4M MFYeb56Et7x7oh+AEvvSnZvHqmfUS1sa6VRFUubKdcwTk/SVAKSwj/w7T3FOH32C BPY5oH+F+tGm3vwvUqcO =l+nK -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AMD 64 version 1.6.0.45 jdk needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Joseph, On 2/28/14, 9:55 AM, Joseph Kelly wrote: > I have a strange architecural problem , I am running the following > versions: > > Processor and arch version > > [root@evl3301581 java]# file /sbin/init /sbin/init: ELF 64-bit LSB > executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, > dynamically linked (uses shared libs), stripped > > Tomcat Version: > > [root@evl3301581 bin]# sh version.sh Using CATALINA_BASE: > /opt/apps/tomcat Using CATALINA_HOME: /opt/apps/tomcat Using > CATALINA_TMPDIR: /opt/apps/tomcat/temp Using JRE_HOME:/usr > Using CLASSPATH: /opt/apps/tomcat/bin/bootstrap.jar Server > version: Apache Tomcat/6.0.39 Server built: Jan 27 2014 10:40:33 > Server number: 6.0.39.0 OS Name:Linux OS Version: > 2.6.18-371.3.1.el5 Architecture: amd64 JVM Version: > 1.7.0_51-mockbuild_2014_01_29_09_35-b00 JVM Vendor: Oracle > Corporation So you are using x86-64 with Tomcat 6.0.39 (upgrade) and Oracle Java 1.7.0_51. Thanks for the full disclosure, but it could have been more compact. What the heck is "1.7.0_51-mockbuild"? Are you doing some kind of funny business with non-released versions of the JVM? > Current java version: > > [root@evl3301581 bin]# /usr/java/latest/bin/java -version java > version "1.6.0_38-ea" Java(TM) SE Runtime Environment (build > 1.6.0_38-ea-b04) Java HotSpot(TM) 64-Bit Server VM (build > 20.13-b02, mixed mode) The far above is in conflict with the near above: Java version. > When using the the JVM in green Formatting is stripped from this list. In cyberspace, nobody can hear you green. :) > [,] I have no problem running tomcat using the following JSVC > daemon (commons-daemon-1.0.15-src) , but when > > I use the JVM in red , I always get this error > > Cannot find any VM in Java Home /opt/apps/java Cannot locate JVM > library file Service exit with a return value of 1 Looks like you have a bad path somewhere. > I have run the JSVC daemon in debug mode to see whats happening in > a bit more detail and I see the following information: > > Attempting to locate Java Home in /opt/apps/java Attempting to > locate VM configuration file /opt/apps/java/jre/lib/jvm.cfg > Attempting to locate VM configuration file > /opt/apps/java/lib/jvm.cfg Attempting to locate VM configuration > file /opt/apps/java/jre/lib/amd64/jvm.cfg Attempting to locate VM > configuration file /opt/apps/java/lib/amd64/jvm.cfg VM > configuration file not found Attempting to locate VM library > /opt/apps/java/jre/lib/amd64/classic/libjvm.so Attempting to locate > VM library /opt/apps/java/jre/lib/amd64/server/libjvm.so Attempting > to locate VM library /opt/apps/java/jre/lib/amd64/client/libjvm.so > Attempting to locate VM library > /opt/apps/java/jre/lib/amd64/libjvm.so Attempting to locate VM > library /opt/apps/java/lib/amd64/classic/libjvm.so Attempting to > locate VM library /opt/apps/java/lib/amd64/server/libjvm.so > Attempting to locate VM library > /opt/apps/java/lib/amd64/client/libjvm.so Attempting to locate VM > library /opt/apps/java/lib/amd64/libjvm.so Attempting to locate VM > library /opt/apps/java/jre/bin/amd64/classic/libjvm.so Attempting > to locate VM library /opt/apps/java/jre/bin/amd64/libjvm.so > Attempting to locate VM library > /opt/apps/java/bin/amd64/classic/libjvm.so Attempting to locate VM > library /opt/apps/java/bin/amd64/libjvm.so Attempting to locate VM > library > /opt/apps/java/jre/lib/amd64/classic/green_threads/libjvm.so > Attempting to locate VM library > /opt/apps/java/jre/lib/classic/libjvm.so Attempting to locate VM > library /opt/apps/java/jre/lib/client/libjvm.so Attempting to > locate VM library /opt/apps/java/jre/lib/libjvm.so Attempting to > locate VM library /opt/apps/java/lib/classic/libjvm.so Attempting > to locate VM library /opt/apps/java/lib/client/libjvm.so Attempting > to locate VM library /opt/apps/java/lib/libjvm.so Attempting to > locate VM library /opt/apps/java/jre/bin/classic/libjvm.so > Attempting to locate VM library > /opt/apps/java/jre/bin/client/libjvm.so Attempting to locate VM > library /opt/apps/java/jre/bin/libjvm.so Attempting to locate VM > library /opt/apps/java/bin/classic/libjvm.so Attempting to locate > VM library /opt/apps/java/bin/client/libjvm.so Attempting to locate > VM library /opt/apps/java/bin/libjvm.so Attempting to locate VM > library /opt/apps/java/jre/lib/amd64/fast64/libjvm.so Attempting to > locate VM library /opt/apps/java/jre/lib/amd64/fast32/libjvm.so > Attempting to locate VM library > /opt/apps/java/lib/amd64/fast64/libjvm.so Attempting to locate VM > library /opt/apps/java/lib/amd64/fast32/libjvm.so Attempting to > locate VM library /usr/lib/libgcj.so.7 Attempting to locate VM > library /usr/lib/libgcj.so.6 Java Home located in /opt/apps/java > +-- DUMPING JAVA HOME STRUCTURE | Java > Home: "/opt/apps/java" | Java VM Config.: "null" | Found > JVMs: 0 -> as we can see it dos
Re: tomcat 6 refuses mod_jk connections after server runs for a couple of days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Issac, On 2/27/14, 6:23 PM, Isaac Gonzalez wrote: > > -Original Message- From: Konstantin Kolinko > [mailto:knst.koli...@gmail.com] Sent: Thursday, February 27, 2014 > 2:40 PM To: Tomcat Users List Subject: Re: tomcat 6 refuses mod_jk > connections after server runs for a couple of days > > 2014-02-28 2:06 GMT+04:00 Isaac Gonzalez > : >> Hi Christopher(and Konstantin), attached is a couple of thread >> dumps of when we experienced the issue again today. I also >> noticed we get this message right before the problem occurs: Feb >> 27, 2014 12:47:15 PM >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run >> SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to >> create new native thread) executing >> org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, >> terminating thread > > That explains why a connection cannot be accepted. > > I wonder are you hitting an "ulimit" limit, or there is just not > enough free memory to allocate stack area for a new thread (which > size is set by -Xss option to java executable). > > I thought of the ulimit settings and increased it to the upward > limit allowed at the end of last weekend: [root@server ~]# su > tomcat [tomcat@server root]$ ulimit -a core file size > (blocks, -c) 0 data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 file size > (blocks, -f) unlimited pending signals (-i) 62835 > max locked memory (kbytes, -l) 64 max memory size > (kbytes, -m) unlimited open files (-n) 65535 Open-files can sometimes be a problem. This setting looks just fine to me, though. > pipe size(512 bytes, -p) 8 POSIX message queues > (bytes, -q) 819200 real-time priority (-r) 0 stack > size (kbytes, -s) 10240 cpu time > (seconds, -t) unlimited max user processes (-u) 1024 You might want to increase this number. How many processes is "tomcat" running outside of the JVM? This is likely to be the limit you are hitting. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOY2AAoJEBzwKT+lPKRYmAwP+wVF9fwj88SOXxWTEKXdbk01 a9slFh4LmnDn0tacrAmA3m47VsndF3ewHwIEF1yP7wNRYf3NXSCzVp0OWuji6ZU1 yfjPpBT3pI8dVPqu9hkWVxkvQxA5xL0sm+9L2BeVBW0QbLs69L0g/v3xt2LwMxvF j/9mZNqW6A177ZG1o5wcdexRhzV2566Z3idWdc8Zp9uISwFdZXdzYxJtTiku9k6q nV3gQ8ICAwI+VGBKc1DwbL6QqUwpY8O7OjmQ5OEJaqHYEXjVNkdgo87oY+2BXRkV 9BW9J1zHLPAi8UhdfumDeqRKBQ7JPRhRLGGrhAHsmmA+G0XzShzU2zY84s5PSGU8 GwNiNZ/NJpTPtYjV5viY3GdWWbyeO9J4VDUBsBbs8k1XN7a44OjmKpRhnVIlQT6z XLYfg3GpWjK8Xdd2L81RB/O6Q2xn9jY5FMik8jh0HgDm38Wf4AeymhVdEaEfVT5Z TdAQECOFeYGDgLHNY7sFr/QQfJkLAFhfNM9xcgDTx4WcUH9V4QMn8S2qjOeFPbgx hqwg+p2au18JMTb+RkmnHAVIcqtiFtUU/dN9Xap/vH+bc8UKimE87brBlnTnD/pk uW0ea5m4f6MDcX2hDSh4+1ZU5uI0ZqTMvcp445UE0GW/4ITu9iauVedvM9fUlVlt fzDyTTTEUHZ10n+yF5XC =kOiz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 6 refuses mod_jk connections after server runs for a couple of days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 2/27/14, 5:40 PM, Konstantin Kolinko wrote: > 2014-02-28 2:06 GMT+04:00 Isaac Gonzalez > : >> Hi Christopher(and Konstantin), attached is a couple of thread >> dumps of when we experienced the issue again today. I also >> noticed we get this message right before the problem occurs: Feb >> 27, 2014 12:47:15 PM >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run >> SEVERE: Caught exception (java.lang.OutOfMemoryError: unable to >> create new native thread) executing >> org.apache.jk.common.ChannelSocket$SocketAcceptor@177ddea, >> terminating thread > > That explains why a connection cannot be accepted. > > I wonder are you hitting an "ulimit" limit, or there is just not > enough free memory to allocate stack area for a new thread (which > size is set by -Xss option to java executable). > > Your thread dumps contain 149 threads each. While it does explain why one (Tomcat) server would become unresponsive, it doesn't really explain why the entire cluster would become unresponsive. Issac, are you using sticky-sessions or anything like that, or does your load-balancing mod_jk configuration choose arbitrarily between a backend server? You initially gave an abridged configuration, so I can't tell. >> After the "split", did both Tomcats appear to lock-up >> simultaneously, or did only one of them have a problem and the >> other one stayed up? > > Isaac: They all appear to lock-up simultaneously, if users try to > access that JK mount point. > > [...] > > Isaac: I am not load-balancing the tomcat servers...I only have > one...I do "load balance" the apache front end servers via dns > round-robin Oh, you only have a single back-end server? Well, then that why they "all" go down at once, so you seem to have found your problem: the server itself is going down because you don't have enough resources to keep it up. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEOWeAAoJEBzwKT+lPKRYUxYQAItxQZTOWjubWA32fDwGhcGy Y4cuBDU7OZiw/I4oQTCEY0Uk62eKf6g0dXQL4VqM8j4jz2VLhP10uPDA3c/+CBhU kpVJg2ifLD0YJmUqnxuTHYIdwwvPrPa/PNCAWYJCcDXE1DVEz8HLAoYlQY5oJ5Cf P+wtYTgWqJyzddtB2sjB+YQcVj+83aWkfKuipednSdm0utCPP5PQzPiF7agoP9qt vDB0preG0GFQXTShYqMRKeEt3hu+BdLXugp7kJA5KDMEcSbWyPzefxWl0CtKhcJB d/ntEtoYbR0gWGO4Qajio6NVmw9TWzBf4spbg8scBz8ijE314VNsw6mdT9F55TZZ 43iYSnDAK1dNfs7guqAAk7z5Gf+fChy28zFmOm0lSzs1/o5HHvJFqKse94hzjJW6 R4uCUVktbvoJPfot6zoG3ofsYm+PVcibPOj4Xh0m7nBPKvqTZ5BVyeLBRR/E+KRy O4jJ0DshRnhy3qL9l5uO6h7miIb+GMwjpc3A6lbbITHVDKspaq8kll+m6sAn1ppV Z8PnNysSMTGHY6azjMisZlp4b/i9r+Nc+HabtbjRrt1StfuWrHTeIwQ46n7XcMrr biATXUpo94kM2eGJecP0jtyBrgYwkaz22NtbW3i2l47XQKa/dhhP6IzlgzK8Fmki eKiBf5+iNyhc9dB3adQ2 =Uchz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: DBCP2 connection pool leak?
you can try out tomcat-jdbc, and see if that solves your problem, it may help you narrow it down. http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html On Fri, Feb 28, 2014 at 11:26 AM, Mark Thomas wrote: > On 28/02/2014 18:22, Felipe Jaekel wrote: > > Hi, > > > > Today I tried to migrate my production server from 7.0.50 to 8.0.3. > > > > After about 3 hours running I start to get JDBC exceptions(stacktrace > > below) and the server stops responding. Looking at Amazon RDS monitoring > it > > shows the connection limit reached 97%. Restarted the server and after > > about the same time the same problem happened. > > > > With 7.0.50 the highest value reached was 60%, so I think that the > > connection pool may be leaking. > > > > I understand that DBCP2 isn't final yet. I just like to know if that is a > > known issue, so I'll return to Tomcat 7. > > It isn't a known issue. There have been some code changes since the DBCP > version that was used in 8.0.3 but nothing I recall that related to a > connection leak. It is worth taking a look at what is going on with JMX > as that might give you some hints. > > Mark > > > > > Thanks, > > Phillip > > > > > > > > > > > javax.persistence.PersistenceException: > > org.hibernate.exception.GenericJDBCException: could not inspect JDBC > > autocommit mode > > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) > > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) > > at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:316) > > at > br.com.spdata.persistence.mysql.service.ErroService.checkExistente(ErroService.java:134) > > at > br.com.spdata.persistence.mysql.service.ErroService.persist(ErroService.java:58) > > at > br.com.spdata.email.AbstractErrorPageController.(AbstractErrorPageController.java:78) > > at > br.com.spdata.tecnico.ErrorPageController.(ErrorPageController.java:14) > > at sun.reflect.GeneratedConstructorAccessor798.newInstance(Unknown > Source) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > > at java.lang.Class.newInstance(Class.java:374) > > at > com.sun.faces.mgbean.BeanBuilder.newBeanInstance(BeanBuilder.java:186) > > at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:100) > > at > com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:409) > > at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:269) > > at > com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:257) > > at > com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:117) > > at > com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) > > at > com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) > > at > org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:80) > > at org.apache.el.parser.AstValue.getValue(AstValue.java:135) > > at > org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) > > at > com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:238) > > at > com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:154) > > at > com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85) > > at > com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) > > at > com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183) > > at > javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) > > at > org.primefaces.renderkit.HeadRenderer.encodeEnd(HeadRenderer.java:106) > > at > javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:919) > > at > javax.faces.component.UIComponent.encodeAll(UIComponent.java:1863) > > at > javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) > > at > com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) > > at > com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) > > at > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) > > at > com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) > > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) > > at > com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) > > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) > > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301)
OT? : Connectors not needed?
While working through a migration, I discovered something interesting. Apparently you don't need any working connectors for a functioning (?) Tomcat instance. Setup: Tomcat 7.0.51, Java 1.7.0_51, Windows 2008 R2 64-bit Config had only two both with the address= and port= parameters set. I had yet to add the referenced IP address to any network adapter when I started the Tomcat service. The service came up, logged the failure to bind to the address/port assignments, and then deployed the webapps. So I had a functional application running, but no way to connect to test against it. I suppose one would expect this to happen, and I don't know if a lack of running connectors could be detected and a shutdown instituted, but it just seemed a little odd. Jeff
Re: DBCP2 connection pool leak?
On 28/02/2014 18:22, Felipe Jaekel wrote: > Hi, > > Today I tried to migrate my production server from 7.0.50 to 8.0.3. > > After about 3 hours running I start to get JDBC exceptions(stacktrace > below) and the server stops responding. Looking at Amazon RDS monitoring it > shows the connection limit reached 97%. Restarted the server and after > about the same time the same problem happened. > > With 7.0.50 the highest value reached was 60%, so I think that the > connection pool may be leaking. > > I understand that DBCP2 isn't final yet. I just like to know if that is a > known issue, so I'll return to Tomcat 7. It isn't a known issue. There have been some code changes since the DBCP version that was used in 8.0.3 but nothing I recall that related to a connection leak. It is worth taking a look at what is going on with JMX as that might give you some hints. Mark > > Thanks, > Phillip > > > > > javax.persistence.PersistenceException: > org.hibernate.exception.GenericJDBCException: could not inspect JDBC > autocommit mode > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) > at > org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) > at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:316) > at > br.com.spdata.persistence.mysql.service.ErroService.checkExistente(ErroService.java:134) > at > br.com.spdata.persistence.mysql.service.ErroService.persist(ErroService.java:58) > at > br.com.spdata.email.AbstractErrorPageController.(AbstractErrorPageController.java:78) > at > br.com.spdata.tecnico.ErrorPageController.(ErrorPageController.java:14) > at sun.reflect.GeneratedConstructorAccessor798.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at java.lang.Class.newInstance(Class.java:374) > at > com.sun.faces.mgbean.BeanBuilder.newBeanInstance(BeanBuilder.java:186) > at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:100) > at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:409) > at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:269) > at > com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:257) > at > com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:117) > at > com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) > at > com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:80) > at org.apache.el.parser.AstValue.getValue(AstValue.java:135) > at > org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) > at > com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:238) > at > com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:154) > at > com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85) > at > com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) > at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) > at > org.primefaces.renderkit.HeadRenderer.encodeEnd(HeadRenderer.java:106) > at > javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:919) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1863) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) > at > com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) > at > com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) > at > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) > at > com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) > at > org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) > at > org.apache.shiro
DBCP2 connection pool leak?
Hi, Today I tried to migrate my production server from 7.0.50 to 8.0.3. After about 3 hours running I start to get JDBC exceptions(stacktrace below) and the server stops responding. Looking at Amazon RDS monitoring it shows the connection limit reached 97%. Restarted the server and after about the same time the same problem happened. With 7.0.50 the highest value reached was 60%, so I think that the connection pool may be leaking. I understand that DBCP2 isn't final yet. I just like to know if that is a known issue, so I'll return to Tomcat 7. Thanks, Phillip javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not inspect JDBC autocommit mode at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1387) at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310) at org.hibernate.ejb.QueryImpl.getSingleResult(QueryImpl.java:316) at br.com.spdata.persistence.mysql.service.ErroService.checkExistente(ErroService.java:134) at br.com.spdata.persistence.mysql.service.ErroService.persist(ErroService.java:58) at br.com.spdata.email.AbstractErrorPageController.(AbstractErrorPageController.java:78) at br.com.spdata.tecnico.ErrorPageController.(ErrorPageController.java:14) at sun.reflect.GeneratedConstructorAccessor798.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at java.lang.Class.newInstance(Class.java:374) at com.sun.faces.mgbean.BeanBuilder.newBeanInstance(BeanBuilder.java:186) at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:100) at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:409) at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:269) at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:257) at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:117) at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:80) at org.apache.el.parser.AstValue.getValue(AstValue.java:135) at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:238) at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:154) at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85) at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:183) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) at org.primefaces.renderkit.HeadRenderer.encodeEnd(HeadRenderer.java:106) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:919) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1863) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1859) at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:301) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362) at org.apache.shiro.web.servlet.On
AMD 64 version 1.6.0.45 jdk needed
Hello I have a strange architecural problem , I am running the following versions: Processor and arch version [root@evl3301581 java]# file /sbin/init /sbin/init: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped Tomcat Version: [root@evl3301581 bin]# sh version.sh Using CATALINA_BASE: /opt/apps/tomcat Using CATALINA_HOME: /opt/apps/tomcat Using CATALINA_TMPDIR: /opt/apps/tomcat/temp Using JRE_HOME:/usr Using CLASSPATH: /opt/apps/tomcat/bin/bootstrap.jar Server version: Apache Tomcat/6.0.39 Server built: Jan 27 2014 10:40:33 Server number: 6.0.39.0 OS Name:Linux OS Version: 2.6.18-371.3.1.el5 Architecture: amd64 JVM Version:1.7.0_51-mockbuild_2014_01_29_09_35-b00 JVM Vendor: Oracle Corporation Current java version: [root@evl3301581 bin]# /usr/java/latest/bin/java -version java version "1.6.0_38-ea" Java(TM) SE Runtime Environment (build 1.6.0_38-ea-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.13-b02, mixed mode) When using the the JVM in green I have no problem running tomcat using the following JSVC daemon (commons-daemon-1.0.15-src) , but when I use the JVM in red , I allways get this error Cannot find any VM in Java Home /opt/apps/java Cannot locate JVM library file Service exit with a return value of 1 I have run the JSVC daemon in debug mode to see whats happening in a bit more detail and I see the following information: Attempting to locate Java Home in /opt/apps/java Attempting to locate VM configuration file /opt/apps/java/jre/lib/jvm.cfg Attempting to locate VM configuration file /opt/apps/java/lib/jvm.cfg Attempting to locate VM configuration file /opt/apps/java/jre/lib/amd64/jvm.cfg Attempting to locate VM configuration file /opt/apps/java/lib/amd64/jvm.cfg VM configuration file not found Attempting to locate VM library /opt/apps/java/jre/lib/amd64/classic/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/amd64/server/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/amd64/client/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/amd64/libjvm.so Attempting to locate VM library /opt/apps/java/lib/amd64/classic/libjvm.so Attempting to locate VM library /opt/apps/java/lib/amd64/server/libjvm.so Attempting to locate VM library /opt/apps/java/lib/amd64/client/libjvm.so Attempting to locate VM library /opt/apps/java/lib/amd64/libjvm.so Attempting to locate VM library /opt/apps/java/jre/bin/amd64/classic/libjvm.so Attempting to locate VM library /opt/apps/java/jre/bin/amd64/libjvm.so Attempting to locate VM library /opt/apps/java/bin/amd64/classic/libjvm.so Attempting to locate VM library /opt/apps/java/bin/amd64/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/amd64/classic/green_threads/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/classic/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/client/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/libjvm.so Attempting to locate VM library /opt/apps/java/lib/classic/libjvm.so Attempting to locate VM library /opt/apps/java/lib/client/libjvm.so Attempting to locate VM library /opt/apps/java/lib/libjvm.so Attempting to locate VM library /opt/apps/java/jre/bin/classic/libjvm.so Attempting to locate VM library /opt/apps/java/jre/bin/client/libjvm.so Attempting to locate VM library /opt/apps/java/jre/bin/libjvm.so Attempting to locate VM library /opt/apps/java/bin/classic/libjvm.so Attempting to locate VM library /opt/apps/java/bin/client/libjvm.so Attempting to locate VM library /opt/apps/java/bin/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/amd64/fast64/libjvm.so Attempting to locate VM library /opt/apps/java/jre/lib/amd64/fast32/libjvm.so Attempting to locate VM library /opt/apps/java/lib/amd64/fast64/libjvm.so Attempting to locate VM library /opt/apps/java/lib/amd64/fast32/libjvm.so Attempting to locate VM library /usr/lib/libgcj.so.7 Attempting to locate VM library /usr/lib/libgcj.so.6 Java Home located in /opt/apps/java +-- DUMPING JAVA HOME STRUCTURE | Java Home: "/opt/apps/java" | Java VM Config.: "null" | Found JVMs: 0 -> as we can see it dosent find my JVM +--- [root@evl3301581 java]# find /usr/java/ -name "libjvm.so" -print && find /usr/java/ -name "libjvm.so" -print /usr/java/jdk1.6.0_39/jre/lib/i386/server/libjvm.so /usr/java/jdk1.6.0_39/jre/lib/i386/client/libjvm.so -> does not work /usr/java/jre1.6.0_38/lib/amd64/server/libjvm.so /usr/java/jdk1.6.0_39/jre/lib/i386/server/libjvm.so /usr/java/jdk1.6.0_39/jre/lib/i386/client/libjvm.so /usr/java/jre1.6.0_38/lib/amd64/server/libjvm.so -> works After doing a find for these files , I see that the files listed above are in a different location, I have tried symlinking the directories And googled an awful lot, any help would be much appreciated. Ma
Re: Stream closed- IOException exception
thanks Mark and Konstantin for your reply If you create the simplest possible JSP that demonstrates the issue (start with the one you have and remove as much as you can) and then post that JSP here, we can take a look. >> as you can see in stacktrace, there are many jsps forwarding request to another jsp, i am not sure how can I post jsp code. also one observation is, there is a struts action forward in between means jsp-> struts action -> jsp , If I remove this action call and include jsp directly in jsp then its working ... whether something wrong with tiles or struts or tomcat .. ? >> stuck on this for long time and need to resolve it ASAP .. please help ... On Fri, Feb 28, 2014 at 2:47 PM, Mark Thomas wrote: > On 28/02/2014 09:11, Prashant Kadam wrote: > > Hi > > > > I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing > > IOException: Stream closed in one of the layout jsp. Underlying > exception > > is jasper exception - *org.apache.jasper.JasperException: > > java.lang.IllegalStateException: Response has already been committed*. > > Same code is working in 7.0.33 so I doubt that it is happening due to > some > > changes in tomcat so I found out the version from this issue starts. > > Everything works perfect till v7.0.37 and problem starts with v7.0.39. > > I started looking the change log for these versions and I can see is > > "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded > URIs > > and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an > > error but will make use of the replacement character when an error is > > detected. This will allow web applications to handle the URI which will > > most likely result in a 404 response. The fall-back to decoding with > > ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 > > sequences in a request body will trigger an IOException.* The way the > > decoder is used has also been improved. The notable change is that > invalid > > sequences at the end of the input now trigger an error rather than being > > silently swallowed. (markt) " > > > > so want to confirm whether this can be the root cause ? > > It doesn't sound like it as you are writing a response body, not reading > a request body. > > > if not what would > > be the issue - as it works till version 7.0.37 and do not work after > > version 7.0.39 ? > > If you create the simplest possible JSP that demonstrates the issue > (start with the one you have and remove as much as you can) and then > post that JSP here, we can take a look. > > > and how to fix this in the code ? > > That will depend on the root cause of the problem. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- ~ Prashant Kadam
Re: Stream closed- IOException exception
also for other navigation in my application, i can see below exception line with all the already posted stack trace ... javax.servlet.jsp.JspException: javax.servlet.jsp.JspException: javax.servlet.jsp.JspException: org.apache.jasper.JasperException: java.lang.IllegalStateException: Exception occurred when flushing data On Fri, Feb 28, 2014 at 5:09 PM, Prashant Kadam wrote: > Please find below stack trace > > > Feb 28, 2014 4:50:10 PM org.apache.catalina.core.ApplicationDispatcher > invoke > SEVERE: Servlet.service() for servlet jsp threw exception > java.io.IOException: Stream closed > at > org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:210) > at > org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:115) > at > org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:190) > at > org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:126) > at > org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:80) > at > org.apache.jsp.features.common.taskpane.viewListPane_jsp._jspService(viewListPane_jsp.java:280) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) > at > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) > at > org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) > at > org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) > at > org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) > at > org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1083) > at > org.apache.struts.tiles2.TilesRequestProcessor.doForward(TilesRequestProcessor.java:159) > at > org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:396) > at > org.apache.struts.tiles2.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:211) > at > com.web.features.common.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:39) > at > org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:232) > at > org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) > at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544) > at > org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:954) > at > org.apache.jasper.runtime.PageContextImpl.doInclude(PageContextImpl.java:684) > at > org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:678) > at > org.apache.tiles.jsp.context.JspTilesRequestContext.include(JspTilesRequestContext.java:103) > at > org.apache.tiles.jsp.context.JspTilesRequestContext.dispatch(JspTilesRequestContext.java:96) > at > org.apache.tiles.renderer.impl.TemplateAttributeRenderer.write(TemplateAttributeRenderer.java:44) > at > org.apache.tiles.renderer.impl.AbstractBaseAttributeRenderer.render(AbstractBaseAttributeRenderer.java:106) > at > org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:670) > at > org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:690) > at > org.apache.tiles.impl.BasicTilesContainer.renderContext(BasicTilesContainer.java:179) > at > org.apache.tiles.template.InsertTemplateModel.end(InsertTemplateModel.java:101) > at > org.apache.tiles.jsp.taglib.InsertTemplateTag.doTag(InsertTemplateTag.java:255) > at > org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_tiles_005finsertTemplate_005f0(leftTaskPane_jsp.java:1132) > at > org.apache.jsp.features.common.leftTaskPane_jsp._jspx
Re: Stream closed- IOException exception
Please find below stack trace Feb 28, 2014 4:50:10 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.io.IOException: Stream closed at org.apache.jasper.runtime.JspWriterImpl.ensureOpen(JspWriterImpl.java:210) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:115) at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:190) at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:126) at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:80) at org.apache.jsp.features.common.taskpane.viewListPane_jsp._jspService(viewListPane_jsp.java:280) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1083) at org.apache.struts.tiles2.TilesRequestProcessor.doForward(TilesRequestProcessor.java:159) at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:396) at org.apache.struts.tiles2.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:211) at com.web.features.common.TilesRequestProcessor.processForwardConfig(TilesRequestProcessor.java:39) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:232) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:954) at org.apache.jasper.runtime.PageContextImpl.doInclude(PageContextImpl.java:684) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:678) at org.apache.tiles.jsp.context.JspTilesRequestContext.include(JspTilesRequestContext.java:103) at org.apache.tiles.jsp.context.JspTilesRequestContext.dispatch(JspTilesRequestContext.java:96) at org.apache.tiles.renderer.impl.TemplateAttributeRenderer.write(TemplateAttributeRenderer.java:44) at org.apache.tiles.renderer.impl.AbstractBaseAttributeRenderer.render(AbstractBaseAttributeRenderer.java:106) at org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:670) at org.apache.tiles.impl.BasicTilesContainer.render(BasicTilesContainer.java:690) at org.apache.tiles.impl.BasicTilesContainer.renderContext(BasicTilesContainer.java:179) at org.apache.tiles.template.InsertTemplateModel.end(InsertTemplateModel.java:101) at org.apache.tiles.jsp.taglib.InsertTemplateTag.doTag(InsertTemplateTag.java:255) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_tiles_005finsertTemplate_005f0(leftTaskPane_jsp.java:1132) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fwhen_005f3(leftTaskPane_jsp.java:1101) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fchoose_005f3(leftTaskPane_jsp.java:1065) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fforEach_005f1(leftTaskPane_jsp.java:932) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_c_005fif_005f2(leftTaskPane_jsp.java:881) at org.apache.jsp.features.common.leftTaskPane_jsp._jspx_meth_widgets_005fsectioncontent_005f1(leftTaskPane_jsp.java:823) at org.apache.jsp.features.common.leftTaskPane_jsp._
Re: Deploying web apps from war file using different url path
Thanks for that, I changed my pom file finalName to look like:
myApp##${version}
This is exactly what I wanted and now my web app in the url is just myApp.
On Fri, February 28, 2014 2:56 am, Mark Thomas wrote:
> On 28/02/2014 10:38, p...@kuruma.co.uk wrote:
>
>> Is there a way to redefine the web app path from within the war file so
>> it always deploys with the build and tomcat uses this instead of the
>> name of the warfile\webapp and there is no changes to the tomcat
>> configuration?
>
> Use the version marker. i.e.:
> myapp##0.0.1-SNAPSHOT.war
>
> Mark
>
>
>
> -
> 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: Deploying web apps from war file using different url path
On 28/02/2014 10:38, p...@kuruma.co.uk wrote: > Is there a way to redefine the web app path from within the war file so it > always deploys with the build and tomcat uses this instead of the name of > the warfile\webapp and there is no changes to the tomcat configuration? Use the version marker. i.e.: myapp##0.0.1-SNAPSHOT.war Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Deploying web apps from war file using different url path
I am trying to work out how I can build my war file and then deploy it using a different path. I have looked at the tomcat docs (specifically): The locations for Context Descriptors are: 1. $CATALINA_BASE/conf/[enginename]/[hostname]/[webappname].xml I want to be able to build a war file with a name like myapp-0.0.1-SNAPSHOT.war and deploy this without having to put myapp-0.0.1-SNAPSHOT into the URL but I also don’t really want to have to change the name of the context file every time I release a new version to tomcat. On a separate note deploying my warfile and adding a context to tomcat\conf\catalina\localhost\myapp-0.0.1-SNAPSHOT.xml the tomcat logs tell me the context is being used but it ignores my path setting and uses myapp-0.0.1-SNAPSHOT which gives me a 404 error for the url I really want: Any help is appreciated as I don’t want to have to set a final name of myapp for the generated war file. Is there a way to redefine the web app path from within the war file so it always deploys with the build and tomcat uses this instead of the name of the warfile\webapp and there is no changes to the tomcat configuration? Thanks - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
2014-02-28 13:11 GMT+04:00 Prashant Kadam : > Hi > > I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing > IOException: Stream closed in one of the layout jsp. Underlying exception > is jasper exception - *org.apache.jasper.JasperException: > java.lang.IllegalStateException: Response has already been committed*. It is odd to have an IOException to "be caused by" IllegalStateException. Is IOException thrown by your code, or by Tomcat's? What is the full exceptions chain here, with stack traces? > Same code is working in 7.0.33 so I doubt that it is happening due to some > changes in tomcat so I found out the version from this issue starts. > Everything works perfect till v7.0.37 and problem starts with v7.0.39. > I started looking the change log for these versions and I can see is > "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded URIs > and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an > error but will make use of the replacement character when an error is > detected. This will allow web applications to handle the URI which will > most likely result in a 404 response. The fall-back to decoding with > ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 > sequences in a request body will trigger an IOException.* The way the > decoder is used has also been improved. The notable change is that invalid > sequences at the end of the input now trigger an error rather than being > silently swallowed. (markt) " > > so want to confirm whether this can be the root cause ? if not what would > be the issue - as it works till version 7.0.37 and do not work after > version 7.0.39 ? and how to fix this in the code ? > > -- > ~ Prashant Kadam - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Stream closed- IOException exception
On 28/02/2014 09:11, Prashant Kadam wrote: > Hi > > I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing > IOException: Stream closed in one of the layout jsp. Underlying exception > is jasper exception - *org.apache.jasper.JasperException: > java.lang.IllegalStateException: Response has already been committed*. > Same code is working in 7.0.33 so I doubt that it is happening due to some > changes in tomcat so I found out the version from this issue starts. > Everything works perfect till v7.0.37 and problem starts with v7.0.39. > I started looking the change log for these versions and I can see is > "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded URIs > and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an > error but will make use of the replacement character when an error is > detected. This will allow web applications to handle the URI which will > most likely result in a 404 response. The fall-back to decoding with > ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 > sequences in a request body will trigger an IOException.* The way the > decoder is used has also been improved. The notable change is that invalid > sequences at the end of the input now trigger an error rather than being > silently swallowed. (markt) " > > so want to confirm whether this can be the root cause ? It doesn't sound like it as you are writing a response body, not reading a request body. > if not what would > be the issue - as it works till version 7.0.37 and do not work after > version 7.0.39 ? If you create the simplest possible JSP that demonstrates the issue (start with the one you have and remove as much as you can) and then post that JSP here, we can take a look. > and how to fix this in the code ? That will depend on the root cause of the problem. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Stream closed- IOException exception
Hi I am in process of upgrading from tomcat 7.0.33 to 7.0.52 but I am facing IOException: Stream closed in one of the layout jsp. Underlying exception is jasper exception - *org.apache.jasper.JasperException: java.lang.IllegalStateException: Response has already been committed*. Same code is working in 7.0.33 so I doubt that it is happening due to some changes in tomcat so I found out the version from this issue starts. Everything works perfect till v7.0.37 and problem starts with v7.0.39. I started looking the change log for these versions and I can see is "Use the newly added improved UTF-8 decoder for decoding UTF-8 encoded URIs and UTF-8 encoded request bodies. Invalid UTF-8 URIs will not cause an error but will make use of the replacement character when an error is detected. This will allow web applications to handle the URI which will most likely result in a 404 response. The fall-back to decoding with ISO-8859-1 if UTF-8 decoding fails has been removed. *Invalid UTF-8 sequences in a request body will trigger an IOException.* The way the decoder is used has also been improved. The notable change is that invalid sequences at the end of the input now trigger an error rather than being silently swallowed. (markt) " so want to confirm whether this can be the root cause ? if not what would be the issue - as it works till version 7.0.37 and do not work after version 7.0.39 ? and how to fix this in the code ? -- ~ Prashant Kadam
