[akka-user][deprecated] Re: [akka-user] Akka HTTP: How to find out that there is no Content-Type header?

[Heiko Seeberger]

Thanks, Urs!


> Am 10.03.2018 um 12:03 schrieb Urs Schoenenberger 
> <urs.schoenenber...@gmail.com>:
> 
> Hey Heiko,
> 
> I dug into the source code at this point recently, and unfortunately I don't 
> think that what you need is easily possible without changing the library.
> Some headers (Content-Length, Content-Type, Transfer-Encoding) are consumed 
> by the HttpMessageParser without exposing them via the request's "headers" 
> field later.
> This happens during the "parsing" stage in HttpServerBluePrint, which 
> consumes the incoming ByteStrings. Neither the HttpServerBluePrint nor the 
> underlying HttpRequestParser/HttpMessageParser are injectable without copying 
> substantial parts of the library code into your application, as far as I can 
> see.
> If you can use a patched version of Akka HTTP, I'd probably change the 
> recursive call in HttpMessageParser::parseHeaderLines to pass "headers += h" 
> for the Content-Type case, then you have access to the interpreted header 
> through httpRequest.entity.contentType and to the raw header via 
> httpRequest.headers.
> 
> Urs
> 
> On Thursday, March 1, 2018 at 8:58:10 PM UTC+1, Heiko Seeberger wrote:
> Nobody?
> 
>> Am 24.02.2018 um 19:12 schrieb Heiko Seeberger <loe...@posteo.de <>>:
>> 
>> Hey, Akka HTTP experts, 
>> 
>> Akka HTTP treats the Content-Type header in a special way (seemingly 
>> according to the spedification). In particular if the request contains 
>> neither a Content-Type header nor entity data, it sets the Content-Type to 
>> "application/octet-stream“.
>> 
>> This seems to be in sync with the HTTP spec (7.2.1). Is there a way to see 
>> that the raw request did not contain the Content-Type header?
>> 
>> Thanks
>> Heiko
>> 
>> --
>> 
>> Heiko Seeberger
>> Home: heikoseeberger.de <http://heikoseeberger.de/>
>> Twitter: @hseeberger
>> Public key: keybase.io/hseeberger <http://keybase.io/hseeberger>
>> 
>> 
>> 
>> 
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <https://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
*
** New discussion forum: https://discuss.akka.io/ replacing akka-user 
google-group soon.
** This group will soon be put into read-only mode, and replaced by 
discuss.akka.io
** More details: https://akka.io/blog/news/2018/03/13/discuss.akka.io-announced
*
>>>>>>>>>> 
>>>>>>>>>>  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

[Heiko Seeberger]

