Re: [akka-user] Re: Inconsistent behavior of ClusterClient.Send (akka 2.3.2) ?

[Eugene Dzhurinsky]

On Fri, May 23, 2014 at 04:44:42PM +0200, Martynas Mickevičius wrote:
> So I think this could be a bug. Could you register an issue with a
> preferably multi-node test which catches this?

Hi, Martynas!

Thanks for confirming that this is not something local to my environment. I've
created the issue at https://github.com/akka/akka/issues/15285 

Also I've created the vanilla test project, which demonstrates the issue
clearly:

https://github.com/jdevelop/akka-cluster-test

Not as fancy as multi-node test case (I didn't manage to familiarize myself
with SBT, so Maven, sorry) - but hope that everything is more or less
reasonable.

Thanks again!
-- 
Eugene N Dzhurinsky


pgpnIfB3AmPoM.pgp
Description: PGP signature

Re: [akka-user] Using ActorSelection to check if actor exists

[Tony Bones]

Ok, thank you.  This was the same feedback I got from my post on the Play 
group too.  I'll give it a try.


On Thursday, May 8, 2014 10:36:26 PM UTC-7, rkuhn wrote:
>
> Hi Tony,
>
> that might work most of the time ;-) The problem is that the actor’s 
> liveness might easily change between your Identify and the tell or actorOf 
> call. A better approach is to create one supervisor for this type of job 
> that always exists; keep the reference to that one in a Play 
> Plugin
>   
> Then you just send off work to that one, which will process them one by 
> one, enabling it to consistently check its list of child actors 
> (getContext().getChild(name)) and create missing ones if needed 
> (getContext().actorOf()).
>
> Regards,
>
> Roland
>
> 8 maj 2014 kl. 23:28 skrev Tony Bones >:
>
> Ok, so I've been struggling with this same issue for a few days now.  I've 
> used uni-directional Akka actors from Play 2.2.2 to start some background 
> tasks that just blindly run.  This is the first time I had a need to do 
> something more complex and while the docs are very abundant I couldn't make 
> sense of a lot of it since I don't really know Scala too well.
>
> I've done some searching around and it seems there are a few posts on this 
> topic.  So here is my solution to the problem.  Please review and let me 
> know if it looks good or if I'm doing something completely crazy wrong. 
>  It's the result of reading 50 different forums, groups, mailing list, and 
> issue tracker posts...and of course official documentation.
>
> From Play 2.2.2 for Java Controller
>
>> public static Result invite( String id ) {
>>
>> // akka actor
>> ActorRef ref = null;
>> 
>> // selection path
>> String actorId = "InviteSupervisor-" + id;
>> String path = "/user/" + actorId;
>> ActorSelection sel = Akka.system().actorSelection(path);
>>
>> // ask to identify
>> Timeout t = new Timeout(3000);
>> AskableActorSelection asker = new AskableActorSelection(sel);
>> Future fut = asker.ask(new Identify(id), t);
>> ActorIdentity ident;
>> try {
>> // wait results
>> ident = (ActorIdentity)Await.result(fut, t.duration());
>> ref = ident.getRef();
>> } catch (Exception e) {
>> Logger.error(TAG + e.getMessage(), e);
>>
>> // TODO handle timeout or other errors 
>
> return badRequest("Selection Error");
>
> }
>>
>> // actor exist or not
>> if ( ref == null ) {
>> // start new actor
>>
>> // kick off process queue
>> ref = Akka.system().actorOf(InviteSupervisor.props(id), actorId);
>>
>> // start invite import process
>> ref.tell(new InviteSupervisor.ImportMessage(id), ActorRef.noSender());
>> return ok( "Actor not found :(  but one was created :) " + 
>> ref.path().toString() );
>> } else {
>> // already running, get progress
>>
>> String status = "";
>>
>> // get progress
>> Future futProg = asker.ask(new 
>> InviteSupervisor.ProgressMessage(null), t);
>> try {
>> // wait results
>> InviteSupervisor.ProgressMessage msg = 
>> (InviteSupervisor.ProgressMessage)Await.result(futProg, t.duration());
>> status = msg.getProgress().toString();
>>
>> } catch (Exception e) {
>> Logger.error(TAG + e.getMessage(), e);
>>
>> // TODO handle timeout or other errors
>> }
>>
>> return ok( "Actor Found! " + ref.path().toString() + " [" + status + "]");
>> }
>>
>> }
>
>
>
> This looks for an actor instance by id on the selection path.  If not 
> found, it creates the actor.  If found it ask the actor for its progress. 
>  Hitting this same URL multiple times gives the results I was looking for.  
>
> The Actor side doesn't do anything special since I'm putting the id in the 
> path.  It never receives the Identify/ActorIndentity message, I guess its 
> handled by the actor system or something internal?
>
> It might be better to wrap some of this in a Play Promise and return that. 
>  Get ride of the asker future timeout as well.  But I'm wondering if I'm 
> interacting with Akka selection paths correctly here.  How's it look?
>
> -Tony
>
>
>
>
> On Friday, April 11, 2014 1:30:12 AM UTC-7, Martynas Mickevičius wrote:
>>
>> Try googling for some code snippets: 
>> http://lmgtfy.com/?q=akka+ActorIdentity
>>
>> Some results:
>> http://stackoverflow.com/a/18015626/77102
>>
>> http://letitcrash.com/post/55504766698/2-2-spotlight-actorselection-watch-and-identify
>>
>>
>> On Fri, Apr 11, 2014 at 6:52 AM, Atom Cong  wrote:
>>
>>> Hi, Heiko, 
>>>
>>>  Thanks a lot for the response.I saw that in the manual (java 
>>> though, 
>>> http://doc.akka.io/docs/akka/2.3.2/java/untyped-actors.html#actorselection-java),
>>>  
>>> but couldn't understand what exactly is happening.  The sample code of 
>>> class "Follower" does not have any comment, and does not seem match to the 
>>> description above. 
>>>
>>> For example, the text description says "use the getSender() 
>>> reference blah blah", but I don't see getSender() being c

[akka-user] akka-remote (non-clustered) quarantines and general best practices

[Steven Scott]

I've been slowly migrating an application to Akka since scala 2.10 came out 
and pushed me away from scala actors; sorry for any stupid questions as I'm 
always learning.

As a general picture, the application consists of multiple long-lived JVMs 
communicating over ActiveMQ. The standard deployment is to a single 
machine, but with multiple services communicating over AMQ for the ability 
to move specific pieces of functionality to other boxes. As the migration 
and component rewrites have progressed, I'm solely left with actors 
communicating with each other over AMQ using akka-camel. The natural next 
step was to explore akka-remote.

My questions started out as "is this an abuse/unintended usage of 
akka-remote? Is akka-remote meant to be used outside of akka-cluster? Is it 
useful for communicating to local JVMs? What about network hiccups for 
remote JVMs?"

I did as much reading as I could and found that Victor Klang has said it's 
useful for transient 
networks: 
http://stackoverflow.com/questions/6401500/is-akka-suitable-for-systems-with-transient-network-coverage,
 
and the smoking gun for same-machine inter-JVM communication being an 
expected use-case was Dr. Kuhn's comment 
here: 
http://stackoverflow.com/questions/10268613/whats-the-equivalent-of-akka/11787971#comment13246146_10268748

I went ahead and implemented a decent amount of code for using akka-remote 
to talk to one of the services after bumping our akka version to 2.3.3, and 
have to say I'm pleased, especially when comparing to ActiveMQ. Local 
machine communication is flawless, but once I started testing with remote 
machines and doing "ifdown eth0; sleep 20; ifup eth0" network disruption 
tests, I'm left with questions about how to handle quarantines. I looked at 
reference.conf and heeded the admonition to NOT change the quarantine 
timeout from 5 days - restarting one of the actor systems is the only 
alternative.

So - what're the best practices concerning restarting the ActorSystem? 

 - I'm not clustering - these are a few long-lived "heavy" services, not 
just nodes spinning up to do small processing tasks
 - Our general deployment is not HA, we don't usually have standbys waiting
 - Restarting the JVM isn't optimal
   * since the services are fairly substantial and there's a non-trivial 
amount of initialization including database hits to pre-fill caches, 
restarting the JVM is a possibility (less time than the remoting gate 
time), but isn't the first route I'd choose
   * we (very rarely) run on non-linux platforms and so tend to try to keep 
stuff in the JVM instead of relying on upstart/launchd/windows services/etc

My only other thought is to run an additional ActorSystem for remoting.

 - allows programmatic configuration (our runtime configuration system 
could change remoting settings and restart the remoting ActorSystem with 
the new settings)
 - a quarantine situation would just require the remoting ActorSystem to be 
recreated, not a restart of the whole JVM

However, one of the very earliest entries in the Akka documentation states "An 
ActorSystem is a heavyweight structure that will allocate 1…N Threads, so 
create one per logical application." I know creating multiple dispatchers 
in the same ActorSystem is fine, and sometimes (at least historically) a 
dedicated dispatcher was recommended for some remoting cases; I also know 
starting a new ActorSystem takes some amount of time to create dispatchers, 
parse configs, etc; so I'm thinking that the big yellow warning in the 
documentation is a general guideline for getting started with Akka, not a 
hard and fast rule.

Sorry for the long post, can anybody give me some guidance on the situation?

-- 
>>  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] Questions/Problems/Bugs Using Akka?

[Steve Ramage]

