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,">
    


    

        
(original) (raw)
  
   
   
   
   
 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@oracle.com wrote:  
 
  
   
 
On 2/7/18 3:19 PM, gary.adams@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 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/
>
>