`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 <patrik.nordw...@gmail.com>:
> 
> Thanks!
> 
> On Wed, Mar 7, 2018 at 6:16 PM, Jeff <jknight12...@gmail.com 
> <mailto:jknight12...@gmail.com>> wrote:
> An example of documentation for using import context.dispatcher is here 
> https://doc.akka.io/docs/akka/2.5/futures.html#within-actors 
> <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 <jknigh...@gmail.com <>> 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 <jknigh...@gmail.com <>> 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/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> Cheers,
> √
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 

Re: [akka-user] Akka HTTP: How to find out that there is no Content-Type header?

[Heiko Seeberger]

Nobody?

> Am 24.02.2018 um 19:12 schrieb Heiko Seeberger <loe...@posteo.de>:
> 
> Hey, Akka HTTP experts, 
> 
> Akka HTTP treats the Content-Type header in a special way (seemingly 
> according to the spedification). In particular if the request contains 
> neither a Content-Type header nor entity data, it sets the Content-Type to 
> "application/octet-stream“.
> 
> This seems to be in sync with the HTTP spec (7.2.1). Is there a way to see 
> that the raw request did not contain the Content-Type header?
> 
> Thanks
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger
> Public key: keybase.io/hseeberger <http://keybase.io/hseeberger>
> 
> 
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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] Akka HTTP: How to find out that there is no Content-Type header?

[Heiko Seeberger]

Hey, Akka HTTP experts, 

Akka HTTP treats the Content-Type header in a special way (seemingly according 
to the spedification). In particular if the request contains neither a 
Content-Type header nor entity data, it sets the Content-Type to 
"application/octet-stream“.

This seems to be in sync with the HTTP spec (7.2.1). Is there a way to see that 
the raw request did not contain the Content-Type header?

Thanks
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de
Twitter: @hseeberger
Public key: keybase.io/hseeberger




-- 
>>>>>>>>>>  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] Supporting transient states using Akka FSM

[Heiko Seeberger]

Hmm … ain’t is possible to goto(C) when in state A? Instead of going to the 
transient B.

--

Heiko Seeberger
Home: heikoseeberger.de
Twitter: @hseeberger
Public key: keybase.io/hseeberger



> Am 22.12.2017 um 09:15 schrieb Christopher Hunt <hunt...@gmail.com>:
> 
> Hey there,
> 
> I've recently come across a situation with transient FSM states that I'd like 
> to model in Akka FSM. I'm wondering if there's a better way than below in 
> terms of expressing transient states:
> 
> onTransition {
>  case A -> B
>goto(C)
> }
> 
> when(B) {
>   case _ =>
> log.error("we should never have got here")
> }
> 
> 
> 
> i.e. I need the when(B) in order to register the state. However, it is a 
> state that we quickly pass through and serves to support the onTransition 
> logic.
> 
> Is there a better way while retaining the B state?
> 
> Cheers,
> -C
> 
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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.


signature.asc
Description: Message signed with OpenPGP

Re: [akka-user] Coordinated Shutdown

[Heiko Seeberger]

That’s not the issue, shutdown progresses without noticeable delay (much less 
than a second). I’ll investigate further …

--

Heiko Seeberger
Home: heikoseeberger.de
Twitter: @hseeberger
Public key: keybase.io/hseeberger



> Am 19.12.2017 um 10:32 schrieb Patrik Nordwall <patrik.nordw...@gmail.com>:
> 
> Sounds strange. For how long do you sleep in the PhaseServiceUnbind task? 
> Note that there is a default timeout of 5 seconds for a phase, otherwise it 
> will continue with next phase. 
> https://github.com/akka/akka/blob/master/akka-actor/src/main/resources/reference.conf#L1044
>  
> <https://github.com/akka/akka/blob/master/akka-actor/src/main/resources/reference.conf#L1044>
> 
> If that is not the issue then try with loglevel=DEBUG to see what it is doing.
> 
> /Patrik
> 
> On Mon, Dec 18, 2017 at 9:45 PM, Heiko Seeberger <loe...@posteo.de 
> <mailto:loe...@posteo.de>> wrote:
> Hi,
> 
> I’m playing with coordinated shutdown and things are not working as expected.
> 
> I have a taks registered for PhaseServiceUnbind. When I kill (SIGTERM) the 
> running system, I can see (logging) that the task gets evaluated, but it 
> seems that the shutdown process doesn’t wait for its result, i.e. doesn’t 
> wait until the respective Future[Done] has completed. Instead all kinds of 
> cluster related shutdown activities are started immediately.
> 
> So, am I missing something or shouldn’t cluster related shutdown activities 
> wait for the unbind task to complete?
> 
> Thanks
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger
> Public key: keybase.io/hseeberger <http://keybase.io/hseeberger>
> 
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> 
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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] Coordinated Shutdown

[Heiko Seeberger]

Hi,

I’m playing with coordinated shutdown and things are not working as expected.

I have a taks registered for PhaseServiceUnbind. When I kill (SIGTERM) the 
running system, I can see (logging) that the task gets evaluated, but it seems 
that the shutdown process doesn’t wait for its result, i.e. doesn’t wait until 
the respective Future[Done] has completed. Instead all kinds of cluster related 
shutdown activities are started immediately.

So, am I missing something or shouldn’t cluster related shutdown activities 
wait for the unbind task to complete?

Thanks
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de
Twitter: @hseeberger
Public key: keybase.io/hseeberger



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


signature.asc
Description: Message signed with OpenPGP

Re: [akka-user] Problems connecting a remote node using the sample cluster project

[Heiko Seeberger]

You need to start one node with akka.remote.netty.tcp.port=2551 (the first seed 
node) at least, e.g. via a JVM argument. Read up the details in the Cluster 
docs.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 17 Mar 2016, at 01:57, Scott Mackie <scottmacki...@hotmail.com> wrote:
> 
> I think I may have realised one part of my mistake, the 
> "akka.remote.netty.tcp.hostname" needs to be set to the hostname of the 
> machine that the application is running on, so that the remote nodes can talk 
> back to it.
> 
> Now that I've changed that, I'm successfully starting up the application, but 
> its still failing to register with the seed nodes on the first machine. For 
> example :
> 
> [info] [WARN] [03/17/2016 00:56:07.070] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-21] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
> 1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2552]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2552]
> [info] [WARN] [03/17/2016 00:56:17.371] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-22] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2551-
> 0] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2551] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2551]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2551]
> [info] [WARN] [03/17/2016 00:56:27.171] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-21] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
> 1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2552]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2552]
> [info] [WARN] [03/17/2016 00:56:42.229] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-22] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2551-
> 0] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2551] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2551]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2551]
> [info] [WARN] [03/17/2016 00:56:47.272] 
> [ClusterSystem-akka.remote.default-remote-dispatcher-22] 
> [akka.tcp://ClusterSyst
> em@GLA-ENG-2146NX1:12349/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40Scott-PC%3A2552-
> 1] Association with remote system [akka.tcp://ClusterSystem@Scott-PC:2552] 
> has failed, address is now gated for [5000] m
> s. Reason: [Association failed with [akka.tcp://ClusterSystem@Scott-PC:2552]] 
> Caused by: [connection timed out: Scott-PC
> /192.168.0.2:2552]
> 
> 
> 
> On Thursday, 17 March 2016 00:25:06 UTC, Scott Mackie wrote:
> Hi folks,
> 
> I've been taking a look at the clustering sample project provided with the 
> Typesafe Activator 
> <http://www.lightbend.com/activator/template/akka-sample-cluster-scala>, and 
> I'm having some trouble with joining a remotely running cluster.
> 
> I've got the project set up on two machines, the first machine has two 
> instances of the "SimpleClusterApp" running. The consoles for these two 
> processes is showing what I'd expect, membership messages showing that both 
> nodes are on the cluster.
> 
> I wanted to see if I could connect a third instance of this from the second 
> machine, but I can't get the config right. In the application.conf file, I've 
> got the following:
> 
> akka {
>   actor {
> provider = "akka.cluster.ClusterActorRefProvider"
>   }
>   remote {
> log-remote-lifecycle-events = off
> netty.tcp {
>   hostname = "Scott-PC"
>   port = 0
> }
>   }
> 
>   cluster {
> seed-nodes = [
>   "akka.tcp://ClusterSystem@Scott-PC:2551",
>   "akka.tcp://ClusterSystem@Scott-PC:2552"]
> 
> auto-do

Re: [akka-user] change of Tech Lead

[Heiko Seeberger]

Dear Roland,

Reacting to opportunities – should we add opportunistic as another trait to 
Reactive? My apologies, but this was just too tempting. When we meet in Munich, 
I owe you a beer for this and another one or as many as you can drink for the 
fantastic work you did for Akka.

Dear Patrik,

I’m glad to see you take over, knowing that Akka remains in excellent hands.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 07 Mar 2016, at 18:37, Roland Kuhn <goo...@rkuhn.info> wrote:
> 
> Dear fellow hakkers,
> 
> as of today I am passing on the baton of Akka Tech Lead @ Lightbend to Patrik 
> Nordwall. Don’t worry, I will stay around and keep working on Akka, but it 
> will no longer be my day job come April: I am co-founding actyx 
> <https://www.actyx.io/en/>—a new start-up in Munich that aims at bringing 
> reactive design principles to the IT behind industrial manufacturing—where I 
> will build and lead the engineering organization. It was always my plan to 
> solve concrete customer challenges once I have collected enough experience 
> with building the tools, and while I had not yet started looking for an 
> opportunity I could also not pass this one up when it presented itself.
> 
> Akka will be in good hands with Patrik and the rest of the team, he is as 
> passionate about distributed systems as I am and he is a much more 
> disciplined coder—not to mention that he joined the Akka team before any 
> other current member including myself. I am very grateful that I had the 
> chance to be part of this amazing team for the past 4.5 years and I have no 
> desire to leave this awesome community anytime soon.
> 
> Regards,
> 
> Roland
> 
> 
> Lightbend – Reactive apps on the JVM.
> twitter: @rolandkuhn
>  <http://twitter.com/#!/rolandkuhn>
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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.

Re: [akka-user] Using Props.create with arguments that are injected

[Heiko Seeberger]

Why do you think that the `Props` factory taking the actor constructor by name 
is discouraged? It’s the opposite: You definitely SHOULD use it, the other 
approach is using reflection at runtime and is not refactoring safe.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 01 Feb 2016, at 20:46, steven richardson <stevenjohnrichard...@gmail.com> 
> wrote:
> 
> I am running into an issue using Props.create when providing a class and its 
> arguments. The example below is contrived but will hopefully serve its 
> purpose.
> 
> trait Provider {}
> 
> 
> class DefaultProvider extends Provider {}
> 
> class MyActor(provider: Provider) extends Actor {
>   def receive = ...
> }
> 
> 
> Then let's say I am injecting the provider using Guice or another container:
> 
> class ProviderPropsFactory @Inject()(protected val provider: Provider) {
>   def buildProps: Props = Props.create(classOf[MyActor], provider)
> }
> 
> 
> At runtime if I try to start an actor using these props as shown here, I get 
> an IllegalArgumentException when Akka attempts to find the matching 
> constructor for the actor since it is only seems to match on the concrete 
> type rather than allowing a compatible trait or an abstract type from the 
> instance's hierarchy. 
> 
> system.actorOf(factory.buildProps)
> java.lang.IllegalArgumentException: no matching constructor found on class 
> com.sample.MyActor for arguments [class com.sample.DefaultProvider]
>  at akka.util.Reflect$.error$1(Reflect.scala:82) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
>  at akka.util.Reflect$.findConstructor(Reflect.scala:106) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
>  at akka.actor.ArgsReflectConstructor.(Props.scala:353) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
>  at akka.actor.IndirectActorProducer$.apply(Props.scala:312) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
>  at akka.actor.Props.producer(Props.scala:179) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
>  at akka.actor.Props.(Props.scala:192) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
>  at akka.actor.Props$.create(Props.scala:99) 
> ~[akka-actor_2.11-2.3-bin-rp-15v01p06.jar:na]
> 
> I could use this snippet  below instead which I know would work, but this 
> type of approach is discouraged/deprecated and I would like to be doing 
> things the recommended way. Do you have any suggestions?
> 
> class ProviderPropsFactory @Inject()(protected val provider: Provider) {
>   def buildProps: Props = Props(new MyActor(provider))
> }
> 
> 
> Any and all help is appreciated.
> 
> Thanks,
> Steve
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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.

Re: [akka-user] Log4j2 Async Logger

[Heiko Seeberger]

Got it. Unfortunately that’s not possible right now because of the design of 
Akka’s logging facility which is made up from a frontend (the API you actually 
use for logging, based on Akka’s Actor based event stream) and the specific 
backend (e.g. akka-log4j).

Maybe something to consider for Akka Typed? Roland?

Heiko


--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 20 Dec 2015, at 13:17, Guido Medina <oxyg...@gmail.com> wrote:
> 
> Sorry for brevity writing from phone which I hate.
> 
> In a nutshell I would like your plugin akka-log4j to offer an extra class to 
> log directly without an actor in between which is your current 
> implementation, same applies for akka-slf4j.
> 
> That way Akka system has a registered logger and my actors will continue 
> obtaining the logger instance from Akka system.
> 
> -- 
>>>>>>>>>>> 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 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 cluster sharding topology aware

[Heiko Seeberger]

Maybe sharding is not what you need for 90% of your use cases then.

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 14 Dec 2015, at 20:03, Karthik Deivasigamani <karthi...@gmail.com> wrote:
> 
> Patrik,
>  In our system I expect the actors to be created frequently and they'll 
> be short lived in almost 90% of our use cases. The reason why I wanted 
> control over the location in which an actor is created, is to minimize the 
> overhead of passing messages across different machines and keep things local 
> much as possible. Yes I did read about ShardAllocationStrategy and was 
> wondering if there was entity level allocation strategy that I could 
> override. 
> 
> Thanks,
> Karthik
> 
> On Monday, December 14, 2015 at 10:13:40 AM UTC-8, Patrik Nordwall wrote:
> Heiko is right. If allocation at shard level is good enough for you, it’s 
> possible to use a custom ShardAllocationStrategy that cares about the 
> requester ActorRef:
> 
> * @param requester actor reference to the [[ShardRegion]] that requested the 
> location of the
> *  shard, can be returned if preference should be given to 
> the node where the shard was first accessed
> It is possible to use a one-to-one mapping between entity and shard to be in 
> full control for each actor, but that is not very scalable and it adds 
> additional latency for the first message for each entity.
> 
> Cheers,
> Patrik
> 
> 
> On Mon, Dec 14, 2015 at 7:44 AM, Heiko Seeberger <loe...@posteo.de 
> > wrote:
> Allocation happens at the shard level, i.e. for groups of actors, see 
> `ShardCoordinator.ShardAllocationStrategy`. Therefore I don’t think you can 
> achieve what you described.
> 
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger <https://twitter.com/hseeberger>
> Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> 
>> On 14 Dec 2015, at 01:05, Karthik Deivasigamani <kart...@gmail.com 
>> > wrote:
>> 
>> Hi,
>>I have been using cluster sharding feature in akka 2.4.1. I would like 
>> the sharding to be topology aware. For example : if I have a cluster with 
>> nodes - n1,n2,n3,n4. If my request goes to node n1 and if the entity actor 
>> does not exist in the cluster then it must create the entity actor on node 
>> n1 (basically same node where it received the request). Is there a way for 
>> me to control this behavior? Any pointers would be immensely helpful. 
>> 
>> Thanks,
>> Karthik
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <https://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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+.

Re: [akka-user] Akka cluster sharding topology aware

[Heiko Seeberger]

Allocation happens at the shard level, i.e. for groups of actors, see 
`ShardCoordinator.ShardAllocationStrategy`. Therefore I don’t think you can 
achieve what you described.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 14 Dec 2015, at 01:05, Karthik Deivasigamani <karthi...@gmail.com> wrote:
> 
> Hi,
>I have been using cluster sharding feature in akka 2.4.1. I would like the 
> sharding to be topology aware. For example : if I have a cluster with nodes - 
> n1,n2,n3,n4. If my request goes to node n1 and if the entity actor does not 
> exist in the cluster then it must create the entity actor on node n1 
> (basically same node where it received the request). Is there a way for me to 
> control this behavior? Any pointers would be immensely helpful. 
> 
> Thanks,
> Karthik
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at https://groups.google.com/group/akka-user 
> <https://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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.

Re: [akka-user] General Question about organization

[Heiko Seeberger]

> On 28 Nov 2015, at 18:47, Richard Rodseth  wrote:
> 
> One thing you can look into is using the EventBus to send "domain events" 
> between top-level actors. Apparently top-level actors (i.e. created with 
> system.actorOf rather than context.actorOf) are more expensive

Really? Could you elaborate?

Thanks
Heiko

> so you don't want zillions of them, but I think a handful of loosely-coupled 
> components is fine.
> 
> On Fri, Nov 27, 2015 at 2:51 AM, Bill Donn  > wrote:
> I have a rather general question about best practices with akka.
> 
> I'd like to create an application with multiple components.  For example, I'd 
> like to stream input data with akka.io  to add to a 
> database;  I'd also like perhaps a web page to expose the data, or perhaps a 
> rest interface to expose the data.  And perhaps some internal data crunching. 
>
> 
> The actual components aren't really important, instead I was wondering if 
> anyone might share some thoughts on how best to integrate multiple services 
> like this;  is it best to run each as a separate process, or to use a master 
> actor to initiate each of the processes, so as to control restart in the 
> event of failure?  Appreciate any insight.
> 
> -- 
> >> 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 http://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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] General Question about organization

[Heiko Seeberger]

> On 29 Nov 2015, at 01:55, Richard Rodseth <rrods...@gmail.com> wrote:
> 
> Oh, sorry, I thought I remembered reading that in the docs, but perhaps it 
> was just the cost of an actor system vs an actor.

Ah, yes.

> Hopefully my advice was OK regardless :)

I agree with you. Although I go for a single top-level actor per JVM for the 
following two reasons:
(1) Akka Typed (aka Akka 3?) has no actorOf, but instead you create an 
ActorSystem by passing Props for the single top-level actor
(2) Typically the actors created by the single top-level actor are super 
important for the system to work properly and therefore the top-level actor 
needs a custom supervisor strategy – something you can only achieve with a 
configured SupervisorStrategyFactory for the guardian otherwise

Heiko

> 
> On Sat, Nov 28, 2015 at 1:03 PM, Heiko Seeberger <loe...@posteo.de 
> <mailto:loe...@posteo.de>> wrote:
>> On 28 Nov 2015, at 18:47, Richard Rodseth <rrods...@gmail.com 
>> <mailto:rrods...@gmail.com>> wrote:
>> 
>> One thing you can look into is using the EventBus to send "domain events" 
>> between top-level actors. Apparently top-level actors (i.e. created with 
>> system.actorOf rather than context.actorOf) are more expensive
> 
> Really? Could you elaborate?
> 
> Thanks
> Heiko
> 
>> so you don't want zillions of them, but I think a handful of loosely-coupled 
>> components is fine.
>> 
>> On Fri, Nov 27, 2015 at 2:51 AM, Bill Donn <ray.moreh...@gmail.com 
>> <mailto:ray.moreh...@gmail.com>> wrote:
>> I have a rather general question about best practices with akka.
>> 
>> I'd like to create an application with multiple components.  For example, 
>> I'd like to stream input data with akka.io <http://akka.io/> to add to a 
>> database;  I'd also like perhaps a web page to expose the data, or perhaps a 
>> rest interface to expose the data.  And perhaps some internal data crunching.
>> 
>> The actual components aren't really important, instead I was wondering if 
>> anyone might share some thoughts on how best to integrate multiple services 
>> like this;  is it best to run each as a separate process, or to use a master 
>> actor to initiate each of the processes, so as to control restart in the 
>> event of failure?  Appreciate any insight.
>> 
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>> Visit this group at http://groups.google.com/group/akka-user 
>> <http://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
>> 
>> 
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>

Re: [akka-user] [akka-http] problem with multiple client requests using singleRequest

[Heiko Seeberger]

Rüdiger is a rocket scientist, he will be able to migrate without guides and 
hints ;-)

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 20 Nov 2015, at 19:08, Konrad Malawski <konrad.malaw...@typesafe.com> 
> wrote:
> 
> Definitely upgrade to 2.0m2 once its out I think. It has major improvements 
> on internals as well as api :)
> 
> There is a bit of changes since 1.0 but you'll manage, there's a migration 
> guide and we'll add more hints soon.
> 
> On Nov 20, 2015 18:54, "Rüdiger Klaehn" <rkla...@gmail.com 
> <mailto:rkla...@gmail.com>> wrote:
> OK, great. Having done some pretty complex things with the server side
> API, I was surprised to run into issues on the client side so quickly.
> 
> I am using akka-http in production (for a small, non mission-critical
> tool). Should I upgrade to 2.0-M2 or stay with 1.0 and somehow work
> around the bug?
> 
> On Fri, Nov 20, 2015 at 6:51 PM, Konrad Malawski
> <konrad.malaw...@typesafe.com <mailto:konrad.malaw...@typesafe.com>> wrote:
> > Hi Rudiger,
> > Yes it's a bug (two separate ones even, another thing you'll notice is
> > actors leaking).
> > And good news - we tracked it down and fixed it today! Will be released in
> > M2 which will be released early next week.
> >
> > Thanks for reporting!
> >
> > On Nov 20, 2015 18:47, "rklaehn" <rkla...@gmail.com 
> > <mailto:rkla...@gmail.com>> wrote:
> >>
> >> Hi All,
> >>
> >> I am having some seemingly trivial problems with using the client side of
> >> akka-http. Here is a little test program. I would expect it to print 100
> >> responses, but it prints just four and then hangs.
> >>
> >> This seems to be related to the configuration parameter
> >> "akka.http.host-connection-pool.max-connections", which defaults to 4. So 
> >> it
> >> seems that resources are not given back to the pool.
> >>
> >> Is this a bug, or am I doing something wrong? Note that I am aware that
> >> there are other methods to do multiple requests, such as
> >> cachedHostConnectionPool. But in this case I just want to do something
> >> utterly trivial and non-performance-critical with the minimum of fuss.
> >>
> >> Cheers,
> >>
> >> Rüdiger
> >>
> >> ---
> >>
> >> import akka.actor.ActorSystem
> >> import akka.http.scaladsl.Http
> >> import akka.http.scaladsl.model.{HttpRequest, Uri}
> >> import akka.stream.ActorMaterializer
> >>
> >> object TestClient extends App {
> >>   implicit val system = ActorSystem()
> >>
> >>   implicit val mat = ActorMaterializer()
> >>
> >>   implicit val ec = system.dispatcher
> >>
> >>   for(i ← 0 until 100)
> >> Http(system).singleRequest(HttpRequest(uri =
> >> Uri("http://www.google.com <http://www.google.com/>"))).foreach(println)
> >> }
> >>
> >> --
> >> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >> >>>>>>>>>> Check the FAQ:
> >> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >> >>>>>>>>>> <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 
> >> <mailto:akka-user%2bunsubscr...@googlegroups.com>.
> >> To post to this group, send email to akka-user@googlegroups.com 
> >> <mailto:akka-user@googlegroups.com>.
> >> Visit this group at http://groups.google.com/group/akka-user 
> >> <http://groups.google.com/group/akka-user>.
> >> For more options, visit https://groups.google.com/d/optout 
> >> <https://groups.google.com/d/optout>.
> >
> > --
> >>>>>>>>>>> Read the docs: http://akka.io/docs/ <http

Re: [akka-user] CPU-usage and a lot of actors with cluster-systems

[Heiko Seeberger]

I’d rather use pool routers to get parallelism (more work done simultaneously 
given the hardware resources) and delegate blocking work to „tagged“ actors 
which use a dispatcher which is configured properly to deal with blocking (many 
threads).

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 19 Nov 2015, at 21:51, Flo B. <olftheb...@googlemail.com> wrote:
> 
> Thanks Hazen for your explanation and your comment.
> 
> I hope I understood everything right! :) You want to split the work inside an 
> actor and use e. g.  two executors, one for the actor stuff and one for the 
> heavy work (io...). But! It is important for me that the work of message 1 is 
> done before message 2 is handled. And isn't one of the benefits for the actor 
> model and akka itself, that I have the garantee to that message 1 is done 
> before message 2?
> 
> And wouldn't that lead to the decision to use two actors for the task? one 
> for the handling and one for the work?
> 
> Best regards
> 
> Flo
> 
> Am Donnerstag, 19. November 2015 20:45:32 UTC+1 schrieb Jim Hazen:
> I'm not saying use a lot of dispatchers.  I'm saying that you should delegate 
> to maybe 1 more dispatcher for your heavy work to unblock your actor's 
> dispatching thread (and definitely another for blocking IO) allowing it to 
> put more of your Actor's mailbox entries to work concurrently.  In one of 
> your posts you were afraid that actors "doing too much" could be causing 
> things to slow down.  If your actors are blocking on IO or some other lengthy 
> task, a single actor won't be able to process message 2 until the receive 
> block from message 1 has completed.  By delegating heavy work to a different 
> "heavy work" dispatcher, your Actor's dispatcher can start to process more 
> requests from the mailbox.  This allows more heavy/blocking tasks to be 
> inflight.  It doesn't make long tasks take less time, but hopefully will 
> allow you to maximize your remaining resources either queuing up blocking 
> work or processing the results as they return.
> 
> To Patrik's point.  2 actors is already a lot of concurrency.  Unless you 
> broadcast 5 messages to each while the first message waits for 10s on a 
> remote Geo call.  Then you've spent some CPU queuing 100k requests, started 
> the blocking IO for 20k of those and then wait for 10s.  This is an 
> exaggeration, but the idea here is that the time you spend waiting for IO 
> drives down your overall CPU utilization.  If you're looking to maximize CPU 
> utilization you want all of your 100k requests in flight, saturating your IO 
> pipe, and then processing results as they return.  After a window of delay 
> you should be processing results at the max speed of your network, which 
> ought to keep your CPU busier than it is now.
> 
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Cluster aware consistent hashing pool - works only on leader

[Heiko Seeberger]

I suggest you go for sharding backed by ddata, at least in the beginning. It’s 
super convenient and works without any quirks.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 18 Nov 2015, at 21:23, Patrik Nordwall <patrik.nordw...@gmail.com> wrote:
> 
> Leveldb can't be used for cluster sharding, since that is a local journal. 
> The documentation of persistence has links to distributed journals.
> 
> An alternative is to use the ddata mode for cluster sharding, then 
> Distributed Data will be used instead of Persistence for the internal state 
> of Cluster Sharding.
> 
> /Patrik
> ons 18 nov. 2015 kl. 19:33 skrev Jim Hazen <jimhazen2...@gmail.com 
> <mailto:jimhazen2...@gmail.com>>:
> You don't need your clustered actors to be persistence aware. So you are 
> absolutely free to have sharded stateless actors, or manage state in some 
> other way.
> 
> The confusing part is that the cluster sharding internals requires akka 
> persistence to be configured for at least one journal. The internals use this 
> journal to persist internal shard state. Without this journal, cluster 
> sharding simply silently fails to work (or used to).
> 
> Follow the directions for setting up a local leveldb journal. It is well 
> supported by akka and easy to set up. You can then stop worrying about 
> persistence and just use the sharding functionality.
> 
> --
> >>>>>>>>>>  Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>>  Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>>  Search the archives: 
> >>>>>>>>>> https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user%2bunsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka remoting and Docker

[Heiko Seeberger]

> On 15 Nov 2015, at 16:01, Alex Wouda <awo...@gmail.com> wrote:
> 
> Thanks. 
> 
> Also I needed the bind-port and port to be the same.

That’s because of the way you forward the ports: 9100:9100. The second one is 
the container port. If you set that to 2552, you can use bind-port = 2552.

Heiko

> I do not get actually get why yet, but for now my app is working.
> 
> 
> This config works.
> 
> 
> akka {
>   actor {
> provider = "akka.remote.RemoteActorRefProvider"
>   }
>   remote {
>   enabled-transports = ["akka.remote.netty.tcp"]
>   netty.tcp {
>port = 9100
> 
>bind-hostname = ${dockerIp} # internal (bind) hostname // or remote ip
>bind-port = 9100  # internal (bind) port // must be same 
> as it seems to port
> 
>   }
> }
>   }
> 
> 
> regards,
> 
> Alex
> 
> 
> 
> 
> On Sunday, November 15, 2015 at 2:59:16 PM UTC+1, Heiko Seeberger wrote:
> Alex,
> 
> Indeed you are overlooking something: the loopback interface (localhost aka 
> 127.0.0.1) is only for local access, i.e. from the local machine. Why don’t 
> you bind to 0.0.0.0 instead?
> 
> Cheers
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger <https://twitter.com/hseeberger>
> Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
>> On 15 Nov 2015, at 14:33, Alex Wouda <awo...@ <>gmail.com 
>> <http://gmail.com/>> wrote:
>> 
>> Hi,
>> 
>> I'm trying to get a simple app running in docker, this works. But then I'm 
>> not able to access the remote akka system from the host. 
>> 
>> 
>> Using scala 2.11.7 and Akka 2.4.0
>> Whole project is available here: https://github.com/awouda/akka-docker.git 
>> <https://github.com/awouda/akka-docker.git>
>> 
>> 
>> My 'server system'  configuration:
>> 
>> akka {
>>   actor {
>> provider = "akka.remote.RemoteActorRefProvider"
>>   }
>>   remote {
>>   enabled-transports = ["akka.remote.netty.tcp"]
>>   netty.tcp {
>>hostname = ${dockerIp}
>>port = 9100
>> 
>>bind-hostname = "localhost" # internal (bind) hostname
>>bind-port = 2551  # internal (bind) port
>> 
>>   }
>> }
>>   }
>> 
>> dockerIp is provided by a start.sh script.
>> 
>> The provided ip is resolved in the host and passed to the client application.
>> 
>> Also the port in docker is exposed by putting -p 9100:9100.
>> 
>> I must overlook something, or still have misconfiguration, if anyone has 
>> some pointers; appreciated.
>> 
>> tia,
>> 
>> Alex
>> 
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 <http://googlegroups.com/>.
>> To post to this group, send email to akka...@ <>googlegroups.com 
>> <http://googlegroups.com/>.
>> Visit this group at http://groups.google.com/group/akka-user 
>> <http://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <https://gro

Re: [akka-user] Akka remoting and Docker

[Heiko Seeberger]

Alex,

Indeed you are overlooking something: the loopback interface (localhost aka 
127.0.0.1) is only for local access, i.e. from the local machine. Why don’t you 
bind to 0.0.0.0 instead?

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 15 Nov 2015, at 14:33, Alex Wouda <awo...@gmail.com> wrote:
> 
> Hi,
> 
> I'm trying to get a simple app running in docker, this works. But then I'm 
> not able to access the remote akka system from the host. 
> 
> 
> Using scala 2.11.7 and Akka 2.4.0
> Whole project is available here: https://github.com/awouda/akka-docker.git
> 
> 
> My 'server system'  configuration:
> 
> akka {
>   actor {
> provider = "akka.remote.RemoteActorRefProvider"
>   }
>   remote {
>   enabled-transports = ["akka.remote.netty.tcp"]
>   netty.tcp {
>hostname = ${dockerIp}
>port = 9100
> 
>bind-hostname = "localhost" # internal (bind) hostname
>bind-port = 2551  # internal (bind) port
> 
>   }
> }
>   }
> 
> dockerIp is provided by a start.sh script.
> 
> The provided ip is resolved in the host and passed to the client application.
> 
> Also the port in docker is exposed by putting -p 9100:9100.
> 
> I must overlook something, or still have misconfiguration, if anyone has some 
> pointers; appreciated.
> 
> tia,
> 
> Alex
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FlowGraph within Actor

[Heiko Seeberger]

That’s perfectly possible. 

Yet you have to be careful to not close over any mutable actor state, e.g. 
vars, ActorContext, sender(), etc. A good way to avoid that is define the flow 
graph via a method in the companion object of your actor.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 14 Nov 2015, at 03:55, Gary Struthers <agilej...@earthlink.net> wrote:
> 
> I have a flow graph that needs initialization and post processing. I'd like 
> to do this within an actor. The actor receives a message, the flow graph is 
> initialized, then the message is passed to it, then its result is sent to 
> different actors. I don't see this use case in the docs so I don't know if 
> this is fine or problematic.
> 
> Gary
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Persistence: Picking a storage backend

[Heiko Seeberger]

If you are using Akka Cluster, you should go for a distributed backend like 
Cassandra or Kafka.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 26 Oct 2015, at 17:49, vi...@eero.com wrote:
> 
> Based on your production experience, what storage backends have worked well 
> for akka-persistence?
> 
> We are considering postgres because we already use it heavily. Does anyone 
> have experience with this? 
> 
> Is anyone a strong proponent of other storage backends (cassandra, kafka, 
> etc)?
> 
> Thank You!
> Vikas
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is Akka Streams using Akka 2.4.0 or an earlier version?

[Heiko Seeberger]

Akka Streams/HTTP works fine on Akka 2.4 for me: 
https://github.com/hseeberger/reactive-flows/blob/master/build.sbt#L24 
<https://github.com/hseeberger/reactive-flows/blob/master/build.sbt#L24>


--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 24 Oct 2015, at 17:45, tigerfoot <gzol...@gmail.com> wrote:
> 
> One other thought...  Any idea when Akka Stream/HTTP might be released to on 
> Akka 2.4?
> 
> The one "gotta-have" feature for me in 2.4 is bind-hostname/bind-port, which 
> I need for getting my Akka app working in Docker properly.  Works great!
> But my app is also stream-based. :-~
> 
> So I can probably bump back to 2.3.x to fix my immediate issue but then lose 
> my key feature supporting my Docker needs.
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is Akka Streams using Akka 2.4.0 or an earlier version?

[Heiko Seeberger]

Akka 2.4 is supposed to be compatible with Akka 2.3.

Akka Streams and Akka HTTP are based on Akka 2.3, but because of the above they 
should work with Akka 2.4. If that’s not the case, it’s a bug in Akka 2.4.

Before you open a ticket, you better use sbt-dependency-graph 
(https://github.com/jrudolph/sbt-dependency-graph 
<https://github.com/jrudolph/sbt-dependency-graph>) to diagnose what exact 
versions are used in your project. E.g. when adding Akka 2.4 to the library 
dependencies explicitly, this will override (evict) the dependency on Akka 2.3 
from Akka Streams.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 24 Oct 2015, at 01:42, tigerfoot <gzol...@gmail.com> wrote:
> 
> I'm getting some "ambiguous reference" errors in my code relative to two 
> calling signatures for akka.pattern.ask.
> My project imports Akka 2.4.0 only.
> 
> Upon research Akka 2.3.x uses one of the signatures and 2.4.0 uses a new 
> signature, so I'm guessing that the 2.3.x Akka is coming in as a dependency 
> somewhere.
> I'm trying to figure out what imports are still tied to the previous Akka 
> version so I can attempt to sort this out.
> 
> Is the Akka Streams/Http 1.0 using Akka 2.4 or the previous version?
> 
> Thanks,
> Greg
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How many actors can be launched in an ActorSystem ?

[Heiko Seeberger]

An actor without any state and with an empty mailbox weighs some 400 bytes 
only, hence you could create some 25 millions. Yet your actors probably need 
state and of course you also have to count the messages which are in flight.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 14 Oct 2015, at 01:56, Pradeep Chanumolu <pchanum...@mapr.com> wrote:
> 
> Hi, 
> 
> Can anyone specify how many actors can be launched in an ActorSystem if we 
> have close to 10g jvm memory? 
> 
> Thanks,
> Pradeep
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka logging adaptor doesn't support slf4j's trace level?

[Heiko Seeberger]

If you want to bypass Akka Logging, you maybe want to consider using Log4j with 
async logging, because its Disruptor based impl seems pretty neat. Maybe in 
Akka 3 they should get rid of Akka Logging altogether and use async Log4j 
logging directly?

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 09 Oct 2015, at 16:18, Heiko Seeberger <m...@heikoseeberger.de> wrote:
> 
> If you want to bypass Akka Logging, you maybe want to consider using Log4j 
> with async logging, because its Disruptor based impl seems pretty neat. Maybe 
> in Akka 3 they should get rid of Akka Logging altogether and use async Log4j 
> logging directly?
> 
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger <https://twitter.com/hseeberger>
> Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
>> On 09 Oct 2015, at 16:09, Eugene Dzhurinsky <jdeve...@gmail.com 
>> <mailto:jdeve...@gmail.com>> wrote:
>> 
>> On Fri, Oct 09, 2015 at 04:02:00PM +0200, Heiko Seeberger wrote:
>>> I disagree. Akka's logging facility doesn’t wrap SLF4J, it just offers a 
>>> backend based on SLF4J, like akka-log4j provides a backend based on Log4j 
>>> 2. Personally, I don’t like too many levels and I believe the ones provided 
>>> by Akka are perfect.
>> 
>> I would say that restricting the functionality of logging frameworks in Akka
>> to some predefined set of levels - forces me to always prefer SLF4J over Akka
>> logging.  If they are so strict about hard-coded log methods - okay, but
>> having at least some method in Akka logger that allows to pass a custom log
>> level (of type Any) to a back-end service of the actual logging system would
>> improve usability of that logging. 
>> 
>> -- 
>> Eugene N Dzhurinsky
>> 
>> -- 
>>>>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>>>>>>>>>>>> Check the FAQ: 
>>>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>>>>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>>>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>>>>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>> Visit this group at http://groups.google.com/group/akka-user 
>> <http://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka logging adaptor doesn't support slf4j's trace level?

[Heiko Seeberger]

I disagree. Akka's logging facility doesn’t wrap SLF4J, it just offers a 
backend based on SLF4J, like akka-log4j provides a backend based on Log4j 2. 
Personally, I don’t like too many levels and I believe the ones provided by 
Akka are perfect.

Just my 5 cents
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 09 Oct 2015, at 14:14, Colin Smith <smithcol...@gmail.com> wrote:
> 
> I too find myself wanting log.trace(), and don't see a reason not to 
> introduce it.
> 
> When trace logging is enabled one doesn't expect fantastic performance, but 
> the insights that a deeper-than-debug level of logging might provide.
> 
> My use-case is that I want to see all the metric data that is being reported 
> by my application to new relic, not just how many metrics, as the debug level 
> currently provides.
> 
> see 
> https://github.com/kamon-io/Kamon/blob/master/kamon-newrelic/src/main/scala/kamon/newrelic/MetricReporter.scala#L59
> 
> Only trace should provide this level of detail.
> 
> I would expect any framework that wraps a logging implementation should 
> provide this functionality, it is essential. Why not make it easy for your 
> users and provide the Slf4jLoggingAdapter complete with trace?
> 
> 
> On Friday, 9 May 2014 06:29:48 UTC+1, rkuhn wrote:
> Hi Eugene,
> 
> see this ticket: 
> https://www.assembla.com/spaces/akka/tickets/3651?comment=422208093 
> <https://www.assembla.com/spaces/akka/tickets/3651?comment=422208093>
> 
> In short, within Akka I don’t see a reason to introduce it, but you can 
> easily use implicit classes to enable `log.trace(...)` and create your own 
> Slf4jLoggingAdapter (by copying the Akka one and adding one line).
> 
> Regards,
> 
> Roland
> 
> 9 maj 2014 kl. 01:43 skrev Eugene Dzhurinsky <jdev...@gmail.com 
> >:
> 
>> Hello, all! 
>> 
>> Is there any update on this topic, like - was this log level implemented in 
>> Akka slf4j bridge? 
>> 
>> As far as I can see, no - so what's the status?
>> 
>> Thanks!
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 http://groups.google.com/group/akka-user 
>> <http://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> 
> Dr. Roland Kuhn
> Akka Tech Lead
> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
> twitter: @rolandkuhn
>  <http://twitter.com/#!/rolandkuhn>
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] is there a way to know when *really* an actor has stopped

[Heiko Seeberger]

A parent need not keep track of its children explicitly, there are 
`context.children` and `context.child(name)`.

Actor termination is not trivial, so some work needs to be done! Locality 
doesn’t help, termination works the same locally and remotely.

Maybe this is a use case for Cluster Sharding?

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 09 Oct 2015, at 18:53, 'Konstantinos Kougios' via Akka User List 
> <akka-user@googlegroups.com> wrote:
> 
> A solution like this could work, but it is a lot more complicated (complexity 
> added just to handle actor termination).
> 
> The databaseServer actor is not affected by the deaths of the indexes.
> 
> Btw, all my Terminated actors are local (same ActorSystem, same jvm) to the 
> watcher, does that help?
> 
> On 09/10/15 17:36, Michael Frank wrote:
>> instead of using actor paths to send directly to the index actor, why not 
>> send your message to the /databaseServer actor, which then forwards the 
>> message to the appropriate index actor?  the databaseServer actor would 
>> contain a Map[String,ActorRef] which maps index name to index actor (which 
>> are its children), and would register deathwatch on each child, so it would 
>> be notified when an index goes away and update its state.
>> 
>> -Michael
>> 
>> On 10/09/15 08:58, 'Konstantinos Kougios' via Akka User List wrote:
>>> well, I am using actor paths to find the actors, which are unique per 
>>> ActorSystem.
>>> 
>>> I.e. paths are
>>> 
>>> ../databaseServer
>>> 
>>> ../databaseServer/index:x1
>>> 
>>> ../databaseServer/index:x2
>>> 
>>> I am using the akka cluster, so each "server" will have these paths.
>>> 
>>> Now when I do a "dropIndex" and drop index x1, actors 
>>> ../databaseServer/index:x1 on each server must terminate. I would like to 
>>> know precisely when that occurred, because a drop/recreate will have the 
>>> issue of the same actor name.
>>> 
>>> Now I could, for tests, use a unique index name each time. But some tests 
>>> need to drop/recreate the /databaseServer (and remember I refer to the 
>>> indexes by ../databaseServer/index:x1)
>>> 
>>> Cheers
>>> 
>>> 
>>> On 09/10/15 12:30, Patrik Nordwall wrote:
>>>> it's probably easies to not reuse the name
>>>> 
>>>> On Fri, Oct 9, 2015 at 1:23 PM, 'Konstantinos Kougios' via Akka User List 
>>>> < <mailto:akka-user@googlegroups.com>akka-user@googlegroups.com 
>>>> <mailto:akka-user@googlegroups.com>> wrote:
>>>> Well, I have this component based on 1 actor. It is the "flow" thing I was 
>>>> talking a few months ago, anyway it does take care of a process between 
>>>> different actors. One thing it does is to stop an other actor and wait 
>>>> till it is terminated. I need to make sure the other actor is really 
>>>> terminated because further down an actor with the same name is created - 
>>>> which randomly & rarely fails with "actor name [databaseServer] is not 
>>>> unique!"
>>>> 
>>>> 
>>>> On 09/10/15 12:17, Patrik Nordwall wrote:
>>>>> 
>>>>> 
>>>>> On Fri, Oct 9, 2015 at 12:59 PM, 'Konstantinos Kougios' via Akka User 
>>>>> List < <mailto:akka-user@googlegroups.com>akka-user@googlegroups.com 
>>>>> <mailto:akka-user@googlegroups.com>> wrote:
>>>>> oh... in that case my code changes won't work. The watcher is not the 
>>>>> parent of the actor.
>>>>> 
>>>>> Will it work if the watcher is child of the same parent of the Terminated 
>>>>> actor?
>>>>> 
>>>>> no, but what would a sibling do? it can't recreate the actor, it is only 
>>>>> the parent that can create child actor with same name
>>>>>  
>>>>> 
>>>>> 
>>>>> 
>>>>> On 09/10/15 06:08, Patrik Nordwall wrote:
>>>>>> Note that this advice is correct but only when the parent actor receives 
>>>>>> the Terminated, i.e. it does not hold for top level actors where you can 
>>>>>> only watch from the "outside".
>>>>>> tors 8 okt. 2015 kl. 11:46 skrev Kostas ko

Re: [akka-user] When you join a cluster, are all actors nodes?

[Heiko Seeberger]

> On 29 Sep 2015, at 06:10, lapming.lee <lapming@gmail.com> wrote:
> 
> Hi Heiko, 
> 
> Say I have 2 micro service nodes: web, and authentication.  For each, they 
> run their own Actor System and are hosted on their own physical machine.  
> 
> I want to connect the nodes together and be able to scale up the nodes when 
> needed.  For example, if the web node sends a lot of authentication requests 
> to the auth node and it can’t handle the volume, I need to be able to 
> dynamically add a second auth node.

Makes sense, but creating additional nodes is out of router scope.

> For both pool and group router, there are some parts which I don’t 
> understand. 
> 
> For pool router, the router needs to send the routee actor to the target 
> node.  

No. On the remote system the classes need to be available, no classifies are 
transmitted.

> So in this cause, does the web node send an actor to the auth node to connect 
> with each other?  How does this work?
> 
> For group router, since the messages are routed with Actor Selection, there 
> must be one routee node up at all times.   So for the example I gave: 
> a) What if there is no auth node for the web node to connect to before or 
> after the group router is created

Then the group router has zero routees.

> b) What happens if I want to dynamically add a second auth node, can group 
> router handle this situation?

Sure. The cluster aware group router will dynamically adjust the set of routees.

> 
> Regards, 
> Lap 
> 
> On Monday, September 28, 2015 at 12:33:20 AM UTC+8, lapming.lee wrote:
> Hi Heiko, 
> 
> I am reading up on cluster-aware pool router versus group router.  I am 
> understand group router, but not so much with pool router. 
> 
> Say if I have a seed node that has a cluster aware pool router.  When I 
> create a new node with no actors in it, the pool router will automatically 
> deploy routtees there.  
> 
> Here's the questions I have:
> 
> 1) Then shouldn't I just build a monolithic application on a single node and 
> use cluster aware pool routers to scale horizontally but starting up empty 
> nodes? 
> 
> 2) If each node has a specific role (e.g. back-end, front-end,etc), I don't 
> understand why one would deploy routtees in other nodes with different or 
> same roles.  Can you give an example?  And what would they advantage be over 
> group routers?
> 
> Regards, 
> Lap 
> 
> On Sunday, September 27, 2015 at 4:46:41 PM UTC+8, Heiko Seeberger wrote:
> The akka cluster is essentially a membership service for actor systems, not 
> for actors. From the Cluster Specification 
> <http://doc.akka.io/docs/akka/2.3.14/common/cluster.html>  „A node could be a 
> member of a cluster without hosting any actors.“
> 
> Actors can benefit from Akka Cluster via subscribing to cluster events. For 
> example an actor could create child actors on every member node that joins 
> the cluster, which is more or less what a cluster-aware pool router does.
> 
> Cheers
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger <https://twitter.com/hseeberger>
> Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
>> On 27 Sep 2015, at 09:10, lapming.lee <lapmi...@gmail.com <>> wrote:
>> 
>> If I have an actor system with one top-level actor under the user guardian, 
>> and under that top-level actor are multiple child actors.
>> 
>> 1) When I join an cluster system:
>> 
>> A. are all the actors under this actor system automatically a node now? 
>> 
>> B. OR is the top-level actor the only node added to the cluster such that 
>> the entire actor system is ONE node? 
>> 
>> 2) Should all the message passing go through the top-level actor under the 
>> user guardian? Or can I simply send it to any actor using the Event Stream?
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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

Re: [akka-user] actor names unique across cluster?

[Heiko Seeberger]

Actor names must be unique amongst siblings, i.e. one parent actor can’t have 
child actors with the same name.
A different machine means a different actor system and hence a different actor 
tree, i.e. you can have actors with the same path on a different machine.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 29 Sep 2015, at 14:13, Kostas kougios <kostas.koug...@googlemail.com> 
> wrote:
> 
> Is it possible to create an actor with the same name on a different server? 
> (currently my testcase runs in the same jvm)
> 
> I am getting
> 
> [ERROR] [09/29/2015 13:07:35.555] 
> [testSystem-akka.actor.default-dispatcher-22] 
> [akka://testSystem/user/databaseServer] actor name [index:int-string] is not 
> unique!
> akka.actor.InvalidActorNameException: actor name [index:int-string] is not 
> unique!
> 
> The actor [index:int-string] was created on ActorSystem A and I am trying to 
> create [index:int-string] on ActorSystem B. The system name is testSystem on 
> both ActorSystems.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Flow/Stage from reactive Publisher

[Heiko Seeberger]

flatMap that shit ;-)

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 27 Sep 2015, at 20:02, Muki <nepomuk.sei...@gmail.com> wrote:
> 
> Hi Patrik,
> 
> Yes! That worked. flatten was the right hint to fight the right place in the 
> API ;)
> Now it looks like this
> 
> boxes.map { query =>
>source(query.polygon).fold(TrajectoryBox(Nil, query)) {
>   case (box, hit) => box :+ hit.as[Trajectory]
>}
> }
> .flatten(FlattenStrategy.concat)
> .fold[TrajectoryBoxes](TrajectoryBoxes(Nil))(_ :+ _)
> 
> cheers,
> Muki
> 
> Am Dienstag, 22. September 2015 11:41:50 UTC+2 schrieb Patrik Nordwall:
> Have you looked at flatten (concat)?
> /Patrik
> 
> On Sun, Sep 20, 2015 at 2:57 PM, Muki <nepomuk...@gmail.com > 
> wrote:
> Hi,
> 
> I'm currently experimenting with elastic4s reactive streams extension 
> <https://github.com/sksamuel/elastic4s#elastic-reactive-streams> and akka 
> streams. What I want to do:
> 
> (1) List[Polygon] ~> (2) elastic4s publisher ~> (3) List[List[Trajectory]] ~> 
> (4) algorithm
> 
> I have an initial, fixed list of polygons
> For each polygon a geoshape query is performed which results in a 
> List[Trajectory]
> I get a list of lists, because each polygon produces a list
> other stuff, which is already working
> 
> My problem is that I don't know how to create a flow stage from a publisher 
> as the elastic4s API gives you a publisher
> for queries. I can create a single publisher which returns the SearchHits for 
> one Polygon.
> 
> def source(polygon: Polygon[LngLat])(implicit system: ActorSystem): 
> Source[RichSearchHit, Unit] = {
>   val publisher = client.publisher(geoShapeQuery(polygon))
>   Source(publisher)
> }
> 
> 
> Ordering is needed, however I could solve this with indices. I started with 
> this and wonder if this is the way to go, creating a new source for each 
> element:
> 
> val searchHits: Source[Seq[RichSearchHit], Unit] = 
> Source(List.empty[Polygon[LngLat]])
>   .mapAsync(parallelism = 1) { polygon =>
> val sink = Sink.fold[Seq[RichSearchHit], 
> RichSearchHit](Seq.empty[RichSearchHit])(_ :+ _)
> source(polygon).runWith(sink)
>   }
> 
> 
> thanks in advance,
> Muki
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.
> 
> 
> 
> -- 
> 
> Patrik Nordwall
> Typesafe <http://typesafe.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
> 
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Aktor Mailbox Deletion?

[Heiko Seeberger]

You could change the behavior via `context.become` to a new one which ignores 
the respective message(s).

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 24 Sep 2015, at 17:37, Christian Schmitt <c.schm...@briefdomain.de> wrote:
> 
> Hello, currently I send Messages to an Actor which all does the same thing.
> 
> So my Actor will do the same action in a few ms which is bad, is there a way 
> to just drop the mailbox before I run my command inside the Akka Actor? 
> something like:
> 
> 
> def recieve = {
> case Message =>  cleanupMailbox(); doSomething();
> }
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Which actor methods are ok to call in a future callback?

[Heiko Seeberger]

Let me say it again: Don’t ever use callbacks in actors! How could I say it any 
clearer?

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 22 Sep 2015, at 14:20, John Ulric <uja...@gmail.com> wrote:
> 
> @Heiko, @Roland, thanks. The callback in my case essentially makes a decision 
> where to send the future result (to self, to a delegee actor, to the calling 
> actor) plus some error handling, logging and monitoring, so it is a pipe, 
> essentially. I found the code more readable when I make these decisions here 
> in the callback, instead of piping the result to self, making the decisions, 
> and forwarding the message again. Do you think this is an acceptable pattern 
> or would you absolutely discourage to the use of a callback here?
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Mock actor based on actorSelection

[Heiko Seeberger]

Lookup generally is an anti-pattern and also in Akka – except for remoting and 
testing – there is absolutely no need to use lookup via `actorSelection`. 
Either inject the `ActorRef` to B in the constructor of A or send a message to 
A with the `ActorRef` to B.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 13 Sep 2015, at 23:23, Rafael Pacheco <ravpach...@gmail.com> wrote:
> 
> Today I posted this question on StackOverflow, maybe someone can help me.
> I have searched a lot about this and yet have no answer.
> 
> 
> 
> http://stackoverflow.com/questions/32551674/how-to-mock-a-actor-based-on-actorselection
> 
> 
> 
> I have a Actor "A" (user/A) that send message "X" for a other actor "B" 
> (user/B) when receive a message "M". To do this the actor A use 
> ActorSelection I need test that when I send M to A, B will receive "X".
> 
> 
> 
> I try this approachs:
> 
> 
> 
> * I used TestProbe and JavaTestKit on "user/B" but have not success.
> 
> * I also see some similar questions about this but every answer said to use 
> ActorRef insted of ActorSelection. This is not a option for me, I realy need 
> use a ActorSelection.
> 
> 
> 
> Someone have some idea ?
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Futures vs. per-request actors in akka-http

[Heiko Seeberger]

> On 11 Sep 2015, at 22:52, Richard Rodseth  wrote:
> 
> But if C is telling D something and receiving the reply in a separate message 
> D -> C, sender() is no longer any use.
> Maybe that's what you meant by aggregation.

Yep, that’s a non-linear message flow.

> I like to include a replyTo in messages.

Sure, that’s a good idea, because it makes the message protocol very explicit. 
It’s also a good step towards Akka Typed ;-)

Heiko

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka-Http handling multipart formdata with binary file and json object

[Heiko Seeberger]

You could probably use `grouped(2).map { case Seq(a, b) => (a, b) }` and then 
use a graph with an `Unzip` stage ...

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 11 Sep 2015, at 16:10, lucian enache <cors...@gmail.com> wrote:
> 
> Hello everyone, for akka-http when handling a POST request, if I have my 
> entity as a Multipart.FormData ,
>  and I POST some JSON and a binary file, how can I split the two when I parse 
> the formData ?
> 
> This is what I come up with so far
> 
>  path("upload") { /* uploads a file to the database */
>   post {
> entity(as[Multipart.FormData]) { (formData) =>
> 
> 
>   val uploadedUrlsFuture = 
> formData.parts.map(_.entity.dataBytes).mapAsync(parallelism = 1)(part =>
> part
>   .map(_.toArray)
>   .runFold(ByteString())((totalBytes, bytes) => totalBytes ++ 
> bytes)
>   .map(_.toArray[Byte]).map(ResourceManager.saveFile(_)) /* 
> TODO update this to a service */
>   ).grouped(100).runWith(Sink.head)
>   complete(OK)
> }
>   }
> }
> 
> 
> So if I have an Content-Length of 2 in a scenario where I post an JSON Object 
> and a binary file,
>  is there a way to split that up and handle the two separately?
> 
> And is this a good way to provide an upload functionality to a backend trough 
> akka-http and akka-streams (are there better ways to achieve this)?
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
> >>>>>>>>>> <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 
> <mailto:akka-user+unsubscr...@googlegroups.com>.
> To post to this group, send email to akka-user@googlegroups.com 
> <mailto:akka-user@googlegroups.com>.
> Visit this group at http://groups.google.com/group/akka-user 
> <http://groups.google.com/group/akka-user>.
> For more options, visit https://groups.google.com/d/optout 
> <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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Futures vs. per-request actors in akka-http

[Heiko Seeberger]

The whole purpose of forwarding is that the receiving actor sees the sender of 
the original message when using `sender()` (please use the parens).

So, if A sends a message to B via `!` or `tell` and B forwards that message or 
some other one via `forward` to C, C can simply respond to A by using `sender() 
! "response“`.

