R66Reschedule

Once an error occurs, the transfer is interrupted. On certain conditions, it can be automatically rescheduled.

• If the error occurs at the connection step, Waarp will try 3 times before setting the transfer in error.
• On shutdown of a Waarp server, all current transfers are stopped and will be reschedule automatically at startup.
• On an error during a transfer, Waarp will execute the corresponding error tasks (send or recv). If one of them is a RESCHEDULE task with a validated filter, the transfer will be rescheduled. A validated filter depends on the root cause (-case), the time to reschedule the transfer (-delay, -between, -notbetween), the number of temptative (-count and CPTLIMIT).
• If none of the above conditions is met, the transfer is in error and stopped. It can be manually restarted (or programatically restarted) through the administrator web interface, through the RequestTransfert -restart command, or its equivalent through the Thrift interface.

Indeed, not all transfers should be restarted automatically, not for unlimited tries, not for specific error cases, and not due to business reasons. So the standard behavior of Waarp is to try the restart automatically only on network aspects, and then let the rule extending the behavior through the RESCHEDULE task.

 

The RESCHEDULE task has the following capabilities:

• If one RESCHEDULE task is executed (wherever it is) and validated (the transfer is really rescheduled), all following tasks are ignored and the execution flow stops

• The task will rely on 2 informations: the rule default information (specifically for the maximum restart available) and the transfer information which will include the current retry counter.

The options are:

• "-delay ms" where ms is the added number of ms on current time before retry on schedule
• "-case errorCode,errorCode,..." where errorCode is one of the following error of the current transfer (either literal or code in 1 character):
  • ConnectionImpossible(C), ServerOverloaded(l), BadAuthent(A), ExternalOp(E), TransferError(T), MD5Error(M), Disconnection(D), RemoteShutdown(r), FinalOp(F), Unimplemented(U), Shutdown(S), RemoteError(R), Internal(I), StoppedTransfer(H), CanceledTransfer(K), Warning(W), Unknown(-), QueryAlreadyFinished(Q), QueryStillRunning(s), NotKnownHost(N), QueryRemotelyUnknown(u), FileNotFound(f), CommandNotFound(c), PassThroughMode(p)
• "-between start;end" and/or "-notbetween start;end" (multiple times are allowed, start or end can be not set) and where start and stop are in the following format:
  • Yn:Mn:Dn:Hn:mn:Sn where n is a number for each time specification, each specification is optional, as Y=Year, M=Month, D=Day, H=Hour, m=minute, s=second.
  • Format can be X+n, X-n, X=n or Xn where X+-n means adding/subtracting n to current date value, while X=n or Xn means setting exact value
  • If one time specification is not set, it is based on the current date.
  • If "-notbetween" is specified, the planned date must not be in the area.
  • If "-between" is specified, the planned date must be found in any such specified areas (could be in any of the occurrence). If not specified, it only depends on "-notbetween".
  • If none is specified, the planned date is always valid.
  • In case start > end, end will be +1 day
  • In case start and end < current planned date, both will have +1 day.
• "-count limit" will be the limit of retry. The value limit is taken from the "info on transfer".
  • Each time this function is called, the limit value will be replaced as newlimit = limit - 1 in the "info of transfer".
  • To ensure correctness, the value must be in the "info of transfer" since this value will be changed statically in the "info of transfer". However, a value must be setup in the rule in order to reset the value when the count reach 0.
  • So in the rule, "-count resetlimit" must be present, where resetlimit will be the new value set when the limit reaches 0. If it is missing, the condition is not applied.

Note: When the task is definitively in error (counter to 0), the counter in the transfer information is reset to the counter default limit set in the rule and the transfer is stopped. Then it is up to other way to relaunch the transfer to restart the transfer.

Among the various possibilities to relaunch a transfer once it is in error:

• Through the RESCHEDULE task, filtered by the error code and according to constraints and limits
• Through the Admin GUI (HTTPS): Transfer -> Restart
• Through command line: RequestTransfer or SubmitTransfer
• Through API using Thrift: using transferRequestQuery method
• Through the database directly by changing the status of UPDATEDINFO to the value TOSUBMIT (3)

Example of RESCHEDULE usage:

With the following rule:

• "-delay 3600000 -case ConnectionImpossible,ServerOverloaded,Shutdown -notbetween H7:m0:S0;H19:m0:S0 -notbetween H1:m0:S0;H=3:m0:S0 -count 1"

The reschedule task means retry in case of error during initialization of connection in 1 hour if not between 7AM to 7PM and not between 1AM to 3AM and with a limit of 3 retries (retry will be reset to 1 in case of 3 attempts).