调试 scala 期货 - 如何确定未来的执行上下文

Question

related with another question I posted ( scala futures - keeping track of request context when threadId is irrelevant ) when debugging a future, the call stack isn't very informative (as the call context is usually in another thread and another time). this is especially problematic when there can be different paths leading to the same future code (for instance usage of DAO called from many places in the code etc). do you know of an elegant solution for this? I was thinking of passing a token/request ID (for flows started by a web server request) - but this would require passing it around - and also won't include any of the state which you can see in the stack trace. perhaps passing a stack around? :)

Answer 1

Suppose you make a class

case class Context(requestId: Int, /* other things you need to pass around */)

There are two basic ways to send it around implicitly:

1) Add an implicit Context parameter to any function that requires it:

def processInAnotherThread(/* explicit arguments */)(
  implicit evaluationContext: scala.concurrent.EvaluationContext, 
  context: Context): Future[Result] = ???

def processRequest = {
  /* ... */

  implicit val context: Context = Context(getRequestId, /* ... */)
  processInAnotherThread(/* explicit parameters */)
} 

The drawback is that every function that needs to access Context must have this parameter and it litters the function signatures quite a bit.

2) Put it into a DynamicVariable :

// Context companion object
object Context {
  val context: DynamicVariable[Context] =
    new DynamicVariable[Context](Context(0, /* ... */))
}

def processInAnotherThread(/* explicit arguments */)(
  implicit evaluationContext: scala.concurrent.EvaluationContext
): Future[Result] = {
  // get requestId from context
  Context.context.value.requestId

  /* ... */
}

def processRequest = {
  /* ... */

  Context.context.withValue(Context(getRequestId, /* ... */)) {
    processInAnotherThread(/* explicit parameters */)
  }
} 

The drawbacks are that

• it's not immediately clear deep inside the processing that there is some context available and what contents it has and also referential transparency is broken. I believe it's better to strictly limit the number of available DynamicVariable s, preferably don't have more than 1 or at most 2 and document their use.
• context must either have default values or null s for all its contents, or it must itself be a null by default ( new DynamicVariable[Context](null) ). Forgetting to initialize Context or its contents before processing may lead to nasty errors.

DynamicVariable is still much better than some global variable and doesn't influence the signatures of the functions that don't use it directly in any way.

---

In both cases you may update the contents of an existing Context with a copy method of a case class . For example:

def deepInProcessing(/* ... */): Future[Result] =
  Context.context.withValue(
    Context.context.value.copy(someParameter = newParameterValue)
  ) {
    processFurther(/* ... */)
  }