Done (https://github.com/akka/akka/issues/15284)



On Friday, 23 May 2014 11:54:01 UTC-7, Patrik Nordwall wrote:
>
> Ah, that is interesting, I think we have missed an annotation here, please 
> open a ticket.
>
> /Patrik
>
> 23 maj 2014 kl. 20:12 skrev Martynas Mickevičius <
> martynas.m...@typesafe.com >:
>
> Scala does not have checked exceptions. That is why Java compiler cannot 
> help you when calling a Scala method which throws a checked exception in 
> Java.
>
>
> On Fri, May 23, 2014 at 7:47 PM, Steve Ramage 
> > wrote:
>
>> Thank you for your response.
>>
>> AKKAs place in this application is to manage the concurrency involved in 
>> distributing tasks to workers, and processing them, etc... The 
>> implementation of the interface requires multi-threaded operation, and 
>> refactoring the interface introduces a huge burden on basically ever client 
>> of the library. It's also unlikely that they would be willing to adopt the 
>> actor model whole heartedly. Consequently I do have a general problem of 
>> needing to read inboxes from threads, although in this particular instance 
>> I could probably move it back into the Actor that is populating the inbox. 
>> I will look at the article you presented, but I guess the one question that 
>> is still open. Shouldn't inbox.receive() be declared to throw 
>> TimeoutException given that it is in fact throwing it.
>>
>> Steve Ramage
>>
>>
>>
>>
>> On Friday, 23 May 2014 06:29:17 UTC-7, Martynas Mickevičius wrote:
>>
>>> Hello Steve,
>>>
>>> it seems that you are using 
>>> ActorD*sl*. 
>>> It is meant to be used mostly for trying things out in the REPL. I would 
>>> suggest re-factoring your application to separate actors and letting Akka 
>>> do the concurrency management. In that case you should get rid of Runnable 
>>> I see in your example and move it to actor.
>>>
>>> Have you seen this 
>>> article,
>>>  
>>> which discuses some of the shutdown patterns?
>>>
>>>
>>>  On Wed, May 21, 2014 at 9:09 PM, Steve Ramage  wrote:
>>>
  Hello,

 I'm new to Akka, and to provide some context to my question I will 
 provide some background to the problem I'm actually trying to solve. I 
 have 
 only read a few chapters of the Akka manual, but have started implementing 
 anyway since I need to get my hands dirty, and so no doubt do not a firm 
 understanding of Akka principles and concepts. Essentially I have written 
 a 
 library for use in my narrow field of scientific research, and central to 
 it is the following interface (everything is in Java 7, and this is 
 slightly simplified):

 interface TargetAlgorithmEvaluator
 {
/** 
* Do the task descriptions, and when complete notify the onSuccess() 
 or onFailure() method of the callback
*/
public void evaluateTaskAsync(List t, Callback c);
/**
* Shutdown any resources associated with this 
 TargetAlgorithmEvaluator
*/
public void notifyShutdown();
 }

 A task in this case is roughly running a program and getting some 
 results, and there are a bunch of ways you can do it. The tasks come from 
 a 
 very specific domain, and aren't general at all. The first and default way 
 is locally, via the command line. So of course there is an implementation 
 of this that just executes the tasks on the command line, and then gets 
 the 
 results. Sometimes we want to do 'lots' of these executions and so it 
 makes 
 sense to distribute them, and so another one exists that actually uses 
 MySQL and has workers poll from the SQL database, and this works very 
 well. 
 Unfortunately for releasing our tools built with this library, the 
 requirement that users have a tuned MySQL server around is limiting, so we 
 would like some other distributed mechanism and hence Akka. Unlike what I 
 imagine are standard Akka use cases, these distributions are incredibly 
 transient, they just are scheduled on some shared cluster, work together 
 for a while and are terminated. There is no stable or perpetual 
 deployment. 
 It's just a master / slave architecture.  The way this currently works in 
 Akka is that the master job spins up, creates an actor system that is 
 listening for other actors. When other actors on other systems come 
 online, 
 it will dispatch the tasks to them. The workers will then use the Command 
 line implementation locally before giving the result back via Akka to the 
 master.

 One problem I'm currently having is implementing the notifyShutdown() 
 method. This method needs to shutdown all the thread pools and the actor 
 system etc. One thread in this listens to a specific inbox for completion 
 results, and then dispatches cal

Re: [akka-user] Questions/Problems/Bugs Using Akka?

[Patrik Nordwall]

Ah, that is interesting, I think we have missed an annotation here, please open 
a ticket.

/Patrik

> 23 maj 2014 kl. 20:12 skrev Martynas Mickevičius 
> :
> 
> Scala does not have checked exceptions. That is why Java compiler cannot help 
> you when calling a Scala method which throws a checked exception in Java.
> 
> 
>> On Fri, May 23, 2014 at 7:47 PM, Steve Ramage  wrote:
>> Thank you for your response.
>> 
>> AKKAs place in this application is to manage the concurrency involved in 
>> distributing tasks to workers, and processing them, etc... The 
>> implementation of the interface requires multi-threaded operation, and 
>> refactoring the interface introduces a huge burden on basically ever client 
>> of the library. It's also unlikely that they would be willing to adopt the 
>> actor model whole heartedly. Consequently I do have a general problem of 
>> needing to read inboxes from threads, although in this particular instance I 
>> could probably move it back into the Actor that is populating the inbox. I 
>> will look at the article you presented, but I guess the one question that is 
>> still open. Shouldn't inbox.receive() be declared to throw TimeoutException 
>> given that it is in fact throwing it.
>> 
>> Steve Ramage
>> 
>> 
>> 
>> 
>>> On Friday, 23 May 2014 06:29:17 UTC-7, Martynas Mickevičius wrote:
>>> Hello Steve,
>>> 
>>> it seems that you are using ActorDsl. It is meant to be used mostly for 
>>> trying things out in the REPL. I would suggest re-factoring your 
>>> application to separate actors and letting Akka do the concurrency 
>>> management. In that case you should get rid of Runnable I see in your 
>>> example and move it to actor.
>>> 
>>> Have you seen this article, which discuses some of the shutdown patterns?
>>> 
>>> 
 On Wed, May 21, 2014 at 9:09 PM, Steve Ramage  wrote:
 Hello,
 
 I'm new to Akka, and to provide some context to my question I will provide 
 some background to the problem I'm actually trying to solve. I have only 
 read a few chapters of the Akka manual, but have started implementing 
 anyway since I need to get my hands dirty, and so no doubt do not a firm 
 understanding of Akka principles and concepts. Essentially I have written 
 a library for use in my narrow field of scientific research, and central 
 to it is the following interface (everything is in Java 7, and this is 
 slightly simplified):
 
 interface TargetAlgorithmEvaluator
 {
/** 
* Do the task descriptions, and when complete notify the onSuccess() or 
 onFailure() method of the callback
*/
public void evaluateTaskAsync(List t, Callback c);
/**
* Shutdown any resources associated with this TargetAlgorithmEvaluator
*/
public void notifyShutdown();
 }
 
 A task in this case is roughly running a program and getting some results, 
 and there are a bunch of ways you can do it. The tasks come from a very 
 specific domain, and aren't general at all. The first and default way is 
 locally, via the command line. So of course there is an implementation of 
 this that just executes the tasks on the command line, and then gets the 
 results. Sometimes we want to do 'lots' of these executions and so it 
 makes sense to distribute them, and so another one exists that actually 
 uses MySQL and has workers poll from the SQL database, and this works very 
 well. Unfortunately for releasing our tools built with this library, the 
 requirement that users have a tuned MySQL server around is limiting, so we 
 would like some other distributed mechanism and hence Akka. Unlike what I 
 imagine are standard Akka use cases, these distributions are incredibly 
 transient, they just are scheduled on some shared cluster, work together 
 for a while and are terminated. There is no stable or perpetual 
 deployment. It's just a master / slave architecture.  The way this 
 currently works in Akka is that the master job spins up, creates an actor 
 system that is listening for other actors. When other actors on other 
 systems come online, it will dispatch the tasks to them. The workers will 
 then use the Command line implementation locally before giving the result 
 back via Akka to the master.
 
 One problem I'm currently having is implementing the notifyShutdown() 
 method. This method needs to shutdown all the thread pools and the actor 
 system etc. One thread in this listens to a specific inbox for completion 
 results, and then dispatches calls to the callback in another thread. 
 
 The code looks like the following:
 
 Runnable run = new Runnable()
 {
   @Override
   public void run() {

while(!Thread.interrupted() && !stopProcessingInbox.get())
{
  Object o = null;

  try {
Stri

Re: [akka-user] Re: TestKit and absolute actor path path

[Martynas Mickevičius]

There has been discussion about this a while
ago
.

Basically you need to have a way to inject either ActorRef or path for
actor selection. Then you can change these in tests accordingly.


On Fri, May 23, 2014 at 2:12 AM, Edward Sargisson  wrote:

> Well, in my case, I'm creating TestProbes and passing them into the actor
> under test so that I can verify what it does with them.
> For example, I have one class which communicates with 3 other actors and I
> mock out all of them with TestProbes.
>
> However, it does feel like a lot of work which is a clue I may be not
> doing this the best way.
>
> Cheers,
> Edward
>
>
> On Thu, May 22, 2014 at 2:48 PM, Filippo De Luca 
> wrote:
>
>> Hi Edward,
>> In that case it is easy: When an actor need to start a child, I'll pass a
>> Props instance for that actor. So that the actor will be supervised by the
>> parent but the dependencies of the constructor for the child are hidden.
>>
>> ex:
>> class ParentActor(childProps: Props) {
>>
>>val child = context.actorOf(childProps.withRouter(...), "child")
>>
>>...
>> }
>>
>> object ParentActor {
>>
>>   def props(childProps: Props) = Props(classOf[ParentActor], childProps)
>>
>> }
>>
>> class ChildActor(mailServer: MailServer, ) {
>>
>>   
>> }
>>
>> object ChildActor {
>>
>>   def props(mailServer: MailServer, ) = Props(classOf[ChildActor],
>> mailServer, )
>>
>> }
>>
>> val childProps = ChildActor.props(mailServer, )
>>
>> 
>>
>> val toTest = system.actorOf(ParentActor.props(childProps), "parent")
>>
>>
>>
>>
>> On 22 May 2014 21:48, Edward Sargisson  wrote:
>>
>>> I'd love to hear the answer to this too!
>>> I've solved the problem by injecting actorRefs but it does seem to lose
>>> the point of actor supervision.
>>> The other technique I've tried in one spot is to use the TestActorRef to
>>> get the underlyingActor and then set the actorRef on that. This means that
>>> actor construction can do things normally - and then I override it.
>>>
>>> Cheers,
>>> Edward
>>>
>>>
>>> On Thursday, May 22, 2014 3:30:10 AM UTC-7, Filippo De Luca wrote:
>>>
 Hi Guys,
 I am wondering if is it possible to use a probe to test an actor that
 reference the other actor by actor path.

 For example it can use actorFor("/user/foo/bar") or
 actorFor("../my-sibling-actor") is there a way to inject a probe
 inside the actor-system.

 This bring to my mind another question, is it a good practice to
 reference an actor by the path, or is better to pass the actorRef as
 parameter when possible?

 Thanks for your help.
 --
 *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+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.
>>>
>>
>>
>>
>> --
>> *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 a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/v0SZ6C9l4uQ/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/

Re: [akka-user] [akka-streams]: actor producers, load balancers

[Adam Warski]

>
>
>> Which generates an `Actor` backed producer for you (that will call your 
>> function), or if you need complete control you can implement a 
>> `Producer[T]` and give it to `Flow`:
>>
>
> I don't think that is enough. It assumes that the elements are available 
> when calling the closure, otherwise blocking will happen. We have one 
> ticket  for creating a 
> producer from a closure that returns a future. I think we should have 
> support for a producer that is an actor also.
> Stay tuned.
>

Right, I was thinking about a Future-based producer initially as well (I 
could then use ? to get the data from the actor), but then I thought it 
would be actually more efficient if I knew how many elements I can produce 
in the actor.

Adam 

-- 
>>  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-streams]: actor producers, load balancers

[Adam Warski]

On Friday, May 23, 2014 4:57:32 PM UTC+2, Konrad Malawski wrote:
>
> Cześć Adam :-)
>
>
> - is it reasonable (thinking about reactive streams in general) to have an 
> actor which produces elements on-demand (instead of providing a 
> collection/iterator/() => as is currently supported)? As far as I 
> understand the current implementation, subscribers explicitly ask 
> publishers for more elements (through Subscription.requestMore) - so it 
> seems it would be possible to pass such a request to an actor and ask for 
> the given amount of elements. Is there any chance to get "actor producers" 
> in some future releases, or there are no such plans currently?
>
> Yes, definitely! We currently do support it (on release-2.3*-dev*, it’s 
> pretty new) via:
>
> ```
> /**
>* Define the sequence of elements to be produced by the given closure.
>* The stream ends normally when evaluation of the closure results in
>* a [[akka.stream.Stop]] exception being thrown; it ends exceptionally
>* when any other exception is thrown.
>*/
>   def apply[T](f: () ⇒ T): Flow[T]
> ```
>
> Which generates an `Actor` backed producer for you (that will call your 
> function), or if you need complete control you can implement a 
> `Producer[T]` and give it to `Flow`:
>

Is it in the "spirit" of akka-stream/reactive streams to implement your own 
producers? Or should all producers (publishers) be created by the framework?
 

> *Disclaimer*
> Please note that the spec ( 
> https://github.com/reactive-streams/reactive-streams ) is under heavy 
> discussions and development at this moment.
> Our current impl is still targeting the previous version, differences 
> include for example dropping the Producer interface in favour of only 
> keeping `Publisher` etc.
>

Ah, good to know, I was trying to understand today what is exactly the 
difference between Producer and Publisher and why do you need that 
distinction ;)
 

> - another thing is if the streams are thought to be more local, or remote 
> as well? There's currently the TCP stream implementation, which I guess 
> would indicate remote as well (and in such scenarios the need for 
> backpressure arises quite naturally, maybe even more than in locally), but 
> do you plan to develop this somehow? E.g. when there would be multiple 
> consumers for a single producer, a useful component would be a 
> load-balancer which takes into account the backpressure information. 
>
>  
> We’re currently focused on in-jvm implementations, though 
> multi-language-and-runtime are definitely on the reactive-streams’ radar: 
> https://github.com/reactive-streams/reactive-streams/issues/45
> Let’s first nail the in-vm implementation to then move on to the bigger 
> picture (personal opinion here), but there’s so many people involved and 
> loads of excitement around it, so we’ll see ;-)
>

Sure, it's good to focus on one goal initially, thought the initial 
akka-streams does contain TCP based streams, which is an open invitation to 
use it ;)
 

> As for Akka, we’re currently mostly focused on getting akka-http (which 
> will be stream based) out of the door, and optimise it, the rest comes next.
>

stream-based as in reactive-stream-based?
 

> I hope this helps!
> // So... what Producer are you implementing? :-)
>

Just playing around ... to rule the world, as always ;)

