RFR: JDK-8031445: Attach on windows can fail with java.io.IOException: All pipe instances are busy

[Gary Adams]

I finally found some time for some additional testing with the fix below.
I could not force the attach error with windows-x64, but did finally
see some failures with windows-x86.

   - I plan to include the ProblemList.txt change for JDK-8057732,
     because this change removed the timeout observed with that test.

   - JDK-8037274 provided an interim change to include GetLastError()
     in the exception message. That explains why sightings were reporting
     different exception messages.

Chris, if you're OK sponsoring this push, I'll send you a cleaned up rebased
patch on Mon.

On 2/7/18, 3:34 PM, gary.adams at oracle.com wrote:
> On 2/7/18 3:19 PM, gary.adams at oracle.com wrote:
>> Hi Gary,
>>
>> I don't think you intended to include the ProblemList.txt changes in
>> your webrev.
> You are right. I was also looking at JDK-8057732 in the same workspace.
> I believe there may have been a windows-x86 issue that may no longer
> be an issue.
>> I think your changes address the "java.io.IOException: CreateNamedPipe
>> failed" failures if a name collision is the cause. This failure mode was
>> extremely rare (only 3 sightings), and if due to a collision, a single
>> retry should suffice in making it not appear again in our lifetime.
>> However, I don't think this addresses the "java.io.IOException: All pipe
>> instances are busy" issue, which seems to the more common failures mode,
>> although also very rare. Have you looked into its potential cause?
> Unfortunately, we no longer have the stack traces from the earlier 
> test failures.
> The one stack trace we do have comes from this same native call to 
> createNamedPipe.
>
> I have not been able to reproduce any of the original reported errors, 
> yet.
> If this is a question of a heavily loaded system contending for a 
> limit number
> of named pipes, the retry should address a number of those race 
> conditions.
> We could also introduce a delay before the retry in case an older 
> process is exiting
> and not getting enough cycles to complete.
>
> Since we're talking about attach operations, I don't think we'll see this
> issue failing in real life situations.
>> thanks,
>>
>> Chris
>>
>> On 2/7/18 8:51 AM,gary.adams at oracle.com  <http://mail.openjdk.java.net/mailman/listinfo/serviceability-dev>  wrote:
>> >/  The IOException that is observed when creating a new named pipe
>> />/  when the pipe already exists and is in use, recommends to retry
>> />/  the operation later. Since we are already using a random number
>> />/  to generate a unique pipe name, it makes sense to simply
>> />/  retry the operation with a new pipe name.
>> />/
>> />/  Here is a proposed fix. Testing in progress.
>> />/
>> />/     Issue:https://bugs.openjdk.java.net/browse/JDK-8031445
>> />/     Webrev:http://cr.openjdk.java.net/~gadams/8031445/  <http://cr.openjdk.java.net/%7Egadams/8031445/>
>> />/
>> />/
>> /
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180323/9fd747ed/attachment.html>