Blocking inside a lazy val initializer is most definitely very discouraged.
Instead make it a lazy val to a Future[T].
On Thu, Jun 9, 2016 at 11:43 AM, Akka Team <akka.offic...@gmail.com> wrote:
> Hi Gary,
>
> Can it be that the number of blocking calls (calls to Await.result) cause
> all threads in the pool to block, hence unable to fulfill some asynchronous
> task that is needed by the Await itself, and deadlock the system?
>
> Also, I am not sure how lazy val initialization is implemented, but I
> think there might be some locking-like behavior going on there. I recommend
> to do a thread dump on the hung system to see what threads are doing and
> look for deadlocks.
>
> -Endre
>
> On Sun, Jun 5, 2016 at 5:54 PM, Gary Hewett <
> gary.hew...@technical-magic.com> wrote:
>
>> I have the following use case: I need to get a token via an initial
>> Remote API web call and then use that token for all subsequent API calls.
>>
>> Simple enough.
>>
>> Here is the chunk of code however that simply STOPS (stalls) working in
>> production:
>>
>> lazy val authTokenPairJSON: play.api.libs.json.JsValue = {
>>>
>>> TKDebug.PRINT(wsClient)
>>>
>>> val request =
>>> wsClient.url("http://remote.io/some/path";).withHeaders("Authorization"
>>>> -> s"basic ${authRequest}", "Accept" -> "application/json")
>>>
>>> TKDebug.PRINT(request)
>>>
>>> var answer = Await.result(atMost=120.seconds, awaitable={
>>>
>>> TKDebug.PRINT("Await.result")
>>>
>>> val response = request.post("")
>>>
>>> TKDebug.PRINT(response)
>>>
>>> TKDebug.PRINT(response.map{ x => x.json })
>>>
>>> response.map{ x => x.json }
>>>
>>> })
>>>
>>> TKDebug.PRINT(answer)
>>>
>>> answer
>>>
>>> }
>>>
>>>
>> Works fine in development mode...
>>
>> I've broken out the Await so as to get further insight into the exact
>> stop point.
>>
>> The debug lines:
>>
>>>
>>
>> TKDebug.PRINT("Await.result")
>>
>> TKDebug.PRINT(response)
>>
>> TKDebug.PRINT(response.map{ x => x.json })
>>
>>
>> Respond as follows:
>>
>> -----------------------------------------------------
>>> (class java.lang.String):Await.result
>>> -----------------------------------------------------
>>> -----------------------------------------------------
>>> (class scala.concurrent.impl.Promise$DefaultPromise):List()
>>> -----------------------------------------------------
>>> -----------------------------------------------------
>>> (class scala.concurrent.impl.Promise$DefaultPromise):List()
>>> -----------------------------------------------------
>>
>>
>> and yet
>>
>> TKDebug.PRINT(answer)
>>
>>
>> Is never reached. Even when waiting for extreme amounts of time -- the
>> timeout is never fired either.
>>
>> According to some of the research I've done on this the "ThreadPool" for
>> map might be the issue but I'm unsure how to fix that (or why it is
>> different enough to stop simply by moving to production mode).
>>
>> To be clear -- this is not random. It works first, each and overtime in
>> Development. It fails first,e at and every time in production.
>>
>> I did see other work-arounds for turning a Future[T] into a T but
>> essentially they end up doing something like this but with classier
>> wrappers (Pattern matching). Happy to try one of those but I doubt that is
>> the problem.
>>
>> Just in case it makes any difference I am doing this as a background
>> agent in Play and starting via AbstractModule (but getting the initial Akka
>> bootstrap class via Google Guice as an Eager Singleton). I did have a
>> rather nasty silent NPE which is why every line is currently debugged. I'm
>> injecting WSClient and ActorSystem via Guice.
>>
>> class TKSchedulerActorBootstrap @Inject() (actorSystem: ActorSystem, ws:
>>>> WSClient) {}
>>>
>>>
>>>
>> I do know that Play does NOT use this call in Development unit a web page
>> is called. In production it does get called earlier so that a background
>> agent can run before a web page is called. I would hate to think that that
>> is it but even if it was I still need the real root cause and not just the
>> why or at least a work-around to handle it.
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
--
Cheers,
√
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
