Hi Alan, We have reached out to the AIX team regarding your query and we are waiting their response. Meanwhile, we are also investigating the issue. Based on the logs, it appears that the block is occurring between the close and preClose() calls, ans poll() in a parked state.
Thanks Shruthi ________________________________ From: Alan Bateman <alan.bate...@oracle.com> Sent: Friday, February 14, 2025 2:14 PM To: Shruthi . <shruthi.shrut...@ibm.com>; net-dev@openjdk.org <net-dev@openjdk.org> Cc: Syed Moinudeen <smoin...@in.ibm.com> Subject: [EXTERNAL] Re: Suggestion needed to port the fix to JDK17 and JDK11S This Message Is From an External Sender This message came from outside your organization. Report Suspicious<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!99FRGBbSkiWx1TbZ5KTKMrLTSRtWg0uRPhJQ9gyMzN2en9jnS860BbMMokSeYtQbELmk-cTHRf_7dCL17AOuY030w9uiJjlEIL4sog$> On 14/02/2025 08:18, Shruthi . wrote: Hi Alan, Reordering preClose() in AIX resolves the customer issue. We have validated the fix, and the customer has confirmed it as well. It may have resolved your customer issue but I'm not yet convinced it's a robust workaround for the AIX issue. Can you check with your AIX team on how happens if pthread_kill(thread, SGRTMAX-1) is called and the target thread is in not in the read/write syscalls. It looks to me that the signal won't be handled and the thread may continue on and block in read/write. With your patch then thread calling the close method will do the dup2 and hang as before. It's the window between setting readerThread/writerThread and blocking in the read/write syscalls that you need to look at. -Alan
