[akka-user] Help wanted: Distributed Data with akka-typed, java and Akka 2.5.10

2018-02-23 Thread Qux 
Hello

I'll use distributed data with akka-typed and java. I wanted to upgrade 
to  Akka 2.5 and stumbled over following problem:

Before I had Adapters like:
ActorRef>> readResponseAdapter = 
ctx.spawnAdapter(InternalGetResponse::new);
ActorRef>> 
updateResponseAdapter = ctx.spawnAdapter(msg -> new InternalUpdateResponse
());


and using them like:

replicator.tell(new Replicator.Get<>(cacheKey, Replicator.readLocal(), 
readResponseAdapter, Optional.of(msg)));
replicator.tell(new Replicator.Update<>(cacheKey, LWWRegister.create(cluster
, new Cache()),
 Replicator.writeLocal(), updateResponseAdapter, Optional.empty(), t -> t.
withValue(cluster, cache)));



now they look like 

ActorRef readResponseAdapter = 
ctx.messageAdapter(Replicator.GetResponse.class, InternalGetResponse::new);
ActorRef updateResponseAdapter = 
ctx.messageAdapter(Replicator.UpdateResponse.class, msg -> new 
InternalUpdateResponse());

Using the new ones give me problems now:

replicator.tell(new Replicator.Get(cacheKey, Replicator.readLocal(), 
readResponseAdapter, Optional.of(msg)));
replicator.tell(new Replicator.Update(cacheKey, LWWRegister.create(cluster, new 
Cache()),
 Replicator.writeLocal(), updateResponseAdapter, Optional.empty(), t -> 
t.withValue(cluster, cache)));  //doesn't compile

can anyone help me with this? 

-- 
>>  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] Flow.mapAsync and downstream demand

2018-02-23 Thread Jeff 
Actually found a much simpler solution using Source.unfoldAsync. 

On Thursday, February 22, 2018 at 6:54:54 PM UTC-8, Jeff wrote:
>
> My particular use case is a long poll where the id to be sent on the next 
> request is returned from the previous request.
>
> On Thursday, February 22, 2018 at 6:40:48 PM UTC-8, Konrad Malawski wrote:
>>
>> In general relying on exact timing of pulls is rather seen as an anti 
>> pattern…
>> Even if you do a custom stage, it’s very brittle, as any element put 
>> before your stage could cause pulls, simply because that’s how things work.
>> The same can be said about simply changed buffer sizes between stages — 
>> introducing an async boundary anywhere in the pipeline can lead 
>> to more buffer space being allocated, and thus, more pulls being issued.
>>
>> In other words — due to the fact that backpressure is connected through 
>> an entire pipeline (and has to, otherwise it would not do what it should),
>> you can not rely on exact timing of pulls, because changes in the 
>> pipeline may affect this.
>>
>> In your very specific case perhaps it’s doable to make a stage or 
>> pipeline that’ll do the right thing, with enforcing it with zips and loops,
>> but that’ll be specific and take some work and very precise wording of 
>> what you want to achieve (sample code?)
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso ' Malawski
>> Akka  @ Lightbend 
>>
>> On February 23, 2018 at 7:05:18, Jeff (jknigh...@gmail.com) wrote:
>>
>> Currently, Flow.mapAsync and Flow.mapAsyncUnordered always pull upstream 
>> even if there is no demand from downstream and then buffer. However, there 
>> are situations where one might want to way for explicit downstream demand 
>> before pulling. For example, let's say that the next upstream item depends 
>> on the results of the previous item and that you need to feed that back 
>> into the upstream before pulling again. In its current form, Flow.mapAsync 
>> will pull before that feedback loop has been completed.  
>>
>> Is there any way to work around that other than writing a custom 
>> GraphStage? 
>>
>> 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.
>>
>>

-- 
>>  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-user] Re: scheduler: new instance per run or long-lived actor?

2018-02-23 Thread Александр Семибратов 
No. Akka scheduler suits my needs.

пятница, 23 февраля 2018 г., 13:01:46 UTC+4 пользователь wapgui написал:
>
> Did you try this: https://github.com/enragedginger/akka-quartz-scheduler ?
>
> Am Freitag, 23. Februar 2018 07:01:35 UTC+1 schrieb Александр Семибратов:
>>
>> For example
>>  
>> First approach 
>> https://gist.github.com/semibratov/d2968b7bd66198e636d64b9d0e35ec6b
>> Second approach
>> https://gist.github.com/semibratov/a0121fe73883a3b6216735ca20f75e63 
>>  
>>
>

