Coded Smorgasbord: Archive This

Michael W came into the office to a hair-on-fire freakout: the midnight jobs failed. The entire company ran on batch processes to integrate data across a dozen ERPs, mainframes, CRMs, PDQs, OMGWTFBBQs, etc.: each business unit ran its own choice of enterprise software, but then needed to share data. If they couldn't share data, business ground to a halt.

Business had ground to a halt, and it was because the archiver job had failed to copy some files. Michael owned the archiver program, not by choice, but because he got the short end of that particular stick.

The original developer liked logging. Pretty much every method looked something like this:

public int execute(Map arg0, PrintWriter arg1) throws Exception { Logger=new Logger(Properties.getString("LOGGER_NAME")); Log=new Logger(arg1); . . .catch (Exception e) { e.printStackTrace(); Logger.error("Monitor: Incorrect arguments"); Log.printError("Monitor: Incorrect arguments"); arg1.write("In Correct Argument Passed to Method.Please Check the Arguments passed \n \r"); System.out.println("Monitor: Incorrect arguments");}

Sometimes, to make the logging even more thorough, the catch block might look more like this:

catch(Exception e){ e.printStackTrace(); Logger.error("An exception happened during SFTP movement/import. " + (String)e.getMessage());}

Java added Generics in 2004. This code was written in 2014. Does it use generics? Of course not. Every Hashtable is stringly-typed:

Hashtable attributes;...if (((String) attributes.get(key)).compareTo("1") == 0 | ((String) attributes.get(key)).compareTo("0") == 0) { " }

And since everything is stringly-typed, you have to worry about case-sensitive comparisons, but don't worry, the previous developer makes sure everything's case-insensitive, even when comparing numbers:

if (flag.equalsIgnoreCase("1") ) { " }

And don't forget to handle Booleans"

public boolean convertToBoolean(String data) { if (data.compareToIgnoreCase("1") == 0) return true; else return false;}

And empty strings"

if(!TO.equalsIgnoreCase("") && TO !=null) { " }

Actually, since types are so confusing, let's make sure we're casting to know-safe types.

catch (Exception e) { Logger.error((Object)this, e.getStackTraceAsString(), null, null);}

Yes, they really are casting this to Object.

Since everything is stringly typed, we need this code, which checks to see if a String parameter is really sure that it's a string"

protected void moveFile(String strSourceFolder, Object strSourceObject, String strDestFolder) { if (strSourceObject.getClass().getName().compareToIgnoreCase("java.lang.String") == 0) { " } "}

Now, that all was enough to get Michael's blood pressure up, but none of that had anything to do with his actual problem. Why did the copy fail? The logs were useless, as they were spammed with messages with no particular organization. The code was bad, sure, so it wasn't surprising that it crashed. For a little while, Michael thought it might be the getFiles method, which was supposed to identify which files needed to be copied. It did a recursive directory search (with no depth checking, so one symlink could send it into an infinite loop) nor did it actually filter files that it didn't care about. It just made an ArrayList of every file in the directory structure and then decided which ones to copy.

He spent some time really investigating the copy method, to see if that would help him understand what went wrong:

sourceFileLength = sourceFile.length();newPath = sourceFile.getCanonicalPath();newPath = newPath.replace(".lock", "");newFile = new File(newPath);sourceFile.renameTo(newFile); destFileLength = newFile.length();while(sourceFileLength!=destFileLength){ //Copy In Progress}//Remy: I didn't elide any code from the inside of that while loop- that is exactly how it's written, as an empty loop.

Hey, out of curiosity, what does the JavaDoc have to say about renameTo?

Many aspects of the behavior of this method are inherently platform-dependent: The rename operation might not be able to move a file from one filesystem to another, it might not be atomic, and it might not succeed if a file with the destination abstract pathname already exists. The return value should always be checked to make sure that the rename operation was successful.

It only throws exceptions if you don't supply a destination, or if you don't have permissions to the files. Otherwise, it just returns false on a failure.

So" if the renameTo operation fails, the archiver program will drop into an infinite loop. Unlogged. Undetected. That might seem like the root cause of the failure, but it wasn't.

As it turned out, the root cause was that someone in ops hit "Ok" on a security update, which triggered a reboot, disrupting all the scheduled jobs.

Michael still wanted to fix the archiver program, but there was another problem with that. He owned the InventoryArchiver.jar. There was also OrdersArchiver.jar, and HRArchiver.jar, and so on. They had all been "written" by the same developer. They all did basically the same job. So they were all mostly copy-and-paste jobs with different hard-coded strings to specify where they ran. But they weren't exactly copy-and-paste jobs, so each one had to be analyzed, line by line, to see where the logic differences might possibly crop up.

[Advertisement] Infrastructure as Code built from the start with first-class Windows functionality and an intuitive, visual user interface. Download Otter today!