Re: [akka-user] Akka Typed BehaviorTestKit with TimerScheduler

[dollyg]

Thanks, Patrick.

For now, we have used a workaround by mocking a TimerScheduler instance as 
below:

val timerScheduler = mock[TimerScheduler[MyMessage]]

doNothing()
  .when(timerScheduler)
  .startSingleTimer(
ArgumentMatchers.eq(MyBehavior.TimerKey),
ArgumentMatchers.any[MyMessage],
ArgumentMatchers.any[FiniteDuration]
  )

doNothing().when(timerScheduler).cancel(eq(MyBehavior.TimerKey))


and creating the behavior like below:

val behaviorTestKit = BehaviorTestKit(createBehavior(timerScheduler))

private def createBehavior(timerScheduler: TimerScheduler[MyMessage]): 
Behavior[MyMessage] = {
  Behaviors
.mutable[MyMessage](
ctx =>
  new MyBehavior(
ctx,
timerScheduler,
someInfo
  )
  )
}


We have also raised an issue here 
.

Thanks and Regards,
Dolly


On Thursday, March 8, 2018 at 3:13:09 PM UTC+5:30, Patrik Nordwall wrote:
>
> I think it will be difficult to support the ordinary scheduler in 
> BehaviorTestKit but perhaps we could use the manual scheduler: 
> https://doc.akka.io/docs/akka/current/typed/testing.html#controlling-the-scheduler
>
> Please create an issue at https://github.com/akka/akka/issues/new
>
> Thanks,
> Patrik
>
> On Thu, Mar 8, 2018 at 7:23 AM,  
> wrote:
>
>> Hi,
>>
>> We are trying to create a BehaviorTestKit using a behavior which spawns 
>> a timer within.
>>
>> val behaviorTestKit = BehaviorTestKit(createBehavior)
>>
>>
>> private def createBehavior(): Behavior[MyMessage] = {
>>   Behaviors
>> .withTimers[MyMessage](
>>   timerScheduler ⇒
>> Behaviors
>>   .mutable[MyMessage](
>> ctx =>
>>   new MyBehavior(
>> ctx,
>> timerScheduler,
>> someInfo
>> )
>> )
>> )
>> }
>>
>>
>> The above code results in error below:
>>
>> An exception or error caused a run to abort: no scheduler 
>> java.lang.UnsupportedOperationException: no scheduler
>>
>> *spawn *provided in ActorTestKit works fine in spawning an actor for 
>> this behavior.
>>
>> However, we need to test the underlying effects of the given behavior and 
>> hence need to use BehaviorTestKit.
>> Could someone please provide a solution to this problem?
>>
>> Thanks and Regards,
>> Dolly
>> ThoughtWorks
>>
>> -- 
>> >> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend  -  Reactive apps on the JVM
> Twitter: @patriknw
>
>

-- 
>>  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.

Re: [akka-user] import context.dispatcher nullpointerexception

[Jeff]

I agree with Heiko on this one - import context.dispatcher is used 
everywhere. It is mentioned in the docs not to close over 'context' and 
access it outside of message handlers, however I think more education is 
needed here. 

On Wednesday, March 7, 2018 at 5:35:05 PM UTC-8, Konrad Malawski wrote:
>
> Yes it is nulled using unsafe.
>
> -- 
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On March 8, 2018 at 7:32:56, Heiko Seeberger (loe...@posteo.de 
> ) wrote:
>
> `import context.dispatcher` is what „everybody“ is doing, not? I’m using 
> it all over the place, because I have learned that one can import from 
> stable identifiers (e.g. vals) in Scala. Hence I don’t think changing the 
> docs has the necessary effect.
>
> How can a final val be „nulled"? Unsafe? Reflection?
>
> Cheers
> Heiko
>
> --
>
> Heiko Seeberger
> Home: heikoseeberger.de
> Twitter: @hseeberger
> Public key: keybase.io/hseeberger
>
>
>
>
> Am 07.03.2018 um 19:23 schrieb Patrik Nordwall  >:
>
> Thanks!
>
> On Wed, Mar 7, 2018 at 6:16 PM, Jeff  
> wrote:
>
>> An example of documentation for using import context.dispatcher is here 
>> https://doc.akka.io/docs/akka/2.5/futures.html#within-actors 
>>
>> I can create some PR to update the documentation
>>
>> On Wednesday, March 7, 2018 at 6:09:24 AM UTC-8, Patrik Nordwall wrote: 
>>>
>>> It's because when the actor is stopped some of the fields are cleared 
>>> (yeah, even though they are vals) to "help" the GC in case something (e.g. 
>>> an local ActorRef) is still referencing the actor instance. 
>>>
>>> implicit val ec = context.dispatcher
>>>
>>> would solve it here.
>>>
>>> Where in the documentation is the import recommended? We should probably 
>>> update that. Would you be able creating a PR fixing it? Thanks.
>>>
>>> /Patrik
>>>
>>> On Tue, Mar 6, 2018 at 10:44 PM, Jeff  wrote:
>>>
 I suspected as much. So what would you suggest as for handling use 
 cases where you could have chained flatmaps on futures that at the end 
 will 
 pipeTo a message back to the actor. Should we set the ExecutionContext to 
 a 
 val? 

 On Tuesday, March 6, 2018 at 12:09:22 PM UTC-8, √ wrote: 