-- 
>>  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-user] ANNOUNCE: Akka 2.5.10 released

2018-02-23 Thread Patrik Nordwall 
Dear hakkers,

We are excited to announce a new patch release of Akka 2.5. This version
contains several new features:


   -

   Artery transport with TCP and TLS
   
   -

   StreamRefs - Reactive Streams over the Network
    (click for 5min video)
   -

   Rolling update config validation
   
,
   thanks to @renatocaval 


Other notable improvements and bug fixes:


   -

   Remove unused and quarantined outbound connections in Artery (memory
   leak), #23967 
   -

   Fix blocking-io-dispatcher setting in Akka Streams, #24357
   
   -

   Fix bug that caused stashed timer messages to be discarded, #24557
   
   -

   Fix bug in automatic unsubscribe from DistributedPubSub on actor
   termination, thanks to @naiello , #24294
   
   -

   Akka Streams combinators
   -

  Flow.ask, #24325 
  -

  Source.lazilyAsync, thanks to @kelebra ,
  #24519 
  -

  Flow.lazyInit, thanks to @gosubpl , #24427
  
  -

  Flow.wireTap, thanks to @catalin-ursachi
  , #15077
  
  -

  Flow.divertTo, thanks to @viktorklang ,
  #24388 
  -

  Flow.alsoTo eager cancellation by default, thanks to @jeremystone
  , #24291
  
  -

  Flow.collectType thanks to @hepin1989 ,
  #24254 
  -

  Allow RestartFlow/RestartSink to restart only on failures, thanks to
  @nachinius , #24421
  
  -

  Higher level API for TLS over TCP, #24153
  


A total of 131 issues were closed since 2.5.9. The complete list can be
found on the 2.5.10 milestone
 on github.
Artery transport with TCP and TLS

Customers and users have asked for encryption in the new remoting
implementation (Artery). Rather than adding encryption to Aeron (UDP) we
decided to include an alternative transport based on Akka Streams TCP/TLS,
which shares its basic infrastructure with the Aeron (UDP) transport.

It can also be used with plain TCP without TLS, which is a good alternative
when UDP can't be used. It’s also using less CPU than Aeron when the system
is idle or at low message rates.

We have done extensive testing of the new transport, and we continuously
run all of Akka's tests for remoting and clustering with the TCP transport
in the CI environment. However, since it's a new implementation the TCP/TLS
transport is not ready for usage in production yet, but please test it and
report any issues.

You find more information and instructions of how to enable TCP or TLS in
Artery in the documentation
.
StreamRefs - Reactive Streams over the network

Stream references, or “stream refs” for short, allow running Akka Streams
across multiple nodes within an Akka Cluster.

The screencast  should give
you a good overview of this exciting feature.

The prime use case for stream refs is to replace raw actor or HTTP
messaging between systems where a long running stream of data is expected
between two entities. Often times, they can be used to effectively achieve
point to point streaming without the need of setting up additional message
brokers or similar secondary clusters.

Stream refs are well suited for any system in which you need to send
messages between nodes and need to do so in a flow-controlled fashion.
Typical examples include sending work requests to worker nodes, as fast as
possible, but not faster than the worker node can process them, or sending
data elements which the downstream may be slow at processing. It is
recommended to mix and introduce stream refs in Actor messaging based
systems, where the actor messaging is used to orchestrate and prepare such
message flows, and later the stream refs are used to do the flow-controlled
message transfer.

You find more details in the documentation
.
Akka Typed

There are several breaking chang

Re: [akka-user] [Akka-Streams] Want to always receive latest element in Sink

2018-02-23 Thread saloniv 
Hello Arnout,

We are providing api for developers to use. So, there is a callback written 
by other developers which will be executed instead of Thread.sleep in 
example. 

Hence, we cannot say whether they will write CPU intensive code or some 
kind of IO.

Hope this helps.

