Java uses curl timeout and no return result problem There is a request without response stuck problem

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:

Remember once JAVA uses ProcessBuilder to execute Shell task stuck problem analysis_scx_white's Blog-CSDN Blog_java processbuilder stuck

Java calls RunTime.getRuntime().exec and reports an error at java.lang.UNIXProcess.exitValue

java – Runtime.getRuntime().exec hangs and executes blocking problem during loading, need to get execution result_ai_lian_shuo's blog-CSDN blog_java runtime.getruntime.exec

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. 

Guess you like

Origin blog.csdn.net/wdd668/article/details/126889566