batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Douglas <brent.n.doug...@gmail.com>
Subject Fwd: #stop behaviour in the RI and BatchEE
Date Sun, 08 Mar 2015 12:29:23 GMT
Hi all,


I sent this to Romain originally and at his request I will copy it here (it
is copy/pasted from later in the email chain):

>>START COPY

While poking around how #stop works in the RI and BatchEE I noticed what
looks like a couple of race conditions in the stop handling.

Firstly in BaseStepController there is bit that looks like this:

            transitionToFinalBatchStatus();
>             defaultExitStatusIfNecessary();
>             persistExitStatusAndEndTimestamp();


If #stop is called between the part in #transitionToFinalBatchStatus where
the BatchStatus is set and when persistExitStatusAndEndTimestamp actually
reads the BatchStatus the step will end with a status of STOPPING.

Secondly in ExecutionTransitioner is this method:

    public ExecutionStatus doExecutionLoop() {
>         //snip
>         while (true) {
>             // a
>             final ExecutionElementController currentElementController =
> getNextElementController();
>             currentStoppableElementController = currentElementController;
>             // b
>             currentStoppableElementController = null;
>             // c
>         }
>     }


Calling #stop reads currentStoppableElementController which, if I'm reading
this correctly, can be null even when there is another element to be
executed meaning that if #stop is called while transitioning between
elements this (section a or c) the job is not going to be stopped.

>> END COPY

I have attached a patch for the second issue.

I also get an (unrelated) NPE when building the CLI module:


[ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (default) on project batchee-cli: Error rendering velocity resource.
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (default) on project batchee-cli: Error rendering velocity resource.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering
> velocity resource.
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1246)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:520)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at java.util.ArrayList.removeAll(ArrayList.java:689)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers(DefaultMavenFileFilter.java:216)
> at
> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:84)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.copyResourceIfExists(ProcessRemoteResourcesMojo.java:884)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1139)
> ... 22 more


That's using jdk8u25 and mvn 3.2.2.

Brent


---------- Forwarded message ----------
From: Romain Manni-Bucau <rmannibucau@gmail.com>
Date: Sun, Mar 8, 2015 at 8:00 AM
Subject: Re: #stop behaviour in the RI and BatchEE
To: Brent Douglas <brent.n.douglas@gmail.com>


Please fwd it to batchee list im in holidays this week with no computer.
Back the week after to help.

Ps:  npe is of course an issue ;)
Le 8 mars 2015 02:21, "Brent Douglas" <brent.n.douglas@gmail.com> a écrit :

Hi Romain,
>
> I've attached a patch for the second issue.
>
> Btw I get an NPE when building the CLI module.
>
> Brent
>
> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
>> (default) on project batchee-cli: Error rendering velocity resource.
>> NullPointerException -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
>> goal org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
>> (default) on project batchee-cli: Error rendering velocity resource.
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>> at
>> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:483)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
>> Caused by: org.apache.maven.plugin.MojoExecutionException: Error
>> rendering velocity resource.
>> at
>> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1246)
>> at
>> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:520)
>> at
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>> ... 19 more
>> Caused by: java.lang.NullPointerException
>> at java.util.Objects.requireNonNull(Objects.java:203)
>> at java.util.ArrayList.removeAll(ArrayList.java:689)
>> at
>> org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers(DefaultMavenFileFilter.java:216)
>> at
>> org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:84)
>> at
>> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.copyResourceIfExists(ProcessRemoteResourcesMojo.java:884)
>> at
>> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1139)
>> ... 22 more
>
>
>
> On Sat, Mar 7, 2015 at 10:19 PM, Brent Douglas <brent.n.douglas@gmail.com>
> wrote:
>
>> I might later tonight, they both look pretty easy to solve but as you
>> say, it's unlikely they will actually crop up as an actual issue.
>>
>> Brent
>>
>> On Sat, Mar 7, 2015 at 10:13 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>
>>> Hi Brent
>>>
>>> I think you are right but it also depends the usage and backend
>>> configuration but by default your observation sounds right. Even if it is a
>>> very no luck case we can surely enhance it a bit - do you want to propose a
>>> patch?
>>>
>>> However note that fixing it completely needs a global
>>> locking/transaction mecanism which in practise is rarely needed - only saw
>>> it needed in advanced unit tests but not in real life cases. For batchee i
>>> am tempted to propose it as a flag off by default to not break existing
>>> behavior.
>>> Le 7 mars 2015 19:59, "Brent Douglas" <brent.n.douglas@gmail.com> a
>>> écrit :
>>>
>>> Hi Scott and Romain,
>>>>
>>>> While poking around how #stop works in the RI and BatchEE I noticed
>>>> what looks like a couple of race conditions in the stop handling.
>>>>
>>>> Firstly in BaseStepController there is bit that looks like this:
>>>>
>>>>             transitionToFinalBatchStatus();
>>>>>             defaultExitStatusIfNecessary();
>>>>>             persistExitStatusAndEndTimestamp();
>>>>
>>>>
>>>> If #stop is called between the part in #transitionToFinalBatchStatus
>>>> where the BatchStatus is set and when persistExitStatusAndEndTimestamp
>>>> actually reads the BatchStatus the step will end with a status of STOPPING.
>>>>
>>>> Secondly in ExecutionTransitioner is this method:
>>>>
>>>>     public ExecutionStatus doExecutionLoop() {
>>>>         //snip
>>>>         while (true) {
>>>>             // a
>>>>             final ExecutionElementController currentElementController =
>>>> getNextElementController();
>>>>             currentStoppableElementController =
>>>> currentElementController;
>>>>
>>>>             // b
>>>>
>>>>             currentStoppableElementController = null;
>>>>
>>>>             // c
>>>>         }
>>>>     }
>>>>
>>>> Calling #stop reads currentStoppableElementController which, if I'm
>>>> reading this correctly, can be null even when there is another element to
>>>> be executed meaning that if #stop is called while transitioning between
>>>> elements this (section a or c) the job is not going to be stopped.
>>>>
>>>> I'm not familiar with these code bases though and I didn't really look
>>>> at it super hard so feel free to disregard this if I'm reading it wrong.
>>>>
>>>> Brent
>>>>
>>>
>>
>

Mime
View raw message