A ~> B ~> C
A <~ C

Makes sense?

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 10 Sep 2015, at 21:17, Richard Rodseth <rrods...@gmail.com> wrote:
> 
> Oh good. Thanks.
> 
> On Thu, Sep 10, 2015 at 12:14 PM, Patrik Nordwall <patrik.nordw...@gmail.com 
> <mailto:patrik.nordw...@gmail.com>> wrote:
> 
> 
> On Thu, Sep 10, 2015 at 8:29 PM, Richard Rodseth <rrods...@gmail.com 
> <mailto:rrods...@gmail.com>> wrote:
> Well I must be missing something. Here's what I'm doing:
> 
> case SimulatorServiceRequestHandler.AskForStatus => {
> 
>   val requester = sender
> 
>   // Create a per-request actor whose result will go to my sender
> 
>   val getStatusActor = context.actorOf(GetStatusActor.props(requester, 
> service))
> 
>   getStatusActor ! GetStatusActor.DoIt // Reply goes to requester
> 
> 
> Ok, that is good.
> 
> }
> 
> 
> I thought you were proposing
> 
> case msg @ SimulatorServiceRequestHandler.AskForStatus => {
> 
>   // Create a per-request actor and forward the message
> 
>   val getStatusActor = context.actorOf(GetStatusActor.props(service))
> 
>   getStatusActor forward msg
> 
> }
> 
> But then does GetStatusActor have to reply from within it's own AskForStatus 
> handler? If so, and other actors are involved, how does it do that without 
> doing another ask with pipeToSender ?
> 
> 
> It would have replied to the sender(), which points to the original ask 
> future (PromiseActorRef).
> 
> I like your approach of passing in the requester ActorRef in the constructor.
>  
> 
> On Thu, Sep 10, 2015 at 11:09 AM, Patrik Nordwall <patrik.nordw...@gmail.com 
> <mailto:patrik.nordw...@gmail.com>> wrote:
> By forward I mean forward (not chained ask). ;-)
> 
> 
> On Thu, Sep 10, 2015 at 8:03 PM, Richard Rodseth <rrods...@gmail.com 
> <mailto:rrods...@gmail.com>> wrote:
> It seemed to me that forwarding implied chained asks. Not sure what you mean 
> by aggregation vs linear flow. The goal for me is to have no asks, other than 
> the one in the route definition, and that means that the one-off actor can't 
> reply from within its "DoIt" message handler.
> 
> On Thu, Sep 10, 2015 at 9:21 AM, Heiko Seeberger <loe...@posteo.de 
> <mailto:loe...@posteo.de>> wrote:
> That should work, but as long as there’s no aggregation or something but just 
> a linear flow of messages, I think forwarding is the simplest solution.
> 
> Cheers
> Heiko
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de <http://heikoseeberger.de/>
> Twitter: @hseeberger <https://twitter.com/hseeberger>
> Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> 
>> On 10 Sep 2015, at 17:02, Richard Rodseth <rrods...@gmail.com 
>> <mailto:rrods...@gmail.com>> wrote:
>> 
>> Thanks for the response. This is somewhat encouraging. +1 to cookbook and 
>> migration docs.
>> 
>> I'm not up to speed on Flows, so I don't know what the proposed solution 
>> would look like in a route definition.
>> In the meantime (this is just for a new proof of concept app) I embraced the 
>> Ask in the route definition and create one-offs in response. I didn't use 
>> forwarding as Patrik mentioned. Instead the one-off has a "requester" 
>> property and after doing a bunch of tells and receives, completes the ask 
>> future by sending a response to the requester. I hope this is OK - it seems 
>> to work as a bridge between AskWorld and TellDon'tAskWorld. 
>> 
>> On Wed, Sep 9, 2015 at 3:34 AM, Akka Team <akka.offic...@gmail.com 
>> <mailto:akka.offic...@gmail.com>> wrote:
>> 
>> 
>> On Wed, Sep 9, 2015 at 12:27 PM, Patrik Nordwall <patrik.nordw...@gmail.com 
>> <mailto:patrik.nordw...@gmail.com>> wrote:
>> 
>> 
>> On Wed, Sep 9, 2015 at 12:05 PM, Akka Team <akka.offic...@gmail.com 
>> <mailto:akka.offic...@gmail.com>> wrote:
>> 
>> 
>> On Wed, Sep 9, 2015 at 11:59 AM, Patrik Nordwall <patrik.nordw...@gmail.com 
>> <mailto:patrik.

Re: [akka-user] [akka-http] How do you complete using the routing DSL when using actor ask?

[Heiko Seeberger]

Sorry, but that’s step into the wrong direction. You should use the `onSuccess` 
or similar directives.
For an example take a look here: 
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L72
 
<https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L72>