>
> Context is bound to the lifecycle of the actor.
>
> On Tue, Mar 6, 2018 at 8:37 PM, Jeff  wrote:
>
>> I have noticed an issue where if a future maps/flatmaps after actor 
>> shutdown, a NullPointerException is thrown. I've narrowed it down to 
>> the import context.dispatcher, which I technically understand since 
>> that is closing over actor state. If I change that to implicit val 
>> ec = context.dispatcher, everything works fine.  
>>
>> I'd like to understand what is the best practice in this case, since 
>> the documentation for context.dispatcher indicates that it is 
>> threadsafe and looking at the actor trait, context is a val. Most 
>> documentation seems to indicate that import context.dispatcher is 
>> preferred. 
>>
>> Thanks
>> Jeff
>>
>> --
>> >> 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+...@googlegroups.com.
>> To post to this group, send email to akka...@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+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at https://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>>
>>> Patrik Nordwall
>>> Akka Tech Lead
>>> Lightbend  -  Reactive apps on the JVM
>>> Twitter: @patriknw
>>>
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: 

[akka-user] Akka Http 10.1.0 Released

['Johannes Rudolph' via Akka User List]

Dear hakkers,


we are happy to announce Akka Http 10.1.0, the first release of the 10.1.x 
series.


See the announcement 
at https://akka.io/blog/news/2018/03/08/akka-http-10.1.0-released.


The most important changes are:

   - The new client pool implementation introduced in 10.0.11 is now the 
   default. We have identified and fixed several bugs in the RC period so by 
   now we are quite confident that the new client pool will be a solid 
   replacement for the legacy one.
   - Documentation has been completely consolidated between Scala and Java 
   pages. Hundreds of directive documentation pages have been merged in a 
   tireless effort by @jonas , @jlprat 
   , and Akka team’s @raboof 
   . The overall documentation structure has 
   been improved.
   - Experimental artifacts are available for Scala 2.13.0-M3.
   - Support for Akka 2.4.x, which is at its end-of-life with the end of 
   2017, has been removed. In the future, this will allow us to make use of 
   features that only Akka 2.5 supports.
   - Methods deprecated during the life-time of Akka HTTP 10.0.x have been 
   removed. Methods just deprecated for 10.0.11 have not yet been removed to 
   allow for a smooth transition.

New client pool implementation is now the default


The new client pool implementation introduced in 10.0.11 is now the 
default. Since 10.0.11, we fixed several bugs in the new client pool 
implementation. You can still fall back to the old implementation by 
setting akka.http.host-connection-pool.pool-implementation = legacy.

Akka is not an explicit dependency anymore / Removal of Akka 2.4 support

Akka HTTP 10.0.x has always supported Akka 2.5, while allowing users to 
still remain on Akka 2.4.x if they choose to do so. By now Akka 2.4 has 
reached its end of life. Therefore, Akka HTTP 10.1.x only supports Akka >= 
2.5.11 (and future versions during the life of Akka HTTP 10.1.x) so we will 
be able to make of features only provided by Akka 2.5. In some cases we 
bump the minimum supported patch version of Akka to be able to use new 
features quickly.


Using Akka HTTP with Akka 2.5 used to be a bit confusing, because Akka HTTP 
explicitly depended on Akka 2.4. Trying to use it together with Akka 2.5, 
running an Akka HTTP application could fail with class loading issues if 
you forgot to add a dependency to both akka-actor and akka-stream of the 
same version. For that reason, we changed the policy not to depend on 
akka-stream explicitly anymore but mark it as a provided dependency in our 
build. That means that you will always have to add a manual dependency to 
akka-stream (veterans may remember this policy from Spray).


