Reputation: 20012
I have simple Java Class with a main function. I run this class with command-line 'command' which is present in the bat file, I have scheduled the bat file to run after every 2 hours.
This .class uses some resources which some time are not available at the request and due to timeout the .class terminated abnormally.
What I want to is if the bat terminates abnormally is there a way to check it and run it again until it runs properly.
Secondly if the bat terminates abnormally, is there a way to roll back the operations this .class performed before terminating. Lets say it was updating some text in a text file. Is there a way to roll it back.
Upvotes: 0
Views: 904
Reputation: 502
It sounds like the bat fails because the java class job fails. If failure of the java job can be detected inside the batch file, you should be able to do everything you want from there.
First, to confirm the java job raises an error the batch identifies, add the following after the line that runs the java class job and test it. You should see errorlevel 0 with success and >0 with error:
REM THIS IS LINE THAT RUNS JAVA JOB
echo errorlevel is "%errorlevel%
pause
Assuming the above returns accurate exit info, here's some code that implements the other answers and reruns the java job.
To continuously rertry the java job until it runs successfully, add a label and a goto statement:
REM Add following label to a line before the java class job
:runhere
REM THIS IS LINE THAT RUNS JAVA JOB
rem Check errorlevel and retry if failure
If not %errorlevel%==0 goto runhere
Exit
To rertry the job n times and then quit even if not yet successful, create backup file as @niebloomj suggests and set a counter. This tries to run the job 10 times.
set COPYCMD=/Y
set Outputfile=path\file.ext
set Outputbak=path\file_bak.ext
copy "%Outputfile%" "%Outputbak%"
Set /a count=0
:runhere
REM THIS IS LINE THAT RUNS JAVA JOB
If %errorlevel%==0 (
:: now have new good output file
del "%Outputbak%"
exit
)
rem Check count and retry
If %count% LSS 10 (
set /a count+=1
goto runhere
)
rem When count = the "check" number above, replace old file and quit
copy "%Outputbak%" "%Outputfile%"
del "%Outputbak%"
echo Java job failed after retries. "%Outputfile%" not updated.
pause
Exit
Upvotes: 1
Reputation: 46
If you want to have a .bat run continuously until it runs properly after crashing you can achieve this by creating a windows service. When you create the windows service you can specify what happens after crashing, how long to wait before running the script again, and how many times it should try to run the script again.
As far as reverting what a script has done to a textfile, there are multiple solutions:
Have your script make a copy of the file, you can rename it original_new, and manipulate the new copy. At the end of the script you can have it delete the original and replace it with the copy by changing original_new to original. In case the program crashes, you will have two files, so at the beginning of your script, check to see if original_new already exists, if it does, delete it then copy the original.
You can keep a record log of everything the script does and on the startup of the script it checks the log and if the log is incomplete then the script first reverts any of the logs until it reaches the last complete sign and then runs the actual intension of the script.
Upvotes: 1
Reputation: 121710
There are many causes of abnormal termination.
There is a heuristic that you can adopt here:
OutOfMemoryError
; understand that by "an exception" in the statement above, it is "any instance of Throwable
"; Error
is a subclass of Throwable
, OutOfMemoryError
is a subclass of Error
;System.exit()
and ensure that the error code is something other than 1 because of the above.Secondly if the bat terminates abnormally, is there a way to roll back the operations this .class performed before terminating. Lets say it was updating some text in a text file. Is there a way to roll it back.
No generic way; this really depends on your program itself. If you are talking about file I/O, there exist several paradigms to ensure that the original contents of files do not end up corrupted, at least as far as the programming language itself is concerned; more severe corruption scenarios are delegated to the filesystem itself.
Side note about exit codes... At least with Unix systems, you should be wary that in fact "valid" exit codes range from 0 to 127; yes, that is 7 bits. The 8th bit is there to signal that the process termination is due to a signal, in which case the lower 7 bits are to be interpreted (understand, "read") as the signal number which triggered program termination.
Upvotes: 3