Don’t forget to provide implicit values for Timeout, ExecutionContext and 
Materializer.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 10 Sep 2015, at 18:00, Matthew Adams <matt...@matthewadams.me> wrote:
> 
> ...and half a baby step further.  I changed onSuccess to match.  Now I think 
> the problem is one of typing:  (bank ? oa) is of type Future[Any], which 
> makes sense because the match clause will return either a Balance or an 
> AccountAlreadyExists type.  Changed route to
> 
>   val route =
> 
> path("accounts") {
> 
>   post {
> 
> entity(as[OpenAccount]) { oa =>
> 
>   bank ? oa match {
> 
> case b: Balance => complete(b)
> 
> case x: AccountAlreadyExists => complete(x)
> 
>   }
> 
> } ~
> 
>   entity(as[Transfer]) { t =>
> 
> bank ? t match {
> 
>   case tr: TransferResult => complete(tr)
> 
>   case nsax: NoSuchAccount => complete(nsax)
> 
>   case ifx: InsufficientFunds => complete(ifx)
> 
> }
> 
>   }
> 
>   } ~
> 
> get {
> 
>   complete((bank ? GetAccounts()).mapTo[Accounts])
> 
> }
> 
> 
> but still getting compilation errors
> 
> [error] 
> /Users/matthew/Documents/github/payment-flow/solution/src/main/scala/com/demo/akka/http/Rest.scala:50:
>  type mismatch;
> [error]  found   : scala.concurrent.Future[Any] with 
> com.demo.akka.http.BankResults.Balance
> [error]  required: akka.http.scaladsl.marshalling.ToResponseMarshallable
> [error] case b: Balance => complete(b)
> [error] ^
> [error] 
> /Users/matthew/Documents/github/payment-flow/solution/src/main/scala/com/demo/akka/http/Rest.scala:51:
>  type mismatch;
> [error]  found   : scala.concurrent.Future[Any] with 
> com.demo.akka.http.BankResults.AccountAlreadyExists
> [error]  required: akka.http.scaladsl.marshalling.ToResponseMarshallable
> [error] case x: AccountAlreadyExists => complete(x)
> [error]  ^
> [error] 
> /Users/matthew/Documents/github/payment-flow/solution/src/main/scala/com/demo/akka/http/Rest.scala:56:
>  type mismatch;
> [error]  found   : scala.concurrent.Future[Any] with 
> com.demo.akka.http.BankResults.TransferResult
> [error]  required: akka.http.scaladsl.marshalling.ToResponseMarshallable
> [error]   case tr: TransferResult => complete(tr)
> [error]   ^
> [error] 
> /Users/matthew/Documents/github/payment-flow/solution/src/main/scala/com/demo/akka/http/Rest.scala:57:
>  type mismatch;
> [error]  found   : scala.concurrent.Future[Any] with 
> com.demo.akka.http.BankResults.NoSuchAccount
> [error]  required: akka.http.scaladsl.marshalling.ToResponseMarshallable
> [error]   case nsax: NoSuchAccount => complete(nsax)
> [error]^
> [error] 
> /Users/matthew/Documents/github/SciSpike/Scala-2-Course-PP/lesson-360-exercises/payment-flow/solution/src/main/scala/com/demo/akka/http/Rest.scala:58:
>  type mismatch;
> [error]  found   : scala.concurrent.Future[Any] with 
> com.demo.akka.http.BankResults.InsufficientFunds
> [error]  required: akka.http.scaladsl.marshalling.ToResponseMarshallable
> [error]   case ifx: InsufficientFunds => complete(ifx)
> [error]   ^
> [error] 5 errors found
> [error] (compile:compile) Compilation failed
> [error] Total time: 1 s, completed Sep 10, 2015 10:57:35 AM
> 
> Still poking away...
> 
> On Thursday, September 10, 2015 at 10:44:02 AM UTC-5, Matthew Adams wrote:
> Ok, made one baby step.  I was missing an implicit ActorMaterializer within 
> scope.  Fixed that.  Now, compile errors are:
> 
> [error] 
> /Users/matthew/Documents/github/payment-flow/solution/src/main/scala/com/demo/akka/http/Rest.scala:50:
>  type mismatch;
> [error]  found   : Unit
> [error]  required: akka.http.sca

Re: [akka-user] Futures vs. per-request actors in akka-http

[Heiko Seeberger]

That should work, but as long as there’s no aggregation or something but just a 
linear flow of messages, I think forwarding is the simplest solution.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de <http://heikoseeberger.de/>
Twitter: @hseeberger <https://twitter.com/hseeberger>
Public key: keybase.io/hseeberger <https://keybase.io/hseeberger>
> On 10 Sep 2015, at 17:02, Richard Rodseth <rrods...@gmail.com> wrote:
> 
> Thanks for the response. This is somewhat encouraging. +1 to cookbook and 
> migration docs.
> 
> I'm not up to speed on Flows, so I don't know what the proposed solution 
> would look like in a route definition.
> In the meantime (this is just for a new proof of concept app) I embraced the 
> Ask in the route definition and create one-offs in response. I didn't use 
> forwarding as Patrik mentioned. Instead the one-off has a "requester" 
> property and after doing a bunch of tells and receives, completes the ask 
> future by sending a response to the requester. I hope this is OK - it seems 
> to work as a bridge between AskWorld and TellDon'tAskWorld. 
> 
> On Wed, Sep 9, 2015 at 3:34 AM, Akka Team <akka.offic...@gmail.com 
> <mailto:akka.offic...@gmail.com>> wrote:
> 
> 
> On Wed, Sep 9, 2015 at 12:27 PM, Patrik Nordwall <patrik.nordw...@gmail.com 
> <mailto:patrik.nordw...@gmail.com>> wrote:
> 
> 
> On Wed, Sep 9, 2015 at 12:05 PM, Akka Team <akka.offic...@gmail.com 
> <mailto:akka.offic...@gmail.com>> wrote:
> 
> 
> On Wed, Sep 9, 2015 at 11:59 AM, Patrik Nordwall <patrik.nordw...@gmail.com 
> <mailto:patrik.nordw...@gmail.com>> wrote:
> 
> 
> On Wed, Sep 9, 2015 at 11:17 AM, Akka Team <akka.offic...@gmail.com 
> <mailto:akka.offic...@gmail.com>> wrote:
> Hi Richard,
> 
> There is no easy way currently to do per-request actors (except that 
> everything in your handler Flow is kind of a per-request actor), this is 
> something we need to improve. I created an issue: 
> https://github.com/akka/akka/issues/18431 
> <https://github.com/akka/akka/issues/18431>
> 
> It's possible to create an actor from the mapAsync function and return the 
> Future of an ask request to that new actor. What am I missing?
> /Patrik
> 
> Where would you create the actor? You need an ActorRefFactory for that, and 
> the only legal way from inside a stage would be then to create a top-level 
> actor, which is far from optimal. 
> 
> I could have created a top level actor up front and let that one create child 
> actors on demand. The ask would go to the top level actor that forwards to a 
> child. It could be a router if a single top level actor becomes a bottleneck.
> 
> That can work, even if not trivial. Also ties the Flow to a certain top-level 
> actor, making it less reusable -- but it might not matter in an Http handler 
> anyway. I just still don't like that single bottleneck point, router or not. 
>  
> 
> I agree that this is a nice feature to have built-in, but I think there are 
> ways that are rather alright already.
> 
> If nothing else, we should make this a cookbook pattern. Btw there is no HTTP 
> cookbook yet.
> 
> -Endre
>  
>  
> 
> -Endre
>  
>  
> 
> 
> -Endre
> 
> On Mon, Sep 7, 2015 at 7:23 PM, Richard Rodseth <rrods...@gmail.com 
> <mailto:rrods...@gmail.com>> wrote:
> I've run into the same problem. How to do per-request actors rather than ask 
> pattern with Akka Http, and I'm afraid I don't understand how handlerFlow 
> helps. I've started a separate thread, but if either of you can elaborate 
> that would be great. The Spray migration page is still marked TODO.
> 
> Thanks.
> 
> On Tue, Jun 16, 2015 at 7:00 PM, Nicolau Werneck <nwern...@gmail.com 
> <mailto:nwern...@gmail.com>> wrote:
> Great, thanks for the reply!++nic
> 
> 
> On Tuesday, June 16, 2015 at 5:40:55 AM UTC-3, Richard Bradley wrote:
> You can see the source code to the net-a-porter Spray example here:
> https://github.com/NET-A-PORTER/spray-actor-per-request/blob/master/src/main/scala/com/netaporter/Boot.scala
>  
> <https://github.com/NET-A-PORTER/spray-actor-per-request/blob/master/src/main/scala/com/netaporter/Boot.scala>
> 
> The startup looks like:
>   IO(Http) ! Http.Bind(serviceActor, "localhost", port = 38080)
> 
> where "serviceActor" is an actor that mixes in spray.routing.HttpService, as 
> you say. The actor uses that trait to call "runRoute" to bind its Route to 
> the HTTP layer.
> 
> 
> In Akka HTTP, you instead need to wrap a Route with 
> "akka.http.scaladsl.server.Route.handlerFlow" to turn it into a 
> Flow[

Re: [akka-user] Akka Http routes in an actor

[Heiko Seeberger]

> On 08 Sep 2015, at 15:46, Richard Rodseth <rrods...@gmail.com> wrote:
> 
> The original inspiration was the Net-a-Porter article and template
> https://github.com/NET-A-PORTER/spray-actor-per-request#master 
> <https://github.com/NET-A-PORTER/spray-actor-per-request#master>
> http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ 
> <http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/>
> 
> At the time we had a lot of timeout issues. Perhaps these were mostly 
> backpressure-related and we could have used ask at the "edge" of the app.

Yeah, in my small world the route talks to one or more high level service 
actors via ask and there’s no need to chain asks which of course is a PITA.
You can get the idea here: 
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L72
 
<https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L72>

Cheers
Heiko

> The Net-a-Porter approach seems to have worked well for us, and I'm pretty 
> sure Typesafe folk endorsed the approach here on the list. Certainly chaining 
> asks seems like something that would be problematic as described in the 
> article. The template does include a generic trait, and it's easy to create a 
> "target" of the per-request parent, and create children within that target. 
> 
> Perhaps the not-yet-there migration from Spray docs will address best 
> practices for bridging HTTP with the rest of the app.
> 
> On Mon, Sep 7, 2015 at 10:57 PM, Heiko Seeberger <loe...@posteo.de 
> <mailto:loe...@posteo.de>> wrote:
>> On 08 Sep 2015, at 07:39, Richard Rodseth <rrods...@gmail.com 
>> <mailto:rrods...@gmail.com>> wrote:
>> 
>> Thanks for the link to that sample.
>> The other problem in doing per-request actors without ask pattern, as in the 
>> net-a-porter sample seems to be that Routes are no longer defined as 
>> RequestContext => Unit. Any thoughts on that? Are we now required to use 
>> Futures (or Flows?) to bridge routing with actors?
> 
> Why would you want to use per-request actors at all? As Akka HTTP by default 
> has an idle-timeout for connections, you should impose a timeout on your 
> per-request actor anyway. Which you always should do for one-off actors to 
> avoid memory leaks. That’s exactly what the ask-pattern gives you: one-off 
> actors with a timeout.
> 
> Cheers
> Heiko
> 
>> 
>> 
>> On Mon, Sep 7, 2015 at 10:18 PM, Heiko Seeberger <loe...@posteo.de 
>> <mailto:loe...@posteo.de>> wrote:
>>> On 07 Sep 2015, at 19:32, Richard Rodseth <rrods...@gmail.com 
>>> <mailto:rrods...@gmail.com>> wrote:
>>> 
>>> Maybe just move the bind call into my routing actor, in response to some 
>>> sort of Start message ?
>> 
>> Yep.
>> 
>> Here’s a similar example: 
>> https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L133
>>  
>> <https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L133>
>> 
>> Pay attention to not use any actor state/internals in the route, i.e. define 
>> the route in the companion object.
>> 
>> Cheers
>> Heiko
>> 
>> 
>>> 
>>> On Mon, Sep 7, 2015 at 8:38 AM, Richard Rodseth <rrods...@gmail.com 
>>> <mailto:rrods...@gmail.com>> wrote:
>>> I'm trying Akka Http for the first time, coming from Spray. In Spray I have 
>>>  a routing actor which extends HttpService and is passed to HttpBind as 
>>> shown below. This way routes can create per-request actors as a child of 
>>> the routing actor.
>>> What would be the equivalent in Akka Http?
>>> 
>>> I'm not so worried about the bind responder stuff right now, but here's 
>>> what my Spray initialization looks like:
>>> 
>>> class BindResponder(service: ActorRef, system:ActorSystem) extends Actor 
>>> with ActorLogging {
>>>  def receive = {
>>>   case b @ Http.Bound(connection) => {
>>> log.info <http://log.info/>(s"Successfully bound, starting 
>>> processing $b")
>>> ...
>>> self ! PoisonPill
>>> 
>>>   }
>>>   case cf @ Http.CommandFailed(command) => {
>>> log.error(s"Binding failed, shutting down process $cf")
>>> System.exit(0)
>>>   

Re: [akka-user] Akka 3.4.0 Persistence, Persistence Queries - dependencies and migrations

[Heiko Seeberger]

Tal,

You decided to use a experimental features (Akka Persistence in 2.3), so the 
issues you are facing now are no surprise.

Just my 5 cents
Heiko


> On 07 Sep 2015, at 16:06, Tal Pressman  wrote:
> 
> Hi,
> 
> Akka 2.4 is coming, bringing with it Persistence Queries, which for the most 
> part look really great. However, there are some issues with it that I find 
> problematic.
> 
> The first regards dependencies - 2.4.0 deprecates PersistentView, but the 
> recommended classes are part of an entirely different module, and that is 
> still experimental. On top of that, the new module depends on the stream 
> module, which is itself experimental. So what is someone more conservative 
> supposed to use?
> 
> The second issue is about migration from 2.3 to 2.4. In our application, for 
> example, we created stream Sources that wrap a PersistentView. Obviously, 
> there are a lot of drawbacks to this approach compared to the Query approach, 
> but there are advantages as well (for example: we don't care which 
> persistence plugin is used, and we know exactly which "queries" are supported 
> - all events belonging to a persistenceId).
> Now, if we decide to migrate to 2.4, "our" classes become deprecated (or 
> rather, use deprecated APIs). We could switch to a Query-based 
> implementation, but then we have to contend with the issue of when (if at 
> all) plugins are updated to support the new API.
> 
> Bottom line, the way it looks right now, it would be hard for me to justify 
> switching over to using the new query API at the moment (even though I 
> *really* want to), so at least I hope PersistentViews won't go anywhere 
> anytime soon.
> 
> Tal
> 
> 
> -- 
> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Http routes in an actor

[Heiko Seeberger]

> On 07 Sep 2015, at 19:32, Richard Rodseth  wrote:
> 
> Maybe just move the bind call into my routing actor, in response to some sort 
> of Start message ?

Yep.

Here’s a similar example: 
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L133
 


Pay attention to not use any actor state/internals in the route, i.e. define 
the route in the companion object.

Cheers
Heiko


> 
> On Mon, Sep 7, 2015 at 8:38 AM, Richard Rodseth  > wrote:
> I'm trying Akka Http for the first time, coming from Spray. In Spray I have  
> a routing actor which extends HttpService and is passed to HttpBind as shown 
> below. This way routes can create per-request actors as a child of the 
> routing actor.
> What would be the equivalent in Akka Http?
> 
> I'm not so worried about the bind responder stuff right now, but here's what 
> my Spray initialization looks like:
> 
> class BindResponder(service: ActorRef, system:ActorSystem) extends Actor with 
> ActorLogging {
>  def receive = {
>   case b @ Http.Bound(connection) => {
> log.info (s"Successfully bound, starting processing 
> $b")
> ...
> self ! PoisonPill
> 
>   }
>   case cf @ Http.CommandFailed(command) => {
> log.error(s"Binding failed, shutting down process $cf")
> System.exit(0)
> // TODO In future we might try to shutdown the actor system cleanly, 
> but
> // that is non-trivial
> // system.shutdown()
>   }
> }
>
>   }
>   
>val bindResponder = system.actorOf(Props(new BindResponder(serviceActor, 
> system)))
>   
>   IO(Http)(system).tell(Http.Bind(this.routingActor, hostName, port = 
> servicePort),bindResponder)
> 
> 
> 
> -- 
> >> 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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Http routes in an actor

[Heiko Seeberger]

> On 08 Sep 2015, at 07:39, Richard Rodseth <rrods...@gmail.com> wrote:
> 
> Thanks for the link to that sample.
> The other problem in doing per-request actors without ask pattern, as in the 
> net-a-porter sample seems to be that Routes are no longer defined as 
> RequestContext => Unit. Any thoughts on that? Are we now required to use 
> Futures (or Flows?) to bridge routing with actors?

Why would you want to use per-request actors at all? As Akka HTTP by default 
has an idle-timeout for connections, you should impose a timeout on your 
per-request actor anyway. Which you always should do for one-off actors to 
avoid memory leaks. That’s exactly what the ask-pattern gives you: one-off 
actors with a timeout.

Cheers
Heiko

> 
> 
> On Mon, Sep 7, 2015 at 10:18 PM, Heiko Seeberger <loe...@posteo.de 
> <mailto:loe...@posteo.de>> wrote:
>> On 07 Sep 2015, at 19:32, Richard Rodseth <rrods...@gmail.com 
>> <mailto:rrods...@gmail.com>> wrote:
>> 
>> Maybe just move the bind call into my routing actor, in response to some 
>> sort of Start message ?
> 
> Yep.
> 
> Here’s a similar example: 
> https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L133
>  
> <https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L133>
> 
> Pay attention to not use any actor state/internals in the route, i.e. define 
> the route in the companion object.
> 
> Cheers
> Heiko
> 
> 
>> 
>> On Mon, Sep 7, 2015 at 8:38 AM, Richard Rodseth <rrods...@gmail.com 
>> <mailto:rrods...@gmail.com>> wrote:
>> I'm trying Akka Http for the first time, coming from Spray. In Spray I have  
>> a routing actor which extends HttpService and is passed to HttpBind as shown 
>> below. This way routes can create per-request actors as a child of the 
>> routing actor.
>> What would be the equivalent in Akka Http?
>> 
>> I'm not so worried about the bind responder stuff right now, but here's what 
>> my Spray initialization looks like:
>> 
>> class BindResponder(service: ActorRef, system:ActorSystem) extends Actor 
>> with ActorLogging {
>>  def receive = {
>>   case b @ Http.Bound(connection) => {
>> log.info <http://log.info/>(s"Successfully bound, starting 
>> processing $b")
>> ...
>> self ! PoisonPill
>> 
>>   }
>>   case cf @ Http.CommandFailed(command) => {
>> log.error(s"Binding failed, shutting down process $cf")
>> System.exit(0)
>> // TODO In future we might try to shutdown the actor system cleanly, 
>> but
>> // that is non-trivial
>> // system.shutdown()
>>   }
>> }
>>
>>   }
>>   
>>val bindResponder = system.actorOf(Props(new BindResponder(serviceActor, 
>> system)))
>>   
>>   IO(Http)(system).tell(Http.Bind(this.routingActor, hostName, port = 
>> servicePort),bindResponder)
>> 
>> 
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html>
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user+unsubscr...@googlegroups.com>.
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>.
>> Visit this group at http://groups.google.com/group/akka-user 
>> <http://groups.google.com/group/akka-user>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/>
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.a

Re: [akka-user] [Akka-http] Using Flow to transform HttpRequest into HttpResponse

[Heiko Seeberger]

 2. How can I make the call blocking in order to get a HttpResponse but not 
 Future[HttpResponse]

If you are really really really sure that you want to block, you can await the 
completion of any Future with `Await.result(future, Duration.Inf)`

Heiko

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Testing Terminated

[Heiko Seeberger]

 On 05 Aug 2015, at 10:17, Patrik Nordwall patrik.nordw...@gmail.com wrote:
 
 On Wed, Aug 5, 2015 at 8:23 AM, Heiko Seeberger loe...@posteo.de 
 mailto:loe...@posteo.de wrote:
 On 04 Aug 2015, at 22:52, Patrik Nordwall patrik.nordw...@gmail.com 
 mailto:patrik.nordw...@gmail.com wrote:
 
 There is no support in testkit for creating fake Terminated messages. That 
 would probably be a nice addition.
 
 I guess you have already explored and rejected the option to actually stop 
 the watched actor in the test.
 
 Sort of. I’m implementing a simple publish-subscribe solution. The mediator 
 watches subscribers and removes these upon termination. The latter I would 
 like to test, i.e. be sure that terminated actors are removed from the 
 mediator. Stopping a subscriber means that it is “hard to use” in assertions 
 ;-)
 
 Any ideas how to test this? Maybe TestActorRef is the only way ...
 
 I would use a separate message to request the current subscribers that you 
 can use from the test to verify that the stopped subscriber is removed from 
 the mediator.

I think I like that. Thanks!

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Testing Terminated

[Heiko Seeberger]

 On 04 Aug 2015, at 22:52, Patrik Nordwall patrik.nordw...@gmail.com wrote:
 
 There is no support in testkit for creating fake Terminated messages. That 
 would probably be a nice addition.
 
 I guess you have already explored and rejected the option to actually stop 
 the watched actor in the test.

Sort of. I’m implementing a simple publish-subscribe solution. The mediator 
watches subscribers and removes these upon termination. The latter I would like 
to test, i.e. be sure that terminated actors are removed from the mediator. 
Stopping a subscriber means that it is “hard to use” in assertions ;-)

Any ideas how to test this? Maybe TestActorRef is the only way ...

Thanks
Heiko


 
 /Patrik
 
 On Tue, Aug 4, 2015 at 9:27 AM, Heiko Seeberger loe...@posteo.de 
 mailto:loe...@posteo.de wrote:
 Sigh! Looks like using reflection doesn’t work, as Akka treats Terminated 
 specially (DeathWatch.receivedTerminated).
 Is there support from TestKit?
 
 Heiko
 
 --
 
 Heiko Seeberger
 Home: heikoseeberger.de http://heikoseeberger.de/
 Twitter: @hseeberger https://twitter.com/hseeberger
 Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 04 Aug 2015, at 08:51, Heiko Seeberger loe...@posteo.de 
 mailto:loe...@posteo.de wrote:
 
 Hi,
 
 What’s the idiomatic way to test that an actor handles Terminated messages 
 correctly? Is there some support from akka-testkit to create  a Terminated 
 instance? Or should we use reflection?
 
 Thanks
 Heiko
 
 --
 
 Heiko Seeberger
 Home: heikoseeberger.de http://heikoseeberger.de/
 Twitter: @hseeberger https://twitter.com/hseeberger
 Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 
 -- 
 
 Patrik Nordwall
 Typesafe http://typesafe.com/ -  Reactive apps on the JVM
 Twitter: @patriknw
 
 
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http

Re: [akka-user] Testing Terminated

[Heiko Seeberger]

Sigh! Looks like using reflection doesn’t work, as Akka treats Terminated 
specially (DeathWatch.receivedTerminated).
Is there support from TestKit?

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 04 Aug 2015, at 08:51, Heiko Seeberger loe...@posteo.de wrote:
 
 Hi,
 
 What’s the idiomatic way to test that an actor handles Terminated messages 
 correctly? Is there some support from akka-testkit to create  a Terminated 
 instance? Or should we use reflection?
 
 Thanks
 Heiko
 
 --
 
 Heiko Seeberger
 Home: heikoseeberger.de http://heikoseeberger.de/
 Twitter: @hseeberger https://twitter.com/hseeberger
 Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Testing Terminated

[Heiko Seeberger]

Hi,

What’s the idiomatic way to test that an actor handles Terminated messages 
correctly? Is there some support from akka-testkit to create  a Terminated 
instance? Or should we use reflection?

Thanks
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Requester 2.0 library released

[Heiko Seeberger]

Is Requester offering any benefits over ask in combination with pipeTo?

Thanks
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 29 Jul 2015, at 16:49, Justin du coeur jduco...@gmail.com wrote:
 
 For those who are interested, I have just cut the second major release of the 
 Requester library https://github.com/jducoeur/Requester, with many 
 improvements over 1.1.
 
 
 What it is: Requester introduces request(), which can be thought of as the 
 better-behaved big brother to ask().  ask() returns a Future, and is 
 therefore quite dangerous to use inside of an Actor, because the Future 
 violates the single-threadedness of the Actor, and doesn't preserve sender.  
 request(), by contrast, loops the result of its request back into the Actor's 
 mailbox and preserves sender across the whole thing.  Basically, request() 
 works the way you intuitively *expect* ask() to work.
 
 As a result, Requester allows you to safely write completely natural, 
 composed, multi-Actor code inside of an Actor, like this:
 
 case GetSpacesStatus(requester) = {
   for {
 ActiveThings(nConvs) - conversations ? GetActiveThings
 ActiveSessions(nSessions) - sessions ? GetActiveSessions
   }
 sender ! SpaceStatus(spaceId, state.displayName, nConvs, nSessions)
 }
 There is a lot more -- Requester is heavily used by Querki 
 https://www.querki.net/help/#What-is-Querki, and I've been evolving it 
 steadily.  At this point, I think it's in good shape for other folks to make 
 serious use of it.  I invite y'all to play with it; comments and PRs are 
 warmly welcomed.
 
 (And yes, I still need to write up a PR for the Akka documentation, for the 
 external contributions section. I hadn't done so before because I wasn't 
 happy enough about the state of things, but it seems to be getting solid 
 enough now.)
 
 
 Changes in 2.0
 
 The most important change is that RequestM (the equivalent of Future -- a 
 block of work that will be executed in the Actor's receive loop) is now much 
 better-behaved, monadically. By and large, you can treat a RequestM like a 
 Future, and it will typically do what you expect.  In particular, RequestMs 
 now generally compose correctly, where they previously only composed in 
 certain ways.
 
 There is now an implicit conversion from RequestM[T] to Future[T].  This 
 makes it easier to use when your Actor is implementing Future-oriented 
 functions.  (Which I find comes up in client-server RPC programming.)
 
 The loopback is now caught in unhandled(), so you can usually just mix in 
 Requester and start using it.  You only need to explicitly call 
 handleRequestResponse under certain special circumstances.
 
 ? is now an alias for request(), intentionally mimicking ask().
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Implicit value issue for FromRequestUnmarshaller in akka-http with spray-json

[Heiko Seeberger]

You need to show the definition of routes. I assume (speculation again) that 
it’s a method in a different scope which doesn’t take an implicit Materializer 
(or EC).

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 28 Jul 2015, at 23:10, Harit Himanshu harit.subscripti...@gmail.com 
 wrote:
 
 I have similar issue, how did you people resolve it?
 
 On Friday, July 24, 2015 at 2:19:06 AM UTC-7, Kabir Idris wrote:
 Hi Heiko, 
 Here is my code 
 
  implicit val system = ActorSystem()
 
 implicit val executor: ExecutionContext = system.dispatcher
 val log: LoggingAdapter = Logging(system, getClass)
 implicit val materializer = ActorMaterializer()
 
 
   Http().bindAndHandle(routes, httpInterface, httpPort)
 
 
 
 
 On Monday, March 16, 2015 at 12:16:37 AM UTC+1, Arthur Kushka wrote:
 Hi. I was faced with a typical error with spray-json and akka-http that easy 
 to find in Google, but none of solutions helps me.
 
 Scala fail compiling in place where I parsing request body with `entity` 
 directive. As error say, they can`t find implicit value for unmarshaller, but 
 formatter and `SprayJsonSupport` are present in context (in documentation 
 written that that`s enough).
 
 Below is compiler message and my code.
 Please help me with finding solution of this problem.
 
 [error] 
 /home/arhelmus/techmedia/akka-http/src/main/scala/utils/CustomDirectives.scala:31:
  could not find implicit value for parameter um: 
 akka.http.unmarshalling.FromRequestUnmarshaller[utils.Credentials]
 [error] entity(as[Credentials]).flatMap { credentials =
 
 
 package utils
 
 import akka.http.marshallers.sprayjson.SprayJsonSupport
 import akka.http.server.Directive1
 import models.User
 import spray.json._
 
 case class Credentials(login: String, password: String)
 
 trait Protocols extends DefaultJsonProtocol {
   implicit val formatter: RootJsonFormat[Credentials] = 
 jsonFormat2(Credentials.apply)
 }
 
 object CustomDirectives extends CustomDirectives
 
 trait CustomDirectives extends SprayJsonSupport with Protocols {
 
   import akka.http.server.directives.BasicDirectives._
   import akka.http.server.directives.MarshallingDirectives._
   import akka.http.server.directives.ParameterDirectives._
 
   def authenticateByToken: Directive1[User] =
 parameter(token).flatMap { code =
   provide(User(code, asdsada, asdsadasd))
 }
 
   def authenticateByCredentials: Directive1[User] = {
 entity(as[Credentials]).flatMap { credentials =
   provide(User(credentials.login, credentials.login, 
 credentials.password))
 }
   }
 
 }
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Remote Actor Starting locally

[Heiko Seeberger]

The path of the actor in the config must match the path of the actor in the 
actor system, i.e. /connectorActor instead of /connectorActor/processingActor.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 23 Jul 2015, at 22:28, Harit Himanshu harit.subscripti...@gmail.com 
 wrote:
 
 I am trying to deploy actor remotely on different JVM.
 
 **ProcessingMain** (start on JVM1)
 
 object ProcessingMain {
 
   def main(args: Array[String]) = {
 startProcessingSystem()
   }
 
   def startProcessingSystem() = {
 ActorSystem.create(ProcessingSystem, 
 ConfigFactory.load(processingSystem))
 println(ProcessingSystem Started)
   }
 }
 
 **ConnectorMain**(start on JVM2)
 
 object ConnectorMain {
 
   def main(args: Array[String]) = {
 startConnectorSystem()
   }
 
   def startConnectorSystem() = {
 val system = ActorSystem.create(ConnectorSystem, 
 ConfigFactory.load(connectorSystem))
 val actor = system.actorOf(Props[ConnectorActor], connectorActor)
 println(ConnectorSystem Started)
 actor ! StartRemoteProcessor
   }
 }
 
 **common.conf**
 
 akka {
   actor {
 provider = akka.remote.RemoteActorRefProvider
   }
 
   remote {
 netty.tcp {
   hostname = 127.0.0.1
 }
   }
 }
 
 **processingSystem.conf**
 
 include common
 
 akka {
   # LISTEN on tcp port 2552
   remote.netty.tcp.port = 2552
 }
 
 **connectorSystem.conf**
 
 include common
 
 akka {
   actor {
 deployment {
   /connectorActor/processingActor {
 remote = akka.tcp://ProcessingSystem@127.0.0.1:2552
   }
 }
   }
   remote.netty.tcp.port = 2554
 }
 
 **ConnnectorActor**
 
 import akka.actor._
 import com.learn.remote.processing.ProcessingActor
 
 case object StartRemoteProcessor
 
 class ConnectorActor extends Actor with ActorLogging {
   val remoteProcessor = context.actorOf(Props[ProcessingActor], 
 processingActor)
 
   def receive = {
 case StartRemoteProcessor =
   println(Starting Remote Processor)
   remoteProcessor ! Start
   }
 }
 
 When I run **ProcessingMain**, I see
 
 ProcessingSystem Started
 
 When I run **ConnectorMain**, I see
 
 ConnectorSystem Started
 Starting Remote Processor
 ProcessingActor 
 path:akka://ConnectorSystem/user/connectorActor/processingActor
 
 As you see, instead of starting `processingActor` on `ProcessingSystem` it is 
 started on `ConnectorSystem`
 
 What's wrong going on?
 
 
 
 --
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Implicit value issue for FromRequestUnmarshaller in akka-http with spray-json

[Heiko Seeberger]

Do you have an implicit Materializer in scope?

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 23 Jul 2015, at 15:25, Kabir Idris binka...@gmail.com wrote:
 
 Hi all, Im facing the same error in akka-http 1.0 
 
 
 
 On Monday, March 16, 2015 at 12:16:37 AM UTC+1, Arthur Kushka wrote:
 Hi. I was faced with a typical error with spray-json and akka-http that easy 
 to find in Google, but none of solutions helps me.
 
 Scala fail compiling in place where I parsing request body with `entity` 
 directive. As error say, they can`t find implicit value for unmarshaller, but 
 formatter and `SprayJsonSupport` are present in context (in documentation 
 written that that`s enough).
 
 Below is compiler message and my code.
 Please help me with finding solution of this problem.
 
 [error] 
 /home/arhelmus/techmedia/akka-http/src/main/scala/utils/CustomDirectives.scala:31:
  could not find implicit value for parameter um: 
 akka.http.unmarshalling.FromRequestUnmarshaller[utils.Credentials]
 [error] entity(as[Credentials]).flatMap { credentials =
 
 
 package utils
 
 import akka.http.marshallers.sprayjson.SprayJsonSupport
 import akka.http.server.Directive1
 import models.User
 import spray.json._
 
 case class Credentials(login: String, password: String)
 
 trait Protocols extends DefaultJsonProtocol {
   implicit val formatter: RootJsonFormat[Credentials] = 
 jsonFormat2(Credentials.apply)
 }
 
 object CustomDirectives extends CustomDirectives
 
 trait CustomDirectives extends SprayJsonSupport with Protocols {
 
   import akka.http.server.directives.BasicDirectives._
   import akka.http.server.directives.MarshallingDirectives._
   import akka.http.server.directives.ParameterDirectives._
 
   def authenticateByToken: Directive1[User] =
 parameter(token).flatMap { code =
   provide(User(code, asdsada, asdsadasd))
 }
 
   def authenticateByCredentials: Directive1[User] = {
 entity(as[Credentials]).flatMap { credentials =
   provide(User(credentials.login, credentials.login, 
 credentials.password))
 }
   }
 
 }
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Parallel operation on list using future

[Heiko Seeberger]

This is an interesting question, but I don’t think it's closely related to Akka.

Maybe you want to take a look at ScalaBlitz (http://scala-blitz.github.io/) for 
some inspiration and potentially ask your question there.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 14 Jul 2015, at 07:04, Maatary Okouya maatarioko...@gmail.com wrote:
 
 Hi, 
 
 I was just wondering as a general advise if the following made sense. 
 
 
 I have a list, that i need to filter according to the following criteria: Let 
 say the list contain things of type A, B, C and D and i want to take n0 elt 
 of A, n1 elt of B, n2 elt of C and n3 elt of D and then make one list out of 
 it.
 
 the iterative approach is pretty clean (i.e. going over the all list, using 4 
 counters, adding elt to each list until each respective counter reached it 
 limit i.e. n1, n2, n3, n4), but a colleague at work told me to take advantage 
 of multiple cpu and parallelize the operation using future. 
 
 in other words, launching 4 future operation that filter the list, and drop 
 if it applies (i.e.resultinglist  nx), resultinglist.size - n0 or n1 or n2 
 or n3 or n4. then await the result and combine the list. 
 
 I think this is an overkill for something we use to do iteratively pretty 
 easily. I just wonder what people think about that. Yes i can run a test and 
 compare the speed, but it raise the question of, when exactly can we ensure 
 that we are taking advantage of the multiple cpu architecture. Because indeed 
 i understand the motivation behind the suggestion. However, i did not know 
 how to tell that it might be counter productive. We were both stuck in debate 
 and enable to state if it  is good situation or a bad situation to use 
 parallelization. In other word we did not have a criterion. Is  testing the 
 only way to know ?
 
 
 Many thanks,
 
 M
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Custom HTTP headers?

[Heiko Seeberger]

Hi,

How can I define custom HTTP headers, e.g. Last-Event-ID for SSE?

Thanks
Heiko

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Custom HTTP headers?

[Heiko Seeberger]

Thanks, but have seen this one, I was not looking for something raw, but 
deliciously cooked, i.e. looking like a built-in header.

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 27 Jun 2015, at 12:37, Stevo Slavić ssla...@gmail.com wrote:
 
 http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-RC4/index.html#akka.http.scaladsl.model.headers.RawHeader
  
 http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-RC4/index.html#akka.http.scaladsl.model.headers.RawHeader
 
 On Sat, Jun 27, 2015 at 12:28 PM, Heiko Seeberger loe...@posteo.de 
 mailto:loe...@posteo.de wrote:
 Hi,
 
 How can I define custom HTTP headers, e.g. Last-Event-ID for SSE?
 
 Thanks
 Heiko
 
 --
   Read the docs: http://akka.io/docs/ http://akka.io/docs/
   Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
   Search the archives: 
  https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user%2bunsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 --
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] How can the sender Actor be notified that the message handling cluster node crashed ?

[Heiko Seeberger]

Yes, of course. You might also get a Terminated message if the other system is 
temporarily – but too long – unreachable. In that case the other system will 
remain quarantined, i.e. all communication from it will be blocked, in order to 
make sure Terminated means what it suggests: no zombies ;-)

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 24 Jun 2015, at 13:35, john.vie...@gmail.com wrote:
 
 I am using the latest akka.
 I ended up doing a  context().watch(RemoteActor) in Actor A.
 This seems to work even if the remote node crashes.
 Is this the expected behavior when death watching  clustered nodes: The 
 watcher gets a Terminated message also on jvm crashes?
 
 Am Mittwoch, 24. Juni 2015 12:04:03 UTC+2 schrieb john@gmail.com:
 1) Actor A (Frontend Actor)  is created.
 2) A message is send to a backend Actor (running on a node in the cluster) by 
 a constant-hashing router. Actor A is a member of this message.
 3) The Cluster node which received the message from A crashes
 
 How can Actor A be notified that the node crashed?
 
 Can I use Death watching for this? Or do I have to setup all the machinary 
 myself?
  How would I register  Actor A for receiving a Terminated message?
 
 --
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Akka Remoting Separate JVMs: Restarting ChildActor when JVM crashed?

[Heiko Seeberger]

You seem to confuse failure and termination. Failure happens when an actor 
throws an exception, e.g. during handling a message. Then it gets suspended and 
its parent needs to decide what to do, e.g. restart. Termination happens when 
an actor gets stopped, e.g. by itself, or – in the case of removing – when the 
remote failure detector decides that the other side is no longer reachable, 
which of course happens when the other JVM crashes. Termination has nothing to 
do with supervision, though the parent could watch the lifecycle of its 
children by calling `context.watch`. Hoping that helps.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 22 Jun 2015, at 20:36, Harit Himanshu harit.subscripti...@gmail.com 
 wrote:
 
 Hello
 
 I am learning Remoting and have a question. I am looking at example where 
 remote actor is created programmatically. As per the typesafe activator 
 sample, I read 
 
 Error handling, i.e. supervision, works exactly in the same way as if the 
 child actor was a local child actor. In addtion, in case of network failures 
 or JVM crash the child will be terminated and automatically removed from the 
 parent even though they are located on different machines.
 
 Question (assuming parent and child are on separate JVMs)
 If the child actor crashes the JVM(where it lived) and supervision strategy 
 on parent(on a different JVM) is to Restart, will it start the entire 
 ActorSystem for Child Actor? I guess not because ActorSystem was started as a 
 separate process (by command-line).
 If 1. is true, how can we recover the Child Actor since the entire Actor 
 System (where Child Actor lived) crashed?
 Thank you
 + Harit Himanshu
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to send JSON object to actor using akka-http? (Java API)

[Heiko Seeberger]

Here you are:
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L79
 
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L79

Cheers
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 20 Jun 2015, at 22:22, tub...@gmail.com wrote:
 
 Hi,
 
 Can you please point me to an example where akka-http is used to process an 
 incoming JSON object within a POST request?
 I want to deserialize the object and send it to an actor to process it.
 
 All I can get out of it is a ByteStream. Do you have to manually deserialize 
 it?
 
 
 Best Regards
 
 --
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Akka Remoting Separate JVMs: Restarting ChildActor when JVM crashed?

[Heiko Seeberger]

1. yes
2. not exactly: it’s not possible to become a parent by looking up an actor, 
because each actor gets started by a parent actor (if you use 
ActorSystem.actorOf the system actor called guardian will be the parent)

So, one possible solution: Your parent actor watches its children which are 
deployed remotely; it also watches cluster events, in particular MemberUp; once 
it detects that too many children have died and there are spare remote cluster 
members nodes, it creates new children on these remote member nodes. BTW, 
that’s more or less what a cluster based pool router does, so you might not 
have to handle that yourself ...

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 22 Jun 2015, at 21:24, Harit Himanshu harit.subscripti...@gmail.com 
 wrote:
 
 Thanks a lot Heiko, That makes lot of sense.
 
 So as I understand
 If the JVM (where child actor resides) terminates(or crashes), no supervision 
 applies.
 The only way to recover then would be to start the process (JVM) with 
 ChildActor again(manually or some other way) and parent Actor (in separate 
 JVM) looks up for it and starts watching it again
 Correct me if this understanding is wrong
 
 Thank you
 + Harit Himanshu
 
 On Mon, Jun 22, 2015 at 12:08 PM, Heiko Seeberger loe...@posteo.de 
 mailto:loe...@posteo.de wrote:
 You seem to confuse failure and termination. Failure happens when an actor 
 throws an exception, e.g. during handling a message. Then it gets suspended 
 and its parent needs to decide what to do, e.g. restart. Termination happens 
 when an actor gets stopped, e.g. by itself, or – in the case of removing – 
 when the remote failure detector decides that the other side is no longer 
 reachable, which of course happens when the other JVM crashes. Termination 
 has nothing to do with supervision, though the parent could watch the 
 lifecycle of its children by calling `context.watch`. Hoping that helps.
 
 Heiko
 
 --
 
 Heiko Seeberger
 Home: heikoseeberger.de http://heikoseeberger.de/
 Twitter: @hseeberger https://twitter.com/hseeberger
 Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 --
 
 Heiko Seeberger
 Home: heikoseeberger.de http://heikoseeberger.de/
 Twitter: @hseeberger https://twitter.com/hseeberger
 Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 22 Jun 2015, at 20:36, Harit Himanshu harit.subscripti...@gmail.com 
 mailto:harit.subscripti...@gmail.com wrote:
 
 Hello
 
 I am learning Remoting and have a question. I am looking at example where 
 remote actor is created programmatically. As per the typesafe activator 
 sample, I read 
 
 Error handling, i.e. supervision, works exactly in the same way as if the 
 child actor was a local child actor. In addtion, in case of network failures 
 or JVM crash the child will be terminated and automatically removed from the 
 parent even though they are located on different machines.
 
 Question (assuming parent and child are on separate JVMs)
 If the child actor crashes the JVM(where it lived) and supervision strategy 
 on parent(on a different JVM) is to Restart, will it start the entire 
 ActorSystem for Child Actor? I guess not because ActorSystem was started as 
 a separate process (by command-line).
 If 1. is true, how can we recover the Child Actor since the entire Actor 
 System (where Child Actor lived) crashed?
 Thank you
 + Harit Himanshu
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  https://groups.google.com/group/akka-user
 --- 
 You received this message because you are subscribed to a topic in the Google 
 Groups Akka User List group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/akka-user/SQF0wiObHGY/unsubscribe 
 https://groups.google.com/d

Re: [akka-user] Writing custom directives and encapsualting routes in akka-http

[Heiko Seeberger]

Try ExecutionContext (for Futures) and/or FlowMaterializer (for marshalling).
See 
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L51
 
https://github.com/hseeberger/reactive-flows/blob/master/src/main/scala/de/heikoseeberger/reactiveflows/HttpService.scala#L51

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 20 Jun 2015, at 04:11, Nicolau Werneck nwern...@gmail.com wrote:
 
 I am writing an application where I have different types of entities. I wrote 
 a generic DAO object with Slick to perform basic CRUD operations, and I want 
 to create routes to make a simples http service for these entities. I have 
 similar routes, so I wanted to write a function for a generic CRUD routes.
 
 Now the problem is, I can assign part of a route to a `val` and then put that 
 in the route definition like a directive. But if I use a `def` in order to 
 write a function to take parameters and write each specific route, with type 
 parameters, it doesn't work. I get an error like:
 
 Error:(33, 18) type mismatch;
  found   : scala.concurrent.Future[Option[E]]
  required: akka.http.scaladsl.marshalling.ToResponseMarshallable
   dao.get(elementId)
  ^
 
 I suppose it might be the need for some implicit parameter, I don't know. Any 
 hints?
 
 ++nic
 
 --
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

[akka-user] HTTP/2

[Heiko Seeberger]

Akka team,

Are there plans to add support for HTTP/2 to Akka HTTP anytime soon?

Thanks
Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [akka-user] Deprecation of PoisonPill

[Heiko Seeberger]

Sebastiaan,

To my knowledge PoisonPill will be phased out, see also Martynas' response: 
...was not reintroduced in the new akka-typed module.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 05 Feb 2015, at 11:46, Sebastiaan Samyn sebastiaan.sa...@gmail.com wrote:
 
 I did get the graceful shutdown part at the time, but I thought that you 
 explicitly said something about PoisonPill being phased out altogether. 
 Anyway, it might be my memory playing tricks on me ;).
 
 Thanks for the response! 
 Sebastiaan Samyn
 
 On Thursday, January 22, 2015 at 7:53:16 AM UTC+1, Heiko Seeberger wrote:
 Hi Sebastiaan,
 
 As Martinas pointed out (and I tried to tell in London) you should define 
 some ShutMeDownGracefully (replace this exemplary name with one matching 
 the context) message for each actor which needs graceful shutdown and 
 implement the specific behavior which might vary (not every actor needs to 
 process its current mailbox, other shutdown-algorithms are possible) 
 depending on the specific purposes of the actor.
 
 Heiko
 
 --
 
 Heiko Seeberger
 Home: heikoseeberger.de http://heikoseeberger.de/
 Twitter: @hseeberger https://twitter.com/hseeberger
 Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 21 Jan 2015, at 19:41, Martynas Mickevičius martynas.m...@typesafe.com 
 javascript: wrote:
 
 Hi Sebastiaan,
 
 there is nothing special in PoisonPill in the sense that you can always 
 implement one of your own.
 
 Currently there is no way for an actor to choose not to swallow a 
 PoisonPill. This is why it was not reintroduced in the new akka-typed 
 module. This is probably what Heiko was hinting at.
 
 On Mon, Jan 19, 2015 at 3:23 PM, Sebastiaan Samyn sebastia...@gmail.com 
 javascript: wrote:
 Hi,
 
 Earlier this year I took the advanced akka course in London and there I was 
 told by Heiko Seeberger that the PoisonPill message would soon become 
 deprecated.
 
 Since I haven't seen any news on this, I was wondering if this statement 
 still stands.
 
 Will PoisonPill become deprecated? Was this really ever an idea that you 
 guys played with or can I continue to use it without worrying about 
 compatibility issues with future akka versions?
 
 Regards,
 Sebastiaan Samyn
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 javascript:.
 To post to this group, send email to akka...@googlegroups.com javascript:.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 
 -- 
 Martynas Mickevičius
 Typesafe http://typesafe.com/ – Reactive 
 http://www.reactivemanifesto.org/ Apps on the JVM
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 javascript:.
 To post to this group, send email to akka...@googlegroups.com javascript:.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit

Re: [akka-user] Deprecation of PoisonPill

[Heiko Seeberger]

Hi Sebastiaan,

As Martinas pointed out (and I tried to tell in London) you should define some 
ShutMeDownGracefully (replace this exemplary name with one matching the 
context) message for each actor which needs graceful shutdown and implement the 
specific behavior which might vary (not every actor needs to process its 
current mailbox, other shutdown-algorithms are possible) depending on the 
specific purposes of the actor.

Heiko

--

Heiko Seeberger
Home: heikoseeberger.de http://heikoseeberger.de/
Twitter: @hseeberger https://twitter.com/hseeberger
Public key: keybase.io/hseeberger https://keybase.io/hseeberger
 On 21 Jan 2015, at 19:41, Martynas Mickevičius 
 martynas.mickevic...@typesafe.com wrote:
 
 Hi Sebastiaan,
 
 there is nothing special in PoisonPill in the sense that you can always 
 implement one of your own.
 
 Currently there is no way for an actor to choose not to swallow a PoisonPill. 
 This is why it was not reintroduced in the new akka-typed module. This is 
 probably what Heiko was hinting at.
 
 On Mon, Jan 19, 2015 at 3:23 PM, Sebastiaan Samyn sebastiaan.sa...@gmail.com 
 mailto:sebastiaan.sa...@gmail.com wrote:
 Hi,
 
 Earlier this year I took the advanced akka course in London and there I was 
 told by Heiko Seeberger that the PoisonPill message would soon become 
 deprecated.
 
 Since I haven't seen any news on this, I was wondering if this statement 
 still stands.
 
 Will PoisonPill become deprecated? Was this really ever an idea that you guys 
 played with or can I continue to use it without worrying about compatibility 
 issues with future akka versions?
 
 Regards,
 Sebastiaan Samyn
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 
 -- 
 Martynas Mickevičius
 Typesafe http://typesafe.com/ – Reactive 
 http://www.reactivemanifesto.org/ Apps on the JVM
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Simplest possible setup wich allows system restart of individual nodes

