Fwd: Tomcat Fatal Error
Hi, We are facing the below fatal error in tomcat log file frequently. While the error occurs our tomcat is stopped. Kindly help us on this ASAP. Also paste the /root/hs_err_pid1112.log with this mail. A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b06 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 # # An error report file with more information is saved as: # /root/hs_err_pid1112.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp */root/hs_err_pid1112.log* # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b06 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x0065d800): VMThread [stack: 0x40101000,0x40202000] [id=1114] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00b0 Registers: RAX=0x, RBX=0xf2f51410, RCX=0x, RDX=0x2c22b7a0 RSP=0x40200960, RBP=0x402009b0, RSI=0x, RDI=0x R8 =0x2c23f7c8, R9 =0x0007, R10=0x0005, R11=0x2bc6c030 R12=0xff404040, R13=0xf2f51420, R14=0xfae43ab8, R15=0xf2f51424 RIP=0x2baeed75, EFLAGS=0x00010246, CSGSFS=0xe033, ERR=0x0004 TRAPNO=0x000e Top of Stack: (sp=0x40200960) 0x40200960: 2c22b7a0 f2f51410 0x40200970: fae43ac0 2bb09699 0x40200980: 2c23f7c8 f2f51410 0x40200990: 2c241820 00caea00 0x402009a0: 2c23f7c8 0001 0x402009b0: 40200a30 2bc6c334 0x402009c0: 402009e0 fae22378 0x402009d0: fae22328 0036d251a301 0x402009e0: 40200a10 fae22378 0x402009f0: 2c23f7c8 0x40200a00: 40200ad0 2c241a80 0x40200a10: 2c241a80 0x40200a20: 40200ad0 0001 0x40200a30: 40200a60 2bdf720f 0x40200a40: 40200a60 2c241a80 0x40200a50: 0002 0060df40 0x40200a60: 40200ab0 2bd56892 0x40200a70: 40200a87 6e616c2f6176616a 0x40200a80: 016e697274532f67 0x40200a90: 0060df40 2c241a80 0x40200aa0: 2c241a80 0001 0x40200ab0: 40200b20 2baaeb84 0x40200ac0: 2c241a80 6e616c2f61766100 0x40200ad0: 2c206f90 2bd49f00 0x40200ae0: 2c241a80 40200b01 0x40200af0: 0001 0001 0x40200b00: 0060df40 0x40200b10: 40200b50 096cf700 0x40200b20: 40200ba0 2bab1a0f 0x40200b30: 2c241a80 0001 0x40200b40: 2c241a80 2baaddb2 0x40200b50: 40010100 Instructions: (pc=0x2baeed75) 0x2baeed55: 74 81 48 8b 05 5a 93 72 00 80 38 00 0f 84 b9 00 0x2baeed65: 00 00 41 8b 44 24 08 8b 4a 08 48 d3 e0 48 03 02 0x2baeed75: 48 8b 80 b0 00 00 00 83 e0 07 48 83 f8 05 0f 84 0x2baeed85: 47 ff ff ff 48 83 ef 01 0f 85 3d ff ff ff 48 89 Register to memory mapping: RAX=0x is an unknown value RBX= [error occurred during error reporting (printing register info), id 0xb] Stack: [0x40101000,0x40202000], sp=0x40200960, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 V [libjvm.so+0x617334] MarkSweep::follow_stack()+0x44 V [libjvm.so+0x7a220f] Universe::oops_do(OopClosure*, bool)+0x1f V [libjvm.so+0x701892] SharedHeap::process_strong_roots(bool, bool, SharedHeap::ScanningOption, OopClosure*, CodeBlobClosure*, OopsInGenClosure*)+0x252 V [libjvm.so+0x459b84] GenCollectedHeap::gen_process_strong_roots(int, bool, bool, bool, SharedHeap::ScanningOption, OopsInGenClosure*, bool,
Re: Tomcat Fatal Error
On Dec 23, 2013, at 5:17 AM, CRMG Sysadmin c...@softsmith.com wrote: Hi, We are facing the below fatal error in tomcat log file frequently. While the error occurs our tomcat is stopped. Kindly help us on this ASAP. This is not a Tomcat issue. Your JVM is crashing. See further down for more info... Also paste the /root/hs_err_pid1112.log with this mail. As any FYI, it would seem that you're running Tomcat as root (based on the path listed). This is not a good idea and is almost always unnecessary. A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b06 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 # # An error report file with more information is saved as: # /root/hs_err_pid1112.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp */root/hs_err_pid1112.log* # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b06 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x0065d800): VMThread [stack: 0x40101000,0x40202000] [id=1114] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00b0 Registers: RAX=0x, RBX=0xf2f51410, RCX=0x, RDX=0x2c22b7a0 RSP=0x40200960, RBP=0x402009b0, RSI=0x, RDI=0x R8 =0x2c23f7c8, R9 =0x0007, R10=0x0005, R11=0x2bc6c030 R12=0xff404040, R13=0xf2f51420, R14=0xfae43ab8, R15=0xf2f51424 RIP=0x2baeed75, EFLAGS=0x00010246, CSGSFS=0xe033, ERR=0x0004 TRAPNO=0x000e Top of Stack: (sp=0x40200960) 0x40200960: 2c22b7a0 f2f51410 0x40200970: fae43ac0 2bb09699 0x40200980: 2c23f7c8 f2f51410 0x40200990: 2c241820 00caea00 0x402009a0: 2c23f7c8 0001 0x402009b0: 40200a30 2bc6c334 0x402009c0: 402009e0 fae22378 0x402009d0: fae22328 0036d251a301 0x402009e0: 40200a10 fae22378 0x402009f0: 2c23f7c8 0x40200a00: 40200ad0 2c241a80 0x40200a10: 2c241a80 0x40200a20: 40200ad0 0001 0x40200a30: 40200a60 2bdf720f 0x40200a40: 40200a60 2c241a80 0x40200a50: 0002 0060df40 0x40200a60: 40200ab0 2bd56892 0x40200a70: 40200a87 6e616c2f6176616a 0x40200a80: 016e697274532f67 0x40200a90: 0060df40 2c241a80 0x40200aa0: 2c241a80 0001 0x40200ab0: 40200b20 2baaeb84 0x40200ac0: 2c241a80 6e616c2f61766100 0x40200ad0: 2c206f90 2bd49f00 0x40200ae0: 2c241a80 40200b01 0x40200af0: 0001 0001 0x40200b00: 0060df40 0x40200b10: 40200b50 096cf700 0x40200b20: 40200ba0 2bab1a0f 0x40200b30: 2c241a80 0001 0x40200b40: 2c241a80 2baaddb2 0x40200b50: 40010100 Instructions: (pc=0x2baeed75) 0x2baeed55: 74 81 48 8b 05 5a 93 72 00 80 38 00 0f 84 b9 00 0x2baeed65: 00 00 41 8b 44 24 08 8b 4a 08 48 d3 e0 48 03 02 0x2baeed75: 48 8b 80 b0 00 00 00 83 e0 07 48 83 f8 05 0f 84 0x2baeed85: 47 ff ff ff 48 83 ef 01 0f 85 3d ff ff ff 48 89 Register to memory mapping: RAX=0x is an unknown value RBX= [error occurred during error reporting (printing register info), id 0xb] Stack: [0x40101000,0x40202000], sp=0x40200960, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 V
Re: Fwd: Tomcat Fatal Error
CRMG Sysadmin wrote: Hi, We are facing the below fatal error in tomcat log file frequently. While the error occurs our tomcat is stopped. Kindly help us on this ASAP. May I point out that the log below already provides a link to report the error, which seems to belong to Java itself, not to Tomcat ? Incidentally, it may also be useful to point out, for further reference, that the word ASAP in capitals, tends to elicit negative feelings on a mailing list such as this one, which is staffed by volunteers. Finally, this may also be of help : http://www.catb.org/~esr/faqs/smart-questions.html Also paste the /root/hs_err_pid1112.log with this mail. A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b06 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 # # An error report file with more information is saved as: # /root/hs_err_pid1112.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp */root/hs_err_pid1112.log* # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.0-b06 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x499d75] instanceKlass::oop_follow_contents(oopDesc*)+0x3f5 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --- T H R E A D --- Current thread (0x0065d800): VMThread [stack: 0x40101000,0x40202000] [id=1114] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00b0 Registers: RAX=0x, RBX=0xf2f51410, RCX=0x, RDX=0x2c22b7a0 RSP=0x40200960, RBP=0x402009b0, RSI=0x, RDI=0x R8 =0x2c23f7c8, R9 =0x0007, R10=0x0005, R11=0x2bc6c030 R12=0xff404040, R13=0xf2f51420, R14=0xfae43ab8, R15=0xf2f51424 RIP=0x2baeed75, EFLAGS=0x00010246, CSGSFS=0xe033, ERR=0x0004 TRAPNO=0x000e Top of Stack: (sp=0x40200960) 0x40200960: 2c22b7a0 f2f51410 0x40200970: fae43ac0 2bb09699 0x40200980: 2c23f7c8 f2f51410 0x40200990: 2c241820 00caea00 0x402009a0: 2c23f7c8 0001 0x402009b0: 40200a30 2bc6c334 0x402009c0: 402009e0 fae22378 0x402009d0: fae22328 0036d251a301 0x402009e0: 40200a10 fae22378 0x402009f0: 2c23f7c8 0x40200a00: 40200ad0 2c241a80 0x40200a10: 2c241a80 0x40200a20: 40200ad0 0001 0x40200a30: 40200a60 2bdf720f 0x40200a40: 40200a60 2c241a80 0x40200a50: 0002 0060df40 0x40200a60: 40200ab0 2bd56892 0x40200a70: 40200a87 6e616c2f6176616a 0x40200a80: 016e697274532f67 0x40200a90: 0060df40 2c241a80 0x40200aa0: 2c241a80 0001 0x40200ab0: 40200b20 2baaeb84 0x40200ac0: 2c241a80 6e616c2f61766100 0x40200ad0: 2c206f90 2bd49f00 0x40200ae0: 2c241a80 40200b01 0x40200af0: 0001 0001 0x40200b00: 0060df40 0x40200b10: 40200b50 096cf700 0x40200b20: 40200ba0 2bab1a0f 0x40200b30: 2c241a80 0001 0x40200b40: 2c241a80 2baaddb2 0x40200b50: 40010100 Instructions: (pc=0x2baeed75) 0x2baeed55: 74 81 48 8b 05 5a 93 72 00 80 38 00 0f 84 b9 00 0x2baeed65: 00 00 41 8b 44 24 08 8b 4a 08 48 d3 e0 48 03 02 0x2baeed75: 48 8b 80 b0 00 00 00 83 e0 07 48 83 f8 05 0f 84 0x2baeed85: 47 ff ff ff 48 83 ef 01 0f 85 3d ff ff ff 48 89 Register to memory mapping: RAX=0x is an unknown value RBX= [error occurred during error reporting (printing register info), id 0xb] Stack: [0x40101000,0x40202000], sp=0x40200960, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x499d75]
Re: [OT] EOFException in AjpNioProcessor
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 12/22/13, 8:54 AM, Konstantin Preißer wrote:
Note that the reason for a EOFException is slightly different than
just reading from a stream when there is no more data present.
In Java (and .Net), when you read from a Stream which is finished
(there is no more data present), read() returns -1. Even when you
repeatedly call read(), you will still get -1, but no exception.
Normally you do just while ((read = input.read(buffer)) 0) {
...} to test for the end of stream/data.
It's important to note for beginners that you want the comparison
operator to be = and not just . If you use 0 than you run the
risk of attempting to read from a stream that has stalled and getting
zero bytes (and stopping) when there may future bytes on the stream.
So it seems that contrarily to what I was writing earlier, the EOFexception is thus not an
indication of something wrong in the logic.
After consulting the relevant Javadocs (which I should probably have done before writing
nonsense, mea culpa), I am nevertheless under the impression that there are some
inconsistencies in terms of what one could be expecting (in terms of exceptions) when
reading the HttpRequest input stream. The basic thing seems to be :
- if read() returns n 0, then you have actually read something
- if read() returns n = 0, you have not read anything, but there was no error and there
was no end of file condition. (This should only happen when you are reading from
something in non-blocking mode, though.)
- if read() returns n = -1, then you do not have an error, but you have reached the
end-of-file; and if you read() again, you'll keep getting -1.
- if you get an exception, the basic thing seems to be an IOexception, but then it depends
of the actual sub-class which you are using for the stream, which can redefine this.
And considering how it happens, the EOFexception seems to be really misnamed, because it
is /anything but/ an EOF condition.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
On Dec 22, 2013, at 8:54 AM, Konstantin Preißer kpreis...@apache.org wrote: I suspect the AJP client intentionally closes the connection if e.g. the HTTP client which connected to the outer Webserver (HTTPD, IIS) aborted the HTTP connection (or there was some other error) so this error is reflected at Tomcat (which can therefore throw this exception). Otherwise Tomcat or the Webappp would not know that there was an error and if it e.g. was sending a 10 GB file, it would continue to send it. If this is the case, then shouldn't the AJP client include the AbortException as the 'causedBy' property for the EOFException? The last line in the stack trace is: at org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358) So something went wrong when it tried to read the socket, but I would think there would be some java.net.* or java.io.* exception (ie. AbortException, SocketException) corresponding to that problem. Throwing the EOFException without an associated cause sounds like there is something wrong with the state of the data being received, not with the underlying network socket itself. --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293
Re: EOFException in AjpNioProcessor
Jesse Barnum wrote: On Dec 22, 2013, at 8:54 AM, Konstantin Preißer kpreis...@apache.org wrote: I suspect the AJP client intentionally closes the connection if e.g. the HTTP client which connected to the outer Webserver (HTTPD, IIS) aborted the HTTP connection (or there was some other error) so this error is reflected at Tomcat (which can therefore throw this exception). Otherwise Tomcat or the Webappp would not know that there was an error and if it e.g. was sending a 10 GB file, it would continue to send it. If this is the case, then shouldn't the AJP client include the AbortException as the 'causedBy' property for the EOFException? The last line in the stack trace is: at org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358) So something went wrong when it tried to read the socket, but I would think there would be some java.net.* or java.io.* exception (ie. AbortException, SocketException) corresponding to that problem. Throwing the EOFException without an associated cause sounds like there is something wrong with the state of the data being received, not with the underlying network socket itself. Take this with a grain of salt again, but from the reading I've done, I believe that the EOFexception comes from the class which you use for read()-ing the input stream. It is that class which translates the underlying exception to EOFexception. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jessie, On 12/23/13, 11:45 AM, Jesse Barnum wrote: On Dec 22, 2013, at 8:54 AM, Konstantin Preißer kpreis...@apache.org wrote: I suspect the AJP client intentionally closes the connection if e.g. the HTTP client which connected to the outer Webserver (HTTPD, IIS) aborted the HTTP connection (or there was some other error) so this error is reflected at Tomcat (which can therefore throw this exception). Otherwise Tomcat or the Webappp would not know that there was an error and if it e.g. was sending a 10 GB file, it would continue to send it. If this is the case, then shouldn't the AJP client include the AbortException as the 'causedBy' property for the EOFException? The last line in the stack trace is: at org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358) So something went wrong when it tried to read the socket, but I would think there would be some java.net.* or java.io.* exception (ie. AbortException, SocketException) corresponding to that problem. Throwing the EOFException without an associated cause sounds like there is something wrong with the state of the data being received, not with the underlying network socket itself. What version of Tomcat are you running? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuHAkAAoJEBzwKT+lPKRYWcYQAKJHqK08p7BPk4qNOGPfgbMK VA+DArjK+NnO1tNJxVWjVxDmEsU6SYaVbSveLL8zrXrRMnlRHsjNVF+Vu24clG3c 5FuyYvyNLu970j8AIPgQaKCCwmdd6o7rLoN3UgeUbGrZ5aNu9ov5VnohD4b9/Ftg 13CinwekjbdVoqhbm7BSoIZwXnI2ZgG6we2Lpi5+4DlnLOcAk94CV8sl/WlBIjaN QKxexjEV6sXK76re4ymAWhGk+FqMBH3dyFnFIengyvYlmh1uttVSMvDotvF4qOTm rM4YLSrcGKDYI+52LrRM/+dfFCN2kNAzTIGoNQoLdkr7Gs2FNweozakuKpvsWYhE EQviKWjAJI4dfPYjWeKwpjDOW4pc5hhMRNK1XOxeok4OCIJMRei7b61L67KCyEfq eJsCXFkitXJFlRvxSrK8oWdC915KwpY2x/a8l/6QwYvXBVANawWBNc7uVqcvwfre xayQ+nu1yavrCE5W/oqHdcbdWEMK6ghRQwiMuCmx/HEswY5gWyJ6Vzjcxe00eIbR pjsiXroZE6+HPdVxNyUgRwgIiXi6FRaZbT1lToKt4p/82srhcnO+EkWJazMklEdE V9FvJ45cy+144j7XWksHqIYBiK5E6h9UarBzdf7IEmo+/RXVn3GVIkrLF58HS3UH w0aPhRRCOhadHldbpHPY =Nfr/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: EOFException in AjpNioProcessor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 12/23/13, 12:09 PM, André Warnier wrote:
Jesse Barnum wrote:
On Dec 22, 2013, at 8:54 AM, Konstantin Preißer
kpreis...@apache.org wrote:
I suspect the AJP client intentionally closes the connection if
e.g. the HTTP client which connected to the outer Webserver
(HTTPD, IIS) aborted the HTTP connection (or there was some
other error) so this error is reflected at Tomcat (which can
therefore throw this exception). Otherwise Tomcat or the
Webappp would not know that there was an error and if it e.g.
was sending a 10 GB file, it would continue to send it.
If this is the case, then shouldn't the AJP client include the
AbortException as the 'causedBy' property for the EOFException?
The last line in the stack trace is:
at
org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358)
So something went wrong when it tried to read the socket, but I would
think there would be some java.net.* or java.io.* exception (ie.
AbortException, SocketException) corresponding to that problem.
Throwing the EOFException without an associated cause sounds
like there is something wrong with the state of the data being
received, not with the underlying network socket itself.
Take this with a grain of salt again, but from the reading I've
done, I believe that the EOFexception comes from the class which
you use for read()-ing the input stream. It is that class which
translates the underlying exception to EOFexception.
EOFException is likely being thrown directly from AjpNioProcessor.
This is lines 375-377 of current 7.0.x/trunk:
} else if (nRead == -1) {
//return false;
throw new EOFException(sm.getString(iib.eof.error));
So perhaps Tomcat is using that exception in a way that is unexpected.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSuHOMAAoJEBzwKT+lPKRYu18P/2fadeTxmZpuDTjoUD5U8mG+
ep7ViMTQigSGHo+y45UbwCGrfYtUtpRslqNziLwyrHnwvV6jPGvjsgabUEMWwVK4
OTKFPQVDIJ8TzZMWQSovZDAQCrnbYTirwj1ktVMBIPdtrAAETkaljotPZl5lIbhH
MG2NOp2APkPGofSGGkT0Ke8QuwVOcDaZEtsvE92X3KZDjo3hgenFMZ7nbBaYi1aG
7B7KFPsBzVqTngWVRiv+1kqGtr6lQYYyNVQx+l5Za3IWVeX56TvDMf3nsDQ2eEnB
jiWiIBPxnT9ykptemiQBYv2lw/JYs9MARp7dLj0hMYQUKPpgdVywag0nRH9M9/Y1
x153jT6fy7EZoEu0bQslrSQMS8H2yU8jBqb+EHAih5UVtNLKn2e77/8rUeMI1eI8
KindHFkyIgD4ejpu6HQoKwGYjnsQA6M0UBv8t2TWRSq1ey++bR5Xx6HTUuh/+0SL
xZ1uDARUgEuI9Ai+r+1+M058nbEXBinMjKmBF722WcaIi/SHLBZkJHH25UgJNvjX
EIcY7MozfA/RZ0X6hd8E+TsDI3DC68sbpHS25zDv7XkLzjaijfFnDkdybXIHCh5K
zhJyfqsn6n4R18I5VKKHHqDGRlsgtw2m8gBK3OGkjss9jXJ52sUvj7eYKbW8Z48q
M6BXCMR8U2ukdeGXVvGV
=FZYW
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOFException in AjpNioProcessor
Hi Jesse, -Original Message- From: Jesse Barnum [mailto:jsb_tom...@360works.com] Sent: Monday, December 23, 2013 5:46 PM To: Tomcat Users List Subject: Re: EOFException in AjpNioProcessor On Dec 22, 2013, at 8:54 AM, Konstantin Preißer kpreis...@apache.org wrote: I suspect the AJP client intentionally closes the connection if e.g. the HTTP client which connected to the outer Webserver (HTTPD, IIS) aborted the HTTP connection (or there was some other error) so this error is reflected at Tomcat (which can therefore throw this exception). Otherwise Tomcat or the Webappp would not know that there was an error and if it e.g. was sending a 10 GB file, it would continue to send it. If this is the case, then shouldn't the AJP client include the AbortException as the 'causedBy' property for the EOFException? The last line in the stack trace is: at org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:35 8) So something went wrong when it tried to read the socket, but I would think there would be some java.net.* or java.io.* exception (ie. AbortException, SocketException) corresponding to that problem. Throwing the EOFException without an associated cause sounds like there is something wrong with the state of the data being received, not with the underlying network socket itself. An AbortException or SocketException would mean that there was a problem with the socket so that the connection closed abnormally (which could also happen if there are still bytes to send when the connection is closed by the client, and the linger timeout occurs). However, in the case of the EOFException, the problem is not the socket itself, but that the AJP client which is connected to the socket (HTTPD with mod_jk, IIS with ISAPI Redirector etc.) has unexpectedly closed the connection. This could be thought as of a protocol error. I have not much knowledge about how mod_jk, ISAPI redirectors or other AJP clients work, but if they intentionally close the connection, then I think this is because the AJP protocol does not have a message indicating that the HTTP connection to the client has failed, so it has to close the AJP connection to let Tomcat know there was an error on the HTTP connection side (I also could be wrong here, I'm just guessing). I agree that an EOFException can be a bit misleading in this case, but since it is a subclass of IOException, you should be fine if you already catch IOExceptions. Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Fatal Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 12/23/13, 7:01 AM, Daniel Mikusa wrote: On Dec 23, 2013, at 5:17 AM, CRMG Sysadmin c...@softsmith.com wrote: We are facing the below fatal error in tomcat log file frequently. While the error occurs our tomcat is stopped. Kindly help us on this ASAP. This is not a Tomcat issue. Your JVM is crashing. See further down for more info... +1 A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 I don't recognize this version of the JRE. What version are you actually running? Fortunately there is a stack trace listed here, unfortunately it would seem to indicate that there is a problem during garbage collection. A couple thoughts on this… 1.) Upgrade your JVM. The latest version may have a fix for this bug. 2.) Change your GC options. Seems like you're using the CMS collector. You could try using a different collector or different options for CMS. 3.) Contact your JVM vendor for support. If you have the opportunity (and updating the JVM doesn't fix things), I would highly recommend running memtest86 on your machine and have it run through a few cycles. You may have a bad segment of memory, a bad CPU, or another bad component. JVMs usually don't crash in this way. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuHWUAAoJEBzwKT+lPKRYYQ8QAJWIkIEdGQXxCW2jfZ6Dfhn5 NpoSpvHb595X27ezrT66oVy/l6fccIF28KV5ZFrk5ziAeTR9uq8yjsecJc06SEy9 s7JXFnh/AHNLpTeunQdraHAhv798LFgRg9W72zlAhYlHt+aWWI4yBnxSLp3DgaR/ U4GD9B1ipJQPFRiI6fZylpOxOiHy2SJjApibbTjTmYhKCY+F/UbenHxBfnenp8Jk FWIlS/eQQl7xKAyFqoS5nIX8nyD4Ygrz/+7rXxduVV4slHO/kSY5Wnm/6+/ZZKTv wT7XlgsEtvDueejZhYxy7MTCAGkt18TgYsXoRmxITImH+RfiyvDiPDjedELgiIrh +OiCJUHmzFLLPT8VoBZk7TZExTmoUzrtnIREzoCOgE75RyUWyuUiFSYcg5PGv2S2 Y7JE9ZS3UvA7MZqMDjLgi6SH46/TM6t85ZBn7zOltJmQEbPsrj96fGYNwz6uYTo0 xcB7sBeLq5PFinoJhBy8T/4O63Var+88Npntfj5/5xtbSLBLpYCIuRYpp8xzzVgi kpTG0/feGTwjBwHNBNHubesN1HtKgQ28Ddn2yOVHfFKyGBxZ93EMHZdqpFOG5Ply NuLFgN47o5p7p/8okXP1VJ2ETqYOm2JjVMr80QKVdUVxkRZx8kK42SEjYO+k4cji JW38VogoYRz5qrcVhVN5 =KAmM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Tomcat Fatal Error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 12/23/13, 7:05 AM, André Warnier wrote: May I point out that the log below already provides a link to report the error, which seems to belong to Java itself, not to Tomcat ? I think you get that link no matter why the JVM crashed. For example, when tcnative crashes, I think you still get the Sun bug report link even though the problem isn't in the JVM. Even if the JVM was looking for where the signal was sent (maybe from inside libjvm.so) the cause could be a bad pointer/reference passed-into the JVM or something like that. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuHY+AAoJEBzwKT+lPKRYtUUQAKfG8DQiqWQNmoNifI4rUXdv PqGtnmzB78hOva+IAfgcDH20IAjIxou+vnfdwWB0tP+nt9mVXGewvMJyA3mmYDJA m+xNbZsHlprh2XVrTSi0q77YO6yLW+f4BQbUj03FM3Pop5CeOOiSYVFBlnaHx1VF gwAAPQJEZzfT31bC+xjNzzhfwFQIaOlDtlFJxrnXF6t+4WZE6ovPhfSMaZ/gGSxX mONpxreC49+5mH9lYZ6y4TlXfOf39lByvRPgej6jAbGzk2pqZbkmPMewrqN9BaP7 JHTdVwI7mgl7oXq0r7SbSQXw8p1RndEDfNRQvuSl9Nxcgdqelzj9W+OvxpyhJ5wJ p5I2+cTTntfSc62iQ21bECWM2WaKJdQ/PP9fnj2Pcz2H2HTp+KZrhWF9eRTu/Dnj HykHkOAMCXpmakEMR7Cdn1N/GLuIDRfyKM5U5b133HZiHaSAA4G50vDWL8uypOvR rT+ocCVPYrJDUWxTmd4gaKg0F/f+On1RuGVlW/jRisJVCGxAwLFoSC7sZcwRxsUz ZtWudseAxL3mWswipCZFMqItn5pFIp+EsimFmatP9+zEH9PguPm8QX5YfAuOed2L nRik13bLfh0y2JAtuvCai/xyNdbMRkO7qFRucRoCJLX0oQSW0wIYZ9lJNbBa2Hcl wCM4DNf8jaWS0J6/n06K =ZZOu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: EOFException in AjpNioProcessor
Hi André,
-Original Message-
From: André Warnier [mailto:a...@ice-sa.com]
Sent: Monday, December 23, 2013 6:09 PM
To: Tomcat Users List
Subject: Re: EOFException in AjpNioProcessor
Jesse Barnum wrote:
On Dec 22, 2013, at 8:54 AM, Konstantin Preißer kpreis...@apache.org
wrote:
I suspect the AJP client intentionally closes the connection if e.g. the
HTTP
client which connected to the outer Webserver (HTTPD, IIS) aborted the
HTTP connection (or there was some other error) so this error is reflected at
Tomcat (which can therefore throw this exception). Otherwise Tomcat or the
Webappp would not know that there was an error and if it e.g. was sending a
10 GB file, it would continue to send it.
If this is the case, then shouldn't the AJP client include the
AbortException
as the 'causedBy' property for the EOFException? The last line in the stack
trace is:
at
org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:35
8)
So something went wrong when it tried to read the socket, but I would
think there would be some java.net.* or java.io.* exception (ie.
AbortException, SocketException) corresponding to that problem. Throwing
the EOFException without an associated cause sounds like there is something
wrong with the state of the data being received, not with the underlying
network socket itself.
Take this with a grain of salt again, but from the reading I've done, I
believe
that the
EOFexception comes from the class which you use for read()-ing the input
stream.
It is that class which translates the underlying exception to EOFexception.
In that case, the stacktrace would show that the Exception is thrown in the
webapp's code (and if the Exception is created using a cause, it would show a
Caused by: ... stacktrace showing the original source).
However, the stacktrace from Jesse shows that the EOFException is thrown by
Tomcat's AjpNioProcessor class:
java.io.EOFException
at
org.apache.coyote.ajp.AjpNioProcessor.readSocket(AjpNioProcessor.java:358)
at
org.apache.coyote.ajp.AjpNioProcessor.read(AjpNioProcessor.java:314)
at
org.apache.coyote.ajp.AjpNioProcessor.readMessage(AjpNioProcessor.java:406)
at
org.apache.coyote.ajp.AjpNioProcessor.receive(AjpNioProcessor.java:375)
at
org.apache.coyote.ajp.AbstractAjpProcessor$SocketInputBuffer.doRead(AbstractAjpProcessor.java:1066)
at org.apache.coyote.Request.doRead(Request.java:422)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290)
at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:431)
at
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:315)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:167)
at com.prosc.io.IOUtils.writeInputToOutput(IOUtils.java:49)
at com.prosc.io.IOUtils.inputStreamAsBytes(IOUtils.java:116)
at com.prosc.io.IOUtils.inputStreamAsString(IOUtils.java:136)
at com.prosc.io.IOUtils.inputStreamAsString(IOUtils.java:127)
at com.prosc.licensecheck.LicenseCheck.doPost(LicenseCheck.java:164)
[...]
Lines 351-361 of Tomcat 7.0.35's AjpNioProcessor#readSocket() are as follows:
351 if (nRead 0) {
352 socket.getBufHandler().getReadBuffer().flip();
353 socket.getBufHandler().getReadBuffer().limit(nRead);
354 socket.getBufHandler().getReadBuffer().get(buf, pos, nRead);
355 return nRead;
356 } else if (nRead == -1) {
357 //return false;
358 throw new EOFException(sm.getString(iib.eof.error));
359 } else {
360 return 0;
361 }
Line 358 throws the EOFException because there was no more data to read on the
AJP connection although (I think) the AJP connector expected the client to send
further data (the request body).
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Fatal Error
On 12/23/2013 9:40 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dan, On 12/23/13, 7:01 AM, Daniel Mikusa wrote: On Dec 23, 2013, at 5:17 AM, CRMG Sysadmin c...@softsmith.com wrote: We are facing the below fatal error in tomcat log file frequently. While the error occurs our tomcat is stopped. Kindly help us on this ASAP. This is not a Tomcat issue. Your JVM is crashing. See further down for more info... +1 A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x2baeed75, pid=1112, tid=1075845456 # # JRE version: 7.0-b125 I don't recognize this version of the JRE. What version are you actually running? It's quite a bit worse than that. The original poster is running on Fedora 8 (!?). Fedora has a very short lifespan (approximately 13 months per release). Fedora 20 was just released last Tuesday. If this is a publicly accessible server, it's basically a cracker's paradise. From the OP's logs: OS:Fedora release 8 (Werewolf) The Tomcat version is also old, and appears to be a vendor-repackaged version. From the OP's logs: /var/lib/apache-tomcat-6.0.29 Fortunately there is a stack trace listed here, unfortunately it would seem to indicate that there is a problem during garbage collection. A couple thoughts on this… 1.) Upgrade your JVM. The latest version may have a fix for this bug. 2.) Change your GC options. Seems like you're using the CMS collector. You could try using a different collector or different options for CMS. 3.) Contact your JVM vendor for support. If this is a repackaged version from Fedora, there is no support (regardless of the fact that Fedora 8 was EOL'ed January 7, 2009). If you have the opportunity (and updating the JVM doesn't fix things), I would highly recommend running memtest86 on your machine and have it run through a few cycles. You may have a bad segment of memory, a bad CPU, or another bad component. JVMs usually don't crash in this way. - -chris To the original poster: 1. Update your OS Use a server-grade OS (CentOS if you want a freely available RedHat clone). I like Fedora (use it on my laptop), but it is not a server-grade OS. Even their web site states this. 2. Update your JRE 1.7.0_45 is the latest as I write this. Get it from Oracle. 3. Install Tomcat from tomcat.apache.org 6.0.37 or 7.0.47 (preferred) 4. Don't run as root If you're binding to port 80, investigate JSVC. 5. Fix your web application There are lots of issues here, but first get your infrastructure house in order. Address the first 4, and if the problem persists send a bug report to the link given in the crash report. If there are other Tomcat / application issues, then do the following: 1. give an exact list of the components (OS, JRE, Tomcat) per mailing list instructions 2. paste the offending log into the body of the mail message This list is quite helpful (one of the best IMHO), but no one here (I think) is a mind reader. If it becomes an application issue, then you might get redirected to a more appropriate list (looks like you use Struts). However, there are lots of talented people here who do occasionally give application-level pointers. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What if my database is unavailable at startup?
Barry, You have testOnBorrow=true without a validation query. That means the line is useless. Or as the docs say:* NOTE - for a true value to have any effect, the validationQuery parameter must be set to a non-null string* Best, Alec On Mon, Dec 16, 2013 at 10:07 AM, Propes, Barry L barry.l.pro...@citi.comwrote: -Original Message- From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] Sent: Friday, December 13, 2013 4:23 PM To: Tomcat Users List Subject: Re: What if my database is unavailable at startup? OP, On Fri, Dec 13, 2013 at 2:24 PM, Dames, Kristopher J kristopher.da...@mercy.net wrote: I use tomcat 6 and have noticed if a database is not available when tomcat starts, tomcat will not try to connect once the database becomes available. Tomcat must be restarted to establish the database connection. What are best practices regarding this? Is there a way in tomcat to get it to automatically retry so I don't have to restart tomcat? I use DBCP but am willing to try some other pool. Barry, On Fri, Dec 13, 2013 at 4:59 PM, Propes, Barry L barry.l.pro...@citi.com wrote: I use DBCP and Oracle as well, and am also on Tomcat 6 - 6.0.26. Take a look at mine, as I have NO trouble with it, and see if you can configure it similarly with success. NOTE - remove those other two parameters that Jose mentions in a prior email. Resource auth=Container description=mytomcatapp name=jdbc/myoracle type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver username=username password=password url=jdbc:oracle:thin:@cgnrdb1p:1648:SERVNAME maxIdle=30 maxWait=1 maxActive=10 testOnBorrow=true timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=28800 poolPreparedStatements=true removeAbandoned=true removeAbandonedTimeout=300 logAbandoned=false/ are you suggesting that your (or a correct(ed)) Resource will solve the problem stated in OP (above)? can/should we assume that your URL is referencing a database on a different machine, same network/intranet/LAN? url=jdbc:oracle:thin:@x.y.com:1521:x it seems as though OP is referencing a database somewhere on the 'internet'. -- Oh ok. Yes, mine is on the same network, through an intranet. Different machine, but same network. If that helps. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Non-Blocking IO Write Issue
On Dec 19, 2013, at 8:08 PM, David Bullock david.bull...@machaira.com.au
wrote:
On 20 December 2013 04:10, Daniel Mikusa dmik...@gopivotal.com wrote:
When run, you'll see that it processes some of the requests but fails due to
a timeout. I've not been able to replicate the other exceptions with the
unit test though, so those may be unrelated.
@WebServlet(asyncSupported = true)
public class DataStreamingServlet extends HttpServlet {
@Override
protected void service(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException
{
...
DataStreamWriteListener dswl = new
DataStreamWriteListener(asyncContext, blocks);
response.getOutputStream().setWriteListener(dswl);
}
private class DataStreamWriteListener implements WriteListener {
@Override
public void onWritePossible() throws IOException {
ServletOutputStream output =
context.getResponse().getOutputStream();
Any thoughts on what's happening here?
This is a total guess ... getOutputStream() is waiting on a lock it
will never acquire?
No, it's non-blocking IO so it wouldn't (definitely shouldn't) wait here.
Instead it writes until it's told that it cannot write (output.isReady() ==
false) without blocking. At that point, the container is supposed to call my
code (onWritePossible) once it can write again. Unfortunately, once this
problem starts to occur onWritePossible doesn't get called back.
I did a little more testing and for requests that timeout, it does not appear
that onWritePossible ever gets called. I added some logging to the code to
indicate when it first calls onWritePossible, when it must wait to write more
data and when it's done writing data. While the test is warming up and the
requests are being processed OK, I see all three log statements. Once the
problem manifests, new requests do not trigger any logging. They just timeout
and continue to timeout until I restart the JVM.
(Increase the timeout, do a thread-dump).
When I take a thread dump of the code, it just shows all of the threads doing
nothing. Increasing timeout doesn't seem to help. Failures still occur within
the same timeframe (i.e. same number requests to the server). The only affect
is to create a delay between when requests stop being processed and the stack
trace shows up.
What happens if you instead pass the ServletOutputStream to the
DataStreamWriteListener's constructor?
Unfortunately nothing. I still see the issue.
Thanks
Dan
cheers,
David.
-
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: What if my database is unavailable at startup?
-Original Message- From: Tomcat Random [mailto:tomcat.ran...@gmail.com] Sent: Monday, December 23, 2013 2:56 PM To: Tomcat Users List Subject: Re: What if my database is unavailable at startup? Barry, You have testOnBorrow=true without a validation query. That means the line is useless. Or as the docs say:* NOTE - for a true value to have any effect, the validationQuery parameter must be set to a non-null string* Best, Alec On Mon, Dec 16, 2013 at 10:07 AM, Propes, Barry L barry.l.pro...@citi.comwrote: -Original Message- From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] Sent: Friday, December 13, 2013 4:23 PM To: Tomcat Users List Subject: Re: What if my database is unavailable at startup? OP, On Fri, Dec 13, 2013 at 2:24 PM, Dames, Kristopher J kristopher.da...@mercy.net wrote: I use tomcat 6 and have noticed if a database is not available when tomcat starts, tomcat will not try to connect once the database becomes available. Tomcat must be restarted to establish the database connection. What are best practices regarding this? Is there a way in tomcat to get it to automatically retry so I don't have to restart tomcat? I use DBCP but am willing to try some other pool. Barry, On Fri, Dec 13, 2013 at 4:59 PM, Propes, Barry L barry.l.pro...@citi.com wrote: I use DBCP and Oracle as well, and am also on Tomcat 6 - 6.0.26. Take a look at mine, as I have NO trouble with it, and see if you can configure it similarly with success. NOTE - remove those other two parameters that Jose mentions in a prior email. Resource auth=Container description=mytomcatapp name=jdbc/myoracle type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver username=username password=password url=jdbc:oracle:thin:@cgnrdb1p:1648:SERVNAME maxIdle=30 maxWait=1 maxActive=10 testOnBorrow=true timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=28800 poolPreparedStatements=true removeAbandoned=true removeAbandonedTimeout=300 logAbandoned=false/ are you suggesting that your (or a correct(ed)) Resource will solve the problem stated in OP (above)? can/should we assume that your URL is referencing a database on a different machine, same network/intranet/LAN? url=jdbc:oracle:thin:@x.y.com:1521:x it seems as though OP is referencing a database somewhere on the 'internet'. -- Oh ok. Yes, mine is on the same network, through an intranet. Different machine, but same network. If that helps. OK, thanks for the heads up. I'll remove that attribute as I really don't need it. - 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: Logging makes a grown man cry
Sorry if resurrecting the dead is frowned upon here but I thought I would just add my resolve to this. Honestly, after writing a lot of code otherwise, logging was probably the most frustrating. Tomcat 7.0.42, RHEL 6 1. SL4FJ with Logback works beautifully. 2. I have custom error pages in web.xml that redirect various exceptions to servlets. The servlets capture the exceptions and write them out to different logs using SLF/Logback. 3. The default logging.properties is completely commented out. Note: deleting it is different than it being empty. 4. Since spymemcached logging is baked in, I added SLF as its logger in my ContextInitialized listener: // set SLF4J as the logger for spymemcached Properties systemProperties = System.getProperties(); systemProperties.put(net.spy.log.LoggerImpl, net.spy.memcached.compat.log.SLF4JLogger); System.setProperties(systemProperties); ch.qos.logback.classic.Logger logger = (ch.qos.logback.classic.Logger) LoggerFactory.getLogger(net.spy.memcached); logger.setLevel(Level.ERROR); Cheers, Alec
Re: What if my database is unavailable at startup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Barry, On 12/23/13, 4:14 PM, Propes, Barry L wrote: -Original Message- From: Tomcat Random [mailto:tomcat.ran...@gmail.com] Sent: Monday, December 23, 2013 2:56 PM To: Tomcat Users List Subject: Re: What if my database is unavailable at startup? Barry, You have testOnBorrow=true without a validation query. That means the line is useless. Or as the docs say:* NOTE - for a true value to have any effect, the validationQuery parameter must be set to a non-null string* Best, Alec On Mon, Dec 16, 2013 at 10:07 AM, Propes, Barry L barry.l.pro...@citi.comwrote: -Original Message- From: Howard W. Smith, Jr. [mailto:smithh032...@gmail.com] Sent: Friday, December 13, 2013 4:23 PM To: Tomcat Users List Subject: Re: What if my database is unavailable at startup? OP, On Fri, Dec 13, 2013 at 2:24 PM, Dames, Kristopher J kristopher.da...@mercy.net wrote: I use tomcat 6 and have noticed if a database is not available when tomcat starts, tomcat will not try to connect once the database becomes available. Tomcat must be restarted to establish the database connection. What are best practices regarding this? Is there a way in tomcat to get it to automatically retry so I don't have to restart tomcat? I use DBCP but am willing to try some other pool. Barry, On Fri, Dec 13, 2013 at 4:59 PM, Propes, Barry L barry.l.pro...@citi.com wrote: I use DBCP and Oracle as well, and am also on Tomcat 6 - 6.0.26. Take a look at mine, as I have NO trouble with it, and see if you can configure it similarly with success. NOTE - remove those other two parameters that Jose mentions in a prior email. Resource auth=Container description=mytomcatapp name=jdbc/myoracle type=javax.sql.DataSource driverClassName=oracle.jdbc.driver.OracleDriver username=username password=password url=jdbc:oracle:thin:@cgnrdb1p:1648:SERVNAME maxIdle=30 maxWait=1 maxActive=10 testOnBorrow=true timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=28800 poolPreparedStatements=true removeAbandoned=true removeAbandonedTimeout=300 logAbandoned=false/ are you suggesting that your (or a correct(ed)) Resource will solve the problem stated in OP (above)? can/should we assume that your URL is referencing a database on a different machine, same network/intranet/LAN? url=jdbc:oracle:thin:@x.y.com:1521:x it seems as though OP is referencing a database somewhere on the 'internet'. -- Oh ok. Yes, mine is on the same network, through an intranet. Different machine, but same network. If that helps. OK, thanks for the heads up. I'll remove that attribute as I really don't need it. ... and you'll get the default, which is (wait for it): testOnBorrow=true Are you sure you'll never get a dropped Connection? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSuLBRAAoJEBzwKT+lPKRYuq4P/2TPBX4rXZ+UXe4b/0Ra6O7e jkhNZT6IFC3lsFRXAdpdgNc3Cj0cudLzlfqViOwwAVbWcUSL8SXTaU72Ty9r5rM9 rn2LOBLgn5zIPVTsW25+/AUv+8Ffxjse3tgeWBCAMglxAt6qBtWJoOUEWTw/3UXF m3e8TnKSkpMnLPPUYCWvXoJbp8oBNx6gvBtDLtwMewNZ86E2zzxmdmUPeQA9oJQ9 FHQr6WX8H7f5RjR0oEc9fOLiAHYkxmFDLzsNgXP7aH9VeymNCms9iMc54Ey8SnFP 9Rlthn6Gopg9zOCwgGBJRk3CEQajWVmEOalGCpr4KDt83NMC59OhDwZosBL/k/P9 2x0oEQHW3/zyDT+LOGX1Zphb8OnawUhZ6/ht9Y/QEcmefWsMEBU4tIjSjOLpnCfB KtMhcl4iceTfpOmuFsR7GvwPhJ3JjpfbnPa+WO+W9qFPXeiCyaJK14xPMZo4T8Tu 27V5t8wrbjl57DBrQUScCYsHvOiSodqlI5u1CudojUo6eq8FSPabVHW8utr+S6k9 6cUHcjweqrasXEOILKYuC5v0P+/aTdhJqYL8JK9Jd7Mcn5tzgzTj1r8CWAFPaP40 YB8Psa/Xv0KwQPHB8jcUNQlP4af9TkfVuG4pqzpJ/2YxSXi2/a6uIo0YaN0QqCDB 6XhbjMPhW+TqiBm/oKaW =AzYx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ssl_error_internal_error_alert in tomcat 7
Date: Fri, 20 Dec 2013 14:43:30 -0500 From: ch...@christopherschultz.net To: users@tomcat.apache.org Subject: Re: ssl_error_internal_error_alert in tomcat 7 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thanks for the suggestions!! Jaya, On 12/20/13, 2:13 PM, jaya ravindran wrote: Tried with -ssl3. Got back the following SSL handshake has read 3426 bytes and written 284 bytes --- New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA Server public key is 1024 bit You really need to increase the size of your public key. 1024 bits is considered dangerous these days. Recently, Microsoft Windows (finally!) issued an update that requires all SSL/TLS connections to have 1024 bit key sizes. Any chance you're being bitten by that? These days, I wouldn't use anything less than a 4096-bit server key. Can you re-create your key, cert, etc.? The output of s_client shows you have a self-signed certificate so you shouldn't have any problem doing that. Perhaps it will fix everything. (?) Changed key size is not fixing the problem. I Secure Renegotiation IS supported SSL-Session: Protocol : SSLv3 Cipher: EDH-RSA-DES-CBC3-SHA Session-ID: 52B4960B812952824F26DCA6DB67455143F624E615D1CAADA39E2831676944C7 Session-ID-ctx: Master-Key: A871539A23FD30DB1336B8B95AF50026DEDC0ADA79B80706E9B8CAA5E59E90AFAA2BEC8FA60FCCF32C0415EEA4D6F21B Key-Arg : None Start Time: 1387566603 Timeout : 7200 (sec) Verify return code: 19 (self signed certificate in certificate chain) The verify return code is different -- not sure what the difference between 18 and 19 is -- but otherwise things look okay to me. Is the site public? If so, can you email me the URL privately and I can take a look? Not a public site. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJStJ3iAAoJEBzwKT+lPKRY6hgP/2JxByzzNVwsAOowrzBVV8z3 nqP6DC8j+UoFsHBes946ofAi8o2uc7TIJ/TTW4ylf7OIc4sTGOV6X9pn68lHR4io 3ZzMgBHbuSAmVazVNa+7Syy1LkxfzT6fnD8NXF70M10r0XUTVJRGVBRqMbhxdAsj 4swWydanJz0Yjqbbn4vWZnvIMuwa4cKUCyLOwvKZwWTjtXqfZj3z7n6eiyHt9kBN Mo2BCrJpG52OBesELkTWZuawFm3Wpar0KaDm+34ve139lf2IOqqwoW3uXyLYfRTM BR0/2OxxY/KxwHUgsllgk6yOmKsdxvphAAVJKTWdl3J0I0EpaSvXBDXnJGGes6cl 6yhpITtmjx9xbrRuWWqvie5QWiZ3PxwoR8lsOR1tbLxeRSxgGsQ1KtjV5YSsmfb/ n3D/jhYevUYurE59gAjOSQqpLF+LYTVqhM4lNVGaGTMkDissCC/w9TIzZoJPK7UL d/Dh9+cpN2U0IqpV7QMwDu38rLetR+KqZYolFoTTdHBgc/q7R9r2y1vTdihK2NgL JJ98TQXRJ1v8iqfWenRSBgwFvCPzeATskYphxZHl3ANPQK218BlOUrc8TJTU5Dip 9d6VWlKdSqVgpzc/2FYhe9QoP9KlFj96NqlSw54Fw+g+zjD7VAILLrYX1GLWSd3t EkRYC/2aSmjZQu87Fb2P =y0Tn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Non-Blocking IO Write Issue
On 24 December 2013 07:58, Daniel Mikusa dmik...@gopivotal.com wrote: On Dec 19, 2013, at 8:08 PM, David Bullock david.bull...@machaira.com.au wrote: On 20 December 2013 04:10, Daniel Mikusa dmik...@gopivotal.com wrote: Unfortunately, once this problem starts to occur onWritePossible doesn't get called back. When I take a thread dump of the code, it just shows all of the threads doing nothing. Increasing timeout doesn't seem to help. Failures still occur within the same timeframe (i.e. same number requests to the server). The only affect is to create a delay between when requests stop being processed and the stack trace shows up. What happens if you instead pass the ServletOutputStream to the DataStreamWriteListener's constructor? Unfortunately nothing. I still see the issue. OK, new theory. At some point, something happens in your onWritePossible handler which throws an unchecked exception and crashes the Tomcat thread which is responsible for keeping track of which async servlets are still wanting to write data and doing appropriate cleanup of the NIO selectors/keys. My money would have been on calling getOutputStream() on the response a second time (it throws java.lang.IllegalStateException, which is unchecked), but you say you got rid of that. To eliminate other unchecked candidates, make your onWritePossible() catch java.lang.Throwable and emit appropriate log messages if it catches anything (or more usefully, point a debugger at the catch clause). If that doesn't yield success, then I would like to see 2 thread dumps - once when onWritePossible() has been called (maybe put in a Thread.sleep(5000) so you have time to tickle the JVM), and once when it is in the failure state. (one in the starting-to-fail state would be good too). cheers, David. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
