Source Not Available Again..

[clk430]

OK, Boca, Janhes and Eyetry have helped me identify why maps get a “source not available” on certain files, however the map actually pulls it.

The classic double trigger issue. An application drops the file, Mercator attempts to pick it up, but the file is not finished. A second map is kicked off when the file is finished and pulls the file, only for the first map not to have a file anymore. Thus, the double trigger.

Simple Fix: Have the application drop a trigger when the file is done or have them name it to a .tmp extension, then rename it when it’s complete.

Unfortunately, redesign is not an option at this point and either is having the application drop a trigger/rename. So what are my options to reduce the double trigger issue?

Example: Map #1 calls a batch file via the batch adapter to unzip a file. Map#2 (multithreaded) picks up the unzipped files (wild carded input source) and FTP’s them.

Map#2 Gets the source not available all the time because the winzip .exe is too slow releasing the files.

So how can I REDUCE the errors?

Single thread Map #2?
Map Delay (9999) on Map #2
.ini Trigger time increase?

 

[janhes]

Probably all 3. Try it and see.

 

[BocaBurger]

Map delay and thrigger time should match, however, the trigger time effects all maps, so you don't want it too long.

Does map one produce more than one file? if not, it can have another card to provide the trigger for #2. if yes, your batch command might be able to rename the files after they are created.

Or, have map one create the files in current card. set card scope to card. Have another card (call a batch) to move the files to the trigger directory.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[SeriesConsumer]

I don't see how this problem could be solved using either single treading or delaying map execution. There will always be situations where the map might fail. The only _clean_ solution would be to use either a separate trigger (i.e. not the files being unzipped themselves) or a mechanism like RSYNC to unzip the files to a temporary location and then move them to the place the map's file trigger expects them to be.

 

[BocaBurger]

BTW, it is usually the second map that would get the source not available, when the first map deletes it.
Unfortunately, not everyone can implement the clean(est) solution.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!