[Heiko Seeberger]

Another link that might help understand how to use Akka Cluster Sharding: 
https://github.com/hseeberger/reactive-flows/commit/e0fe29434592e591b8579b43c6c082ad6137e44c
 
https://github.com/hseeberger/reactive-flows/commit/e0fe29434592e591b8579b43c6c082ad6137e44c

Heiko

 On 14 Nov 2014, at 12:03, Richard Bowker mechajohntravo...@googlemail.com 
 wrote:
 
 I agree, this sounds like a good fit:
 
 this link helped me to understand what to do
 
 https://github.com/ktoso/akkamazing/commits/cluster-sharding-steps-ktoso
 
 
 
 On Thursday, November 13, 2014 11:31:59 AM UTC, Martynas Mickevičius wrote:
 Hi Anders,
 
 it seems that cluster sharding fits the bill here. Especially when in your 
 current setup you send messages to children based on an ID of the event which 
 is exactly what sharding by entity ID does.
 
 Now say you have a cluster of nodes and use cluster sharding. If you remove 
 one node from the cluster the coordinator will rebalance the sharded entities 
 to the remaining nodes. Same happens when new node joins the cluster. A 
 predicate upon which fulfillment rebalance is started is defined in the shard 
 allocation strategy.
 
 You can also use PersistentActors If you want to recover state when sharded 
 entities are moved to different nodes.
 
 On Mon, Nov 10, 2014 at 12:48 PM, Anders Båtstrand ande...@gmail.com 
 javascript: wrote:
 Dear group
 
 In a project where performance is not an issue (yet, and possibly never), I 
 am thinking about the following cold-standy solution to enable us to restart 
 nodes without loosing state:
 
 One node is running with Persistent Actors saving to a database. When that 
 node goes down, the other node is started manually, and reading all events 
 from the database it gets in the same state.
 
 The problem with this is that we have to do something manually (start the new 
 server), and that we are unavailable in the meantime (for instance for a GUI).
 
 What is the next step, to have both nodes running at the same time, and not 
 appear down to the clients? Is it to have two (or more) nodes running in a 
 cluster, with all actors created as singletons? 
 
 We use a pattern where events we receive (over SOAP)  are sent to a parent 
 actor, which forwards to children based on an ID in the event. If the ID is 
 unkown, the parent actor creates a new child. 
 The children builds up state based on the events, and publishes other events 
 based on this state. As I imagine it, the parent actor would be a singleton, 
 creating all the children on the same node... That way, starting up the 
 parent actor on an already running Akka instance would be pretty fast, and 
 reading from the same database it would get in the same state. 
 ClusterSingletonProxy stashes away messages during this process, so we don't 
 loose requests.
 
 The doc, however, warns against the singleton pattern (Using a singleton 
 should not be the first design choice), and I am wondering what the 
 alternative is for my scenario.
 
 Best regards,
 
 Anders Båtstrand
 
 
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 javascript:.
 To post to this group, send email to akka...@googlegroups.com javascript:.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 
 
 -- 
 Martynas Mickevičius
 Typesafe http://typesafe.com/ – Reactive 
 http://www.reactivemanifesto.org/ Apps on the JVM
 
 -- 
  Read the docs: http://akka.io/docs/ http://akka.io/docs/
  Check the FAQ: 
  http://doc.akka.io/docs/akka/current/additional/faq.html 
  http://doc.akka.io/docs/akka/current/additional/faq.html
  Search the archives: https://groups.google.com/group/akka-user 
  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 
 mailto:akka-user+unsubscr...@googlegroups.com.
 To post to this group, send email to akka-user@googlegroups.com 
 mailto:akka-user@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user 
 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.

-- 
  Read the docs: http://akka.io/docs/
  Check the FAQ: 
 

Re: [akka-user] ClusterRouter routees paths resolving

[Heiko Seeberger]

Amit,

As a pool router is the parent of the routees it creates, you could simply use 
`context.parent` from within a routee to get the router. Then you could use the 
`Broadcast` envelope to send a message from one routee to all others. Of course 
you can then use the sender reference to talk to the other routess directly. 
With this approach you don't have to use any paths or look-ups.

Hoping this helps.

Heiko


On 25 Aug 2014, at 21:36, Amit Kalfus jam...@gmail.com wrote:

 Hi,
 
 I'm currently using an ClusterRouterPool, with an instance on each node, 
 which creates somthing in the form of: 
 /user/ClusterRouterPoolName/c1.../user/ClusterRouterPoolName/c2 etc.
 
 and inside this instances I create several actors. 
 
 My question is: what is the best way to communicate between this actors, 
 which are inside the same 'c' actor?
 
 I don't want to use a relative path, since it may be updated/changed with the 
 evolution of my product, and may not be aligned on all actors. but if I 
 didn't had the c1..k in the path,
 I could just use the local path /user/ClusterRouterPoolName/myTargetActor, 
 without resolving the cluster naming I use.
 
 Is it safe to say that the local instance of the pool will always be with the 
 numbering of '1'?
 
 thanks in advanced.
 
 Amit
 
 -- 
  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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Actor system unexpected slow down at load?

[Heiko Seeberger]

While this is sort of speculative, it looks like you have introduced a 
bottleneck. Maybe you can use a router for your main actor, resulting in 
parallelizing entry work (assuming you have multiple cores and enough threads)?

Heiko

On 23 Aug 2014, at 02:37, Paul Cleary pclear...@gmail.com wrote:

 I have an actor system that is setup using all of the akka defaults.
 
 Nothing in the system has a lot of latency, we are talking about sub 
 millisecond (20 microsecond) latencies.
 
 All traffic flows through a single actor to downstream actors.  This main 
 actor just forwards the message onto children using a lookup.
 
 I am doing load testing, and have seen the same trend both on my local, as 
 well as in a server environment.  The main actor keeps up superbly up until 
 a certain point.
 
 I get up to about 1500 requests per second in my load test, which generates a 
 boat load (10s of thousands) of messages against my single actor.
 
 At that point, all of a sudden the mailbox size gets enormous on my main 
 actor.
 
 None of the downstream actors are doing anything, so it isn't like some roque 
 actor is chewing up threads.
 
 The main actor IS making progress, albeit very very very slowly.
 
 When I did a thread dump, almost all of the dispatcher threads were waiting 
 (i.e., parked not doing anything).
 
 The mailbox size grows into the millions during the test.  The main actor 
 never really catches up, just putt putts along, it doesn't get faster.
 
 A few other notes:
 1. I did not max out memory or hit stop the world GC at any point during the 
 test.
 2. The CPU is very low on the machine, under 50%
 3. There are no hardcore errors on the main actor, he doesn't restart or 
 anything like that
 4. I am using Akka 2.2.3
 
 So, my questions are:
 1. If the threads aren't busy (they are waiting), why isn't my main actor 
 making faster progress?  Why are the other threads waiting seemingly not 
 doing anything?
 
 2. What might cause the system to seemingly shut down?
 
 
 -- 
  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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Multiple ActorSystems ('weight', uses, etc?)

[Heiko Seeberger]

Glenn,

Find my answers below.

Heiko

On 22 Aug 2014, at 05:03, Glenn / devalias glenn.gr...@wlpc.com.au wrote:

 Heya,
 
 So, most/pretty much everything I read says ActorSystems are heavyweight, and 
 you should only use one unless you have a 'really good reason' to use more 
 than one since they are 'heavy'.

Where did you find that last statement? I'm asking because in order to use Akka 
actors you need at least one ActorSystem.

 
 I was wondering
 Just how heavy is an ActorSystem? 
The heaviest part of an actor system is the dispatcher: Each actor system has 
at least one. The dispatcher essentially is the engine that makes the actors 
run. In order to do so it needs threads, usually obtained from a thread pool. 
The default dispatcher by default (default to the power of two) uses a 
fork-join thread pool with at least 8 threads.

There are other shared facilities, some in user space and some internal, e.g. 
the guardian actors, the event stream, the scheduler, etc. All of these need to 
be created and started.
 Conceivably how many could you run in a JVM and how much memory/threads/etc 
 would it require? 
I don't think that heaviness in terms of memory is an issue here. What really 
matters are the thread pools. As I said, per default an actor system creates a 
fork-join pool with at least 8 threads. If your application needs to bulkhead 
certain actors from others, e.g. because some of the actors are doing blocking 
stuff, you need multiple dispatchers, i.e. multiple thread pools.
 Is there a commonly known 'weight' for an ActorSystem?
 I've also been wondering about what would be a 'really good reason' to have 
 multiple ActorSystems.

One good reason that comes to my mind are tests which are executed in parallel. 
In my project that's usually the case, I would say that the tests typically 
create more actor systems at one time than I have cores available, i.e. some 10.