Adam 

-- 
>>  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] Questions/Problems/Bugs Using Akka?

[Martynas Mickevičius]

Scala does not have checked exceptions. That is why Java compiler cannot
help you when calling a Scala method which throws a checked exception in
Java.


On Fri, May 23, 2014 at 7:47 PM, Steve Ramage  wrote:

> Thank you for your response.
>
> AKKAs place in this application is to manage the concurrency involved in
> distributing tasks to workers, and processing them, etc... The
> implementation of the interface requires multi-threaded operation, and
> refactoring the interface introduces a huge burden on basically ever client
> of the library. It's also unlikely that they would be willing to adopt the
> actor model whole heartedly. Consequently I do have a general problem of
> needing to read inboxes from threads, although in this particular instance
> I could probably move it back into the Actor that is populating the inbox.
> I will look at the article you presented, but I guess the one question that
> is still open. Shouldn't inbox.receive() be declared to throw
> TimeoutException given that it is in fact throwing it.
>
> Steve Ramage
>
>
>
>
> On Friday, 23 May 2014 06:29:17 UTC-7, Martynas Mickevičius wrote:
>
>> Hello Steve,
>>
>> it seems that you are using 
>> ActorD*sl*.
>> It is meant to be used mostly for trying things out in the REPL. I would
>> suggest re-factoring your application to separate actors and letting Akka
>> do the concurrency management. In that case you should get rid of Runnable
>> I see in your example and move it to actor.
>>
>> Have you seen this 
>> article,
>> which discuses some of the shutdown patterns?
>>
>>
>> On Wed, May 21, 2014 at 9:09 PM, Steve Ramage  wrote:
>>
>>> Hello,
>>>
>>> I'm new to Akka, and to provide some context to my question I will
>>> provide some background to the problem I'm actually trying to solve. I have
>>> only read a few chapters of the Akka manual, but have started implementing
>>> anyway since I need to get my hands dirty, and so no doubt do not a firm
>>> understanding of Akka principles and concepts. Essentially I have written a
>>> library for use in my narrow field of scientific research, and central to
>>> it is the following interface (everything is in Java 7, and this is
>>> slightly simplified):
>>>
>>> interface TargetAlgorithmEvaluator
>>> {
>>>/**
>>>* Do the task descriptions, and when complete notify the onSuccess()
>>> or onFailure() method of the callback
>>>*/
>>>public void evaluateTaskAsync(List t, Callback c);
>>>/**
>>>* Shutdown any resources associated with this TargetAlgorithmEvaluator
>>>*/
>>>public void notifyShutdown();
>>> }
>>>
>>> A task in this case is roughly running a program and getting some
>>> results, and there are a bunch of ways you can do it. The tasks come from a
>>> very specific domain, and aren't general at all. The first and default way
>>> is locally, via the command line. So of course there is an implementation
>>> of this that just executes the tasks on the command line, and then gets the
>>> results. Sometimes we want to do 'lots' of these executions and so it makes
>>> sense to distribute them, and so another one exists that actually uses
>>> MySQL and has workers poll from the SQL database, and this works very well.
>>> Unfortunately for releasing our tools built with this library, the
>>> requirement that users have a tuned MySQL server around is limiting, so we
>>> would like some other distributed mechanism and hence Akka. Unlike what I
>>> imagine are standard Akka use cases, these distributions are incredibly
>>> transient, they just are scheduled on some shared cluster, work together
>>> for a while and are terminated. There is no stable or perpetual deployment.
>>> It's just a master / slave architecture.  The way this currently works in
>>> Akka is that the master job spins up, creates an actor system that is
>>> listening for other actors. When other actors on other systems come online,
>>> it will dispatch the tasks to them. The workers will then use the Command
>>> line implementation locally before giving the result back via Akka to the
>>> master.
>>>
>>> One problem I'm currently having is implementing the notifyShutdown()
>>> method. This method needs to shutdown all the thread pools and the actor
>>> system etc. One thread in this listens to a specific inbox for completion
>>> results, and then dispatches calls to the callback in another thread.
>>>
>>> The code looks like the following:
>>>
>>> Runnable run = new Runnable(){  @Override
>>>   public void run() {   
>>> while(!Thread.interrupted() && !stopProcessingInbox.get())
>>> { Object o = null;  
>>>   try { String threadName = "My Thread " + Math.random();
>>> System.out.println(threadName);
>>> Thread.currentThread().setName(threadName); 
>>> try {
>>>   o = inb

Re: [akka-user] Is there an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Patrik Nordwall]

> 23 maj 2014 kl. 17:53 skrev Lawrence Wagerfield :
> 
> That should be:
> 
> self ! Recover()
> 
>> On Friday, May 23, 2014 4:50:25 PM UTC+1, Lawrence Wagerfield wrote:
>> Ahh brilliant :)
>> 
>> One thing I'm struggling with though:
>> 
>> I'm looking through the source for Processor and I don't understand how 
>> calling sender ! Recover() is optional, given the initial receive must be 
>> performing similar stashing/unstashing to ensure recovery is processed 
>> first. 
>> 
>> However, if the Recover() never arrives (i.e. I opt-out of recovery on 
>> start-up), then I would have thought all messages would be indefinitely 
>> stashed.

Correct, indefinitely stashed or out of memory or reaching the configured stash 
limit. Anyway, it's not useful to not send Recover. What might be useful is to 
Recover to another point in the history than default (latest).

/Patrik
>> 
>> I guess I don't need to worry about this (unless I land a job at TypeSafe!), 
>> but am curious nonetheless.
>> 
>> Thanks,
>> Lawrence
>> 
>> 
>>> On Friday, May 23, 2014 4:44:52 PM UTC+1, Patrik Nordwall wrote:
>>> and we have a ticket to support this even better: 
>>> https://github.com/akka/akka/issues/13944
>>> 
>>> /Patrik
>>> 
>>> 
 On Fri, May 23, 2014 at 5:32 PM, Lawrence Wagerfield 
  wrote:
 Thank you, exactly what I needed :)
 
 
> On Friday, May 23, 2014 4:30:40 PM UTC+1, Konrad Malawski wrote:
> Hello Lawrence!
> No additional callback is provided, but there is a nice pattern that 
> effectively provides the same functionality:
> 
> Please check the section of the docs about recovery status: 
> http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-status
> If you’d keep the “last msg” around, and then you get your “FIRST” msg, 
> you know recovery has finished and you can run your logic.
> 
> I hope this helps, happy hakking!
> 
> -- 
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
> 
> 
 
 -- 
 >> 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 -  Reactive apps on the JVM
>>> Twitter: @patriknw
>>> 
>>> 
>>> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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] Questions/Problems/Bugs Using Akka?

[Steve Ramage]

Thank you for your response.

AKKAs place in this application is to manage the concurrency involved in 
distributing tasks to workers, and processing them, etc... The 
implementation of the interface requires multi-threaded operation, and 
refactoring the interface introduces a huge burden on basically ever client 
of the library. It's also unlikely that they would be willing to adopt the 
actor model whole heartedly. Consequently I do have a general problem of 
needing to read inboxes from threads, although in this particular instance 
I could probably move it back into the Actor that is populating the inbox. 
I will look at the article you presented, but I guess the one question that 
is still open. Shouldn't inbox.receive() be declared to throw 
TimeoutException given that it is in fact throwing it.

Steve Ramage




On Friday, 23 May 2014 06:29:17 UTC-7, Martynas Mickevičius wrote:
>
> Hello Steve,
>
> it seems that you are using 
> ActorD*sl*. 
> It is meant to be used mostly for trying things out in the REPL. I would 
> suggest re-factoring your application to separate actors and letting Akka 
> do the concurrency management. In that case you should get rid of Runnable 
> I see in your example and move it to actor.
>
> Have you seen this 
> article, 
> which discuses some of the shutdown patterns?
>
>
> On Wed, May 21, 2014 at 9:09 PM, Steve Ramage 
> > wrote:
>
>> Hello,
>>
>> I'm new to Akka, and to provide some context to my question I will 
>> provide some background to the problem I'm actually trying to solve. I have 
>> only read a few chapters of the Akka manual, but have started implementing 
>> anyway since I need to get my hands dirty, and so no doubt do not a firm 
>> understanding of Akka principles and concepts. Essentially I have written a 
>> library for use in my narrow field of scientific research, and central to 
>> it is the following interface (everything is in Java 7, and this is 
>> slightly simplified):
>>
>> interface TargetAlgorithmEvaluator
>> {
>>/** 
>>* Do the task descriptions, and when complete notify the onSuccess() 
>> or onFailure() method of the callback
>>*/
>>public void evaluateTaskAsync(List t, Callback c);
>>/**
>>* Shutdown any resources associated with this TargetAlgorithmEvaluator
>>*/
>>public void notifyShutdown();
>> }
>>
>> A task in this case is roughly running a program and getting some 
>> results, and there are a bunch of ways you can do it. The tasks come from a 
>> very specific domain, and aren't general at all. The first and default way 
>> is locally, via the command line. So of course there is an implementation 
>> of this that just executes the tasks on the command line, and then gets the 
>> results. Sometimes we want to do 'lots' of these executions and so it makes 
>> sense to distribute them, and so another one exists that actually uses 
>> MySQL and has workers poll from the SQL database, and this works very well. 
>> Unfortunately for releasing our tools built with this library, the 
>> requirement that users have a tuned MySQL server around is limiting, so we 
>> would like some other distributed mechanism and hence Akka. Unlike what I 
>> imagine are standard Akka use cases, these distributions are incredibly 
>> transient, they just are scheduled on some shared cluster, work together 
>> for a while and are terminated. There is no stable or perpetual deployment. 
>> It's just a master / slave architecture.  The way this currently works in 
>> Akka is that the master job spins up, creates an actor system that is 
>> listening for other actors. When other actors on other systems come online, 
>> it will dispatch the tasks to them. The workers will then use the Command 
>> line implementation locally before giving the result back via Akka to the 
>> master.
>>
>> One problem I'm currently having is implementing the notifyShutdown() 
>> method. This method needs to shutdown all the thread pools and the actor 
>> system etc. One thread in this listens to a specific inbox for completion 
>> results, and then dispatches calls to the callback in another thread. 
>>
>> The code looks like the following:
>>
>> Runnable run = new Runnable(){  @Override
>>   public void run() {
>>  while(!Thread.interrupted() && !stopProcessingInbox.get())
>>  { Object o = null;  
>>try { String threadName = "My Thread " + Math.random(); 
>>  System.out.println(threadName);
>>  Thread.currentThread().setName(threadName); 
>>  try {
>>o = inbox.receive(new FiniteDuration(1, TimeUnit.SECONDS));
>>  } finally
>>  { System.err.println("Done recieve");   
>> } } catch(Throwable e)
>>{ System.out.println("Error: " + e);
>> 

Re: [akka-user] Cluster Singleton duplicated if primary seed restarted

[anil chalil]

Hello

Is this situation can occur even if we have a small cluster like 3 instance 
and all instances in seed list?

On Wednesday, 9 April 2014 08:46:38 UTC+3, Jem Mawson wrote:
>
> Thank you Konrad. I'm really impressed by the depth of investigation and 
> your explanation. 
>
>
> On 8 April 2014 23:19, Konrad Malawski 
> > wrote:
>
>> Hello Jem,
>> We looked deeper into this and it seems that it’s both working as 
>> mendated by the current design (I’ll explain in detail bellow), as well as 
>> there is a way of forcing your desired behaviour (which totally makes sense 
>> in some scenarios). 
>>
>> Analysis:
>> First let’s dissect your log and see what’s happening:
>>
>> Note1: Seed nodes are nothing very magical. It’s only a list of nodes, a 
>> joining node will try to talk to when trying to join a cluster.
>> Note2: Joining “self” is normal and expected.
>>
>> Ok, so let’s look at the above logs and write up what’s happening:
>>
>> // seed nodes = [51, 52]
>> // other node = [39]
>>
>> > 51 starts; 52 not started yet, 39 not started yet
>> > 51 joins self, this is fine. This is the beginning of clusterA.
>> > 39 starts
>> > 39 contacts 51, joins it's cluster
>> > cluster singleton started on 39 or 51
>> > 52 starts
>> > 51 stops
>> // 51 never talked to 51 at this point (that's the root of the problem!), it 
>> didn't make it in time before 51 died
>> || if singleton was running on 51 the manager notices this, and it will 
>> start it on 39
>> || if singleton was running on 39, it stays there
>> > 52 tries to join the cluster; seed nodes are 51, 52; 51 just died
>> > 52 joins self, this is the beginning of clusterB! A new cluster has 
>> > emerged.
>> > 52 has no idea about 39. Noone told it to contact 39, so it won't. (We do 
>> > not have magical auto-discovery)
>> > 52 starts the singleton (!).
>> // the singleton is running twice among our apps, but not "twice in the same 
>> cluster" - because 52 has no way of knowing that there is some 39 node 
>> running "somewhere".
>> > 51 comes back up, it has 52 in seed nodes, so it will join it; 
>> > 51 notices that 52 has the singleton, and will not do anything to it.
>>
>> Ok… Se we know why this happens. Is this “valid” behaviour? Well… It’s 
>> “expected” - effectively this shows that two clusters have raised, not one.
>>
>> Then, the seed nodes never had the chance to talk to each other about 
>> “that new guy” who joined, so it’s address is unknown to 52 - which creates 
>> a new cluster, which the new 51 instance joins => creating a completely new 
>> cluster.
>>
>> I may just say “this is fine” of course, and for some applications it 
>> might be. But I definitely see good use cases for really guaranteeing this 
>> singleton instance.
>>
>> Suggestions:
>> Here are a few ways to increase it’s resilience:
>>
>> 1) We can *leverage roles* in order to keep the cluster singleton from 
>> starting until more seed nodes know about each other.
>> This allows us to not loose information about the 39 node if 51 goes 
>> down, because 52 will also be aware of it.
>>
>> Basically the idea here is that “there always must be at least one seed 
>> node, that knows the singletons”.
>> This way you can increase the resilience of the system (how much 
>> guarantees we get about the singleton not suddenly becoming a doubleton 
>> ;-)), by increasing the number of seed nodes.
>> Graphically speaking: A B C X Y Z, where ABC are seed nodes and X Y Z 
>> joined later, means that we can afford to loose 2 of ABC at the same time, 
>> and the remaining one will keep track of the singletons replicated to the
>> X Y Z nodes, so even when B and C re-join (new instances of apps), they 
>> will get the information that the singleton is running already on “some 
>> node called X”, of which otherwise the rejoining nodes would not know the 
>> addresses (and would cause the problem as in the above example).
>>
>> Code wise, it’s very simple to implement, and I’ve prepared a pull 
>> request with a sample for you: 
>> https://github.com/Synesso/scratch-akka-cluster-singleton/pull/1/files
>> We just mark all seed nodes with special seed role. This means that we 
>> won’t start the cluster until seed nodes have been contracted. By 
>> increasing their number you get more resilience against failing (and 
>> getting a doubleton on restarting these services, because they will not 
>> form a new cluster, but re-join the “last man standing” seed node).
>>
>> 2) You could try to stop using seed-nodes, because they’re static, and 
>> thus… tricky. 
>>
>> And instead use a “global” service registry, where each ActorSystem would 
>> register itself when running.
>> Then when joining the cluster, you’d ask that service “hey, who is online 
>> now?”. The difference from seed nodes here is that the initial contact 
>> points can be updated, and seed-nodes are hardcoded in the config.
>> I’ve implemented such systems using ZooKeeper in the past. You would have 
>> a paths like /akka/clusters/ba

[akka-user] JMX & Akka

[Andreas Gies]

Hello Hakkers,

if I understand correctly the Typesafe console will be discontinued. As far 
as I am aware one thing it brought to the table was some kind of JMX 
support. 
I was wondering if the JMX support also vanishes or if it remains in some 
lib ?

The reason I am asking is that JMX would allow me to tap into hawtio 
(http://hawt.io/) for monitoring Akka in my container (at least to some 
extent). 


Best regards
Andreas

-- 
>>  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] Re: Cluster Sharding Questions

