|
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