Please make sure you have chosen and added a dependency to akka-stream when 
updating to the new version.


Currently, the right dependency to add is


libraryDependencies += "com.typesafe.akka" %% "akka-stream" % "2.5.11"


Support for Scala 2.13.0-M3


Akka HTTP 10.1.0 is released for Scala 2.11, 2.12, and 2.13.0-M3. Due to a 
regression 
in Scala 2.13.0-M3  tail 
call optimization does not apply anymore in some cases where it did before 
which might lead to stack overflow when running with Scala 2.13.0-M3.

Deprecation Removals

Methods were removed that have been deprecated during the life-time of Akka 
HTTP 10.0.x. Methods that were only deprecated in the last release of Akka 
HTTP, 10.0.11, are not yet removed to allow for a smooth transition. In 
general, our guarantee for minor release updates is that code that compiled 
on the latest version of the previous minor release (10.0.11 in this case) 
should be both source and binary compatible with the latest version of the 
current minor release. We might make exceptions to the rule for cases where 
the maintenance burden seems greater than the risk of breaking major users 
/ third-party libraries. We’ll treat any other binary incompatibilities as 
regressions.

Compatibility Notes

As the compatibility notes 
 
explain 
in detail, we guarantee binary compatibility. In some cases, however, a new 
version is not strictly source compatible. We try to limit the impact of 
these kinds of changes but sometimes, they are inevitable to improve the 
API.

Source incompatible changes are:

   - Removed deprecated methods from 10.0.x
   - ServerBinding.unbind return type has been changed to Future[Done] / 
   CompletionStage[Done] for consistency.

Removal of OSGi support

Supporting OSGi is error prone and high maintenance and it repeatably 
broke, blocked releases, or metadata turned out to be wrong. As we are no 
experts in OSGi, and are nowadays focusing our efforts on JDK9+ jigsaw 
compatibility we had to remove OSGi support for now. If you care about OSGi 
support please step up and help out. Most important would be adding tests 
that verify 

Re: [akka-user] Question on the WeaklyUp state

[Patrik Nordwall]

It depends on the cluster based tool you are using if it can make use of
weakly up nodes or not. For example routers and distributed data can use
weakly up, while singleton and sharding requires fully up.

The advantage is that you can start using the weakly up nodes for some
tasks without waiting for unreachable nodes to be removed (or healed).

On Thu, Mar 8, 2018 at 5:40 AM, Grace  wrote:

> Hi,
>
> I read the description here:
> https://doc.akka.io/docs/akka/2.5.5/scala/cluster-usage.
> html#weaklyup-members
>
> 1) When a node is in the weakly up state, does the node process jobs like
> the nodes of the Up state?
>
> 2) In what case is it useful to have akka.cluster.allow-weakly-up-members 
> turned
> on?  What's the advantage of having a node join the weakly up state as part
> of the cluster versus to just wait in the joining state until it is moved
> into the Up state?
>
> Thanks,
> Grace
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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.

Re: [akka-user] Akka Typed BehaviorTestKit with TimerScheduler

[Patrik Nordwall]

I think it will be difficult to support the ordinary scheduler in
BehaviorTestKit but perhaps we could use the manual scheduler:
https://doc.akka.io/docs/akka/current/typed/testing.html#controlling-the-scheduler

Please create an issue at https://github.com/akka/akka/issues/new

Thanks,
Patrik

On Thu, Mar 8, 2018 at 7:23 AM,  wrote:

> Hi,
>
> We are trying to create a BehaviorTestKit using a behavior which spawns a
> timer within.
>
> val behaviorTestKit = BehaviorTestKit(createBehavior)
>
>
> private def createBehavior(): Behavior[MyMessage] = {
>   Behaviors
> .withTimers[MyMessage](
>   timerScheduler ⇒
> Behaviors
>   .mutable[MyMessage](
> ctx =>
>   new MyBehavior(
> ctx,
> timerScheduler,
> someInfo
> )
> )
> )
> }
>
>
> The above code results in error below:
>
> An exception or error caused a run to abort: no scheduler
> java.lang.UnsupportedOperationException: no scheduler
>
> *spawn *provided in ActorTestKit works fine in spawning an actor for this
> behavior.
>
> However, we need to test the underlying effects of the given behavior and
> hence need to use BehaviorTestKit.
> Could someone please provide a solution to this problem?
>
> Thanks and Regards,
> Dolly
> ThoughtWorks
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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.