Scenes:
The tomcat service requests the interface of B service
B service interface takes about 20 minutes to process business
But what I see is that the B service interface receives the request, processes the data, and returns
The tomcat service does not normally display the results returned by the interface, resulting in abnormal processing of subsequent businesses.
Locate the relevant code position through the log log. It is found that when curl requests the B service location, the result log cannot be printed normally, no matter how you adjust it, it will not work.
But if the processing time of service B is about 10 minutes, the result can be returned normally
However, if you use curl to directly request service B on the tomcat server, the results can be displayed normally on the console after 20 minutes of processing.
Therefore, it is considered to be a problem with the curl mechanism of java. Finally, I found it on csdn and located the error of jvm.
Use jstack -l java process id to find the following error point
"pool-6-thread-1" #93 prio=5 os_prio=0 tid=0x00007f50a01d6800 nid=0x12d22 in Object.wait() [0x00007f50ed0f0000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
- locked <0x00000006886bea30> (a java.lang.UNIXProcess)
at com.xxxx.framework.utils.HttpConn.execCurl(HttpConn.java:271)
at com.xxxx.framework.utils.HttpConn.postJson(HttpConn.java:250)
at DeviceCollectService.deviceCollectOrgin(DeviceCollectService.java:197)
at DeviceCollectService.lambda$null$5(DeviceCollectService.java:140)
at DeviceCollectService$$Lambda$961/1537756698.accept(Unknown Source)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
atDeviceCollectService.lambda$deviceCollect$6(DeviceCollectService.java:138)
at DeviceCollectService$$Lambda$960/957562996.accept(Unknown Source)
at java.util.HashMap.forEach(HashMap.java:1289)
at .DeviceCollectService.deviceCollect(DeviceCollectService.java:135)
at .DeviceCollectService.access$000(DeviceCollectService.java:38)
at .DeviceCollectService$1.call(DeviceCollectService.java:83)
at DeviceCollectService$1.call(DeviceCollectService.java:79)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
pass
The log found by jstack -l pid is stuck
There are no exceptions in the tomcat log
注意:UNIXProcess.waitFor(UNIXProcess.java:395)
This class was not found in the jdk1.8 package, some said it was reflected
Refer to the following article
related articles:
Java calls RunTime.getRuntime().exec and reports an error at java.lang.UNIXProcess.exitValue
The final approach is:
Read out the wrong stream and then read the input stream
Otherwise, the wrong stream will be blocked because the waiting time is too long, and the pie pipeline is only 4K in length, which will cause the subsequent streams to fail to be read normally.
This problem has actually existed since it went online in June 2021 and has not been located.
I started locating last night. After having previous experience, I quickly located the relevant code block. Coupled with the guidance of the big guys, I was able to solve the problem.