On Wednesday, February 7, 2018 at 6:26:11 PM UTC+5:30, Arnout Engelen wrote:
>
> Hello Saloni,
>
> I think it would be helpful to have a more realistic example than doing 
> "Thread.sleep(1000)" in the sink.
>
> Could we unpack what this sleep is intended to mimic in your 'real' 
> application? Is it for example doing CPU-intensive data parsing or perhaps 
> some kind of IO?
>
>
> Kind regards,
>
> Arnout
>
> On Thu, Jan 25, 2018 at 7:27 AM, > 
> wrote:
>
>> Hello,
>>
>> We are having a requirement that if a consumer is slower than producer 
>> then discard all the elements that cannot be consumed and whenever the 
>> consumer gets ready, feed the latest element from producer.
>>
>> We tried an approach as follows:
>>
>> Source.actorRef(0, OverflowStrategy.dropHead)   // actor receives 
>>> data at every 10 milliseconds
>>
>> .runWith {
>>>println("data received")
>>>Thread.sleep(1000)   // mimic consumer processing data in 
>>> every 1 second
>>> }
>>
>>
>> We shrank the buffer size to 1 (minimal possible) with following settings
>>
>> private val actorMaterializerSettings = ActorMaterializerSettings(
>>> actorSystem).withInputBuffer(1, 1)
>>
>>
>> With this buffer size, Sink pulls data 1 to consume and data 2 to put in 
>> buffer at initialization.
>>
>> While data 1 is getting processed we are dropping data from producer.
>>
>> When data 1 gets processed after 1000 milliseconds (1 second) ideally I 
>> should receive data 10 (and drop 2 - 9 as consumer is slow) but instead I 
>> receive data 2 from the buffer. data 2 in our domain is extremely useless 
>> as it is stale.
>>
>> Is there a way to disable buffer at Sink totally and always pull latest 
>> data from Source ?
>>
>>
>> -- 
>> >> 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.
>>
>
>
>
> -- 
> Arnout Engelen
> *Senior Software Engineer*
> E: arnout@lightbend.com 
> T: https://twitter.com/raboofje
>
>
>

-- 
>>  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-user] Re: scheduler: new instance per run or long-lived actor?

2018-02-23 Thread wapgui 
Did you try this: https://github.com/enragedginger/akka-quartz-scheduler ?

Am Freitag, 23. Februar 2018 07:01:35 UTC+1 schrieb Александр Семибратов:
>
> For example
>  
> First approach 
> https://gist.github.com/semibratov/d2968b7bd66198e636d64b9d0e35ec6b
> Second approach
> https://gist.github.com/semibratov/a0121fe73883a3b6216735ca20f75e63 
>  
>

-- 
>>  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 actoreRef with macWire DI, actoreRef is not set

2018-02-23 Thread Tim Moore 
I think your problem is the implicit sender.

When you call actor2 ! Msg1() from inside your Actor1 receiver, it sends
the Actor1 ref as the implicit sender.

Then, then Actor2 replies to the sender, it goes back to the same Actor1
instance.

When you call actor2 ! Msg1() from inside the FailedService object, you
don't have a sender in scope, so it defaults to the dead letter queue.

See https://doc.akka.io/docs/akka/2.5/actors.html#tell-fire-forget

One way you could solve that is to add the implicit sender argument to your
testSend() method:

class FailedService(actor2: ActorRef@@Actor2) {
  def testSend()(implicit sender: ActorRef) = {
actor2 ! Msg1()
  }
}




On Fri, Feb 23, 2018 at 6:29 PM, Kanwaljeet Singh 
wrote:

