I have a BAT file, which creates a number of csv files by reading DB tables. bcp.exe is used for this purpose, thus, for each CSV created from a table, there’s a separate bcp.exe call. All these are found in the BAT file, which I invoke using Runtime.exec().
Now the issue I face is random. It can’t be recreated in developer environment, but occurs once in a while in the production environment.
Sometimes after the BAT file is executed, only few of the CSV files have been created, and the rest is missing. But when you re-execute the same, you get all the CSVs.
Here’s the code:
String command = "cmd /C " + batFilePath + " " + batParams;
LOGGER.info("Executing : " + command);
Runtime rt = Runtime.getRuntime();
Process process = rt.exec(command);
process.getInputStream();
is = process.getInputStream();
isr = new InputStreamReader(is);
br = new BufferedReader(isr);
String line;
while ((line = br.readLine()) != null) {
LOGGER.info(line);
}
Would really appreciate it if anyone can enlighten me on how this might happen, since I am all at sea regarding this.
Thanks in advance,
-Raj.
Just a couple of points.
The first is that I’ve never understood why Java insists on getting the process’s output stream with
getInputStream– that’s just bizarre. But that’s just me ranting, there’s not much you can do about that 🙂Secondly, I’m not sure why you have a “naked”
process.getInputStream();in your code. I don’t think it’s bad but it seems unnecessary.Thirdly (and, to be honest, this is the only one I think may help), you need to debug the batch file itself rather than your Java code.
This can be done with the following two suggestions.
First, get the error stream and look at it. It’s quite possible that
cmdis delivering error information which you’re just ignoring.Secondly, change the batch file to output copious amounts of debug statements, one after each line if necessary. This will hopefully pinpoint the problem down to a specific place in the batch file.
If it only happens in production (and intermittently), that’s harder, but we generally find that our customers are more than willing to accept debug-style temporary patches so we can collect the information to fix the problems they’re seeing.
Output from a batch file which is simply logged is also a low-risk change. Some debug code is not so low-risk and we have to test that very thoroughly before involving the customer production systems. Some will refuse point blank, a not-unwise position to take.