This exception is caused by the following reasons.
1. After the client initiates the request again, the server does not wait for the server to finish the response. Click the stop button, causing the server to receive the cancel request. Usually, there will be no such boring user. This situation may be due to the user submitting a request and the server side is slow, such as business logic problems, which causes the page to not be refreshed for a long time, and the user may cancel or re-initiate the request.
2. When the Tomcat server accepts user requests, it has its own processing capabilities. Resource restrictions such as threads and servers. Requests that exceed the scope of Tomcat's carrying capacity will be stopped by tomcat, which may also cause this error.
3. Linux's threading mechanism will cause JVM errors, especially during peak connections, which often occur. Tomcat also has similar situations under Linux.
Java code
- Explanation:
- 2.－－posted by: cooper
- is a clipping from Sun on working around JVM crashes under high
- counts in the JVM 1.3 for Linux
- 5.
- Linux, use a larger signal number for hotspot thread
- /resumption handler. The signal number being used is
- by environment variable _JAVA_SR_SIGNUM. Setting it to a
- larger than SIGSEGV (11) will solve the problem. A good number
- use is 12, which is SIGUSR2. Using signal 16 to work around the
- might have potential problems. So on tcsh, "setenv
- 12._JAVA_SR_SIGNUM 12" can solve the problem.
- sun's explanation:
- －－posted by: cooper
- Below is a clipping from Sun on working around JVM crashes under high
- thread counts in the JVM 1.3 for Linux
- On Linux, use a larger signal number for hotspot thread
- suspension/resumption handler. The signal number being used is
- specified by environment variable _JAVA_SR_SIGNUM. Setting it to a
- number larger than SIGSEGV (11) will solve the problem. A good number
- to use is 12, which is SIGUSR2. Using signal 16 to work around the
- problem might have potential problems. So on tcsh, "setenv
- _JAVA_SR_SIGNUM 12" can solve the problem.
Copy the code
"_JAVA_SR_SIGNUM=12" There must be no spaces on both sides of the equal sign, and the equal sign is a half-width.
material:
The reason why Broken pipe is usually caused by the fact that when the read end of the pipeline is not reading, and the write end of the pipeline continues to have threads writing, the pipeline will be interrupted. (Since the pipeline is unidirectional communication) SIGSEGV (Segment fault) means that the address corresponding to the pointer is an invalid address and there is no physical memory corresponding to the address. The following is the signal explanation of UNIX: 11 / SIGSEGV: Unerlaubter Zugriff auf Hauptspeicher (Adressfehler). 12 / SIGUSER2: User-defined Signal 2 (POSIX). Change _JAVA_SR_SIGNUM to 12 just to make the signal user-defined so that it does not report it, which cannot solve the problem. Recommended methods:
1. The resource has not been completely released, and it must reach the NULL value after use (JAVA's GC is not that perfect)
2. The database connection order is closed! (RS, PS, CONN)
3. Optimize the JAVA virtual machine and add corresponding memory parameters!
4. Don't get large pieces of text in the database (that is, the value of a column should not be too large)
5. JAVA is not recommended to use String to obtain a lot of information. (It is easy to cause memory leakage, it is recommended to use StringBuffer)
6. Repeated submission of the page
7. Try to move METHOD to JAVA. All methods in JSP are regarded as global variables, and there are many problems with the compilation and execution itself.
8. If it is a query function, use non-XA (transaction) as much as possible.
9. Try to use the newer and more stable version of JDK. The lower version of JVM itself also has many bugs, such as garbage collection of 1.5 must be a very obvious improvement compared to 1.2, 1.3.
10. The LINUX system itself is not so stable, and some problems are unavoidable~~:)