> In my current code u feel that it is cyclic dependency because you see
> actor1 having access to failedService bean and actor2. But in reality, I
> can just remove actor2 being injected into actor1 if I can get away by
> using failedservice bean. Even if I do that, things remain the same. I have
> my Actor1 as below now(and I think no cyclic depenency now). I still hit
> the issue
>
> class Actor1(failedService: FailedService) extends Actor{
>   override def receive: Receive = {
> case TriggerActor1() =>
>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>   failedService.testSend()
>   //actor2 ! Msg1()
> case Msg2() => println("got msg2 from actor 1")
>   }
>
>
> On Thu, Feb 22, 2018 at 11:57 PM Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> It is a macwire thing ;-)
>> It hides you made a cyclic dependency.
>>
>> how would you make this work, plain java/scala:
>>
>> val a = new A(requires B!)
>> val b = new B(a /*requires A*/)
>> Hm, A has an issue...
>>
>> val b = new B(requires B)
>> val a = new A(b /*requires B!*/)
>> Hmm, B can’t get A…
>>
>> As simple as that.
>> Don’t do cyclic dependencies like that.
>>
>> you can create both and do a `a ! HelloIAm(b)` or something similar.
>>
>> --
>> Cheers,
>> Konrad 'ktoso ' Malawski
>> Akka  @ Lightbend 
>>
>> On February 23, 2018 at 16:51:48, Kanwaljeet Singh (ksachd...@gmail.com)
>> wrote:
>>
>> here is my code
>>
>> class Actor1(failedService: FailedService, actor2: ActorRef @@ Actor2) 
>> extends Actor{
>>   override def receive: Receive = {
>> case TriggerActor1() =>
>>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>>   failedService.testSend()
>>   //actor2 ! Msg1()
>> case Msg2() => println("got msg2 from actor 1")
>>   }
>>
>>
>>
>> class Actor2 extends Actor {
>>   override def receive: Receive = {
>> case Msg1() => {
>>   println("send without future")
>>   val origsender = sender()
>>   origsender ! Msg2()
>> }
>>   }
>>
>>
>> class FailedService(actor2: ActorRef@@Actor2) {
>>   def testSend() = {
>> actor2 ! Msg1()
>>   }
>> }
>>
>>
>> With my current code as shared above, Actor1 is able to send Msg1 to Actor2
>>
>> and actor2 responds with Msg2 but Msg2 goes to deadletter. I get the below 
>> error
>>
>> akka.actor.DeadLetterActorRef - Message [backup.failedakka.Msg2] from 
>> Actor[akka://application/user/actor2#-662746578] to 
>> Actor[akka://application/deadLetters] was not delivered. [1] dead letters 
>> encountered.
>>
>>
>> However, if insted of using the line "failedService.testSend()" in my 
>> Actor1, I uncomment the line below it
>>
>> and use that to communicate, things work fine.
>>
>> Is the Q clear now? I am injecting dependencies with MacWire
>>
>> On Thu, Feb 22, 2018 at 11:07 PM Kanwaljeet Singh 
>> wrote:
>>
>>> this is nto a macwire question I think.
>>>
>>> On Thu, Feb 22, 2018 at 11:06 PM Konrad “ktoso” Malawski <
>>> konrad.malaw...@lightbend.com> wrote:
>>>
 I don’t understand what’s going where or how ;-)
 Could you share code?

 Also, isn’t this a macwire question? Better to ask on
 https://github.com/adamw/macwire/issues ?

 --
 Cheers,
 Konrad 'ktoso ' Malawski
 Akka  @ Lightbend 

 On February 23, 2018 at 16:05:22, ksachd...@gmail.com (
 ksachd...@gmail.com) wrote:


1.

Scenario 1 - Working scenario
- Actor1 -->MyMsg1-->Actor2
   - Actor2 MyMsgHandler - Processes message(with Future), does
   pipeTo to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2



1.

Scenario2 - Failing scenario
- Actor1 has a bean injected via MacWire - myBean.
   - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
   - Actor2 MyMsgHandler processes message(with Future), does
   pipeTo to sender and tries sending MyMsg2 - Goes to deadLetter.
   The actor Ref for sender is never set.

 How do I fix scenario2?

 --
 >> Read the docs: http://akka.io/docs/
 >>

Re: [akka-user] Akka actoreRef with macWire DI, actoreRef is not set

2018-02-23 Thread Konrad “ktoso” Malawski 
This is not a 24h/7d support channel, wait a bit ;-)
Thanks.

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On February 23, 2018 at 17:34:30, Kanwaljeet Singh (ksachd...@gmail.com)
wrote:

Any pointers Konrad?

On Thu, Feb 22, 2018, 11:59 PM Kanwaljeet Singh  wrote:

> In my current code u feel that it is cyclic dependency because you see
> actor1 having access to failedService bean and actor2. But in reality, I
> can just remove actor2 being injected into actor1 if I can get away by
> using failedservice bean. Even if I do that, things remain the same. I have
> my Actor1 as below now(and I think no cyclic depenency now). I still hit
> the issue
>
> class Actor1(failedService: FailedService) extends Actor{
>
>
>   override def receive: Receive = {
> case TriggerActor1() =>
>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>   failedService.testSend()
>   //actor2 ! Msg1()
> case Msg2() => println("got msg2 from actor 1")
>   }
>
>
> On Thu, Feb 22, 2018 at 11:57 PM Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> It is a macwire thing ;-)
>> It hides you made a cyclic dependency.
>>
>> how would you make this work, plain java/scala:
>>
>> val a = new A(requires B!)
>> val b = new B(a /*requires A*/)
>> Hm, A has an issue...
>>
>> val b = new B(requires B)
>> val a = new A(b /*requires B!*/)
>> Hmm, B can’t get A…
>>
>> As simple as that.
>> Don’t do cyclic dependencies like that.
>>
>> you can create both and do a `a ! HelloIAm(b)` or something similar.
>>
>> --
>> Cheers,
>> Konrad 'ktoso ' Malawski
>> Akka  @ Lightbend 
>>
>> On February 23, 2018 at 16:51:48, Kanwaljeet Singh (ksachd...@gmail.com)
>> wrote:
>>
>> here is my code
>>
>> class Actor1(failedService: FailedService, actor2: ActorRef @@ Actor2) 
>> extends Actor{
>>   override def receive: Receive = {
>> case TriggerActor1() =>
>>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>>   failedService.testSend()
>>   //actor2 ! Msg1()
>> case Msg2() => println("got msg2 from actor 1")
>>   }
>>
>>
>>
>> class Actor2 extends Actor {
>>   override def receive: Receive = {
>> case Msg1() => {
>>   println("send without future")
>>   val origsender = sender()
>>   origsender ! Msg2()
>> }
>>   }
>>
>>
>> class FailedService(actor2: ActorRef@@Actor2) {
>>   def testSend() = {
>> actor2 ! Msg1()
>>   }
>> }
>>
>>
>> With my current code as shared above, Actor1 is able to send Msg1 to Actor2
>>
>> and actor2 responds with Msg2 but Msg2 goes to deadletter. I get the below 
>> error
>>
>> akka.actor.DeadLetterActorRef - Message [backup.failedakka.Msg2] from 
>> Actor[akka://application/user/actor2#-662746578] to 
>> Actor[akka://application/deadLetters] was not delivered. [1] dead letters 
>> encountered.
>>
>>
>> However, if insted of using the line "failedService.testSend()" in my 
>> Actor1, I uncomment the line below it
>>
>> and use that to communicate, things work fine.
>>
>> Is the Q clear now? I am injecting dependencies with MacWire
>>
>> On Thu, Feb 22, 2018 at 11:07 PM Kanwaljeet Singh 
>> wrote:
>>
>>> this is nto a macwire question I think.
>>>
>>> On Thu, Feb 22, 2018 at 11:06 PM Konrad “ktoso” Malawski <
>>> konrad.malaw...@lightbend.com> wrote:
>>>
 I don’t understand what’s going where or how ;-)
 Could you share code?

 Also, isn’t this a macwire question? Better to ask on
 https://github.com/adamw/macwire/issues ?

 --
 Cheers,
 Konrad 'ktoso ' Malawski
 Akka  @ Lightbend 

 On February 23, 2018 at 16:05:22, ksachd...@gmail.com (
 ksachd...@gmail.com) wrote:


1.

Scenario 1 - Working scenario
- Actor1 -->MyMsg1-->Actor2
   - Actor2 MyMsgHandler - Processes message(with Future), does
   pipeTo to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2



1.

Scenario2 - Failing scenario
- Actor1 has a bean injected via MacWire - myBean.
   - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
   - Actor2 MyMsgHandler processes message(with Future), does
   pipeTo to sender and tries sending MyMsg2 - Goes to deadLetter.
   The actor Ref for sender is never set.

 How do I fix scenario2?

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

Re: [akka-user] Akka actoreRef with macWire DI, actoreRef is not set

2018-02-23 Thread Kanwaljeet Singh 
Any pointers Konrad?

On Thu, Feb 22, 2018, 11:59 PM Kanwaljeet Singh  wrote:

> In my current code u feel that it is cyclic dependency because you see
> actor1 having access to failedService bean and actor2. But in reality, I
> can just remove actor2 being injected into actor1 if I can get away by
> using failedservice bean. Even if I do that, things remain the same. I have
> my Actor1 as below now(and I think no cyclic depenency now). I still hit
> the issue
>
> class Actor1(failedService: FailedService) extends Actor{
>
>
>   override def receive: Receive = {
> case TriggerActor1() =>
>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>   failedService.testSend()
>   //actor2 ! Msg1()
> case Msg2() => println("got msg2 from actor 1")
>   }
>
>
> On Thu, Feb 22, 2018 at 11:57 PM Konrad “ktoso” Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> It is a macwire thing ;-)
>> It hides you made a cyclic dependency.
>>
>> how would you make this work, plain java/scala:
>>
>> val a = new A(requires B!)
>> val b = new B(a /*requires A*/)
>> Hm, A has an issue...
>>
>> val b = new B(requires B)
>> val a = new A(b /*requires B!*/)
>> Hmm, B can’t get A…
>>
>> As simple as that.
>> Don’t do cyclic dependencies like that.
>>
>> you can create both and do a `a ! HelloIAm(b)` or something similar.
>>
>> --
>> Cheers,
>> Konrad 'ktoso ' Malawski
>> Akka  @ Lightbend 
>>
>> On February 23, 2018 at 16:51:48, Kanwaljeet Singh (ksachd...@gmail.com)
>> wrote:
>>
>> here is my code
>>
>> class Actor1(failedService: FailedService, actor2: ActorRef @@ Actor2) 
>> extends Actor{
>>   override def receive: Receive = {
>> case TriggerActor1() =>
>>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>>   failedService.testSend()
>>   //actor2 ! Msg1()
>> case Msg2() => println("got msg2 from actor 1")
>>   }
>>
>>
>>
>> class Actor2 extends Actor {
>>   override def receive: Receive = {
>> case Msg1() => {
>>   println("send without future")
>>   val origsender = sender()
>>   origsender ! Msg2()
>> }
>>   }
>>
>>
>> class FailedService(actor2: ActorRef@@Actor2) {
>>   def testSend() = {
>> actor2 ! Msg1()
>>   }
>> }
>>
>>
>> With my current code as shared above, Actor1 is able to send Msg1 to Actor2
>>
>> and actor2 responds with Msg2 but Msg2 goes to deadletter. I get the below 
>> error
>>
>> akka.actor.DeadLetterActorRef - Message [backup.failedakka.Msg2] from 
>> Actor[akka://application/user/actor2#-662746578] to 
>> Actor[akka://application/deadLetters] was not delivered. [1] dead letters 
>> encountered.
>>
>>
>> However, if insted of using the line "failedService.testSend()" in my 
>> Actor1, I uncomment the line below it
>>
>> and use that to communicate, things work fine.
>>
>> Is the Q clear now? I am injecting dependencies with MacWire
>>
>> On Thu, Feb 22, 2018 at 11:07 PM Kanwaljeet Singh 
>> wrote:
>>
>>> this is nto a macwire question I think.
>>>
>>> On Thu, Feb 22, 2018 at 11:06 PM Konrad “ktoso” Malawski <
>>> konrad.malaw...@lightbend.com> wrote:
>>>
 I don’t understand what’s going where or how ;-)
 Could you share code?

 Also, isn’t this a macwire question? Better to ask on
 https://github.com/adamw/macwire/issues ?

 --
 Cheers,
 Konrad 'ktoso ' Malawski
 Akka  @ Lightbend 

 On February 23, 2018 at 16:05:22, ksachd...@gmail.com (
 ksachd...@gmail.com) wrote:


1.

Scenario 1 - Working scenario
- Actor1 -->MyMsg1-->Actor2
   - Actor2 MyMsgHandler - Processes message(with Future), does
   pipeTo to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2



1.

Scenario2 - Failing scenario
- Actor1 has a bean injected via MacWire - myBean.
   - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
   - Actor2 MyMsgHandler processes message(with Future), does
   pipeTo to sender and tries sending MyMsg2 - Goes to deadLetter.
   The actor Ref for sender is never set.

 How do I fix scenario2?

 --
 >> 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 actoreRef with macWire DI, actoreRef is not set

2018-02-23 Thread Kanwaljeet Singh 
In my current code u feel that it is cyclic dependency because you see
actor1 having access to failedService bean and actor2. But in reality, I
can just remove actor2 being injected into actor1 if I can get away by
using failedservice bean. Even if I do that, things remain the same. I have
my Actor1 as below now(and I think no cyclic depenency now). I still hit
the issue

class Actor1(failedService: FailedService) extends Actor{
  override def receive: Receive = {
case TriggerActor1() =>
  println("Actor1 triggered from REST controller. Send msg to actor 2")
  failedService.testSend()
  //actor2 ! Msg1()
case Msg2() => println("got msg2 from actor 1")
  }


On Thu, Feb 22, 2018 at 11:57 PM Konrad “ktoso” Malawski <
konrad.malaw...@lightbend.com> wrote:

> It is a macwire thing ;-)
> It hides you made a cyclic dependency.
>
> how would you make this work, plain java/scala:
>
> val a = new A(requires B!)
> val b = new B(a /*requires A*/)
> Hm, A has an issue...
>
> val b = new B(requires B)
> val a = new A(b /*requires B!*/)
> Hmm, B can’t get A…
>
> As simple as that.
> Don’t do cyclic dependencies like that.
>
> you can create both and do a `a ! HelloIAm(b)` or something similar.
>
> --
> Cheers,
> Konrad 'ktoso ' Malawski
> Akka  @ Lightbend 
>
> On February 23, 2018 at 16:51:48, Kanwaljeet Singh (ksachd...@gmail.com)
> wrote:
>
> here is my code
>
> class Actor1(failedService: FailedService, actor2: ActorRef @@ Actor2) 
> extends Actor{
>   override def receive: Receive = {
> case TriggerActor1() =>
>   println("Actor1 triggered from REST controller. Send msg to actor 2")
>   failedService.testSend()
>   //actor2 ! Msg1()
> case Msg2() => println("got msg2 from actor 1")
>   }
>
>
>
> class Actor2 extends Actor {
>   override def receive: Receive = {
> case Msg1() => {
>   println("send without future")
>   val origsender = sender()
>   origsender ! Msg2()
> }
>   }
>
>
> class FailedService(actor2: ActorRef@@Actor2) {
>   def testSend() = {
> actor2 ! Msg1()
>   }
> }
>
>
> With my current code as shared above, Actor1 is able to send Msg1 to Actor2
>
> and actor2 responds with Msg2 but Msg2 goes to deadletter. I get the below 
> error
>
> akka.actor.DeadLetterActorRef - Message [backup.failedakka.Msg2] from 
> Actor[akka://application/user/actor2#-662746578] to 
> Actor[akka://application/deadLetters] was not delivered. [1] dead letters 
> encountered.
>
>
> However, if insted of using the line "failedService.testSend()" in my Actor1, 
> I uncomment the line below it
>
> and use that to communicate, things work fine.
>
> Is the Q clear now? I am injecting dependencies with MacWire
>
> On Thu, Feb 22, 2018 at 11:07 PM Kanwaljeet Singh 
> wrote:
>
>> this is nto a macwire question I think.
>>
>> On Thu, Feb 22, 2018 at 11:06 PM Konrad “ktoso” Malawski <
>> konrad.malaw...@lightbend.com> wrote:
>>
>>> I don’t understand what’s going where or how ;-)
>>> Could you share code?
>>>
>>> Also, isn’t this a macwire question? Better to ask on
>>> https://github.com/adamw/macwire/issues ?
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso ' Malawski
>>> Akka  @ Lightbend 
>>>
>>> On February 23, 2018 at 16:05:22, ksachd...@gmail.com (
>>> ksachd...@gmail.com) wrote:
>>>
>>>
>>>1.
>>>
>>>Scenario 1 - Working scenario
>>>- Actor1 -->MyMsg1-->Actor2
>>>   - Actor2 MyMsgHandler - Processes message(with Future), does
>>>   pipeTo to sender with MyMsg2. Works fine, Actor1 recvs MyMsg2
>>>
>>>
>>>
>>>1.
>>>
>>>Scenario2 - Failing scenario
>>>- Actor1 has a bean injected via MacWire - myBean.
>>>   - myBean has Actor2 injected as a bean and sends MyMsg1 to Actor2
>>>   - Actor2 MyMsgHandler processes message(with Future), does pipeTo
>>>   to sender and tries sending MyMsg2 - Goes to deadLetter. The
>>>   actor Ref for sender is never set.
>>>
>>> How do I fix scenario2?
>>>
>>> --
>>> >> 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.
>>>
>>>

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