This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.To start at the beginning, follow the link to the first post.The next post in the series is
here.
This series is also available as a podcast on iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
This is pretty simple…a batchlet that uses the Java ProcessBuilder to run a set of commands that get injected from the JSL. You can do things you’d expect like setting environment variables before the command runs and defining a working directory.
You can probably imagine all sorts of things you might want to do with this. Sure you could issue shell commands, but you could also run a script. And a script can do all kinds of things, maybe even launch another JVM…although I don’t know why you’d want to do that.
In any event, you’re pretty much just limited by your imagination. You can use this to run nearly anything asynchronous to the Java Batch job.
Ah…so what does that mean? Well, this is going to launch an entire process that will run separately from the JVM running your Java Batch job. Should you wait for it to complete? The OsCommandBatchlet will wait…for a while. You can specify a timeout after which it will just give up.
That’s kind of interesting. What happens if you give up? You’ve got no idea what happened to the running process. Maybe it died and you didn’t find out? Or maybe it is hung somehow? Will it start running again and finish? Your job has moved on and probably assumed it just didn’t work. Looking a bit closer I see that it does a destroyForcibly( ) on the process when it times out. I wonder how guaranteed that is to work? Ah..there’s a waitFor( ) to wait for it to actually finish so you know it isn’t still out there running. If there’s a chance it doesn’t forcibly end, you’d be stuck there.
So there’s an aspect of this that makes things complicated. It is very handy to do, but error handling can get a little dicey. Your script could leave marker files around to indicate what it did (or didn’t) do. Then after the batchlet says it timed out you could go looking for these little footprints to try and see if there’s anything you need to undo or, well, whatever.
The batchlet also generally assumes that whatever you run will return a zero when it works, but there is a parameter you can inject that indicates what a success would look like, in case whatever you are running returns something else to indicate success.
All in all it seems like a pretty handy way to do something quick, but I think I’d be a bit careful in a production job and worry about error cases.