Isolating tests from general concurrency

[gary.adams at oracle.com]

I have not looked into the current exclusiveAccess.dirs implementation
but I assume it requires some ordering of tests to ensure that none of the
tests in the set of excluded directories runs more than one test at a time.
Or is the locking mechanism local to each of the excluding directories?

How is the queue managed when normally concurrent tests are launched?
Instead of waiting til the end, a test requiring concurrency=1 could 
simply wait
for the queue to drain before being launched.


On 3/19/19 5:06 PM, Jonathan Gibbons wrote:
> Igor,
>
> What you suggest is not easy given the way jtreg currently runs 
> tests.  I'm not saying we can't support "nonconcurrent" tests, but I 
> doubt that we would do it as you describe.
>
> -- Jon
>
> On 3/19/19 2:03 PM, Igor Ignatyev wrote:
>> 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