Retry's - Best practices?

[clk430]

It seemed to have been a common practice around here as I looked through all the maps and systems. Retries are set to 30 attempts/5 second interval.

Are there any best practices out there for a simple map (blob-in /blob-out)?

Complex maps?

FTP adapter output maps?

 

[eyetry]

We don't have a standard for that here. Here it depends on the system and a gut feel for trigger file size(s).

I'd think though that you'd want longer intervals with fewer attempts. Why not 5 attempts with 30 second intervals. Its still 150 seconds of wait time. So, why not 3 tries every 50 seconds.

 

[clk430]

Good discussion. Does the 30 or whatever second interval hold the map open, go into resource pending or initpending status?

*btw eyetry, on a side note* the service pack instal we talked about in the other thread is going super, thanks for the tips *

Back on topic.

 

[eyetry]

thanl's for the FB. Nice to hear...

As far as how retry's affect performance and resources availability.... its probably a good question for Boca.

 

[BocaBurger]

There are two retries, Map and Adapter. If you need retries on source files, you have a problem outside of DS TX. Adapter retried should only be needed for targets, and for instances where if there would be a problem, it would be transient in nature (ie a network glitch). two retries 5 sec. should be the maximum. Then you need an error handling system in place.
If your DB is down, you should stop the Event Server. Same if your MQ Server is down.

Not sure why you would ever want to retry a map.





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

 

[clk430]

What are the disadvantages of more retires? For expample, if I am using the FTP put adapter on a map that FTP's a file to a Trading Partner's server - but their server is quirky and sometimes rejects FTP calls to them. Instead of building a error handling system reading traces etc., why not just retry 10 or so times?

 

[BocaBurger]

Depends on how flaky the server is. How long do you want a map to be using up your resources while you are waiting for the server to straighten out?

One or two retries about 5 seconds apart should either get past a transient glitch or prove you need to wait longer.



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

 

[clk430]

I see. How does it use resources? I mean, if the source is not availble (say an app is still using it) and the retry is set at 2 retires every 30 seconds, does the map/thread remain "open" for that duration, init pendinding, resource pending?

 

[BocaBurger]

Not pending, it is active, but not processing data. Remember, if your scope is map, everything completes and then the actual FTP is run during the commit phase (clean up).
For sources, it depends on OS behaviour. We don't get a source not available in a file that's locked, until we try to delete the file after all the output is commited.
Commits are issued output card #1 to #N, then input card #1 to # N



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

 

[clk430]

Not pending, it is active, but not processing data."

So, is this more resource consuming then if data is processing? The map in question for this example is just a blob in/blob out - no FTP.

 

[BocaBurger]

Depends on the resource CPU usage would not be high, but thread is in use and memory is being consumed, as well as file handles.


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