[ 
https://issues.apache.org/jira/browse/GEODE-10499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jinwoo Hwang reassigned GEODE-10499:
------------------------------------

    Assignee: Jinwoo Hwang

> java.net.BindException: Address already in use in 
> PartitionedRegionAttributesMutatorTest during concurrent execution
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: GEODE-10499
>                 URL: https://issues.apache.org/jira/browse/GEODE-10499
>             Project: Geode
>          Issue Type: Bug
>            Reporter: Jinwoo Hwang
>            Assignee: Jinwoo Hwang
>            Priority: Major
>
> h2. Problem
> The {{PartitionedRegionAttributesMutatorTest}} is experiencing 
> [java.net.BindException: Address already in use (Bind 
> failed)|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
>  errors when running in concurrent execution environments. This issue occurs 
> when multiple test instances attempt to bind to the same port simultaneously, 
> leading to port conflicts and test failures.
> The error indicates that the current port allocation mechanism is not 
> providing sufficient isolation between concurrent test executions, 
> particularly in CI/CD environments where multiple test suites run in parallel.
> h2. Steps to Reproduce
>  # Run multiple instances of PartitionedRegionAttributesMutatorTest 
> concurrently:
>  
>  
> ./gradlew test --tests "*PartitionedRegionAttributesMutatorTest*" --parallel
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  *  
>  *  
>  *  
>  * 
>  
>  # Or run the full test suite with parallel execution enabled
>  # Observe BindException failures related to port conflicts
> h2. Error Details
>  
>  
> java.net.BindException: Address already in use (Bind failed)
>     at java.net.PlainSocketImpl.socketBind(Native Method)
>     at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
>     at java.net.ServerSocket.bind(ServerSocket.java:375)
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  *  
>  *  
>  *  
>  * 
>  
> h2. Root Cause
> The current port allocation strategy does not provide adequate isolation for 
> concurrent test execution, leading to multiple tests attempting to bind to 
> the same ports simultaneously.
> h2. Proposed Solution
> Integrate the enhanced 
> [TestSafePortSupplier|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
>  class (already implemented in geode-junit) which provides:
>  * Process-specific port ranges to avoid conflicts
>  * Thread-safe port allocation with retry logic
>  * Cross-process coordination via port registry
>  * Better port availability validation
> h2. Technical Details
> The 
> [TestSafePortSupplier|vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html]
>  addresses this issue by:
>  * Allocating unique port ranges per process (1000 ports each)
>  * Using atomic counters for thread-safe port selection
>  * Implementing retry logic with exponential backoff
>  * Maintaining a registry of used ports across processes
> h2. Acceptance Criteria
>  *  PartitionedRegionAttributesMutatorTest passes consistently in concurrent 
> environments
>  *  No BindException errors related to port conflicts
>  *  Tests can run in parallel without port collisions
>  *  Backward compatibility maintained with existing test infrastructure
>  *  Performance impact is minimal (< 5% test execution time increase)
> h2. Environment
>  * {*}Project{*}: Apache Geode
>  * {*}Test Class{*}: PartitionedRegionAttributesMutatorTest
>  * {*}Issue Type{*}: Concurrency/Port Conflict
>  * {*}OS{*}: All supported platforms (Linux, macOS, Windows)
>  * {*}JVM{*}: All supported versions
> h2. Priority
> *High* - Blocking parallel test execution and CI/CD pipeline reliability



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to