|
163 | 163 | * } |
164 | 164 | * </code></pre> |
165 | 165 | * |
166 | | - * <p>Caution: since using this sometimes implies "long" timeouts, activity-worker losses prior to recording the |
167 | | - * {@link Activity#getTaskToken()} in an external system (or prior to another thread calling it) may not be noticed |
168 | | - * until the "long" timeout occurs. This can be resolved by having another system call |
169 | | - * {@link com.uber.cadence.client.ActivityCompletionClient#heartbeat(byte[], Object)} while that external action is |
170 | | - * running, but there is currently no way to mitigate this issue without these heartbeats. For in-process-only async |
171 | | - * completion, relying on heartbeating is safe and reliable because these heartbeats should occur as long as the |
172 | | - * process / background thread is still running. |
173 | | - * |
174 | | - * <p>If you cannot heartbeat and cannot tolerate this kind of delayed-activity-loss detection, consider emulating a |
175 | | - * long activity via a signal channel instead: you can start a short-lived activity and wait for a "saved to external |
176 | | - * system" signal, retrying as necessary, and then wait for an "external system finished" signal containing the final |
177 | | - * result. |
| 166 | + * <p>Caution: since using this sometimes implies "long" timeouts, activity-worker losses prior to |
| 167 | + * recording the {@link Activity#getTaskToken()} in an external system (or prior to another thread |
| 168 | + * calling it) may not be noticed until the "long" timeout occurs. This can be resolved by having |
| 169 | + * another system call {@link com.uber.cadence.client.ActivityCompletionClient#heartbeat(byte[], |
| 170 | + * Object)} while that external action is running, but there is currently no way to mitigate this |
| 171 | + * issue without these heartbeats. For in-process-only async completion, relying on heartbeating is |
| 172 | + * safe and reliable because these heartbeats should occur as long as the process / background |
| 173 | + * thread is still running. |
| 174 | + * |
| 175 | + * <p>If you cannot heartbeat and cannot tolerate this kind of delayed-activity-loss detection, |
| 176 | + * consider emulating a long activity via a signal channel instead: you can start a short-lived |
| 177 | + * activity and wait for a "saved to external system" signal, retrying as necessary, and then wait |
| 178 | + * for an "external system finished" signal containing the final result. |
178 | 179 | * |
179 | 180 | * <h3>Activity Heartbeating</h3> |
180 | 181 | * |
|
214 | 215 | public final class Activity { |
215 | 216 |
|
216 | 217 | /** |
217 | | - * If this method is called during an activity execution then activity will not complete |
218 | | - * when its method returns. It is expected to be completed asynchronously using {@link |
| 218 | + * If this method is called during an activity execution then activity will not complete when its |
| 219 | + * method returns. It is expected to be completed asynchronously using {@link |
219 | 220 | * com.uber.cadence.client.ActivityCompletionClient}. |
220 | 221 | * |
221 | | - * <p>Caution: since using this sometimes implies "long" timeouts, activity-worker losses prior to recording the |
222 | | - * {@link Activity#getTaskToken()} in an external system (or prior to another thread calling it) may not be noticed |
223 | | - * until the "long" timeout occurs. |
224 | | - * This can be resolved by having another system call |
225 | | - * {@link com.uber.cadence.client.ActivityCompletionClient#heartbeat(byte[], Object)} while that external action is |
226 | | - * running, but there is currently no way to mitigate this issue without these heartbeats. For in-process-only async |
227 | | - * completion, relying on heartbeating is safe and reliable because these heartbeats should occur as long as the |
228 | | - * process / background thread is still running. |
| 222 | + * <p>Caution: since using this sometimes implies "long" timeouts, activity-worker losses prior to |
| 223 | + * recording the {@link Activity#getTaskToken()} in an external system (or prior to another thread |
| 224 | + * calling it) may not be noticed until the "long" timeout occurs. This can be resolved by having |
| 225 | + * another system call {@link com.uber.cadence.client.ActivityCompletionClient#heartbeat(byte[], |
| 226 | + * Object)} while that external action is running, but there is currently no way to mitigate this |
| 227 | + * issue without these heartbeats. For in-process-only async completion, relying on heartbeating |
| 228 | + * is safe and reliable because these heartbeats should occur as long as the process / background |
| 229 | + * thread is still running. |
229 | 230 | * |
230 | | - * <p>If you cannot heartbeat and cannot tolerate this kind of delayed-activity-loss detection, consider emulating a |
231 | | - * long activity via a signal channel instead: you can start a short-lived activity and wait for a "saved to external |
232 | | - * system" signal, retrying as necessary, and then wait for an "external system finished" signal containing the final |
233 | | - * result. |
| 231 | + * <p>If you cannot heartbeat and cannot tolerate this kind of delayed-activity-loss detection, |
| 232 | + * consider emulating a long activity via a signal channel instead: you can start a short-lived |
| 233 | + * activity and wait for a "saved to external system" signal, retrying as necessary, and then wait |
| 234 | + * for an "external system finished" signal containing the final result. |
234 | 235 | */ |
235 | 236 | public static void doNotCompleteOnReturn() { |
236 | 237 | ActivityInternal.doNotCompleteOnReturn(); |
|
0 commit comments