jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: svn commit: r1849687 - in /jmeter/trunk: src/functions/org/apache/jmeter/functions/FileRowColContainer.java test/src/org/apache/jmeter/functions/TestFileRowColContainer.java xdocs/changes.xml
Date Wed, 02 Jan 2019 23:29:47 GMT
On Wed, 2 Jan 2019 at 19:12, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
>
>
> Am 01.01.19 um 21:40 schrieb sebb:
> > On Sun, 30 Dec 2018 at 16:12, Felix Schumacher
> > <felix.schumacher@internetallee.de> wrote:
> >>
> >> Am 29.12.18 um 12:15 schrieb Philippe Mouawad:
> >>> Hello Felix,
> >>> I made a commit yesterday illustrating what I was proposing.
> >>> Nightly builds passed but It may be too early to conclude.
> >>> Does it look ok to you ?
> >> I hadn't thought about that interface. It will probably lessen the
> >> chance that we hit the bug in our setup, but it is still present for all
> >> systems, that don't know about the semantic of that interface.
> > Huh?
> >
> > I don't follow.
> >
> > What bug are you referring to?
>
> We still have the bug I described, in my previous mails, that the script
> base might be set to null, when the test cases are ran concurrently. The
> interface marker we are using now is used by our test runner, only.

OK, I see.

There does not seem to be a standard way to flag JUnit tests that must
be run sequentially.
It looks like Maven Surefire can use @NotThreadSafe [1] but this does
not seem to fully solve all such issues.

Whilst the current solution works, it might perhaps be worth
considering using the annotation instead of the JMeter-specific
interface.

[The standard JCIP annotations use Retention=Runtime which means the
jar must be present at run-time.
That would be a nuisance for the main JMeter code, but not really an
issue for tests.]

Until such time as JUnit fully supports serial running, I suspect the
only way that works with all test runners would be to implement
locking for the tests that need to run serially.
This would be more complicated and would affect the parallelism, but
would potentially allow for several different locks where the tests
exercise un-related code.

[1] http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Parallel_Test_Execution_and_Single_Thread_Execution

> Felix

<snip/>

Mime
View raw message