Isolating tests from general concurrency

[Igor Ignatyev]

Jon,

in vm-testbase we used to have 'nonconcurrent' k/w to get concurrency=1 for specific tests. the keyword was recognized by test harness, and all "nonconcurrent" tests were moved to the end of execution queue and started only after all "concurrent" tests finish their execution. although this would have a side effect on test execution order, I don't think it should be a problem for us as AFAIK jtreg doesn't guarantee any particular order, and the solution is nice and simple and it shouldn't be hard to implement the same/similar logic in jtreg.

-- Igor

(sorry if it creates another email thread, I subscribed to the list after the discussion had started) 
On 3/19/19 12:56 PM, Jonathan Gibbons wrote:
> On 3/19/19 12:03 PM, Gary Adams wrote:
>> A recent question came up about how the exclusiveAccess.dirs property 
>> was being used to 
>> prevent concurrent tests from using some critical resource. It appears 
>> that some of 
>> the hotspot/jtreg/vmTestbase tests were setting the property assuming 
>> they would get 
>> a concurrency=1 type of behavior. 
>> 
>> I'd like to start the discussion about how the current feature works 
>> and see 
>> if a new feature might be appropriate for other related use cases. 
> The feature was originally created for tests that needed exclusive access to specific system resources: specifically, fixed ports in RMI/networking tests. To some extent, it was a quick stop-gap measure, to avoid having to rewrite those tests in short order to use dynamically allocated ports. The need for "concurrency=1" behavior is new/different. Previously, all tests wanting exclusive access had to opt-in to the feature.  To support "concurrency=1", there's an implicit need to check any interlock on all tests that don't request "concurrency=1".
> -- Jon