[Luis Medina]

>
> When scraping the router and using only sharding you will have to make 
> sure that your MessageExtractor is implemented in a way that achieves 
> desired load balancing.
>
 
 Good point. Since the routees (and now the single workers) were going to 
be pulling data instead of getting data pushed to them, I was thinking of 
just having them get created randomly as needed based on the id values. In 
this case, since data isn't being pushed to the workers, it doesn't seem 
like Passivation would work in getting rid of the workers that weren't 
doing anything. I'm probably going to have to implement logic within the 
worker that just kills itself if it has been in an "idle" state for a 
period of time.
 

>  New entry with id 11 will be created in whatever shard 
> MessageExtractor.shardId(...) returned for that message.
>

 Oh so a shard can contain multiple instances of the same entry as long as 
their ids are different? Interesting.

Anyways, I want to thank you Martynas and Patrik too for all of your great 
advice. Your guys' help has really been invaluable. 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.

Re: [akka-user] Re: Cluster Sharding Questions

[Luis Medina]

When scraping the router and using only sharding you will have to make sure 
that your MessageExtractor is implemented in a way that achieves desired 
load balancing.

Good point. Since the routees (and now the single workers) were going to be 
pulling data instead of getting data pushed to them, I was thinking of just 
having them get created randomly as needed based on the id values. In this 
case, since data isn't being pushed to the workers, it doesn't seem like 
Passivation would work in getting rid of the workers that weren't doing 
anything. I'm probably going to have to implement logic within the worker 
that just kills itself if it has been in an "idle" state for a period of 
time.
 

> New entry with id 11 will be created in whatever shard 
> MessageExtractor.shardId(...) returned for that message.


Oh so a shard can contain multiple instances of the same entry as long as 
their ids are different? Interesting.

Anyways, I want to thank you Martynas and Patrik too for all of your great 
advice. Your guys' help has really been invaluable. 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.

Re: [akka-user] Re: Cluster Sharding Questions

[Martynas Mickevičius]

On Fri, May 23, 2014 at 5:10 PM, Luis Medina  wrote:

> Hi Martynas,
>
> The number of distinct entryId values determines the number of workers you
>> are going to have. And the number of ditinct shardId values determines the
>> number of shards (groups of workers which are managed independently) that
>> you are going to have.
>
>
> This makes sense. So ideally, the number of shards in your cluster should
> be a factor of 10 greater than the number of nodes. Given that, if say I
> have 10 shards in my cluster, is it good that I have as many workers? Or is
> this completely based on how much you want to scale?
>

This is completely up to you and how much workers you want to have.


>
> If I'm trying to scale the functionality of a worker, currently I was
> thinking of having each worker instantiate a cluster-aware router whose
> routees could handle the heavy lifting. Would it be better instead to get
> rid of the router, have each worker implement the logic that was in the
> routees, and then use sharding to scale the worker?
>

When scraping the router and using only sharding you will have to make sure
that your MessageExtractor is implemented in a way that achieves desired
load balancing.


>
> Also, is it possible to have a scenario where all of your shards have an
> entry of a particular type running (each with a different entryId) and you
> send a message to the entry type but with an entryId that doesn't match any
> of the ids of the entries that are currently running (ie. There are 10
> shards, each one running an entry with an id value that ranges between
> 1-10, and you send a message with an id value of 11)? What would happen?
>

New entry with id 11 will be created in whatever shard
MessageExtractor.shardId(...) returned for that message.


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



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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 an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Lawrence Wagerfield]

That should be:

self ! Recover()

On Friday, May 23, 2014 4:50:25 PM UTC+1, Lawrence Wagerfield wrote:
>
> Ahh brilliant :)
>
> One thing I'm struggling with though:
>
> I'm looking through the source for Processor and I don't understand how 
> calling sender ! Recover() is optional, given the initial receive must be 
> performing similar stashing/unstashing to ensure recovery is processed 
> first. 
>
> However, if the Recover() never arrives (i.e. I opt-out of recovery on 
> start-up), then I would have thought all messages would be indefinitely 
> stashed.
>
> I guess I don't need to worry about this (unless I land a job at 
> TypeSafe!), but am curious nonetheless.
>
> Thanks,
> Lawrence
>
>
> On Friday, May 23, 2014 4:44:52 PM UTC+1, Patrik Nordwall wrote:
>>
>> and we have a ticket to support this even better: 
>> https://github.com/akka/akka/issues/13944
>>
>> /Patrik
>>
>>
>> On Fri, May 23, 2014 at 5:32 PM, Lawrence Wagerfield <
>> lawr...@dmz.wagerfield.com> wrote:
>>
>>> Thank you, exactly what I needed :)
>>>
>>>
>>> On Friday, May 23, 2014 4:30:40 PM UTC+1, Konrad Malawski wrote:

 Hello Lawrence!
 No additional callback is provided, but there is a nice pattern that 
 effectively provides the same functionality:

 Please check the section of the docs about recovery status: 
 
 http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-
 status
 If you’d keep the “last msg” around, and then you get your “FIRST” msg, 
 you know recovery has finished and you can run your logic.

 I hope this helps, happy hakking!

 -- 
 Konrad 'ktoso' Malawski
 hAkker @ typesafe

 

>>>  -- 
>>> >> 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  -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> 
>>
>> 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is there an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Lawrence Wagerfield]

Ahh brilliant :)

One thing I'm struggling with though:

I'm looking through the source for Processor and I don't understand how 
calling sender ! Recover() is optional, given the initial receive must be 
performing similar stashing/unstashing to ensure recovery is processed 
first. 

However, if the Recover() never arrives (i.e. I opt-out of recovery on 
start-up), then I would have thought all messages would be indefinitely 
stashed.

I guess I don't need to worry about this (unless I land a job at 
TypeSafe!), but am curious nonetheless.

Thanks,
Lawrence


On Friday, May 23, 2014 4:44:52 PM UTC+1, Patrik Nordwall wrote:
>
> and we have a ticket to support this even better: 
> https://github.com/akka/akka/issues/13944
>
> /Patrik
>
>
> On Fri, May 23, 2014 at 5:32 PM, Lawrence Wagerfield <
> lawr...@dmz.wagerfield.com > wrote:
>
>> Thank you, exactly what I needed :)
>>
>>
>> On Friday, May 23, 2014 4:30:40 PM UTC+1, Konrad Malawski wrote:
>>>
>>> Hello Lawrence!
>>> No additional callback is provided, but there is a nice pattern that 
>>> effectively provides the same functionality:
>>>
>>> Please check the section of the docs about recovery status: 
>>> 
>>> http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-
>>> status
>>> If you’d keep the “last msg” around, and then you get your “FIRST” msg, 
>>> you know recovery has finished and you can run your logic.
>>>
>>> I hope this helps, happy hakking!
>>>
>>> -- 
>>> Konrad 'ktoso' Malawski
>>> hAkker @ typesafe
>>>
>>> 
>>>
>>  -- 
>> >> 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  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> 
>
> 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is there an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Patrik Nordwall]

and we have a ticket to support this even better:
https://github.com/akka/akka/issues/13944

/Patrik


On Fri, May 23, 2014 at 5:32 PM, Lawrence Wagerfield <
lawre...@dmz.wagerfield.com> wrote:

> Thank you, exactly what I needed :)
>
>
> On Friday, May 23, 2014 4:30:40 PM UTC+1, Konrad Malawski wrote:
>>
>> Hello Lawrence!
>> No additional callback is provided, but there is a nice pattern that
>> effectively provides the same functionality:
>>
>> Please check the section of the docs about recovery status: 
>> 
>> http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-status
>> If you’d keep the “last msg” around, and then you get your “FIRST” msg,
>> you know recovery has finished and you can run your logic.
>>
>> I hope this helps, happy hakking!
>>
>> --
>> Konrad 'ktoso' Malawski
>> hAkker @ typesafe
>>
>> 
>>
>  --
> >> 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  -  Reactive apps on the JVM
Twitter: @patriknw



-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [akka-streams]: actor producers, load balancers

[Patrik Nordwall]

On Fri, May 23, 2014 at 4:56 PM, Konrad 'ktoso' Malawski <
konrad.malaw...@typesafe.com> wrote:

> Cześć Adam :-)
>
>
> - is it reasonable (thinking about reactive streams in general) to have an
> actor which produces elements on-demand (instead of providing a
> collection/iterator/() => as is currently supported)? As far as I
> understand the current implementation, subscribers explicitly ask
> publishers for more elements (through Subscription.requestMore) - so it
> seems it would be possible to pass such a request to an actor and ask for
> the given amount of elements. Is there any chance to get "actor producers"
> in some future releases, or there are no such plans currently?
>
> Yes, definitely! We currently do support it (on release-2.3*-dev*, it’s
> pretty new) via:
>
> ```
> /**
>* Define the sequence of elements to be produced by the given closure.
>* The stream ends normally when evaluation of the closure results in
>* a [[akka.stream.Stop]] exception being thrown; it ends exceptionally
>* when any other exception is thrown.
>*/
>   def apply[T](f: () ⇒ T): Flow[T]
> ```
>
> Which generates an `Actor` backed producer for you (that will call your
> function), or if you need complete control you can implement a
> `Producer[T]` and give it to `Flow`:
>

I don't think that is enough. It assumes that the elements are available
when calling the closure, otherwise blocking will happen. We have one
ticketfor creating a
producer from a closure that returns a future. I think we
should have support for a producer that is an actor also.
Stay tuned.

/Patrik


>
> ```
> /**
>* Construct a transformation of the given producer. The transformation
> steps
>* are executed by a series of [[org.reactivestreams.api.Processor]]
> instances
>* that mediate the flow of elements downstream and the propagation of
>* back-pressure upstream.
>*/
>   def apply[T](producer: Producer[T]): Flow[T]
> ```
>
> These should be enough to implement what you’re after.
>
> *Disclaimer*
> Please note that the spec (
> https://github.com/reactive-streams/reactive-streams ) is under heavy
> discussions and development at this moment.
> Our current impl is still targeting the previous version, differences
> include for example dropping the Producer interface in favour of only
> keeping `Publisher` etc.
> Also known as: This is still is changing a lot :-)
>
>
>
> - another thing is if the streams are thought to be more local, or remote
> as well? There's currently the TCP stream implementation, which I guess
> would indicate remote as well (and in such scenarios the need for
> backpressure arises quite naturally, maybe even more than in locally), but
> do you plan to develop this somehow? E.g. when there would be multiple
> consumers for a single producer, a useful component would be a
> load-balancer which takes into account the backpressure information.
>
>
> We’re currently focused on in-jvm implementations, though
> multi-language-and-runtime are definitely on the reactive-streams’ radar:
> https://github.com/reactive-streams/reactive-streams/issues/45
> Let’s first nail the in-vm implementation to then move on to the bigger
> picture (personal opinion here), but there’s so many people involved and
> loads of excitement around it, so we’ll see ;-)
> As for Akka, we’re currently mostly focused on getting akka-http (which
> will be stream based) out of the door, and optimise it, the rest comes next.
>
>
> I hope this helps!
> // So... what Producer are you implementing? :-)
>
>
>
>  --
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
>
> 
>
> --
> >> 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  -  Reactive apps on the JVM
Twitter: @patriknw



-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, sen

Re: [akka-user] Is there an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Lawrence Wagerfield]

Thank you, exactly what I needed :)

On Friday, May 23, 2014 4:30:40 PM UTC+1, Konrad Malawski wrote:
>
> Hello Lawrence!
> No additional callback is provided, but there is a nice pattern that 
> effectively provides the same functionality:
>
> Please check the section of the docs about recovery status: 
> 
> http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-status
> If you’d keep the “last msg” around, and then you get your “FIRST” msg, 
> you know recovery has finished and you can run your logic.
>
> I hope this helps, happy hakking!
>
> -- 
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
>
> 
>

-- 
>>  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 an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Konrad 'ktoso' Malawski]

Hello Lawrence!
No additional callback is provided, but there is a nice pattern that 
effectively provides the same functionality:

Please check the section of the docs about recovery status: 
http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html#recovery-status
If you’d keep the “last msg” around, and then you get your “FIRST” msg, you 
know recovery has finished and you can run your logic.

I hope this helps, happy hakking!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

-- 
>>  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] Is there an 'onRecovered' hook in EventsourcedProcessor? (Implementing a 'redo transaction')

[Lawrence Wagerfield]

My EventsourcedProcessor needs to redo some operation if it was only half 
completed.

The events in my system are as follows, where the first event marks the 
beginning of a transaction, and the latter two are mutually exclusive 
outcomes:

UserRegistrationSubmitted
UserRegistered
UserRegistrationDenied

Recovery needs to handle cases where the outcome is undetermined.

This is easy to do in theory as all I need is an 'onRecovered' method to 
override in the EventsourcedProcessor. I would then re-run the registration 
process, post-recovery, if the last event is 'UserSubmittedRegistration'.

How can I achieve this? Or is this bad behaviour for a recovery? If so: 
what's the recommended practice for implementing a redo / handling 
incomplete transactions?

Thanks,
Lawrence

-- 
>>  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] Re: Cluster Sharding Questions

[Luis Medina]

Hi Martynas,

The number of distinct entryId values determines the number of workers you 
> are going to have. And the number of ditinct shardId values determines the 
> number of shards (groups of workers which are managed independently) that 
> you are going to have.


This makes sense. So ideally, the number of shards in your cluster should 
be a factor of 10 greater than the number of nodes. Given that, if say I 
have 10 shards in my cluster, is it good that I have as many workers? Or is 
this completely based on how much you want to scale?

If I'm trying to scale the functionality of a worker, currently I was 
thinking of having each worker instantiate a cluster-aware router whose 
routees could handle the heavy lifting. Would it be better instead to get 
rid of the router, have each worker implement the logic that was in the 
routees, and then use sharding to scale the worker?

Also, is it possible to have a scenario where all of your shards have an 
entry of a particular type running (each with a different entryId) and you 
send a message to the entry type but with an entryId that doesn't match any 
of the ids of the entries that are currently running (ie. There are 10 
shards, each one running an entry with an id value that ranges between 
1-10, and you send a message with an id value of 11)? What would happen?

-- 
>>  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-streams]: actor producers, load balancers

[Konrad 'ktoso' Malawski]

Cześć Adam :-)


- is it reasonable (thinking about reactive streams in general) to have an 
actor which produces elements on-demand (instead of providing a 
collection/iterator/() => as is currently supported)? As far as I understand 
the current implementation, subscribers explicitly ask publishers for more 
elements (through Subscription.requestMore) - so it seems it would be possible 
to pass such a request to an actor and ask for the given amount of elements. Is 
there any chance to get "actor producers" in some future releases, or there are 
no such plans currently?
Yes, definitely! We currently do support it (on release-2.3-dev, it’s pretty 
new) via:

```
/**
   * Define the sequence of elements to be produced by the given closure.
   * The stream ends normally when evaluation of the closure results in
   * a [[akka.stream.Stop]] exception being thrown; it ends exceptionally
   * when any other exception is thrown.
   */
  def apply[T](f: () ⇒ T): Flow[T]
```

Which generates an `Actor` backed producer for you (that will call your 
function), or if you need complete control you can implement a `Producer[T]` 
and give it to `Flow`:

```
/**
   * Construct a transformation of the given producer. The transformation steps
   * are executed by a series of [[org.reactivestreams.api.Processor]] instances
   * that mediate the flow of elements downstream and the propagation of
   * back-pressure upstream.
   */
  def apply[T](producer: Producer[T]): Flow[T]
```

These should be enough to implement what you’re after.

Disclaimer
Please note that the spec ( 
https://github.com/reactive-streams/reactive-streams ) is under heavy 
discussions and development at this moment.
Our current impl is still targeting the previous version, differences include 
for example dropping the Producer interface in favour of only keeping 
`Publisher` etc.
Also known as: This is still is changing a lot :-)



- another thing is if the streams are thought to be more local, or remote as 
well? There's currently the TCP stream implementation, which I guess would 
indicate remote as well (and in such scenarios the need for backpressure arises 
quite naturally, maybe even more than in locally), but do you plan to develop 
this somehow? E.g. when there would be multiple consumers for a single 
producer, a useful component would be a load-balancer which takes into account 
the backpressure information. 

We’re currently focused on in-jvm implementations, though 
multi-language-and-runtime are definitely on the reactive-streams’ radar: 
https://github.com/reactive-streams/reactive-streams/issues/45
Let’s first nail the in-vm implementation to then move on to the bigger picture 
(personal opinion here), but there’s so many people involved and loads of 
excitement around it, so we’ll see ;-)
As for Akka, we’re currently mostly focused on getting akka-http (which will be 
stream based) out of the door, and optimise it, the rest comes next.


I hope this helps!
// So... what Producer are you implementing? :-)



-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

-- 
>>  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: Inconsistent behavior of ClusterClient.Send (akka 2.3.2) ?

[Martynas Mickevičius]

Hello Eugene,

I have tried running your example and I get the same error. My example did
not even have TaskChunk actor created by TaskSchedulerActor.

After I changed the configuration to


deployment {
  "/router_scheduler/*/router_chunkworker" {
router = *round-robin-pool*
nr-of-instances = 3


that error was gone. So I think this could be a bug. Could you register an
issue with a preferably multi-node test which catches this?


On Thu, May 22, 2014 at 6:21 AM, Eugene Dzhurinsky wrote:

> Hi all!
>
> I did some further research/debugging and realized that something is
> definitely broken after the node with role *chunk* is started and an
> actor *TaskChunkActor *is deployed there.
>
> If a node with a *TaskChunkActor* is not started, then the call stack for
> a payload processing looks like on the picture:
>
> http://i.imgur.com/PGRIOQT.png
>
> but if the node with a *TaskChunkActor* is started, the call stack for
> the same payload looks like:
>
> http://i.imgur.com/0OsSeOO.png
>
> So there's no *DistributedPubSubMediator* in the call stack, and I have
> no idea how is that possible. the configuration is the same, the only
> difference if the node is started or not.
>
> Can you please help me to understand what may cause such strange behavior?
>
> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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] [akka-streams]: actor producers, load balancers

[Adam Warski]

Hello,

I've been looking at the akka-streams, and got two questions:

- is it reasonable (thinking about reactive streams in general) to have an 
actor which produces elements on-demand (instead of providing a 
collection/iterator/() => as is currently supported)? As far as I 
understand the current implementation, subscribers explicitly ask 
publishers for more elements (through Subscription.requestMore) - so it 
seems it would be possible to pass such a request to an actor and ask for 
the given amount of elements. Is there any chance to get "actor producers" 
in some future releases, or there are no such plans currently?

- another thing is if the streams are thought to be more local, or remote 
as well? There's currently the TCP stream implementation, which I guess 
would indicate remote as well (and in such scenarios the need for 
backpressure arises quite naturally, maybe even more than in locally), but 
do you plan to develop this somehow? E.g. when there would be multiple 
consumers for a single producer, a useful component would be a 
load-balancer which takes into account the backpressure information. 

Thanks!

-- 
Adam

-- 
>>  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] Questions/Problems/Bugs Using Akka?

[Martynas Mickevičius]

Hello Steve,

it seems that you are using
ActorD*sl*.
It is meant to be used mostly for trying things out in the REPL. I would
suggest re-factoring your application to separate actors and letting Akka
do the concurrency management. In that case you should get rid of Runnable
I see in your example and move it to actor.

Have you seen this
article,
which discuses some of the shutdown patterns?


On Wed, May 21, 2014 at 9:09 PM, Steve Ramage  wrote:

> Hello,
>
> I'm new to Akka, and to provide some context to my question I will provide
> some background to the problem I'm actually trying to solve. I have only
> read a few chapters of the Akka manual, but have started implementing
> anyway since I need to get my hands dirty, and so no doubt do not a firm
> understanding of Akka principles and concepts. Essentially I have written a
> library for use in my narrow field of scientific research, and central to
> it is the following interface (everything is in Java 7, and this is
> slightly simplified):
>
> interface TargetAlgorithmEvaluator
> {
>/**
>* Do the task descriptions, and when complete notify the onSuccess() or
> onFailure() method of the callback
>*/
>public void evaluateTaskAsync(List t, Callback c);
>/**
>* Shutdown any resources associated with this TargetAlgorithmEvaluator
>*/
>public void notifyShutdown();
> }
>
> A task in this case is roughly running a program and getting some results,
> and there are a bunch of ways you can do it. The tasks come from a very
> specific domain, and aren't general at all. The first and default way is
> locally, via the command line. So of course there is an implementation of
> this that just executes the tasks on the command line, and then gets the
> results. Sometimes we want to do 'lots' of these executions and so it makes
> sense to distribute them, and so another one exists that actually uses
> MySQL and has workers poll from the SQL database, and this works very well.
> Unfortunately for releasing our tools built with this library, the
> requirement that users have a tuned MySQL server around is limiting, so we
> would like some other distributed mechanism and hence Akka. Unlike what I
> imagine are standard Akka use cases, these distributions are incredibly
> transient, they just are scheduled on some shared cluster, work together
> for a while and are terminated. There is no stable or perpetual deployment.
> It's just a master / slave architecture.  The way this currently works in
> Akka is that the master job spins up, creates an actor system that is
> listening for other actors. When other actors on other systems come online,
> it will dispatch the tasks to them. The workers will then use the Command
> line implementation locally before giving the result back via Akka to the
> master.
>
> One problem I'm currently having is implementing the notifyShutdown()
> method. This method needs to shutdown all the thread pools and the actor
> system etc. One thread in this listens to a specific inbox for completion
> results, and then dispatches calls to the callback in another thread.
>
> The code looks like the following:
>
> Runnable run = new Runnable(){  @Override
>   public void run() { 
>   while(!Thread.interrupted() && !stopProcessingInbox.get())
>   { Object o = null;  
> try { String threadName = "My Thread " + Math.random();
>   System.out.println(threadName);
>   Thread.currentThread().setName(threadName); 
>   try {
> o = inbox.receive(new FiniteDuration(1, TimeUnit.SECONDS));
>   } finally
>   { System.err.println("Done recieve");   
> } } catch(Throwable e)
> { System.out.println("Error: " + e);
>   throw e;  }
>
>
>if (o == null) continue;
>
>   //Rest of while loop here
>
>  }
>}
> }
> }
>
>
> Essentially the problem is that I would like to make the inbox.receive
> sensitive to interruption, that might occur when notifyShutdown() is
> called. The above code however has some very weird output that I just don't
> understand:
>
> My Thread 0.7085946542233289
> Done recieve
> Error: java.util.concurrent.TimeoutException: deadline passed
> Exception in thread "My Thread 0.7085946542233289" java.lang.Error: 
> java.util.concurrent.TimeoutException: deadline passedat 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1151)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:744)Caused by: 
> java.util.concurrent.TimeoutException: deadline passed   at 
> akka.actor.dsl.Inbox$InboxActor$$anonfun$receive$1.applyOrElse(Inbox.scala:117)
>

Re: [akka-user] Tuning Linux for Akka

[Martynas Mickevičius]

Hi Jonathan,

it is hard to give advice arbitrarily. Do you see a bottleneck somewhere in
your system?


On Fri, May 23, 2014 at 4:42 AM, Jonathan  wrote:

> What are some best practices and recommendations for tuning Linux for Akka
> and Akka remoting?  Most systems are not setup correctly to handle the
> number of threads so you need to increase nofile parameter in
> /etc/security/limits.conf
> This is just one parameter that needs to be changed/confirmed.  I'm sure
> there are more parameters to tune.
>
> In my case, I'm using Amazon EC2 Instances
>
> Version Info:
> [ec2-user@ip-10-238-38-27 ~]$ uname -mrs
> Linux 3.10.40-50.136.amzn1.x86_64 x86_64
> [ec2-user@ip-10-238-38-27 ~]$  cat /proc/version
> Linux version 3.10.40-50.136.amzn1.x86_64 (mockbuild@gobi-build-60001)
> (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP Tue May 13
> 21:35:08 UTC 2014
>
> -Jonathan
>
> --
> >> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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] Empty Snapshot files causes EOFException

[Björn Antonsson]

Hi James,

I've opened an issue and is investigating the problem.

B/

On 23 May 2014 at 09:51:53, Björn Antonsson (bjorn.antons...@typesafe.com) 
wrote:

Hi James,

That is indeed strange. Would you mind opening an issue with this description, 
and maybe even a minimized reproducer?

B/ 

On 22 May 2014 at 14:50:23, James Brems (jamesbrem...@gmail.com) wrote:

Hi Björn,

today I found out that the root cause seems to be the length of the fully 
qualified class name of the snapshot class. If the length (pacakge+class name) 
exceeds 60 characters an EOFException is thrown instead of calling fromBinary.

Here's my reference.conf:

akka {
  actor {
    serializers {
    customSerializer = "com.handler.util.CommonSerializer"
    }
    serialization-bindings {
    "com.handler.common.dispatcher.xxx.MySnapshot" = 
customSerializer
    }
  }
}

Here's the scala file where I define the MySnapshot class:

package com.handler.common.dispatcher.xxx

@SerialVersionUID(1L)
case class MySnapshot(id: String)

Here's the common serializer:

package com.handler.util

class CommonSerializer extends Serializer {
  def includeManifest: Boolean = true
  def identifier = 5177

  def toBinary(obj: AnyRef): Array[Byte] = {
    val outputStream = new ByteArrayOutputStream()
    outputStream.toByteArray
  }

  def fromBinary(bytes: Array[Byte],
 clazz: Option[Class[_]]): AnyRef = {
    None
  }
}

If I make the package name shorter it works without throwing an EOFException - 
fromBinary is called then.
--
>> 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.
-- 
Björn Antonsson
Typesafe – Reactive Apps on the JVM
twitter: @bantonsson

SEE YOU IN BERLIN
Scala
Days
June 16th-18th,
Berlin

-- 
Björn Antonsson
Typesafe – Reactive Apps on the JVM
twitter: @bantonsson

SEE YOU IN BERLIN
Scala
Days
June 16th-18th,
Berlin

-- 
>>  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 messages back in actor test

[Martynas Mickevičius]

Hi Leon,

Yes, you can do that with receiveOne(d: Duration): AnyRef call.

Do not hesitate to look at
testingdocs
and testkit
example .


On Fri, May 23, 2014 at 9:59 AM, Leon Ma  wrote:

> Hi,
>
> Usually I do:
>
> actorRef ! SomeRequest
> expectMsg(SomeResponse)
>
>
> However I'd like to know whether I can get the last response message
> object like this:
>
> actorRef ! SomeRequest
> val resp = lastMsg()
>
> resp.propA should be (...)
> resp.StringProp contains "mysubstring" should be(true)
>
>
> Is it doable?
>
>
>
> Thanks
>
> Leon
>
>  --
> >> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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] Print physical path of ActorRef instance

[Martynas Mickevičius]

Hi Jonathan,

you can use

akka.serialization.Serialization.serializedActorPath(actorRef)

which will get you

akka.tcp://ClusterSystem@127.0.0.1:59905/user/clientActor#-878542148


On Fri, May 23, 2014 at 4:06 AM, Jonathan  wrote:

> How do you get the physical actor path (not logical path) from an ActorRef
> instance?
>
> --
> >> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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: Cluster Sharding Questions

[Martynas Mickevičius]

On Thu, May 22, 2014 at 11:32 PM, Luis Medina  wrote:

> Hi Patrik,
>
> I think I forgot to mention a couple of things. The workers themselves are
> going to be pulling their work from RabbitMQ, they will persist it in case
> of failure, and then they will start processing it through its router.
> Since the workers themselves won't be receiving work in the form of
> messages, which would normally be used to start up an entry, I'm going to
> be having a singleton watchdog that periodically sends a "wakeup" message
> to each of the workers in case they get re-balanced and need to get started
> again.
>
> Given this, could you clarify what you meant by using a few numbers for
> the message ids? Going off of the same example where I have 4 nodes and I
> need to have 40 shards, should the id values that the shardId() method
> produces fall within the same 40 id values? What about the values for the
> entryId() method?
>

The number of distinct entryId values determines the number of workers you
are going to have. And the number of ditinct shardId values determines the
number of shards (groups of workers which are managed independently) that
you are going to have.


>
> In terms of using the cluster Pub/Sub for the workers, do you mean having
> the stream publish the messages that it gets to a particular topic(s) and
> then have the workers subscribe to said topics and receive messages that
> way? Or did you have something else in mind for using Pub/Sub?
>
> --
> >> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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: Is it possible to use EventsourcedProcessor with FSM[S, D]?

[Konrad 'ktoso' Malawski]

Thanks, your feedback is well appreciated!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe

-- 
>>  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] Re: Is it possible to use EventsourcedProcessor with FSM[S, D]?

[Lawrence Wagerfield]