Apart from that, I don't think having multiple local actor systems, i.e. in one 
JVM or on one machine, is a common pattern. If you really want to scale up most 
efficiently, one actor system with one thread pool configured to the numbers of 
cores (assuming a blocking factor of zero) should give you the best results. If 
you then need to further scale, scale out, i.e. create actor systems on remote 
nodes.

 The one topic that particularly came to mind was an overall 'network' of 
 'nodes' (though not necessarily in the clustered sense) where each node needs 
 to maintain it's own sandboxed ActorSystem to prevent 'crosstalk' from 
 another ActorSystem (except by well defined channels using remoting, 
 receptionist, 'protected mode', and all the other fun things Akka provides in 
 that regard)
 
 Conceivably this model COULD be put into a conventional model (single 
 ActorSystem + potentially a few more/cluster setup for remote 
 deployment/etc), but then it seems like you would have to manually 
 re-implement a lot of protections to attempt to isolate each 'node' from 
 affecting one another. (eg context.parent.parent.parent, 
 context.select(../../../../../../../*) or context.system.shutdown, etc)
 
 Aside from the 'heaviness' of running these multiple ActorSystems, it raises 
 a few more questions.
 In the 'normal actor' model, we can make use of remote deployment to easily 
 farm these 'nodes' out to remote servers, possibly even lazily/on demand (not 
 starting them till required), though it would seem there is no way to 
 remotely 'deploy' an ActorSystem from within Akka (since it would need to 
 'deploy' into an ActorSystem)
 Can an ActorSystem be created 'inside' another ActorSystem (eg. an Actor 
 creates a new ActorSystem) If so, how does this effect the lifecycle of the 
 'inner' ActorSystem? Will it die when the outer ActorSystem dies?
No
 Is clustering designed to allow arbitrary potentially untrusted ActorSystems 
 to communicate? I would think it doesn't really fit the model, since it's 
 possible that a rogue system in a cluster could break/interfere with 
 gossip/etc.
There are security features: 
http://doc.akka.io/docs/akka/2.3.5/scala/remoting.html#Remote_Security
 If clustering isn't the answer, is there a 'best practice' for disparate 
 potentially untrusted ActorSystems to communicate/interact?
 
 Lot's of ponderings and mind dumping here, so hopefully it makes enough sense 
 to be followed.
 
 Looking forward to your thoughts/insights! :)
 
 - Glenn / devalias
 
 
 
 
 -- 
  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 http://groups.google.com/group/akka-user.
 

Re: [akka-user] Using stash with become

[Heiko Seeberger]

Luis,

As an actor only handles one message at a time, the order of `unstashAll` and 
`context.become` doesn't matter at all: Both happen while processing the 
current message which means that no other message gets processed until both 
methods (and the rest of the current behavior) have been executed. Then, when 
the next message is about to get processed, both methods have already been 
executed.

BTW, I have seen many who have been thinking along the same lines ;-)

Cheers
Heiko

On 19 Aug 2014, at 19:09, Luis Medina lu4...@gmail.com wrote:

 Hi all,
 
 I'm working on implementing retry functionality in one of my actor's that 
 will retry writing a message to RabbitMQ if the original write fails. This 
 looks something like this:
 
 private String retryMessage;
 
 private void processMessage(String message) {
 try {
 writer.write(message);
} catch (IOException e) {
 LOGGER.warn(Unable to write message to RabbitMQ. Retrying...);
 retryMessage = message;
 context().become(retry);
 sendTimeout();
 }
 }
 
 private PartialFunctionObject, BoxedUnit retry = ReceiveBuilder
.match(String.class, message - stash())
.match(ReceiveTimeout.class, receiveTimeout - retryMessage())
.build();
 
 private void sendTimeout() {
 long waitTime = getWaitTime();
 
 context().setReceiveTimeout(Duration.Undefined());
 context().setReceiveTimeout(Duration.create(waitTime, 
 TimeUnit.MILLISECONDS));
 }
 
 private void retryMessage() {
 try {
 writer.write(retryMessage);
 context().setReceiveTimeout(Duration.Undefined());
 context().unbecome();
 unstashAll();
 } catch (IOException e) {
 LOGGER.warn(Unable to write message to RabbitMQ. Retrying...);
 sendTimeout();
 }
 }
 
 As you can see, when the write fails, the actor switches to a retry mode. 
 In this retry mode, it will stash any incoming messages that are meant to be 
 written until it can successfully write the original message that it failed 
 on. To do a retry, I set a ReceiveTimeout that whose duration increases 
 exponentially with each failure. When the actor receives a ReceiveTimeout, it 
 simply tries to write it again. Now the part that I'm curious about has to do 
 with unstashing all of the messages and unbecoming its retry mode.
 
 In the retryMessage() method, if the write is successful, the ReceiveTimeout 
 will be shut off, the actor will revert back to its original state, and any 
 messages that were stashed during this time will be unstashed. In terms of 
 reverting back to its original state and unstashing messages, is this the 
 right order in which to do this? In all of the examples that I've seen, I 
 noticed that the unstashAll() always came before the context().unbecome() 
 which is what I originally had. After giving it some thought, however, I 
 started to wonder if having this order would cause me to lose any messages if 
 they arrived in between the unstashAll() and context().unbecome() operations 
 thus causing them to get stashed but never becoming unstashed again. This is 
 why I ended up reversing their order. Is my thinking correct?
 
 Luis
 
 -- 
  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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Testing parent/child behaviors

[Heiko Seeberger]

Tom,

Why don't you use a protected factory method (`def createChild: ActorRef = 
...`) in the parent to create your child actor instead of doing it inline? Then 
override it the way you want in the tests. Sometimes good old OO (I know that 
Alan Kay not necessarily meant inheritance when inventing OO) does the trick ;-)

Heiko

On 20 Aug 2014, at 17:00, Tom Sorensen tsoren...@gmail.com wrote:

 I've already looked at all the links from 
 https://www.assembla.com/spaces/akka/tickets/3043#/activity/ticket: as well 
 as 
 http://hs.ljungblad.nu/post/69922869833/testing-parent-child-relationships-in-akka
 
 Still no closer to actually finding a working solution for testing an actor 
 which spawns a child itself. The latter method appears to be the most 
 elegant, but I simply do not understand what is being done in the Bar class 
 with this, and whether or not it's crucial to the overall implementation. 
 The method using ActorRefFactory as linked from the doc ticket is clear, but 
 it doesn't seem that you can name the Actor being created in this manner, and 
 my use case requires that we be able to do so.
 
 My actual use case is a FSM that spawns a child actor; for testing I do want 
 to use TestFSMRef in TestKit, but I want to avoid spawning a real child 
 during the test.
 
 Tom Sorensen
 
 -- 
  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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cluster aware router - get the host name for routees

[Heiko Seeberger]

ConsistentHashingRouter?


On 20 Jul 2014, at 01:04, Stas Shevchenko stass...@gmail.com wrote:

 I have to implement simple cluster with that conditions
 
 a) there are 1 client system and 2 worker systems
 b) client system is connected to worker systems via remote (I use a 
 netty-remote)
 c) client must forward messages to only one worker system at a time (should 
 be set in config)
 d) if the worker system with priority (enabled for dispatching messages from 
 client) is down, then client should route all messages to another worker.
 
 I implemented that using an Actor, simulates router with help of Cluster 
 events like MemeberUp etc, saving member host to routees map to be able to be 
 selected by this host during the routing message.
 
 Is there any possibility to implement routing by host using the Akka Cluster 
 aware Router? I cant find the configuration for it, that has an access to 
 make routing by host name.
 
 Stas
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Kafka journal

[Heiko Seeberger]

 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 http://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+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.com.
 Visit this group at http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
 
 -- 
 Martin Krasser
 
 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Scheduling using ActorSelection

[Heiko Seeberger]

I like this idea!

Just a side note: Restarting an actor won't lead to a stale ActorRef; the 
opposite is the case!

Heiko

On 07 Jul 2014, at 09:19, Måns Schultz gfae...@gmail.com wrote:

 Hello and thanks again for an excellent framework.
 
 I'm have a minor question about schedulers. As ActorRefs are somewhat harder 
 to lookup these days it would be really sweet if the Scheduler interface 
 could have a schedule method that takes an ActorSelection. Also as I 
 understand  the ActorRef this would also allow you to schedule without 
 worrying about actor restarts (since an ActorRef can become stale) and 
 schedule messages to groups of actors. Would this make the interface too 
 bloated or is the entire concept of scheduling to ActorSelections a bad idea? 
 I see that the ActorRef method has a stop condition (receiver.isTerminated) 
 which I guess would be hard to replicate for selections. 
 
 All this can ofcourse be accomplished using anonymous Runnables, would just 
 be nice to avoid it if there are no outstanding issues. 
 
 Best Regards
 
 Måns Schultz
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Immutable Messages and the Java Memory Model

[Heiko Seeberger]

On 23 Jun 2014, at 03:24, Nicholas Phillips nico.phill...@gmail.com wrote:

 I'm having some difficulty understanding some of the guarantees that the Akka 
 framework provides.  The documentation states:
 
 To prevent visibility and reordering problems on actors, Akka guarantees the 
 following two happens before rules:
 
 The actor send rule: the send of the message to an actor happens before the 
 receive of that message by the same actor.
 The actor subsequent processing rule: processing of one message happens 
 before processing of the next message by the same actor.
 Both rules only apply for the same actor instance and are not valid if 
 different actors are used.
 
 I understand the documentation but am wondering if anything is guaranteed 
 about sending a message to a different actor.

Akka gives you at-most-once delivery and guarantees ordering of messages per 
sender-receiver pair, see 
http://doc.akka.io/docs/akka/2.3.3/general/message-delivery-reliability.html.

 The documentation also indicates that messages should (not must) be 
 immutable.  If I send a mutable message to another actor, does the receiving 
 actor run the risk of not seeing the fields that were set in the sending 
 actor?

No, that shouldn't happen when you are using a well designed mailbox. The 
default one is build on top of java.util.concurrent.ConcurrentLinkedQueue which 
gives you the following memory consistency effects: As with other concurrent 
collections, actions in a thread prior to placing an object into 
aConcurrentLinkedQueue happen-before actions subsequent to the access or 
removal of that element from theConcurrentLinkedQueue in another thread. 
(file:///Users/heiko/tools/java/java-8-docs/api/index.html)

On the other hand, changes applied by the sender after sending might not be 
seen by the receiver. And other fun things like 
ConcurrentModificationExceptions might happen ...

 
 My java project deals with some pretty unwieldy model objects that have 40+ 
 instance variables, but I'd like to pass those model objects between actors 
 as fields on a message.  I can make the model object a final field on the 
 message, but that obviously doesn't really make it immutable.  Making the 
 fields of the model object final puts incredible bloat on the constructor, so 
 I don't really consider that an option.  My reading of 
 http://java.dzone.com/articles/memory-barriersfences indicates that the final 
 keyword will enforce a store barrier, implying that as long as I set all of 
 the fields on my model object before I set it as a message field, the message 
 recipient should see a fully populated object - is that correct?  Even if the 
 statement is true, I don't think that will be easy to enforce across my team. 
  Does Akka guarantee anything stronger?

Because of the above, visibility of the values shouldn't be an issue here.

 I have the use case where I pass my (mutable) model object along to another 
 actor who computes and sets some of the values on that model object before 
 constructing a reply with it.  Is this a terrible idea in Akka, or is there a 
 way to make it work?

I consider this a terrible idea, on the long run this  certainly opens many 
cans of worms. You should treat your messages (and objects contained in 
messages) as effectively immutable, i.e. never change them. Simply create a 
copy, if you need to change them.

Heiko

 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [design] Use actorSelection or pass actorRef as parameter

[Heiko Seeberger]

Using `actorSelection` is a look up and we all know that look ups should be 
avoided. In addition you can’t watch an `ActorSelection`. So you should clearly 
prefer the second variant.

Heiko

On 21 Jun 2014, at 20:08, Владимир Морозов greenhos...@gmail.com wrote:

 Hi all,
 
 I have system design question about application with akka actors inside.
 
 For example I have some Actors:
 
 object EmailSender {
   case class SendMessage(address: String, msg: String)
 }
 
 class EmailSender(config: SMTPConfig) extends Actor with ActorLogging {
   import EmailSender._
 
   def receive = {
 case SendMessage(address, msg) =
   // some email send logic
   }
 }
 
 object Worker {
   case object DoWork
 }
 
 
 //First variant
 class Worker extends Actor with ActorLogging {
   import Worker._
 
   val emailActor = context.actorSelection(email-sender)
 
   def receive = {
 case DoWork =
   //do some work and send email
   emailActor ! EmailSender.SendMessage(ad...@localhost.com, Work 
 complete)
   }
 }
 
 //Second variant
 class Worker(emailActor: ActorRef) extends Actor with ActorLogging {
   import Worker._
 
   def receive = {
 case DoWork =
   //do some work and send email
   emailActor ! EmailSender.SendMessage(ad...@localhost.com, Work 
 complete)
   }
 }
 
 What variant more 'true akka-style'?
 
 PS: I read about cake pattern and cake I really liked, for obvious dependency 
 injections, but I don't figure out how use 'cake' in case of some dependent 
 actor`s.
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Git tutorial links not working

[Heiko Seeberger]

Is there a specific reason for using Akka 2.0? The latest release is 2.3.3. 
Tutorials for 2.3 can be found via Activator 
(http://www.typesafe.com/activator).

Heiko


On 22 Jun 2014, at 17:34, Vincent Ohprecio ohpre...@gmail.com wrote:

 Just tried using the instructions on 
 http://doc.akka.io/docs/akka/2.0.2/intro/getting-started-first-scala.html and 
 I found all the git links where returning 404. I checked the source that I 
 downloaded from git and it didn't have a tutorials folder.
 
 Suggestions?
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How to terminate router after its childs complete their work....

[Heiko Seeberger]

In your example the workers have no way to tell that all work (assigned to 
them) has been done: How should they know that they will only ever receive some 
100 messages?

Instead the router has to trigger closing down the workers, e.g. via sending a 
PoisonPill. Or, instead of using a group router, you could use a pool router, 
i.e. one that creates the routees (workers) as children. Then, when the router 
knows that all work has been done, it could simply shut down itself which will 
result in shutting down the workers, because stopping an actor is a recursive 
operation.

Heiko


On 20 Jun 2014, at 16:47, Pramod Ransing pramodransi...@gmail.com wrote:

  val workers = Vector.fill(10)(system.actorOf(Props[Worker]))
  val router =system.actorOf(Props().withRouter(RoundRobinRouter(workers)))
 
  for( i- 1 to 1000)router ! message
 
   'message' send to all workers(Worker Actor) to process. Now what code 
 should I write so that I will notice workers has finished their work and then 
 I will shutdown router ...
 
 pls give simple demo example ...
 
 Thanks in advance..!!   
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Web: heikoseeberger.de




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is ask an anti-pattern in akka actors?

[Heiko Seeberger]

Actor selection essentially is look up and we all know that look up should not 
be overused. It has it’s purpose though, e.g. when you want to connect to a 
remote system (How would you get an actor ref for a remote actor?). Rule of 
thumb: If you have an actor ref, use it.

Heiko

On 28 May 2014, at 16:31, Filippo De Luca m...@filippodeluca.com wrote:

 ​Hi Heiko,
 So moving forward, is the actor selection a bad practice instead? The 
 temptation to don't pass the actorRef and instead let the actor search for 
 the dependencies is high, but I see difficulties to test and and heavy 
 dependency on the actor system hierarchy.​
 
 Any thoughts on that? Thanks. 
 
 On 28 May 2014 14:41, Heiko Seeberger heiko.seeber...@gmail.com wrote:
 Then your problem is not related to the ask pattern, but using 
 `ActorSelection` instead of `ActorRef`.
 
 
 
 
 -- 
 Filippo De Luca
 -
 WWW: http://filippodeluca.com
 IM:  filosgang...@gmail.com
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Distributed workers question

[Heiko Seeberger]

On 28 May 2014, at 16:17, Eric Nelson eric.nelso...@gmail.com wrote:

 Heiko, that makes sense. I appreciate your reply. I was planning on using an 
 adaptive load balancing router to be smarter about what workers get work. I'm 
 wondering about other possible advantages to the worker pulls work 
 approach. One thing that comes to mind is that I'm constantly pushing work to 
 worker nodes, and the waiting jobs are piling up in the message boxes of the 
 workers. If a worker goes down, then my unprocessed messages are lost. The 
 worker pull mechanism seems safer in that it only takes one job at a time and 
 doesn't request another until it's completed its current task. Could that be 
 another advantage?

Well, in this case the unprocessed messages pile up at the master which can 
also go down. Hence I wouldn't consider that aspect an advantage.

Heiko


 Thanks again for any ideas. 
 
 --Eric
 
 On Tuesday, May 27, 2014 11:16:30 PM UTC-6, Heiko Seeberger wrote:
 Eric,
 
 In your approach, the master is pushing work towards the workers whereas in 
 the other approach the workers are pulling work (technically its still a 
 push, but only after readiness has been signaled). The pull based approach 
 might be advantageous if the work is not evenly distributed, e.g. because 
 some messages need more time to be handled or the worker machines differ 
 largely in capacity.
 
 Hoping this helps.
 
 Heiko
 
 
 On Wed, May 28, 2014 at 12:22 AM, Eric Nelson eric.n...@gmail.com wrote:
 Hi all. I have a question based on the Activator template akka distributed 
 workers. I have already written a system very similar to this one. The main 
 difference is that I don't have the workers register with the master. The 
 master simply uses a cluster-based router to round-robin out work to anyone 
 who is in the cluster with that worker path. This way, I don't have the 
 complexity of having the workers constantly having to send out a registration 
 message, I simply let the cluster router handle it with any worker actor who 
 is currently up and in the cluster.
 
 But I feel like I might be missing something that this registration model 
 provides, that maybe my views on this are too simplistic and there's a good 
 reason for this model. Can anyone help me in understanding what might be the 
 main deficiencies in my approach, and what I would gain by having a 
 registration mechanism from workers to master? (I am using the Cluster 
 Singleton approach for my Master actor, which works very nicely because I 
 only want on master at a time in the cluster, who pull in work from a DB 
 source, and distributes the work out to available worker actors). 
 
 Any help and insight is greatly appreciated. I love Akka and the amazing 
 community behind it.
 
 --Eric
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 
 Heiko Seeberger
 Twitter: @hseeberger
 Blog: blog.heikoseeberger.name
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is ask an anti-pattern in akka actors?

[Heiko Seeberger]

Nothing can ensure that the other actor receives the message, but with actor 
refs you can use death watch (also remote death watch), i.e. you are notified 
if the other actor dies. You can’t watch actor selections.

Heiko


On 28 May 2014, at 17:42, Ketil Johannessen ketil.johanness...@gmail.com 
wrote:

 
 But can you please explain why using an actorref ensures no dead letter, 
 while an actorSelection
 may cause this. Example pseudocode as follows:
 
 Using actorref:
 val ref = context.actorOf(Props(classOf[ChildActor],ChildActor.NAME)
 ref ! test  // --- this is okay
 
 while using actorSelection results sometimes in DeadLetter due to delayed 
 child actor instantiation:
 val ref = context.actorOf(Props(classOf[ChildActor],ChildActor.NAME)
 
 val selection = context.actorSelection(something)
 selection ! test  // -- results in DeadLetter sporadically
 
 
 On Wednesday, May 28, 2014 5:28:43 PM UTC+2, Heiko Seeberger wrote:
 Actor selection essentially is look up and we all know that look up should 
 not be overused. It has it’s purpose though, e.g. when you want to connect to 
 a remote system (How would you get an actor ref for a remote actor?). Rule of 
 thumb: If you have an actor ref, use it.
 
 Heiko
 
 On 28 May 2014, at 16:31, Filippo De Luca m...@filippodeluca.com wrote:
 
 ​Hi Heiko,
 So moving forward, is the actor selection a bad practice instead? The 
 temptation to don't pass the actorRef and instead let the actor search for 
 the dependencies is high, but I see difficulties to test and and heavy 
 dependency on the actor system hierarchy.​
 
 Any thoughts on that? Thanks. 
 
 On 28 May 2014 14:41, Heiko Seeberger heiko.s...@gmail.com wrote:
 Then your problem is not related to the ask pattern, but using 
 `ActorSelection` instead of `ActorRef`.
 
 
 
 
 -- 
 Filippo De Luca
 -
 WWW: http://filippodeluca.com
 IM:  filosg...@gmail.com
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
 
 
 --
 
 Heiko Seeberger
 Twitter: @hseeberger
 Blog: blog.heikoseeberger.name
 
 
 
 
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


--

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name




-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Distributed workers question

[Heiko Seeberger]

On 28 May 2014, at 18:47, Martin Senne martin.se...@googlemail.com wrote:

 doesn't the activator template for distributed workers also use a resilient 
 (and persisted (?)) master to handle failure?
 
I haven't said that it's not possible to make any component (e.g. the master) 
resilient via persistence or other means. What I tried to say was that the pull 
approach alone doesn't result in better fault-tolerance.

Heiko

 cheers, Martin
 
 Am 28.05.2014 17:31 schrieb Heiko Seeberger heiko.seeber...@gmail.com:
 On 28 May 2014, at 16:17, Eric Nelson eric.nelso...@gmail.com wrote:
 
 Heiko, that makes sense. I appreciate your reply. I was planning on using an 
 adaptive load balancing router to be smarter about what workers get work. 
 I'm wondering about other possible advantages to the worker pulls work 
 approach. One thing that comes to mind is that I'm constantly pushing work 
 to worker nodes, and the waiting jobs are piling up in the message boxes of 
 the workers. If a worker goes down, then my unprocessed messages are lost. 
 The worker pull mechanism seems safer in that it only takes one job at a 
 time and doesn't request another until it's completed its current task. 
 Could that be another advantage?
 
 Well, in this case the unprocessed messages pile up at the master which can 
 also go down. Hence I wouldn't consider that aspect an advantage.
 
 Heiko
 
 
 Thanks again for any ideas. 
 
 --Eric
 
 On Tuesday, May 27, 2014 11:16:30 PM UTC-6, Heiko Seeberger wrote:
 Eric,
 
 In your approach, the master is pushing work towards the workers whereas in 
 the other approach the workers are pulling work (technically its still a 
 push, but only after readiness has been signaled). The pull based approach 
 might be advantageous if the work is not evenly distributed, e.g. because 
 some messages need more time to be handled or the worker machines differ 
 largely in capacity.
 
 Hoping this helps.
 
 Heiko
 
 
 On Wed, May 28, 2014 at 12:22 AM, Eric Nelson eric.n...@gmail.com wrote:
 Hi all. I have a question based on the Activator template akka distributed 
 workers. I have already written a system very similar to this one. The main 
 difference is that I don't have the workers register with the master. The 
 master simply uses a cluster-based router to round-robin out work to anyone 
 who is in the cluster with that worker path. This way, I don't have the 
 complexity of having the workers constantly having to send out a 
 registration message, I simply let the cluster router handle it with any 
 worker actor who is currently up and in the cluster.
 
 But I feel like I might be missing something that this registration model 
 provides, that maybe my views on this are too simplistic and there's a good 
 reason for this model. Can anyone help me in understanding what might be the 
 main deficiencies in my approach, and what I would gain by having a 
 registration mechanism from workers to master? (I am using the Cluster 
 Singleton approach for my Master actor, which works very nicely because I 
 only want on master at a time in the cluster, who pull in work from a DB 
 source, and distributes the work out to available worker actors). 
 
 Any help and insight is greatly appreciated. I love Akka and the amazing 
 community behind it.
 
 --Eric
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
 
 
 
 -- 
 
 Heiko Seeberger
 Twitter: @hseeberger
 Blog: blog.heikoseeberger.name
 
 -- 
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.
 
 
 --
 
 Heiko Seeberger
 Twitter: @hseeberger
 Blog: blog.heikoseeberger.name
 
 
 
 
 
 -- 
  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

Re: [akka-user] Distributed workers question

[Heiko Seeberger]

Eric,

In your approach, the master is pushing work towards the workers whereas in
the other approach the workers are pulling work (technically its still a
push, but only after readiness has been signaled). The pull based approach
might be advantageous if the work is not evenly distributed, e.g. because
some messages need more time to be handled or the worker machines differ
largely in capacity.

Hoping this helps.

Heiko


On Wed, May 28, 2014 at 12:22 AM, Eric Nelson eric.nelso...@gmail.comwrote:

 Hi all. I have a question based on the Activator template akka
 distributed workers. I have already written a system very similar to this
 one. The main difference is that I don't have the workers register with the
 master. The master simply uses a cluster-based router to round-robin out
 work to anyone who is in the cluster with that worker path. This way, I
 don't have the complexity of having the workers constantly having to send
 out a registration message, I simply let the cluster router handle it with
 any worker actor who is currently up and in the cluster.

 But I feel like I might be missing something that this registration model
 provides, that maybe my views on this are too simplistic and there's a good
 reason for this model. Can anyone help me in understanding what might be
 the main deficiencies in my approach, and what I would gain by having a
 registration mechanism from workers to master? (I am using the Cluster
 Singleton approach for my Master actor, which works very nicely because I
 only want on master at a time in the cluster, who pull in work from a DB
 source, and distributes the work out to available worker actors).

 Any help and insight is greatly appreciated. I love Akka and the amazing
 community behind it.

 --Eric

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Immutable messages with collections

[Heiko Seeberger]

Akka users,

How do those of you who are using Akka with Java write immutable message
classes with collections?

Thanks
Heiko

-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

://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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 *Dr. Roland Kuhn*
 *Akka Tech Lead*
 Typesafe http://typesafe.com/ – Reactive apps on the JVM.
 twitter: @rolandkuhn
 http://twitter.com/#!/rolandkuhn

  --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka FSM 2.3.2, abstract override and receive method?

[Heiko Seeberger]

`receive` doesn't handle messages, it returns a partial function (type
Receive = PartialFunction[Any, Unit]) which is called for each message.

Therefore you can't delegate to `super` like you did (case x =
super.receive(x)), but you have to chain the two partial functions using
`orElse`.

Heiko



On Sun, May 18, 2014 at 3:04 AM, Eugene Dzhurinsky jdeve...@gmail.comwrote:

 Hello!

 I'm trying to implement some sort of common handling of receive of a
 message for subset of FSM actors. So I've created the trait PullTaskHelper,
 which has the method

   abstract override def receive: Actor.Receive = {
 case WorkerRegistration ⇒
   log.debug(Registering the worker actor {}, sender().path)
   addWorker(sender())
 case GiveMeWork ⇒
   sendTask(sender())
 case Terminated(ref) ⇒
   log.warning(Terminated actor {}, ref)
   removeWorker(ref)
 case x ⇒
   super.receive(x)
   }

 And I'm getting the error






 *Error:(16, 12) overriding method receive in trait PullTask of type =
 akka.actor.Actor.Receive; method receive in trait FSM of type =
 TaskChunkActor.this.Receive needs `abstract override' modifierscase class
 TaskChunkActor(parentActor: ActorRef) extends PullTask with FSM[URLState,
 URLStateData] with ActorLogging {   ^*So it seems that the only
 way to resolve this - is to define some helper method in PullTaskHelper,
 and invoke it directly in the implementations?

 Thanks!

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Get reference to parent actor from childred actors, deployed to the cluster via router

[Heiko Seeberger]

As the setup remains stable, I'd go for (1) with an `ActorRef`.

Heiko


On Fri, May 16, 2014 at 4:41 AM, Eugene Dzhurinsky jdeve...@gmail.comwrote:

 I have rather simple setup - a singleton actor, which takes tasks from
 outside of the cluster. This actor maintains set of worker actors,
 deployed to the cluster via the *consistent-hashing-pool* router - so it
 doesn't have the references to workers directly.

 Now I need to register the worker actors in the singleton in order to
 implement the pooling pattern - so the workers will query singleton for
 more work using ask.

 Inside a worker actor the call to context.parent will return the
 reference to the router, and if a message would be sent to this reference -
 it will not be dispatched to the singleton actor, as far as I learned
 from the docs.

 Now I see at least 2 ways of passing a reference to a singleton actor:

 1) pass the reference to the singleton actor as an argument to the
 constructor of the worker actor. This could be a string with the physical
 address of the singleton of reference - not sure which would work better?

 2) in the broadcast message about a new work awailable include the
 reference to self (not sure how to do it either)

 What is the preferred way to solve such task of passing a reference to the
 singleton actor?

 Thanks!

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Why akka-remote uses netty over akka-tcp for transportation?

[Heiko Seeberger]

Take a look at the Akka Roadmap:
https://docs.google.com/document/d/18W9-fKs55wiFNjXL9q50PYOnR7-nnsImzJqHOPPbM4E/mobilebasic?pli=1hl=en_US

Heiko


On Fri, May 16, 2014 at 4:15 AM, Taehyun Park gold.dest...@gmail.comwrote:

 Hello AKKA team,
 I was wondering why akka-remote uses netty instead of akka-io(tcp).
 Are you guys planning on replacing netty with akka-http in the future?



 Thank you!

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Active restore ClusterShard

[Heiko Seeberger]

Couldn't we add a watchdog feature to Cluster Sharding itself?

Heiko


On Fri, May 16, 2014 at 9:25 AM, Patrik Nordwall
patrik.nordw...@gmail.comwrote:

 Hi Jeroen,


 On Thu, May 15, 2014 at 10:09 PM, Jeroen Gordijn jeroen.gord...@gmail.com
  wrote:

 Hi,

 When rebalancing a Shard, the old shard is stopped and a new shard is
 started on another node, after which all messages for that Shard will be
 send to the new node. When a message is received, the actor will be
 created. When Akka-persistence is used the Actor will reload all its events
 and restore state before processing the new message. But if no message is
 sent, the actor will not be created. This can be problematic when the actor
 is has some active state with retry mechanisme or timeout. Is my
 understanding correct?


 Your reasoning is correct. I think you can implement that by letting the
 actor schedule a keep-alive message to itself, but via the ShardRegion.
 Normally that will be local only message roundtrip via the scheduler and
 local ShardRegion, but after rebalancing it will delegate the message to
 the new node and thereby wake up the actor again.

 What this doesn't solve is when a node crashes. An actor living on that
 node will not be automatically started somewhere else, until a message is
 sent to it. To solve that I think you have to let the actor register itself
 to a a few (for redundancy) watchdog actors, which watch the actor and know
 how to send the wake-up message via ClusterSharding.

 Does that make sense?

 Cheers,
 Patrik



 Is there a way to actively restore the Shard state when the shard is
 moved to another node? One problem I can see with this is when going back
 to less nodes. This means that the shards will be rebalanced, but
 potentially giving memory problems. This will cause rebalancing and memory
 problems on the next node and eventually putting the whole cluster down.
 Starting the cluster will be also problematic for the same reason.

 Cheers,
 Jeroen

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  Reactive apps on the JVM
 Twitter: @patriknw
 JOIN US. REGISTER TODAY! http://www.scaladays.org/
 Scala http://www.scaladays.org/
 Days http://www.scaladays.org/
 June 16th-18th, http://www.scaladays.org/
 Berlin http://www.scaladays.org/

  --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Remote deploy of set of actors in cluster with consistent-hashing-pool

[Heiko Seeberger]

On Thu, May 15, 2014 at 6:17 PM, Eugene Dzhurinsky jdeve...@gmail.comwrote:

 On Thu, May 15, 2014 at 06:11:21PM +0200, Heiko Seeberger wrote:
  Yep, start the router on the chunk node. Pay attention to the path in
 the
  configuration file, it must match the semi-absolute (without /user) path
 of
  your router actor.
 
  Then also remove the unnecessary and confusing routees.paths from the
  config.

 Yeah, it seems to be only necessary for Group routers, so they will know
 where
 to look for the actor.


Yes.


 So, again, the path in config should be provided
 without /user part, correct?


Yes, the path underneath akka.actor.deployment needs to be relative to the
user guardian, i.e. without /user. Slightly inconsistent, but hey, that's
life.


 Also, if another pooled router will be started on another chunk node -
 will it
 create it's own set of routees, or reuse existing ones?


As a pool router creates its own children, the answer is clear. It will
create it's own ones.

Heiko



 Thanks for the prompt answers!

 --
 Eugene N Dzhurinsky




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Setting dispatcher for actor system

[Heiko Seeberger]

default-dispatcher goes underneath akka.actor, not underneath akka.

Heiko


On Wed, May 14, 2014 at 8:32 AM, PVillela pvill...@gmail.com wrote:

 I have been trying to set the dispatcher for an actor system to be used by
 default for actors created with the actor system but I can't get it to
 work.  Specifically, I want to use the
 akka.testkit.CallingThreadDispatcher.  I have tried the following two
 configurations (at the classpath root) but they don't work
 (println(myActorSystem.dispatcher.getClass() still yields
 akka.dispatch.Dispatcher):

 akka {
   loglevel = DEBUG

   default-dispatcher {
 type=akka.testkit.CallingThreadDispatcherConfigurator
   }
 }

 akka {
   loglevel = DEBUG

   default-dispatcher {
 type=akka.test.calling-thread-dispatcher
   }
 }

 I'm using akka 2.10-2.2.3.

 Thanks for any assistance.

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Does akka-persistence demand incorruptible actor state?

[Heiko Seeberger]

You can delete messages from the journal or use an EventSourcedProcessor
which only stores/replays validated commands (messages).

Heiko


On Wed, May 14, 2014 at 10:21 PM, Lawrence Wagerfield 
lawre...@dmz.wagerfield.com wrote:

 Akka documentation highlights that actor state is reset on 
 failurehttp://doc.akka.io/docs/akka/snapshot/general/supervision.html#supervision-directives
  in
 standard actor systems.

 However, an actor powered by Persistent messages will simply have these
 messages replayed and hence will rebuild the same state.

 Does akka-persistence therefore assume we have designed all
 processors/views to have incorruptible internal state?

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Cluster sharding API

[Heiko Seeberger]

Maybe we could have `start` return an `ActorRef` immediately, i.e. an
asynchronous operation like `actorOf`?

Heiko



On Fri, May 9, 2014 at 4:48 PM, Patrik Nordwall
patrik.nordw...@gmail.comwrote:




 On Fri, May 9, 2014 at 4:43 PM, Jeroen Gordijn 
 jeroen.gord...@gmail.comwrote:

 Thanks Patrik, I overlooked that it is blocking, that makes the fix even
 easier. You mention that  you would not do it in the same place and I don't
 have enough experience to comment on that, but in the course it seemed
 perfectly valid to do just that. I created a ticket:
 https://github.com/akka/akka/issues/15157


 Thanks, yes, on second thought I agree. Pass it in to other actors.
 /Patrik



 Cheers,
 Jeroen

 Op vrijdag 9 mei 2014 16:33:07 UTC+2 schreef Patrik Nordwall:

 You should be able to do those calls immediately after each other, from
 same thread.
 ClusterSharding(context.system).start
 ClusterSharding(context.system).shardRegion

 Start doesn't return until it has been initalized.

 Normally, I don't think these two things are done at the same place in
 the code, so I don't think it is much value in returning the ActorRef from
 start, but it would not hurt to do so. Please create a 
 tickethttps://github.com/akka/akka/issues.
 Thanks for reporting.

 Cheers,
 Patrik


 On Fri, May 9, 2014 at 3:48 PM, Jeroen Gordijn jeroen@gmail.comwrote:

 Hi,

 I followed the Advanced akka course in the last 2 days (which was
 awesome by the way) and noticed something of the API which I think can be
 improved. When you start the ClusterSharding its return type is Unit and
 you have to retrieve the ShardRegion by calling the shardRegion on
 ClusterSharding. However, this cannot take place in a short period, because
 shardRegion(...) will 'throw new IllegalArgumentException(sShard
 type [$typeName] must be started first)'.

 In my mind it would be an improvement if the start returns an ActorRef
 immediately and then buffers all requests to it until the ShardRegion is
 initialized. Am I overlooking some problems with that?

 Cheers,
 Jeroen

 -- Start ShardRegion
 ClusterSharding(context.system).start(
 player,
 Some(Player.props),
 Player.idExtractor,
 Player.shardResolver(10)
   )

 -- get reference to ShardRegion
   val playerRegion = ClusterSharding(context.
 system).shardRegion(player)

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  Reactive apps on the JVM
 Twitter: @patriknw
 JOIN US. REGISTER TODAY! http://www.scaladays.org/
 Scala http://www.scaladays.org/
 Days http://www.scaladays.org/
 June 16th-18th, http://www.scaladays.org/
 Berlin http://www.scaladays.org/

   --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




 --

 Patrik Nordwall
 Typesafe http://typesafe.com/ -  Reactive apps on the JVM
 Twitter: @patriknw
 JOIN US. REGISTER TODAY! http://www.scaladays.org/
 Scala http://www.scaladays.org/
 Days http://www.scaladays.org/
 June 16th-18th, http://www.scaladays.org/
 Berlin http://www.scaladays.org/

  --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

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

Re: [akka-user] About actor creation

[Heiko Seeberger]

What exactly do you mean with the 2nd code complains? Could you please
show the exact compilation error? Or are you using IntelliJ and get tricked
by a false red?

Heiko


On Wed, May 7, 2014 at 3:20 PM, Leon Ma tutuf...@gmail.com wrote:

 Hi,

 I have some questions regarding to akka actor creation.(I'm using akka
 2.2.3)

 I'm expecting below 2 statements have same effect: (according to some
 document)

  context.actorOf(Props(classOf[MyClass], myParam))
  context.actorOf(Props(new MyClass(myParam)))


 However, the 2nd code complains about the Props does not have
 corresponding apply method.
 Does that mean I can't create an actor instance by myself?


 Further more, what if I want to do some dynamic mixing when creating my
 actor like this:

 context.actorOf(Props(new MyClass(myParam) with traitA with traitB))


 is it doable?


 Thanks





  --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Starting an FSM in a cluster

[Heiko Seeberger]

On Sun, May 4, 2014 at 6:23 PM, Eugene Dzhurinsky jdeve...@gmail.comwrote:

 On Sun, May 04, 2014 at 09:46:50AM +0200, Heiko Seeberger wrote:
  class MyActor(myParameter: String) extends Actor with FSM { ... }
 
  context.actorOf(Props(new MyActor(myArgument)))

 As far as I understand, this will create an actor on the same host/same
 JVM,
 but I need it to be created in a cluster.


Got it. You still can deploy it remotely in the cluster. Just use
`Cluster.state` to get all member nodes which are up, choose one and get
its `address`, then use `Props.withDeploy(Deploy(scope =
RemoteScope(address)))`.

That's a simple approach. You could also start manager actors on member
nodes and ask one of those to create the actors by sending the `Props`. And
you can take a look into cluster sharding.

Heiko



 --
 Eugene N Dzhurinsky




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

Of course, but if the channel-internal ACK has already arrived, why should
we require another application-level one that might get lost?

Heiko


On Mon, May 5, 2014 at 4:25 PM, Martin Krasser krass...@googlemail.comwrote:


 On 05.05.14 14:59, Heiko Seeberger wrote:

 On the other hand, an application level ACK is an additional message that
 might get lost ...


 The same is true for the channel-internal ACK.


  Heiko


 On Sun, May 4, 2014 at 8:06 PM, Heiko Seeberger heiko.seeber...@gmail.com
  wrote:

 Maybe yes.

  Heiko


 On Sun, May 4, 2014 at 12:57 PM, Martin Krasser 
 krass...@googlemail.comwrote:


 On 04.05.14 11:00, Heiko Seeberger wrote:

  Not all communication follows the request-response pattern. In my case
 there's no need for an application level response, its only purpose is the
 technical ACK.


  Isn't that a special case of request-response?



  Heiko


 On Sun, May 4, 2014 at 10:41 AM, Martin Krasser krass...@googlemail.com
  wrote:

  Maybe a confirm(reply: Any) method would make sense, where reply is
 sent to the sender of the Persistent message. This would also allow for
 some internal optimizations.


 On 04.05.14 10:18, Martin Krasser wrote:


 On 04.05.14 10:07, Heiko Seeberger wrote:

 On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.com
  wrote:

  Hi Heiko,


 On 03.05.14 06:58, Heiko Seeberger wrote:

 Hi,

  A short-lived actor A should send a result message to some other
 actor B before it terminates itself. As it is important that this message
 gets delivered, I would like to use a channel in order to retry message
 delivery. In case of permanent delivery failure (redeliverMax exceeded) 
 the
 short-lived actor A would send the message to some other actor C which
 would know what to do. This can be implemented using a
 redeliverFailureListener.

  My question is: How can the short-lived actor A know that the
 message has been delivered, i.e. the ConfirmablePersistent message has 
 been
 confirmed? AFAIK there's no deliverSuccessListener or such.


  Actor B should send an application-level reply to actor A. Channels
 preserve sender references.


  Well, that's how I have already implemented it without channels. I
 was hoping that channels would make that easier ;-)


 The purpose of a channel is to make delivery of a message from A - B
 more reliable (by implementing a retry-ack protocol where the ack is
 generated by the receiver by calling confirm()) and it shouldn't hide an
 application-level conversation between actors A and B which also includes
 the reply from B to A. You'd also send a reply if A sends a message to B
 without using a channel. Hence, when using a channel, B should confirm
 delivery *in addition* to sending a reply.


  Is it possible to add a feature like a deliverSuccessListener in the
 future?


 It's not a big deal to add that but I'm not sure if it's a good idea
 from a design perspective. Curious what others think ...


  Thanks
 Heiko

   --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz

--
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




  --

  Heiko Seeberger
 Twitter: @hseeberger
 Blog: blog.heikoseeberger.name
  --
  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

Re: [akka-user] Re: Starting an FSM in a cluster

[Heiko Seeberger]

On Sun, May 4, 2014 at 3:22 AM, Eugene Dzhurinsky jdeve...@gmail.comwrote:


Okay, fine. My question was related to how to create an instance of FSM
 actor,
 which accepts parameters in it's constructor, however thinking carefully I
 think that it's quite possible to pass the initialization stuff in a
 message.


```
class MyActor(myParameter: String) extends Actor with FSM { ... }

context.actorOf(Props(new MyActor(myArgument)))
```

Does that make sense?

Heiko




 Thank you for the explanation!

 --
 Eugene N Dzhurinsky




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.comwrote:

  Hi Heiko,


 On 03.05.14 06:58, Heiko Seeberger wrote:

 Hi,

  A short-lived actor A should send a result message to some other actor
 B before it terminates itself. As it is important that this message gets
 delivered, I would like to use a channel in order to retry message
 delivery. In case of permanent delivery failure (redeliverMax exceeded) the
 short-lived actor A would send the message to some other actor C which
 would know what to do. This can be implemented using a
 redeliverFailureListener.

  My question is: How can the short-lived actor A know that the message
 has been delivered, i.e. the ConfirmablePersistent message has been
 confirmed? AFAIK there's no deliverSuccessListener or such.


 Actor B should send an application-level reply to actor A. Channels
 preserve sender references.


Well, that's how I have already implemented it without channels. I was
hoping that channels would make that easier ;-)

Is it possible to add a feature like a deliverSuccessListener in the future?

Thanks
Heiko

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

Not all communication follows the request-response pattern. In my case
there's no need for an application level response, its only purpose is the
technical ACK.

Heiko


On Sun, May 4, 2014 at 10:41 AM, Martin Krasser krass...@googlemail.comwrote:

  Maybe a confirm(reply: Any) method would make sense, where reply is sent
 to the sender of the Persistent message. This would also allow for some
 internal optimizations.


 On 04.05.14 10:18, Martin Krasser wrote:


 On 04.05.14 10:07, Heiko Seeberger wrote:

 On Sun, May 4, 2014 at 9:55 AM, Martin Krasser krass...@googlemail.comwrote:

  Hi Heiko,


 On 03.05.14 06:58, Heiko Seeberger wrote:

 Hi,

  A short-lived actor A should send a result message to some other
 actor B before it terminates itself. As it is important that this message
 gets delivered, I would like to use a channel in order to retry message
 delivery. In case of permanent delivery failure (redeliverMax exceeded) the
 short-lived actor A would send the message to some other actor C which
 would know what to do. This can be implemented using a
 redeliverFailureListener.

  My question is: How can the short-lived actor A know that the message
 has been delivered, i.e. the ConfirmablePersistent message has been
 confirmed? AFAIK there's no deliverSuccessListener or such.


  Actor B should send an application-level reply to actor A. Channels
 preserve sender references.


  Well, that's how I have already implemented it without channels. I was
 hoping that channels would make that easier ;-)


 The purpose of a channel is to make delivery of a message from A - B more
 reliable (by implementing a retry-ack protocol where the ack is generated
 by the receiver by calling confirm()) and it shouldn't hide an
 application-level conversation between actors A and B which also includes
 the reply from B to A. You'd also send a reply if A sends a message to B
 without using a channel. Hence, when using a channel, B should confirm
 delivery *in addition* to sending a reply.


  Is it possible to add a feature like a deliverSuccessListener in the
 future?


 It's not a big deal to add that but I'm not sure if it's a good idea from
 a design perspective. Curious what others think ...


  Thanks
 Heiko

   --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz

  --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

Maybe yes.

Heiko


On Sun, May 4, 2014 at 12:57 PM, Martin Krasser krass...@googlemail.comwrote:


 On 04.05.14 11:00, Heiko Seeberger wrote:

  Not all communication follows the request-response pattern. In my case
 there's no need for an application level response, its only purpose is the
 technical ACK.


 Isn't that a special case of request-response?



  Heiko


 On Sun, May 4, 2014 at 10:41 AM, Martin Krasser 
 krass...@googlemail.comwrote:

  Maybe a confirm(reply: Any) method would make sense, where reply is sent
 to the sender of the Persistent message. This would also allow for some
 internal optimizations.


 On 04.05.14 10:18, Martin Krasser wrote:


 On 04.05.14 10:07, Heiko Seeberger wrote:

 On Sun, May 4, 2014 at 9:55 AM, Martin Krasser 
 krass...@googlemail.comwrote:

  Hi Heiko,


 On 03.05.14 06:58, Heiko Seeberger wrote:

 Hi,

  A short-lived actor A should send a result message to some other
 actor B before it terminates itself. As it is important that this message
 gets delivered, I would like to use a channel in order to retry message
 delivery. In case of permanent delivery failure (redeliverMax exceeded) the
 short-lived actor A would send the message to some other actor C which
 would know what to do. This can be implemented using a
 redeliverFailureListener.

  My question is: How can the short-lived actor A know that the message
 has been delivered, i.e. the ConfirmablePersistent message has been
 confirmed? AFAIK there's no deliverSuccessListener or such.


  Actor B should send an application-level reply to actor A. Channels
 preserve sender references.


  Well, that's how I have already implemented it without channels. I was
 hoping that channels would make that easier ;-)


 The purpose of a channel is to make delivery of a message from A - B
 more reliable (by implementing a retry-ack protocol where the ack is
 generated by the receiver by calling confirm()) and it shouldn't hide an
 application-level conversation between actors A and B which also includes
 the reply from B to A. You'd also send a reply if A sends a message to B
 without using a channel. Hence, when using a channel, B should confirm
 delivery *in addition* to sending a reply.


  Is it possible to add a feature like a deliverSuccessListener in the
 future?


 It's not a big deal to add that but I'm not sure if it's a good idea from
 a design perspective. Curious what others think ...


  Thanks
 Heiko

   --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz

--
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




  --

  Heiko Seeberger
 Twitter: @hseeberger
 Blog: blog.heikoseeberger.name
  --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.


 --
 Martin Krasser

 blog:http://krasserm.blogspot.com
 code:http://github.com/krasserm
 twitter: http://twitter.com/mrt1nz

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

[akka-user] How can the sender know that a message has been delivered (confirmed) by a channel?

[Heiko Seeberger]

Hi,

A short-lived actor A should send a result message to some other actor B
before it terminates itself. As it is important that this message gets
delivered, I would like to use a channel in order to retry message
delivery. In case of permanent delivery failure (redeliverMax exceeded) the
short-lived actor A would send the message to some other actor C which
would know what to do. This can be implemented using a
redeliverFailureListener.

My question is: How can the short-lived actor A know that the message has
been delivered, i.e. the ConfirmablePersistent message has been confirmed?
AFAIK there's no deliverSuccessListener or such.

Thanks
Heiko

-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Membership in multiple clusters?

[Heiko Seeberger]

I don't think so, but you could use the Cluster Client to easily talk from
one cluster (or some Akka system) to the other.

Heiko


On Fri, May 2, 2014 at 6:05 AM, tigerfoot gzol...@gmail.com wrote:

 Can a node be configured to belong to multiple (2) Akka clusters at the
 same time?

 I want to have one cluster of private back-channel communication and a
 second (possibly with different/overlapping membership) for
 public/application-level communication.

 --
  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 http://groups.google.com/group/akka-user.
 For more options, visit https://groups.google.com/d/optout.




-- 

Heiko Seeberger
Twitter: @hseeberger
Blog: blog.heikoseeberger.name

-- 
  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.