This is regarding the quirky behavior of running jars with Windows Task Scheduler where the application uses java.io.
I have many tasks set up in Windows Task Scheduler, some of them run node scripts, some of them run java jars. They all run according to the specified triggers without problem, except for a task which uses this one unruly jar. The task in question is configured correctly, no differently than any of the others which run successfully (and the other jars also produce logs, and read and write files with one minor difference noted below).
The specific problem is Task Scheduler reports "The operation completed successfully." but the application appears as if it hadn't started (logs and output file missing). And it's very confusing because it will produce the desired results infrequently but normally it does not. Event Viewer offers no insight into any possible problem sources.
The OP noted the jar runs when java.io is not used and my problematic jar had java.io imports in the main class (my other jars which ran without issue did not have any java.io imports in the main class). The few lines of code using java.io were moved from the main class to another class and all imports deleted. The application started running again, producing the logs and output file. But why, I ask?
Can anyone offer any insight as to what is possibly going on? Is there a known quirk running jars in Task Scheduler when using java.io in the main class? Is there some type of conflict between the JVM and Windows?
I sounds like to the resolution for the problem in the other thread was to specify the working directory for the application; presumably a location where the application would have permissions to perform the java.io operations. Have you tried that already?
posted 3 weeks ago
Hi Ron, thanks for responding.
Yes, I did specify the working directory, as well as double and triple check all of the task settings to make sure everything was set up correctly. Permissions are set up correctly. It's all good. The other tasks which run jars are set up the exact same way and they don't have the same problem, and they do very similar things all on the local machine - reading and writing and web stuff. Event Viewer doesn't show any abnormalities. It's very confusing. The only major difference is java.io code and imports in the main class of the jar in question.
I should note that this problem is resolved. I didn't make that extremely obvious in the first post. The resolution was to remove all of the imports and java.io code from the main class and place them in another class.
There may be no easy answer to this. But I'm trying to find out what may be causing this. Maybe the resolution didn't work at all and my machine is playing games with me. If it's one of those things where the only insight I could get out of it is "it works now. note it and move on", that's fine. I can deal with that. But my hope is this is not uncommon and there is a way to understand why this is happening so I can build better, more stable, applications.
David Gillette wrote:The resolution was to remove all of the imports and java.io code from the main class and place them in another class.
Well, I highly doubt that some along those was even the issue in the first place.
First of all: Any imports are resolved at compile time and replaced with fully qualified class names - so it's only a help for the compiler where to search for classes wich in turn grants us as developers the convenience of not have to type full class names each time but only the name of the class without any package. When you look into a class file you will always find all references are fully qualified class names with thier package names. So, importing something or not doesn't change the resulting class file at all.
Next: As it was mentioned in the linked thread: it's most likely an issue with the working directory and permissions - and most likely some was changed when code was moved from main class to another class. It doesn't magically change how Java behaves only cause you move code from main() into any other place - it will still produce the same bytecode wich is executed the same way by the interpreter. So, this lead to clearly what you might see as a potential issue isn't what it's causing it but something other that got changed along the movement.
But, for god's sake, I tested it on my local Win7 system. I created a simple jar wich just access a file given by an absolute path and ran that from task scheduler - worked without any issue. It even worked accross mounted CIFS/SMB share on a linux system. So, it's clearly neither anything about imports (as they get resolved at compile time) or any class in java.io package. The only other thing that's now left are try to access files from a relative path in wich the user has no write permissions. I guess this "mytery" can easy be solve if you provide old code when it was in main() vs new code after moving - can't be anything other than a wrong path relative to a wrong set working directory.
I'd agree with all of that, except that the OP claimed that the original "bad" version worked intermittently. So to me there's still a bit of a mystery.
posted 1 week ago
Thanks for the thoughtful reply and taking the time to try to reproduce this.
I understand the import statements could not have caused the problem. I suppose that was just a poorly worded explanation on my part. But as Paul noted, the mystery still exists. Here's why: I can firmly assert beyond any doubt the few lines of java.io code were merely moved out of the main class and nothing was changed other than that (that and the single line calling the new class) and I have other tasks doing approx the same thing operating as expected. As far as permissions go they are setup correctly. The application is running under the correct credentials and reading and writing is happening on that user account in a directory where the it has full rights. It's craziness, I know...
I don't think it's fair to ask for insight without providing code or environment details. So I'm going to create a mockup, reproduce the problem, and then I'll post the code, environment details, and task scheduler settings so hopefully this can be reproduced on another machine.
Good luck with reproducing the problem; glitches which happen intermittently are the devil to reproduce. I think there's even a good chance that just removing the Task Scheduler entry and replacing it might have fixed the problem. Or recompiling the Java code without any changes and replacing it in Task Scheduler.
Do not threaten THIS beaver! Not even with this tiny ad: