@@ -281,37 +281,38 @@ public void handle(WorkflowTask task) throws Exception {
281
281
MDC .put (LoggerTag .RUN_ID , runId );
282
282
283
283
boolean locked = false ;
284
- if (!Strings .isNullOrEmpty (stickyTaskQueueName )) {
285
- // Serialize workflow task processing for a particular workflow run.
286
- // This is used to make sure that query tasks and real workflow tasks
287
- // are serialized when sticky is on.
288
- //
289
- // Acquiring a lock with a timeout to avoid having lots of workflow tasks for the same run
290
- // id waiting for a lock and consuming threads in case if lock is unavailable.
291
- //
292
- // Throws interrupted exception which is propagated. It's a correct way to handle it here.
293
- //
294
- // TODO 1: 5 seconds is chosen as a half of normal workflow task timeout.
295
- // This value should be dynamically configured.
296
- // TODO 2: Does "consider increasing workflow task timeout" advice in this exception makes
297
- // any sense?
298
- // This MAYBE makes sense only if a previous workflow task timed out, it's still in
299
- // progress on the worker and the next workflow task got picked up by the same exact
300
- // worker from the general non-sticky task queue.
301
- // Even in this case, this advice looks misleading, something else is going on
302
- // (like an extreme network latency).
303
- locked = runLocks .tryLock (runId , 5 , TimeUnit .SECONDS );
304
-
305
- if (!locked ) {
306
- throw new UnableToAcquireLockException (
307
- "Workflow lock for the run id hasn't been released by one of previous execution attempts, "
308
- + "consider increasing workflow task timeout." );
309
- }
310
- }
311
284
312
285
Stopwatch swTotal =
313
286
workflowTypeScope .timer (MetricsType .WORKFLOW_TASK_EXECUTION_TOTAL_LATENCY ).start ();
314
287
try {
288
+ if (!Strings .isNullOrEmpty (stickyTaskQueueName )) {
289
+ // Serialize workflow task processing for a particular workflow run.
290
+ // This is used to make sure that query tasks and real workflow tasks
291
+ // are serialized when sticky is on.
292
+ //
293
+ // Acquiring a lock with a timeout to avoid having lots of workflow tasks for the same run
294
+ // id waiting for a lock and consuming threads in case if lock is unavailable.
295
+ //
296
+ // Throws interrupted exception which is propagated. It's a correct way to handle it here.
297
+ //
298
+ // TODO 1: 5 seconds is chosen as a half of normal workflow task timeout.
299
+ // This value should be dynamically configured.
300
+ // TODO 2: Does "consider increasing workflow task timeout" advice in this exception makes
301
+ // any sense?
302
+ // This MAYBE makes sense only if a previous workflow task timed out, it's still in
303
+ // progress on the worker and the next workflow task got picked up by the same exact
304
+ // worker from the general non-sticky task queue.
305
+ // Even in this case, this advice looks misleading, something else is going on
306
+ // (like an extreme network latency).
307
+ locked = runLocks .tryLock (runId , 5 , TimeUnit .SECONDS );
308
+
309
+ if (!locked ) {
310
+ throw new UnableToAcquireLockException (
311
+ "Workflow lock for the run id hasn't been released by one of previous execution attempts, "
312
+ + "consider increasing workflow task timeout." );
313
+ }
314
+ }
315
+
315
316
Optional <PollWorkflowTaskQueueResponse > nextWFTResponse = Optional .of (workflowTaskResponse );
316
317
do {
317
318
PollWorkflowTaskQueueResponse currentTask = nextWFTResponse .get ();
0 commit comments