How do I handle retry logic for unreliable external resources?

LLP Connection

Contents

Our second example shows the versatility of the retry module by resending messages to an LLP client. If the client sends back a negative acknowledgment code (an AR: Application Reject or an AE: Application Error), then we resend the message. In this case the LLP client we are talking to has a MySQL Database as a back-end. So when we want to generate negative acknowledgements we can simply stop the MySQL database service.

Note: Where the messages returned from retry.call() refer to “database”, they could easily be changed to refer to “LLP client” if desired.

The steps to use the retry module are similar to the previous example:

  1. Add require 'retry' to the shared module source code, as shown below.
  2. Invoke retry.call() with a table containing these entries:
    • func = The function you wish to call
    • arg1 = The argument to pass in
      Note: Multiple arguments can be passed in to the function
    • retry (optional) = The maximum number of failed retries
    • pause (optional) = The pause between each retry attempt (in seconds)
    • funcname (optional) = The name of the function ( informational for errors and logging)

Testing The Code [top]

We ran it in an LLP–>Translator channel and verified that it worked as expected by stopping and starting the LLP source channel (very similar to how we tested the database example on the previous page).

Sample Code [top]

We decided not to include the code for this example. We would have needed to include the LLP Client code also, and it would have made the example overly complex. You can find the LLP module we used on this page: Using the Translator as an LLP Client.

Note: You can easily adapt the sample code for the database example to interact with your own LLP Client.

Continue: Using multiple parameters and multiple returns