https://github.com/akka/akka/issues/15279

On Friday, May 23, 2014 12:24:59 PM UTC+1, Konrad Malawski wrote:
>
> Hello Lawrence,
> Mixing FSM with EventsourcedProcessor is not directly supported - going 
> with a child actor is easiest way to get what you need I think.
> The reason it's not easy to just mix-in both FSM and EP is because they 
> both do a lot around handling the `receive` "for you" so it may be tough to 
> get all the inter-ops *right.*
>
> Though it may be quite interesting to provide FSM-like mechanisms for 
> eventsourced processors...
> Esp. since we'll be moving towards deprecating and removing 
> Processorand making 
> EventsourcedProcessor the "main" abstraction in persistence I 
> think we should re-think if / how we can provide FSM-like utils for it.
> Would you mind opening a ticket describing this requirement ( 
> https://github.com/akka/akka/issues ), so we can discuss if it's 
> something we would like to provide or not?
>
> Thanks in advance!
>
> -- 
> Konrad
> hAkker
>

-- 
>>  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] Re: Is it possible to use EventsourcedProcessor with FSM[S, D]?

[Konrad Malawski]

Hello Lawrence,
Mixing FSM with EventsourcedProcessor is not directly supported - going 
with a child actor is easiest way to get what you need I think.
The reason it's not easy to just mix-in both FSM and EP is because they 
both do a lot around handling the `receive` "for you" so it may be tough to 
get all the inter-ops *right.*

Though it may be quite interesting to provide FSM-like mechanisms for 
eventsourced processors...
Esp. since we'll be moving towards deprecating and removing 
Processorand making 
EventsourcedProcessor the "main" abstraction in persistence I 
think we should re-think if / how we can provide FSM-like utils for it.
Would you mind opening a ticket describing this requirement ( 
https://github.com/akka/akka/issues ), so we can discuss if it's something 
we would like to provide or not?

Thanks in advance!

-- 
Konrad
hAkker

-- 
>>  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-stream: how to construct a time based Flow

[benq]

Great, things are moving on, this is amazing! 
Thanks for your quick answer.

Any plan / timeline for a 0.3 akka-stream release, with this included?
Or, is it possible to use the release-2.3-dev branch? Is there an artifact 
published somewhere (maven)?

Le vendredi 23 mai 2014 11:52:42 UTC+2, Patrik Nordwall a écrit :
>
> and also https://github.com/akka/akka/pull/15245
>
>
> On Fri, May 23, 2014 at 10:29 AM, Martynas Mickevičius <
> martynas.m...@typesafe.com > wrote:
>
>> Hello,
>>
>> that is being worked on right now. Take a look at the code: 
>> https://github.com/akka/akka/pull/15274
>>  
>>
>> On Fri, May 23, 2014 at 10:28 AM, benq 
>> > wrote:
>>
>>> Hi,
>>>
>>> In the new akka-stream (0.2), is is possible to construct a Flow that 
>>> will emit an event every time interval?
>>>
>>> For example, how can I build a stream that would have one random number 
>>> per second?
>>> Is that possible?
>>>
>>> benq 
>>>
>>> -- 
>>> >> 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.
>>>
>>
>>
>>
>> -- 
>> Martynas Mickevičius
>> Typesafe  – 
>> ReactiveApps on the JVM
>>  
>> -- 
>> >> 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  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> 
>
> 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka-stream: how to construct a time based Flow

[Patrik Nordwall]

and also https://github.com/akka/akka/pull/15245


On Fri, May 23, 2014 at 10:29 AM, Martynas Mickevičius <
martynas.mickevic...@typesafe.com> wrote:

> Hello,
>
> that is being worked on right now. Take a look at the code:
> https://github.com/akka/akka/pull/15274
>
>
> On Fri, May 23, 2014 at 10:28 AM, benq  wrote:
>
>> Hi,
>>
>> In the new akka-stream (0.2), is is possible to construct a Flow that
>> will emit an event every time interval?
>>
>> For example, how can I build a stream that would have one random number
>> per second?
>> Is that possible?
>>
>> benq
>>
>> --
>> >> 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.
>>
>
>
>
> --
> Martynas Mickevičius
> Typesafe  – 
> ReactiveApps on the JVM
>
> --
> >> 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  -  Reactive apps on the JVM
Twitter: @patriknw



-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka-stream: how to construct a time based Flow

[Martynas Mickevičius]

Hello,

that is being worked on right now. Take a look at the code:
https://github.com/akka/akka/pull/15274


On Fri, May 23, 2014 at 10:28 AM, benq  wrote:

> Hi,
>
> In the new akka-stream (0.2), is is possible to construct a Flow that will
> emit an event every time interval?
>
> For example, how can I build a stream that would have one random number
> per second?
> Is that possible?
>
> benq
>
> --
> >> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

-- 
>>  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] akka-stream: how to construct a time based Flow

[benq]

Hi,

In the new akka-stream (0.2), is is possible to construct a Flow that will 
emit an event every time interval?

For example, how can I build a stream that would have one random number per 
second?
Is that possible?

benq 

-- 
>>  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] get messages back in actor test

[Leon Ma]

Hi,

Usually I do:

actorRef ! SomeRequest
expectMsg(SomeResponse)


However I'd like to know whether I can get the last response message object 
like this:

actorRef ! SomeRequest
val resp = lastMsg()

resp.propA should be (...)
resp.StringProp contains "mysubstring" should be(true)


Is it doable?



Thanks

Leon

-- 
>>  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] Empty Snapshot files causes EOFException

[Björn Antonsson]

Hi James,

That is indeed strange. Would you mind opening an issue with this description, 
and maybe even a minimized reproducer?

B/ 

On 22 May 2014 at 14:50:23, James Brems (jamesbrem...@gmail.com) wrote:

Hi Björn,

today I found out that the root cause seems to be the length of the fully 
qualified class name of the snapshot class. If the length (pacakge+class name) 
exceeds 60 characters an EOFException is thrown instead of calling fromBinary.

Here's my reference.conf:

akka {
  actor {
    serializers {
    customSerializer = "com.handler.util.CommonSerializer"
    }
    serialization-bindings {
    "com.handler.common.dispatcher.xxx.MySnapshot" = 
customSerializer
    }
  }
}

Here's the scala file where I define the MySnapshot class:

package com.handler.common.dispatcher.xxx

@SerialVersionUID(1L)
case class MySnapshot(id: String)

Here's the common serializer:

package com.handler.util

class CommonSerializer extends Serializer {
  def includeManifest: Boolean = true
  def identifier = 5177

  def toBinary(obj: AnyRef): Array[Byte] = {
    val outputStream = new ByteArrayOutputStream()
    outputStream.toByteArray
  }

  def fromBinary(bytes: Array[Byte],
 clazz: Option[Class[_]]): AnyRef = {
    None
  }
}

If I make the package name shorter it works without throwing an EOFException - 
fromBinary is called then.
--
>> 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.
-- 
Björn Antonsson
Typesafe – Reactive Apps on the JVM
twitter: @bantonsson

SEE YOU IN BERLIN
Scala
Days
June 16th-18th,
Berlin

-- 
>>  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: sbt downloading denpendecies with wrong revisions

[Martynas Mickevičius]

Also sbt 0.13.5-RC5 has been released couple of days ago with this issue
fixed.


On Fri, May 23, 2014 at 6:15 AM, Anthony Kilman wrote:

> Ran into the same issue. Updated the project/build.properties version from
> 0.13.5-RC1 to 0.13.2, worked like a charm.
>
>
> On Tuesday, May 20, 2014 12:36:38 PM UTC-7, Chifeng Chou wrote:
>>
>> Hello,
>>
>> I checkout the latest source of Akka and ran into many errors in sbt when
>> downloading dependencies(it happened only to some of them):
>>
>> akka> deliver
>> [info] Updating {file:/Users/cfchou/Project/02_scala_libs/akka/}akka-
>> sample-camel-scala...
>> [warn]  module not found: org.apache.camel#camel-http;
>> working@soysauce.local
>> [warn]  local: tried
>> [warn]   /Users/cfchou/.ivy2/local/org.apache.camel/camel-http/
>> working@soysauce.local/ivys/ivy.xml
>> [warn]  public: tried
>> [warn]   http://repo1.maven.org/maven2/org/apache/camel/camel-http/
>> working@soysauce.local/camel-http-work...@soysauce.local.pom
>> ...
>> [warn]  module not found: org.eclipse.jetty#jetty-
>> servlet;${jetty-version}
>> [warn]  local: tried
>> [warn]   /Users/cfchou/.ivy2/local/org.eclipse.jetty/jetty-servlet/${
>> jetty-version}/ivys/ivy.xml
>> [warn]  public: tried
>> [warn]   http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-
>> servlet/${jetty-version}/jetty-servlet-${jetty-version}.pom
>>
>> ...
>>
>> akka > about
>> [info] This is sbt 0.13.5-RC1
>> [info] The current project is 
>> {file:/Users/cfchou/Project/02_scala_libs/akka/}akka
>> 2.4-SNAPSHOT
>> [info] The current project is built against Scala 2.10.4
>> [info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin,
>> sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin,
>> org.sbtidea.SbtIdeaPlugin, com.typesafe.sbt.SbtMultiJvm,
>> sbtassembly.Plugin, com.typesafe.sbt.SbtScalariform,
>> com.typesafe.sbt.SbtSite, com.typesafe.sbt.osgi.SbtOsgi,
>> com.typesafe.tools.mima.plugin.MimaPlugin, com.typesafe.sbt.SbtPgp,
>> com.typesafe.sbt.S3Plugin, sbtunidoc.Plugin, com.typesafe.sbt.SbtGit
>> [info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
>>
>>
>> The revisions "working@soysauce.local" and "${jetty-version}" are not
>> valid. It looks like there's problem of retrieving revisions but I don't
>> really know where to look at. Can anyone help?
>>
>>
>>  --
> >> 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.
>



-- 
Martynas Mickevičius
Typesafe  –
ReactiveApps on the JVM

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