doc/src/library/failures.im

   1 .if false
   2 ==================================================================================
   3         Copyright (c) 2019 Nokia
   4         Copyright (c) 2018-2019 AT&T Intellectual Property.
   5
   6    Licensed under the Apache License, Version 2.0 (the "License");
   7    you may not use this file except in compliance with the License.
   8    You may obtain a copy of the License at
   9
  10        http://www.apache.org/licenses/LICENSE-2.0
  11
  12    Unless required by applicable law or agreed to in writing, software
  13    distributed under the License is distributed on an "AS IS" BASIS,
  14    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  15    See the License for the specific language governing permissions and
  16    limitations under the License.
  17 ==================================================================================
  18 .fi
  19
  20 .if false
  21         Mnemonic:       failures.im
  22         Abstract:       This is the major section on how an application might handle failures
  23         Date:           2 August 2019
  24         Author:         E. Scott Daniels
  25 .fi
  26
  27 &h1(Handling Failures)
  28 The vast majority of states reported by RMR are fatal; if encountered during setup or initialisation,
  29 then it is unlikely that any message oriented processing should continue, and when encountered on
  30 a message operation continued operation on that message should be abandoned.
  31 Specifically with regard to message sending, it is very likely that the underlying transport mechanism
  32 will report a &ital(soft,) or transient, failure which might be successful if the operation is retried at a
  33 later point in time.
  34 The paragraphs below discuss the methods that an application might deal with these soft failures.
  35
  36 &h2(Failure Notification)
  37 When a soft failure is reported, the returned message buffer returned by the RMR function will be &cw(RMR_ERR_RETRY.)
  38 These types of failures can occur for various reasons; one of two reasons is typically the underlying cause:
  39
  40 &half_space
  41 &indent
  42 &beg_list( &lic1 )
  43         &li The session to the targeted recipient (endpoint) is not connected.
  44         &half_space
  45
  46         &li The transport mechanism buffer pool is full and cannot accept another buffer.
  47         &half_space
  48 &end_list
  49 &uindent
  50 &space
  51
  52 Unfortunately, it is not possible for RMR to determine which of these two cases is occurring, and equally
  53 as unfortunate the time to resolve each is different.
  54 The first, no connection, may require up to a second before a message can be accepted, while a rejection
  55 because of buffer shortage is likely to resolve in less than a millisecond.
  56
  57 &h2(Application Response)
  58 The action which an application takes when a soft failure is reported ultimately depends on the nature
  59 of the application with respect to factors such as tolerance to extended message latency, dropped messages,
  60 and over all message rate.
  61
  62 &h2(RMR Retry Modes)
  63 In an effort to reduce the workload of an application developer, RMR has a default retry policy such that
  64 RMR will attempt to retransmit a message up to 1000 times when a soft failure is reported.
  65 These retries generally take less than 1 millisecond (if all 1000 are attempted) and in most cases eliminates
  66 nearly all reported soft failures to the application.
  67 When using this mode, it might allow the application to simply treat all bad return values from a send attempt
  68 as permanent failures.
  69 &space
  70
  71 If an application is so sensitive to any delay in RMR, or the underlying transport mechanism, it is possible to
  72 set RMR to return a failure immediately on any kind of error (permanent failures are always reported without retry).
  73 In this mode, RMR will still set the state in the message buffer to &cw(RMR_ERR_RETRY,) but will &bold(not)
  74 make any attempts to resend the message.
  75 This zero-retry policy is enabled by invoking the &func(rmr_set_stimeout) with a value of 0; this can be done once
  76 immediately after &func(rmr_init:) is invoked.
  77
  78 &space
  79 Regardless of the retry mode which the application sets, it will ultimately be up to the application to
  80 handle failures by queuing the message internally for resend, retrying immediately, or dropping the
  81 send attempt all together.
  82 As stated before, only the application can determine how to best handle send failures.
  83
  84
  85 &h2(Other Failures)
  86 RMR will return the state of processing for message based operations (send/receive) as the status in
  87 the message buffer.
  88 For non-message operations, state is returned to the caller as the integer return value for all functions
  89 which are not expected to return a pointer (e.g. &func(rmr_init:).)
  90 The following are the RMR state constants and a brief description of their meaning.
  91
  92 &space
  93 .st 8p
  94 &indent
  95 &beg_dlist( 1.5i &ditext )
  96         &di(RMR_OK)                     state is good; operation finished successfully
  97         &half_space
  98
  99         &di(RMR_ERR_BADARG)             argument passed to function was unusable
 100         &half_space
 101
 102         &di(RMR_ERR_NOENDPT)    send/call could not find an endpoint based on msg type
 103         &half_space
 104
 105         &di(RMR_ERR_EMPTY)              msg received had no payload; attempt to send an empty message
 106         &half_space
 107
 108         &di(RMR_ERR_NOHDR)              message didn't contain a valid header
 109         &half_space
 110
 111         &di(RMR_ERR_SENDFAILED) send failed; errno may contain the transport provider reason
 112         &half_space
 113
 114         &di(RMR_ERR_CALLFAILED) unable to send the message for a call function; errno may contain the transport provider reason
 115         &half_space
 116
 117         &di(RMR_ERR_NOWHOPEN)   no wormholes are open
 118         &half_space
 119
 120         &di(RMR_ERR_WHID)               the wormhole id provided was invalid
 121         &half_space
 122
 123         &di(RMR_ERR_OVERFLOW)   operation would have busted through a buffer/field size
 124         &half_space
 125
 126         &di(RMR_ERR_RETRY)              request (send/call/rts) failed, but caller should retry (EAGAIN for wrappers)
 127         &half_space
 128
 129         &di(RMR_ERR_RCVFAILED)  receive failed (hard error)
 130         &half_space
 131
 132         &di(RMR_ERR_TIMEOUT)    response message not received in a reasonable amount of time
 133         &half_space
 134
 135         &di(RMR_ERR_UNSET)              the message hasn't been populated with a transport buffer
 136         &half_space
 137
 138         &di(RMR_ERR_TRUNC)              length in the received buffer is longer than the size of the allocated payload,
 139                                                         received message likely truncated (length set by sender could be wrong, but we can't know that)
 140         &half_space
 141
 142         &di(RMR_ERR_INITFAILED) initialisation of something (probably message) failed
 143         &half_space
 144
 145         &di(RMR_ERR_NOTSUPP)    the request is not supported, or RMr was not initialised for the request
 146 &end_dlist
 147 &uindent
 148 .st &textsize
 149 &space
 150
 151 Depending on the underlying transport mechanism, and the nature of the call that RMR attempted, the
 152 system &cw(errno) value might reflect additional detail about the failure.
 153 Applications should &bold(not) rely on errno as some transport mechanisms do not set it with
 154 any consistency.