[akka-user] design question - modeling a multi step data aggregation with actors

[Adam]

Hi,

I’m wondering what would be the best way to model services which 
continually collect data from various sources until it finally has enough 
to create an answer.
In synchronous pseudo code this would look like:

def myservice = {
  val field1 = getData1().map(_.getField1)
  val field2 = getData2(field1).map(_.getField2)
  val field3 = getData3(field1).map(_.getField3)
  val field4 = if (field3>field2) {
getData4(field2).map(_.getField4)
  } else {
getData5(field1,field2)
  }
  new Reply(field2,field3,field4)
}


Of course the actual services are way more complex.

A bit more data regarding my & issues\constraints with this:


   1. The various steps in this process (getData* above) represent 
   non-blocking calls to services outside the JVM (e.g. a database). These 
   services typically have some sort of a callback mechanism, which I convert 
   to Scala futures using promises.
   2. I cannot use anything that is not “production ready” (at least from 
   runtime stability and performance perspectives – a stable API is actually 
   less of a concern for me right now). For this reason I didn’t look at Akka 
   streams so far, although I hope to use it in the future, once it’s 
   officially released.
   3. I want to keep the implementation as concise as possible, but 
   unfortunately I can’t use Scala for this, I have to use Java. Therefore, I 
   cannot resort to Scala structures that would shorten the implementation 
   like case classes and tuples – they just look bad when used from Java.
   4. I’m using an Actor per request approach for these services, meaning 
   that once a response is sent the actor is stopped.


I’ve tried two approaches so far:


   1. Use an actor that uses context.become after each asynchronous call 
   and holds the intermediate data in private fields. In this case there is no 
   single place to look at in this Actor in order to get a “birds’ eye” view 
   of the logical flow. 
   2. Use the ask pattern to convert calls to other actors (e.g. to the 
   actors mediating the access to other services like the database) to futures 
   and then compose them using map\flatMap\etc. While this allows me to more 
   comfortably compose the various asynchronous steps, I’m worried about the 
   performance implications of this. It says everywhere I look that ask is not 
   as efficient as tell (although I have no way to tell by how much…).


Both of these approaches work, and show good performance.
I’m however not happy with how the code looks like.
I’d prefer to find a cleaner solution and I feel like there must be 
something very basic I'm missing here.

-- 
>>  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: design question - modeling a multi step data aggregation with actors

[Adam]

Well, let me first say I'd be interested to hear any suggestion for a 
different approach, regardless of performance, because I believe I'll have 
a much easier time testing performance then I will assessing it.
Furthermore, from my personal experience, in the long term, a cleaner 
solution will almost always end up as a more efficient solution, due to the 
human factor.

Anyway, I'd say the answers to your questions are pretty standard.
The application is deployed on Amazon in multiple availability zones, so 
the network latency can vary a lot.
I *think* it's roughly 0.5-2ms per request to an outside service, but 
regardless to the accuracy of these numbers, you can assume that the 
application is largely IO bound- it spends way more time waiting on the 
database then making calculations.
The volume is extremely large, but it's evenly split between machines, so I 
want to get the throughput as high as possible (would save lots of money on 
hardware).
Currently we're talking about ~700 requests per second - based on the 
remaining CPU and time it's spending on waiting for these calls, I think it 
would be reasonable to aim for something around 2000-2500 requests per 
second.
At that point it should reach close to 100% CPU (which is BTW mainly due to 
serialization of data back and forth), but at this stage, these are all 
rough estimations at best.

So again, any idea for a clean solution to the general pattern here (a 
multi step service that accumalates data from various services in order to 
prepare a response), would be very welcome.





On Wednesday, July 16, 2014 9:33:54 PM UTC+3, David Larsen wrote:
>
> What can you tell us about the expected latency of your getData* calls? 
>  What kind of call volume are you dealing with?  I'm just trying to get a 
> sense of how much elegance you might need to trade to squeeze out perf.
>
> On Wednesday, July 16, 2014 6:56:00 AM UTC-7, Adam wrote:
>>
>> Hi,
>>
>> I’m wondering what would be the best way to model services which 
>> continually collect data from various sources until it finally has enough 
>> to create an answer.
>> In synchronous pseudo code this would look like:
>>
>> def myservice = {
>>   val field1 = getData1().map(_.getField1)
>>   val field2 = getData2(field1).map(_.getField2)
>>   val field3 = getData3(field1).map(_.getField3)
>>   val field4 = if (field3>field2) {
>> getData4(field2).map(_.getField4)
>>   } else {
>> getData5(field1,field2)
>>   }
>>   new Reply(field2,field3,field4)
>> }
>>
>>
>> Of course the actual services are way more complex.
>>
>> A bit more data regarding my & issues\constraints with this:
>>
>>
>>1. The various steps in this process (getData* above) represent 
>>non-blocking calls to services outside the JVM (e.g. a database). These 
>>services typically have some sort of a callback mechanism, which I 
>> convert 
>>to Scala futures using promises.
>>2. I cannot use anything that is not “production ready” (at least 
>>from runtime stability and performance perspectives – a stable API is 
>>actually less of a concern for me right now). For this reason I didn’t 
>> look 
>>at Akka streams so far, although I hope to use it in the future, once 
>> it’s 
>>officially released.
>>3. I want to keep the implementation as concise as possible, but 
>>unfortunately I can’t use Scala for this, I have to use Java. Therefore, 
>> I 
>>cannot resort to Scala structures that would shorten the implementation 
>>like case classes and tuples – they just look bad when used from Java.
>>4. I’m using an Actor per request approach for these services, 
>>meaning that once a response is sent the actor is stopped.
>>
>>
>> I’ve tried two approaches so far:
>>
>>
>>1. Use an actor that uses context.become after each asynchronous call 
>>and holds the intermediate data in private fields. In this case there is 
>> no 
>>single place to look at in this Actor in order to get a “birds’ eye” view 
>>of the logical flow. 
>>2. Use the ask pattern to convert calls to other actors (e.g. to the 
>>actors mediating the access to other services like the database) to 
>> futures 
>>and then compose them using map\flatMap\etc. While this allows me to more 
>>comfortably compose the various asynchronous steps, I’m worried about the 
>>performance implications of this. It says everywhere I look that ask is 
>> not 
>>as efficient as tell (although I have no way to tell by how much…).
>>
>>
>> Bo

[akka-user] Changing socket options from the Java API of Akka IO

[Adam]

Hi,

Is there a way to change socket options such as send & receive buffers from 
the Java API?
All I can find is the set of Scala case classes (e.g. 
http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize),
 
but to the best of my knowledge there is no way to use case classes from 
Java, so I'm wondering if I must create Scala wrappers that can be called 
from Java to achieve this.

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

Re: [akka-user] Changing socket options from the Java API of Akka IO

[Adam]

Hi,

Thanks, this indeed works.
However, just for the record, the way to reference these classes is not 
exactly as the average Java programmer would expect.
I had to decompile the Akka classes in order to understand what to do.

Because these are nested classes I initially expected the call to the 
constructor to look like this:

import akka.io.Inet;
...
final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234);



But actually this will fail compilation.
The correct way to make the call is this:

import akka.io.Inet;
...
final Inet.SocketOption sendBufferSize = new akka.io.Inet$SO$SendBufferSize(
1234);


Which, at least in Eclipse, has the nasty side effect of marking the case 
class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be 
referenced using its binary name).

Anyway, red marker aside, this works.


On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote:
>
> Hi Adam,
>
> Scala’s case classes are normal classes, they just come with a few 
> auto-generated methods (like productIterator() and  static apply()). 
> Nothing stands in the way of using them just like any other Java class.
>
> Regards,
>
> Roland
>
> 23 jul 2014 kl. 10:24 skrev Adam >:
>
> Hi,
>
> Is there a way to change socket options such as send & receive buffers 
> from the Java API?
> All I can find is the set of Scala case classes (e.g. 
> http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize),
>  
> but to the best of my knowledge there is no way to use case classes from 
> Java, so I'm wondering if I must create Scala wrappers that can be called 
> from Java to achieve this.
>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
> twitter: @rolandkuhn
> <http://twitter.com/#!/rolandkuhn>
>  
>

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

Re: [akka-user] Changing socket options from the Java API of Akka IO

[Adam]

Wait...
As long as I'm looking at decompiled code, maybe this is just a 
documentation issue.
Isn't this really the correct way to do this from Java code:

final Inet.SocketOption sendBufferSize = TcpSO.receiveBufferSize(1234);


It doesn't appear in the javadocs of 2.3.4, but the factory methods are 
there in the class.


On Wednesday, July 23, 2014 1:39:48 PM UTC+3, Adam wrote:
>
> Hi,
>
> Thanks, this indeed works.
> However, just for the record, the way to reference these classes is not 
> exactly as the average Java programmer would expect.
> I had to decompile the Akka classes in order to understand what to do.
>
> Because these are nested classes I initially expected the call to the 
> constructor to look like this:
>
> import akka.io.Inet;
> ...
> final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234);
>
>
>
> But actually this will fail compilation.
> The correct way to make the call is this:
>
> import akka.io.Inet;
> ...
> final Inet.SocketOption sendBufferSize = new akka.io.
> Inet$SO$SendBufferSize(1234);
>
>
> Which, at least in Eclipse, has the nasty side effect of marking the case 
> class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be 
> referenced using its binary name).
>
> Anyway, red marker aside, this works.
>
>
> On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote:
>>
>> Hi Adam,
>>
>> Scala’s case classes are normal classes, they just come with a few 
>> auto-generated methods (like productIterator() and  static apply()). 
>> Nothing stands in the way of using them just like any other Java class.
>>
>> Regards,
>>
>> Roland
>>
>> 23 jul 2014 kl. 10:24 skrev Adam :
>>
>> Hi,
>>
>> Is there a way to change socket options such as send & receive buffers 
>> from the Java API?
>> All I can find is the set of Scala case classes (e.g. 
>> http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize),
>>  
>> but to the best of my knowledge there is no way to use case classes from 
>> Java, so I'm wondering if I must create Scala wrappers that can be called 
>> from Java to achieve this.
>>
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@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.
>>
>>
>>
>>
>> *Dr. Roland Kuhn*
>> *Akka Tech Lead*
>> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
>> twitter: @rolandkuhn
>> <http://twitter.com/#!/rolandkuhn>
>>  
>>

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

Re: [akka-user] Changing socket options from the Java API of Akka IO

[Adam]

OK.

Thanks a lot.

On Wednesday, July 23, 2014 1:52:57 PM UTC+3, rkuhn wrote:
>
> Ah, right, that is the more direct route. This is in the JavaDoc by way of 
> “implemented super-interfaces”.
>
> Regards,
>
> Roland
>
> 23 jul 2014 kl. 12:49 skrev Adam >:
>
> Wait...
> As long as I'm looking at decompiled code, maybe this is just a 
> documentation issue.
> Isn't this really the correct way to do this from Java code:
>
> final Inet.SocketOption sendBufferSize = TcpSO.receiveBufferSize(1234);
>
>
> It doesn't appear in the javadocs of 2.3.4, but the factory methods are 
> there in the class.
>
>
> On Wednesday, July 23, 2014 1:39:48 PM UTC+3, Adam wrote:
>>
>> Hi,
>>
>> Thanks, this indeed works.
>> However, just for the record, the way to reference these classes is not 
>> exactly as the average Java programmer would expect.
>> I had to decompile the Akka classes in order to understand what to do.
>>
>> Because these are nested classes I initially expected the call to the 
>> constructor to look like this:
>>
>> import akka.io.Inet;
>> ...
>> final Inet.SocketOption sendBufferSize = new Inet.SO.SendBufferSize(1234
>> );
>>
>>
>>
>> But actually this will fail compilation.
>> The correct way to make the call is this:
>>
>> import akka.io.Inet;
>> ...
>> final Inet.SocketOption sendBufferSize = new akka.io.
>> Inet$SO$SendBufferSize(1234);
>>
>>
>> Which, at least in Eclipse, has the nasty side effect of marking the case 
>> class in red(The nested type akka.io.Inet$SO$SendBufferSize cannot be 
>> referenced using its binary name).
>>
>> Anyway, red marker aside, this works.
>>
>>
>> On Wednesday, July 23, 2014 12:24:45 PM UTC+3, rkuhn wrote:
>>>
>>> Hi Adam,
>>>
>>> Scala’s case classes are normal classes, they just come with a few 
>>> auto-generated methods (like productIterator() and  static apply()). 
>>> Nothing stands in the way of using them just like any other Java class.
>>>
>>> Regards,
>>>
>>> Roland
>>>
>>> 23 jul 2014 kl. 10:24 skrev Adam :
>>>
>>> Hi,
>>>
>>> Is there a way to change socket options such as send & receive buffers 
>>> from the Java API?
>>> All I can find is the set of Scala case classes (e.g. 
>>> http://doc.akka.io/api/akka/snapshot/index.html#akka.io.Inet$$SO$$SendBufferSize),
>>>  
>>> but to the best of my knowledge there is no way to use case classes from 
>>> Java, so I'm wondering if I must create Scala wrappers that can be called 
>>> from Java to achieve this.
>>>
>>> -- 
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@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.
>>>
>>>
>>>
>>>
>>> *Dr. Roland Kuhn*
>>> *Akka Tech Lead*
>>> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
>>> twitter: @rolandkuhn
>>> <http://twitter.com/#!/rolandkuhn>
>>>  
>>>
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+...@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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
> twitter: @rolandkuhn
> <http://twitter.com/#!/rolandkuhn>
>  
>

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

Re: [akka-user] Futures vs actors

[Adam]

I suspect any kind of long running operation running on the same dispatcher 
as other actors (or futures) that are supposed to work at a high throughput 
is problematic - future or actor.

On Wednesday, July 30, 2014 9:09:00 PM UTC+3, Saurabh Rawat wrote:
>
> Hi Bartłomiej,
>
> One more thing, actors are supposed to execute fast code, for any sort of 
> blocking or expensive computation you would make a future anyway. 
>
> Regards,
>
> Saurabh Rawat
>
>
> On Wed, Jul 30, 2014 at 8:34 PM, Martynas Mickevičius <
> martynas.m...@typesafe.com > wrote:
>
>> Hi Bartłomiej,
>>
>> you have laid quite a few arguments for one and the other camp.
>>
>> One more limitation of Future compared with an Actor is that data can 
>> flow only one way in the Future. On the contrary data can flow forward, 
>> backward or even to some other direction when using an Actor.
>>
>>
>>
>> On Mon, Jul 28, 2014 at 12:42 AM, Bartłomiej Szczepanik > > wrote:
>>
>>> I would like ask more experienced people how you choose between futures 
>>> and actors when you are about to implement some asynchronous 
>>> processing/business logic. I was thinking hard and reading about it and had 
>>> a lot of discussion with different people. 
>>>
>>>  
>>>
>>> The first, quite obvious criterion for me is statefulness or 
>>> statelessness. Actors are great for state encapsulation and management. For 
>>> example they fit ideally to DDD Aggregate pattern (and akka-persistence 
>>> helps here a lot). 
>>>
>>>  
>>>
>>> So let's say we are about to implement something stateless. I've heard 
>>> from some people that in this case Futures are the best option. They 
>>> compose nicely what really helps to manage more complicated business logic. 
>>> I am not sure the Futures are the way to go because I have seen a lot of 
>>> examples in activators, documentation and blog posts with stateless 
>>> behavior. 
>>>
>>>  
>>>
>>> The main point against the stateless actors is that they are 
>>> transactional units. Handling of each message is done one by one and it 
>>> seems to be very inefficient. Of course we can get rid of it by spawning 
>>> multiple actors and setting up routers in front of them. But still it seems 
>>> to be unnecessary complicated comparing to simply starting many futures or 
>>> executing the same lines of code parallelly (I assume thread safety).
>>>
>>>  
>>>
>>> Do you have a good criteria to choose the better option in particular 
>>> use case? What disadvantages Futures have which make actors more attractive 
>>> in stateless scenario?
>>>
>>>
>>> Best,
>>>
>>> Bartłomiej
>>>
>>> -- 
>>> >> 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  – Reactive 
>>  Apps 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.
>>
>
>

-- 
>>  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: Tackling the ask pattern and `timeout hell`

[Adam]

I was facing a similar decision a few weeks ago.

For now, I've went with the actor per request approach that Martynas 
mentions.
The actor basically looks like a series of receive methods and I use become 
to switch between them.
Each switch is done whenever I need to wait for an asynchronous call 
(usually when accessing the database).

I also tried the approach of using futures (via the ask pattern), but this 
indeed was harder to work with mainly because it was hard to troubleshoot 
based on error messages and becuase I kept having to disable or lengthen 
these timeouts while debugging.

Note that I don't copy context data between become calls, I use private 
members in the Actor (the blog post also mentions this).




On Monday, July 28, 2014 12:49:31 AM UTC+3, Bartłomiej Szczepanik wrote:
>
> Dear Hakkers,
>
>
> In my current project I have experienced that ask pattern is a kind of 
> awkward solution. I really like it for its elegance and readability but 
> besides not very efficient implementation (spawning actor per each request) 
> it introduces a phenomenon which I call `timeout hell`. It is really hard 
> to introduce a consistent timeout for a user request when you use several 
> ask requests in your pipeline.
>
>  
>
> I have also seen that many people discourage from using that pattern and 
> encourage to replace it with actor per request pattern. Personally I don't 
> see any difference with the ask implementation with a new actor spawned 
> each time. It would be great if someone convince me why it is different and 
> better.
>
>  
>
> I'm guessing the cause of this problem is not about the usage of the ask 
> pattern itself but due to crappy, not reactive design of the system. I 
> agree that the best is not to wait or block for anything. But currently I 
> cannot use fully reactive pipeline with pushing events to GUI and so on. 
> However, I'd like to block user only on HTTP request and be fully reactive 
> in the rest of the pipeline. But still there is a problem. Let me describe 
> it on a simple example.
>
>  
>
> Let's say the backend can handle ChangeColorOfItem command. In the 
> old-style application we probably would write something like (pseudocode):
>
> on(ChangeColorOfItem cmd) {
>
>  item = itemRepository.getById(cmd.itemId)
>
>  item.changeColorTo(cmd.getColor)
>
>  itemRepository.save(item)
>
> }
>
>  
>
> It's easy for me to translate it to akka using ask pattern. But as I said, 
> I would like to avoid it. I came up with several possible solutions:
>
>  
>
> Fire and forget solution
>
>  
>
> The idea is to move all but first steps to recipients of respective 
> messages. For example the repository command retrieves the requested item 
> and sends message to the retrieved item basing on the passed context. I 
> don't like the idea because of scattering of business logic and hindering 
> the reusability of components. 
>
>  
>
> Create an actor and split the business logic on multiple steps
>
>  
>
> Something more sophisticated. Here's some sample of code:
>
>  
>
> Receive = {
>
>   match msg @ ChangeColorOfItem(itemId, color) => {
>
>  itemRepository ! GetById(itemId, Context(sender, msg))
>
>   }
>
>   match RepositoryResponse(item: ActorRef, context) => {
>
>  item ! ChangeColorTo(context.msg.color, context)
>
>   }
>
>   match event @ ColorChanged(itemId, color, context) => {
>
>  itemRepository ! SaveEvent(event)
>
>   }
>
>   match ItemSaved(context) => {
>
>   context.sender ! ColorSuccessfullyChanged(context.msg.id, 
> context.msg.color)
>
>   }
>
> }
>
>  
>
> Advantages (comparing to ask pattern):
>
>- The entire use case logic is still in one place (one actor) 
>- Timeouts handling moved on a higher level (e.g. REST interface 
>level) what enables easy timeout management per entire use case 
>- No problem with resource leaks when there is a timeout or heavy load 
>(no stale future objects in memory, only lightweight message) 
>
>  
>
> Disadvantages:
>
>- Need to pass context explicitly all the time 
>- Logic is harder to read due to steps introduction (a little similar 
>to use of callbacks) 
>- Exclusive processing of steps that in fact don't need that 
>
>  
>
> Different ideas
>
>  
>
> I was thinking about leveraging Futures for similar idea as above. I 
> wanted to pass some kind of callback with the message and it's context to 
> the next recipient. That allows me to keep code in one place (unfortunately 
> in callbacks but still). However I think it is impossible to send a lambda 
> in a message to the actor. Is that any workaround? If so, would you find 
> this approach useful?
>
>  
>
> Generally I would prefer to use a solution that keeps the idea of 
> "application/use case service" which orchestrates the fine-grained classes 
> and encapsulates use cases in the code in exactly one place. If you think 
> it's impossible in reactive approach, please explain that and give some 
> alterna

[akka-user] modifying log level at run-time

[Adam]

Hi,

I know Akka's configuration does not get reloaded at run-time (see here 
).
It is however quite a common use case for logger settings to be re-loadable 
at run-time.
Is there any way to achieve this?

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

Re: [akka-user] modifying log level at run-time

[Adam]

Hi,

One more follow up question.
When using the setting advised by the documentation for this scenario 
(http://doc.akka.io/docs/akka/snapshot/java/logging.html#SLF4J) the only 
real gap from what I need is that with akka.logLevel set to DEBUG and with 
the SLF4J binding configured to INFO, writing code like this:

 
   if (logger.isDebugEnabled()) {
  logger.error("This is an error");
}


Will cause the above error to be logged, which isn't really what I'd expect 
to happen (I'd expect nothing to be logged).

If I were to use the event bus to circumvent this, it would probably 
resolve many cases of this happening (depending on how often this code is 
reached and how often I’d be polling the configuration), but it wouldn’t 
really make this go away.
So should I really go down this road, or is this really a bug that could be 
fixed in Akka?
Or maybe this is actually an intended limitation?

-- 
>>  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: Handle legacy blocking IO (InputStream/OutputStream)

[Adam]

Hi,

I'm not sure how using protobuf forces you to communicate in a blocking 
manner.
I'm also using it but over akka.io, which is modeled as actors, so it's 
completely non blocking and works in exactly the same way as the rest of my 
application does.




On Tuesday, September 2, 2014 11:44:27 AM UTC+3, Andy Bean wrote:
>
> I'm new to akka and have a problem when handling blocking IO. I need to 
> integrate the protobuf library that is reading/writing data using standard 
> java InputStream/OutputStream in a blocking way.
>
> In my case I open a network connection using a SocketChannel and create an 
> InputStream and an OutputStream from it. Now I need to read and write data 
> concurrently. My first approach was to have a Future for reading data in an 
> blocking way and sending it to the enclosing actors. Writing is done in a 
> separate actor. When I receive an error I can only stop the writer but not 
> the reader.
>
> My structure:
>
> class Handler extends Actor {
>  val reader: Future
>  val writer: ActorRef
> }
>
> I'm a bit lost now because I need to handle connection failures and 
> reconnect on errors. What would be the best way to handle my situation?
>
> Greetings,
>  Andy
>

-- 
>>  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: Handle legacy blocking IO (InputStream/OutputStream)

[Adam]

(by akka.io, I meant the IO package of akka 
<http://doc.akka.io/docs/akka/2.3.5/scala/io.html>, of course...)

On Tuesday, September 2, 2014 4:06:56 PM UTC+3, Adam wrote:
>
> Hi,
>
> I'm not sure how using protobuf forces you to communicate in a blocking 
> manner.
> I'm also using it but over akka.io, which is modeled as actors, so it's 
> completely non blocking and works in exactly the same way as the rest of my 
> application does.
>
>
>
>
> On Tuesday, September 2, 2014 11:44:27 AM UTC+3, Andy Bean wrote:
>>
>> I'm new to akka and have a problem when handling blocking IO. I need to 
>> integrate the protobuf library that is reading/writing data using standard 
>> java InputStream/OutputStream in a blocking way.
>>
>> In my case I open a network connection using a SocketChannel and create 
>> an InputStream and an OutputStream from it. Now I need to read and write 
>> data concurrently. My first approach was to have a Future for reading data 
>> in an blocking way and sending it to the enclosing actors. Writing is done 
>> in a separate actor. When I receive an error I can only stop the writer but 
>> not the reader.
>>
>> My structure:
>>
>> class Handler extends Actor {
>>  val reader: Future
>>  val writer: ActorRef
>> }
>>
>> I'm a bit lost now because I need to handle connection failures and 
>> reconnect on errors. What would be the best way to handle my situation?
>>
>> Greetings,
>>  Andy
>>
>

-- 
>>>>>>>>>>  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: combining receive pfs - am I being stupid here?

[Adam]

Interesting.
Which Scala version are you using?

I've copied your code into a Scala project I have that uses Scala 2.11.2 
(with akka 2.3.6) and I get no warnings.
Also the IDE (Intellij) correctly shows that receive is of type 
PartialFunction[Any,Unit].

Have you tried modifying it to:

def receive: Receive = { x orElse y }

?

I would assume that should cause type inference to be skipped and therefore 
also make the warning go away, like in the previous answer.

On Tuesday, September 23, 2014 7:29:08 PM UTC+3, Tim Pigden wrote:
>
> The following example:
>
> class TestPF extends Actor {
>
>   val x: Receive = {
> case "hi" => sender ! "hello"
>   }
>
>   val y: Receive = {
> case "bye" => sender ! "farewell"
>   }
>
>   def receive = { x orElse y }
>
> }
>
> gets a warning
> Warning:(18, 28) a type was inferred to be `Any`; this may indicate a 
> programming error.
>   def receive = { x orElse y }
>^
>
> Am I doing something wrong? I thought this was the intended use pattern. 
> Can I make these warnings go away?
>

-- 
>>  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: combining receive pfs - am I being stupid here?

[Adam]

I think you can assume this is some kind of bug.
According to the definition of Receive 
<http://doc.akka.io/api/akka/2.3.6/?_ga=1.83289750.1264712766.1405541415#akka.actor.Actor$@Receive=PartialFunction[Any,Unit]>
 
it's equivalent to PartialFunction[Any, Unit] and yet, the following 
generates no warning (changed the declared return type of y):

class TestPF extends Actor {

  val x: Receive = {
case "hi" => sender ! "hello"
  }

  val y: PartialFunction[Any, Unit] = {
case "bye" => sender ! "farewell"
  }

  def receive = x orElse y

}

So you should probably open a Scala bug for this, if there isn't already 
one.

On Wednesday, September 24, 2014 1:30:57 AM UTC+3, Tim Pigden wrote:
>
> seems to be to do with the Xlint option
>
>
> On Tuesday, September 23, 2014 11:16:51 PM UTC+1, Tim Pigden wrote:
>>
>> sorry meant to add - yes with or without { } it has the same and just 
>> changing now to 2.3.6 it makes no different
>>
>> On 23 September 2014 23:15, Tim Pigden 
>> > wrote:
>>
>>> 2.11.2 (akka 2.3.4)
>>>
>>> scalacOptions := Seq("-feature", "-deprecation", "-encoding", "utf8", 
>>> "-Xlint")
>>>
>>> On 23 September 2014 21:26, Adam > 
>>> wrote:
>>>
>>>> Interesting.
>>>> Which Scala version are you using?
>>>>
>>>> I've copied your code into a Scala project I have that uses Scala 
>>>> 2.11.2 (with akka 2.3.6) and I get no warnings.
>>>> Also the IDE (Intellij) correctly shows that receive is of type 
>>>> PartialFunction[Any,Unit].
>>>>
>>>> Have you tried modifying it to:
>>>>
>>>> def receive: Receive = { x orElse y }
>>>>
>>>> ?
>>>>
>>>> I would assume that should cause type inference to be skipped and 
>>>> therefore also make the warning go away, like in the previous answer.
>>>>
>>>>
>>>> On Tuesday, September 23, 2014 7:29:08 PM UTC+3, Tim Pigden wrote:
>>>>>
>>>>> The following example:
>>>>>
>>>>> class TestPF extends Actor {
>>>>>
>>>>>   val x: Receive = {
>>>>> case "hi" => sender ! "hello"
>>>>>   }
>>>>>
>>>>>   val y: Receive = {
>>>>> case "bye" => sender ! "farewell"
>>>>>   }
>>>>>
>>>>>   def receive = { x orElse y }
>>>>>
>>>>> }
>>>>>
>>>>> gets a warning
>>>>> Warning:(18, 28) a type was inferred to be `Any`; this may indicate a 
>>>>> programming error.
>>>>>   def receive = { x orElse y }
>>>>>^
>>>>>
>>>>> Am I doing something wrong? I thought this was the intended use 
>>>>> pattern. Can I make these warnings go away?
>>>>>
>>>>  -- 
>>>> >>>>>>>>>> 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/0rkUCQxru5I/unsubscribe.
>>>> To unsubscribe from this group and all its topics, 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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Tim Pigden
>>> Optrak Distribution Software Limited
>>> +44 (0)1992 517100
>>> http://www.linkedin.com/in/timpigden
>>> http://optrak.com
>>> Optrak Distribution Software Ltd is a limited company registered in 
>>> England and Wales.
>>> Company Registration No. 2327613 Registered Offices: Suite 6,The 
>>> Maltings, Hoe Lane, Ware, SG12 9LR England 
>>&

[akka-user] Akka Cluster Metrics- Node Wise

[Adam]

You cannot have separate cpu and heap metrics for nodes within the same JVM.
OSGI won't help either - it mostly achieves containment through complex class 
loaders.

You could sort of have an approximiation of CPU consumption per node by summing 
up the thread cpu consumption for the related dispatcher threads, but that 
would disregard all implicit CPU, like that of GC.

Heap monitoring is yet even harder. The JVMTI API provides some basic 
facilities to acheive that, but the overhead is likely to kill your 
application. Plus it's a huge amount of work, so you'd be better off paying for 
a commercial monitoring product (which still doesn't resolve the issue of 
overhead and probably doesn't give you exactly what you want).

Much cheaper to run several JVMs...

-- 
>>  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] Realtime (as in Electronics) processing in Akka and Garbage Collection's Effect to It

[Adam]

There is also an option of trying the Zing JVM from Azul. It's not free, but 
depending on your case, it might end up being cheaper in the overall, assuming 
it does what they claim - I've never used it myself, only talked to other 
people who were using it.

Also it's possible for some applications to be written in a way that minimize 
the allocation rate. Unfortunately I think this doesn't work well with 
immutability and it can also mean just as much extra effort as writing in a 
different language.

If you do stay on the JVM, Azul also published a free and very useful tool 
called jhiccup (for obviius reasons 😄 ).

-- 
>>  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: [Java 2.3.x] Default message behaviors?

[Adam]

One easy way is to extend UntypedActor, override whatever methods you need 
with final methods and provide your own callback methods for overriding by 
sub classes.
The slightly messy part of this is that you’ll be forced to provide 
callback method names with different names (e.g. onResolverReceive).

A nicer but slightly more complex solution is to use something like AspectJ 
with load time weaving and simply mark classes for which you need such 
defaults with an annotation, interface, or some coding convention.


On Monday, October 20, 2014 10:34:44 PM UTC+3, Chanan Braunstein wrote:
>
> Hello,
>
> Is it possible to define a base class for actors that will provide some 
> default behaviors? For example I create a MyAbstractActor that handles 
> MyMessage type. Someone on my team can then extend that class and handle 
> some other types as well. Somewhat like AbstractPersistentActor handles 
> Persistent messages, but in Java and hopefully without implementing all of 
> Actor which at a glance seems like AbstractPersistentActor is doing.
>
> Thanks,
> Chanan
>

-- 
>>  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] How to Monitor akka, improving performance

[Adam]

I suspect a thread dump in this state and the akka version you're using would 
be invaluable to understanding this.

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

Re: [akka-user] Testing per-request child creation

[Adam]

It's a matter if opinion and I risk stating the obvious, but my (unoriginal) 
rules of thumb are: 

Updates to internal state are out of scope for tests. Sometimes when something 
is not testable, it's for a good reason - you're code should simply be 
modified. This is one of those cases.

Adding introspection methods for tests purposes only is a bad practice, but if 
you already have such a method that is part of the public interface of the 
component under test, then it's legitimate to use it.

For cases where this is not the case you can consider encapsulating the state 
in a separate object that can be passed into the component under test (although 
doing this for something as simple as a timestamp does sound a bit too much).

Alternatively for some cases where the actor can be said to give message based 
access to some encapsulated state, I extract that to a separate class that can 
be unit tested separately.

-- 
>>  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] Maven, scala, akka - version mismatch

[Adam]

Try running "mvn dependency:tree" (before and after commenting out).
It will show you exactly how you get each library. 
Most probably you're getting akka 2.3.X for scala 2.11 as a transitive 
dependency.

-- 
>>  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: Sharing behavior among Actors in Java

[Adam]

 

Hi,
I guess the correct answer is "it depends" J, but I can describe what we 
use right now, as we're also using Akka (and seeing as it's been very 
rewarding to do so we do it more and more), but are confined to Java.So 
first of all, I would recommend against inheritance.
That route quickly becomes very tangled and results in a huge hierarchy of 
classes with way too many methods.

We typically use composition.
I assume the real issue is cases where you want to reuse code that relies 
on running inside an Actor.
Unfortunately UntypedActor is not an interface, so it's indeed difficult to 
mix in behavior.However, since a class method is really not much more than 
a static method that implicitly accepts the "this" pointer (some languages 
like python and Ada even work that way and specify all arguments 
explicitly), your actors can contain other classes that either have methods 
which accept an UntypedActor as a parameter, or accept it in their 
constructor.

We use that often for synchronous paths.

An example:

public class DbAccess {
private final UntypedActor owner;
public DbAccess(UntypedActor owner) {
this.owner = owner;
}

//methods for DB access
}

public class Auth {
private final UntypedActor owner;
public Auth(UntypedActor owner) {
this.owner = owner;
}

//methods for Authentication
}


public class MyActor extends UntypedActor{
private final DbAccess db = new DbAccess(this);
private final Auth auth = new Auth(this);

public void onReceive(Object msg){
//use the shared logic of db and auth wherever needed
}
}

(One nasty issue here is that the constructor of MyActor is sending "this" 
before it's fully constructed, so it's probably better to move the 
initialization of dependencies to preStart, but I kept the code shorter 
here)

There are exceptions to this rule.

For example, if you wanted to override any of the UntypedActor methods 
(e.g. we do that for one-off actors so they will stop in case of an 
unhandled message), you'd have to use inheritance, so in some cases we do 
use that, but we try to keep it down to as few levels of it as possible.


Another alternative if you're using Java 8 AND your methods don't rely on 
state, is to use interfaces with default methods,as a poor man's 
replacement for Scala traits.

In that case, if you wanted to rely on running inside an actor you could 
require actors to implement a single interface that exposes the this 
pointer and then add as many interfaces with default methods as you wish.
For example:

public interface ActorExposer {
public UntypedActor getActor();
}

public interface DbUser extends ActorExposer{
//methods for DB access
public default ...
}

public class Auth extends ActorExposer{
//methods for Authentication
public default ...
}


public class MyActor implements DbUser, Auth{
public void onReceive(Object msg){
//use the shared logic of db and auth whereever needed
}

@Override
public UntypedActor getActor() {
return this;
}
}




Finally, for asynchronous paths we simply use more actors, but I assume 
that was already obvious to you and you were asking about the previous part 
of my answer.
I hope this helps.


Adam.

  

On Tuesday, January 13, 2015 at 10:46:45 PM UTC+2, Alon Goldshuv wrote:
>
> (newbie question)
>
> Hi,
>
> I'd like to write a set of Actors that behave very similarly, however have 
> a few differences as well. 
> In plain java world I'd write an Abstract parent class that includes all 
> of the shared behavior, have each child class extend it, and override only 
> the class methods that differ from the abstract class implementation.
>
> I'm not sure how to do it in Akka - Java. I've seen a very similar 
> question and a really nice answer here 
> <http://stackoverflow.com/questions/17383827/how-do-i-best-share-behavior-among-akka-actors>,
>  
> but it's using scala, and scala traits.
>
> My initial thought was something like:
>
> public abstract class MyParentActor(...) extends UntypedActor {
> ...
> 
> }
>
>
> public class MyChildActor1(...) extends MyParentActor {
> super(...);
> 
>
> public void onReceive(msg) {
>   
> }
> }
>
> Is that a good idea? will that work?
>
> BTW, since the project has yet to start, I'm not tied to a specific Akka 
> version, so I assume 2.3.8.
>
> Thanks in advance!
> Alon.
>
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>  Search the archives:

[akka-user] Re: One-Actor-Per-Request pattern with Akka-Http

[Adam]

So why not always return OK in such cases?

-- 
>>  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: Using different names for application.conf

[Adam]

See here: http://doc.akka.io/docs/akka/snapshot/general/configuration.html

You can add the system property -Dconfig.resource=
And load whatever file you wish as your configuration file.

On Monday, February 2, 2015 at 8:55:13 PM UTC+2, Mark Kaberman wrote:
>
> My application consists out of multiple services (daemons) which 
> unfortunately have to share the location for configuration files. I would 
> prefer to avoid maintaining single application.conf which is shared by all 
> services due to logistical reasons. I also cannot package individual 
> application.conf in the jars since I would like to have the ability to 
> tweak my configuration on the fly (changing number of actor's instances). 
> So my question is if it is possible to use different names for 
> configuration files instead of application.conf? This will allow each 
> service to have own configuration which can share at the same location.
>
> Thanks,
>
> Mark
>
>

-- 
>>  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: Why AKKA Microkernel

[Adam]

You might want to look at
sbt-native-packager<https://github.com/sbt/sbt-native-packager>.
I use it for all of my projects that need to be run on servers and it works
great!  I also use yajsw <http://yajsw.sourceforge.net/> to run it as a
service since at work I need to use Windows servers :(

~Adam~


On Wed, Jan 22, 2014 at 12:58 PM, Peter Wolf  wrote:

> Thanks Victor, I had read that doc, but it left me puzzled.  That's why I
> asked here.
>
> Here is the important paragraph:
>
> "The purpose of the Akka Microkernel is to offer a bundling mechanism so
> that you can distribute an Akka application as a single payload, without
> the need to run in a Java Application Server or manually having to create a
> launcher script."
>
> I would normally create a shell script that simply calls "java 
> ".  It is some work to get the classpath right and include
> everything needed by Akka and my application.  I would then zip everything
> up and copy it manually to each machine, where I would install it.  I would
> finally set up the machine to boot my Actors when the system comes up.
>
> Is this the work that Microkernel makes easier?  Is this why I should use
> it?
>
> Thanks
> P
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
> >>>>>>>>>> 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/groups/opt_out.
>

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

Re: [akka-user] How can I reconcile untyped actors with typeful programming?

[Adam]

While far from perfect, one thing that I do is strictly following the
convention that the only objects a specific actor will process are defined
within that actor's companion object.

I also refrain from directly importing those objects/classes anywhere so I
always have to write out actor.message when sending it. I find that
actually helps a lot.

-- 
>>  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 it possible to use Akka logging while only referencing SLF4J API?

[Adam]

Hi,

I've read thorough the instructions under the logging chapter of the Akka 
manual(Java API in this case) and it seems like what it requires is 
directly using the akka.event.Logging and akka.event.LoggingAdapter classes.
(BTW Suspecting I might have missed something in the documentation, I 
looked for a StaticLoggerBinder class inside the akk-slf4j jar, but 
couldn't find one.)

So I'm wondering if there's a way to avoid this and only use the SLF4J API.
My motivation for doing this is:

   1. I'll have a single logging API used throughout the application
   2. SLF4J actual implementation can be replaced more easily than when 
   having Akka hard-coded everywhere.
   3. Other parts of the application which may not even be aware of running 
   inside an Akka actor system and are already using the SLF4J API, will 
   automatically be switched to using the AKKA implementation.

As it currently stands I can only make parts of the application use Akka 
logging, while other parts will use some other logging framework's 
asynchronous logging and all which that entails (extra threads, locks, etc.)



-- 
>>  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 it possible to use Akka logging while only referencing SLF4J API?

[Adam]

 


Well, I guess that answers my question.

It's just that the explanation about the motivation for using Akka's 
logging ignores the fact that very large portions of the system could be 
unaware of running inside an actor system, which means the performance 
benefit of using Akka's logging is quite limited.
The more classes you have that are unaware of running inside an actor 
system, the more classes you have that use standard logging facilities 
which in turn means using locks, extra threads etc.
I was hoping to find a way to shed that extra weight, but I guess there 
isn't one for now.

Thanks.

 


On Monday, June 23, 2014 6:55:19 PM UTC+3, Björn Antonsson wrote:
>
> Hi Adam,
>
> I'm not sure that I understand your question completely.
>
> Akka can use slf4j as a backend for akka logging. Akka does not provide a 
> generic slf4 backend that uses an akka actor system.
>
> In your akka code you can use akka logging and in your other code you can 
> use slf4j, and the logging can be combined with the help of the akka-slf4j 
> mdoule.
>
> B/
>
> On 22 June 2014 at 10:01:52, Adam (adam...@gmail.com ) wrote:
>
> Hi,
>
> I've read thorough the instructions under the logging chapter of the Akka 
> manual(Java API in this case) and it seems like what it requires is 
> directly using the akka.event.Logging and akka.event.LoggingAdapter 
> classes.
> (BTW Suspecting I might have missed something in the documentation, I 
> looked for a StaticLoggerBinder class inside the akk-slf4j jar, but 
> couldn't find one.)
>
> So I'm wondering if there's a way to avoid this and only use the SLF4J API.
> My motivation for doing this is:
>
>1. I'll have a single logging API used throughout the application 
>2. SLF4J actual implementation can be replaced more easily than when 
>having Akka hard-coded everywhere.
>3. Other parts of the application which may not even be aware of 
>running inside an Akka actor system and are already using the SLF4J API, 
>will automatically be switched to using the AKKA implementation. 
>
> As it currently stands I can only make parts of the application use Akka 
> logging, while other parts will use some other logging framework's 
> asynchronous logging and all which that entails (extra threads, locks, etc.)
>
>
>
>  --
> >>>>>>>>>> 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.
>
> -- 
> *Björn Antonsson*
> Typesafe <http://typesafe.com/> – Reactive Apps on the JVM
> twitter: @bantonsson <http://twitter.com/#!/bantonsson>
>
>

-- 
>>>>>>>>>>  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: Performance Of Akka IO

[Adam]

I think the OS you're using matters a lot for this sort of test. Hopefully 
it's not windows...

What was the maximum concurrency level that you've tested?
Did you make sure (in the performance test code) that this concurrency 
level is actually met in all cases?
Did you try tweaking with the socket options (e.g. increase the read/write 
buffers)?

It would be interesting indeed to know about ACK/NACK.
I'm using the approach of using NACK until I get failure => buffer until 
getting the resumed message => recover using ACKs.=> go back to NACK once 
the buffer is cleared.
I guess it means less total messages traveling back and forth.



On Sunday, February 22, 2015 at 5:47:24 PM UTC+2, Reid Spencer wrote:
>
> Jim,
>
> I think you’re referring to this reference.conf 
> 
>  which 
> has this section of the scheduler settings:
>
>   # Used to set the behavior of the scheduler.
>   # Changing the default values may change the system behavior drastically 
> so make
>   # sure you know what you're doing! See the Scheduler section of the Akka
>   # Documentation for more details.
>   scheduler {
> # The LightArrayRevolverScheduler is used as the default scheduler in 
> the
> # system. It does not execute the scheduled tasks on exact time, but 
> on every
> # tick, it will run everything that is (over)due. You can increase or 
> decrease
> # the accuracy of the execution timing by specifying smaller or larger 
> tick
> # duration. If you are scheduling a lot of tasks you should consider 
> increasing
> # the ticks per wheel.
> # Note that it might take up to 1 tick to stop the Timer, so setting 
> the
> # tick-duration to a high value will make shutting down the actor 
> system
> # take longer.
> tick-duration = 10ms
>
> # The timer uses a circular wheel of buckets to store the timer tasks.
> # This should be set such that the majority of scheduled timeouts (for 
> high
> # scheduling frequency) will be shorter than one rotation of the wheel
> # (ticks-per-wheel * ticks-duration)
> # THIS MUST BE A POWER OF TWO!
> ticks-per-wheel = 512
>
> I tried various combinations for these two parameters and none of it made 
> more than a 5% difference in the numbers which is probably in the noise 
> range for my test set up. While these settings may have consequences on a 
> large actor system with lots of things going on, that’s not my situation 
> currently. I have one supervisor actor talking to one channel actor talking 
> to one TCP OutgoingConnection actor. It is pretty much linear flow of 
> messages into and out of the Akka IO code, repeated in a loop.  I’ve 
> measured the overheads of the actor system infrastructure (mailbox, message 
> send, etc.) and it is negligible (less than a microsecond). 
>
> Do you have any suggestions on how to look at the performance of Akka IO 
> code? Short of any suggestions from the list, I”m about to start hand 
> instrumenting the Akka IO code to find out where it spends its time. 
>
> Reid. 
>
>
>
> On Feb 21, 2015, at 6:30 PM, jimhaz...@gmail.com  wrote:
>
> Hmm. Then I must have been playing with the setting around the same time. 
> It's definitely related to overall thread scheduling. Poke around the 
> reference.conf files in the core akka jars. There should be a description 
> of the overall methodology in there as well. Timer granularity and number 
> of buckets are the big factors. 
>
> -Jim
>
> -- Sent from my mobile device
>
> On Feb 21, 2015, at 2:47 PM, Reid Spencer  > wrote:
>
> Jim,
>
> The spray-can example benchmark 
> 
>  
> program has an application.conf 
> 
>  
> like this:
>
> akka { loglevel = INFO event-handlers = ["
> akka.event.slf4j.Slf4jEventHandler"] actor.default-dispatcher { 
> fork-join-executor { parallelism-min = 1 parallelism-factor = 1 
> #parallelism-max 
> = 1 } }}(non-akka parts elided)
>
> The only interesting thing there is parallelism-factor which is 1 here 
> while I use 2. I'll try it with the lower value.
>
> Thanks,
>
> Reid.
>
>
> On Saturday, February 21, 2015 at 5:24:40 PM UTC-5, Jim Hazen wrote:
>>
>> Hi Reid,
>>
>> Sorry I don't have my IDE in front of me.  You might take a look at some 
>> of Akka's scheduling configuration options.  You mentioned Spray, and 
>> there's a benchmark example Spray app that ships with a pretty good 
>> application.conf that exposes and tweaks some of these config values, the 
>> scheduler being one of them.  AFAIK the scheduler fires completed tasks on 
>> a clock/tick based timer.  You may be bumping up against the scheduler's 
>> default clock timing threshold, which can be reduced.
>>
>> Hope that helps.
>>
>> -Jim
>>
>
> -- 
> >> Read the do

Re: [akka-user] Performance Of Akka IO

[Adam]

I believe 50M messages per second on a single machine was mainly an example 
for scaling up. See the kind of machine that was used for it 

.

Anyway, have you tried doing the same analysis on the "legacy" driver?
It would be interesting to compare the parts related to actual IO.

There's one thing (which may not be helpful to your current questions about 
Akka performance) that bothers me, but I may just be missing out on 
something obvious here, so I'll just ask: if Mongo doesn't allow a 
connection to handle more than one simultaneous request, how can any NBIO 
implementation do much better than a BIO implementation? I mean the test 
pretty much only does IO. It's not like we're using the extra free thread 
to do any other CPU intensive work while waiting on Mongo, right?
Doesn't it mean you have to hold some sort of connection pool so you can 
have more concurrent requests to Mongo in order to see any sort of benefit 
from using NBIO (Akka or not)?
When I use Akka IO in my application I often have lots of concurrent 
requests using the same socket.
They are of course kept serialized by Akka, but I can still have many 
requests on the same connection.



On Monday, February 23, 2015 at 10:57:41 PM UTC+2, Reid Spencer wrote:
>
> So, here's some more information from my testing which just further 
> confuses me because I’m left without a course of action to solve the 
> performance issue. I instrumented the TcpConnection actor via 
> DiagnosticActorLogging to record System.nanoTime on each log message using 
> MDC and then added some logging statements into the TcpConnection, mostly 
> to record doRead and doWrite entry and exit. I wanted to see if the problem 
> was in the actual I/O or the TcpConnection. The results are a little odd.
>
>  
>  appWait
>  doRequest
>  writeWait
>  doWrite
>  writeAck
>  mongoWait
>  doRead
>  readWait
>  doReply
>   *count*
>  10,000
>  10,000
>  10,000
>  10,000
>  10,000
>  10,000
>  10,000
>  10,000
>  10,000
>   *sum*
>  2,641,699.00
>  0.00
>  362,172.00
>  0.00
>  764,298.00
>  2,836,716.00
>  0.00
>  413,031.00
>  0.00
>   *mean*
>  264.17
>  0.00
>  36.22
>  0.00
>  76.43
>  283.67
>  0.00
>  41.30
>  0.00
>   *median*
>  217.00
>  0.00
>  29.00
>  0.00
>  55.00
>  167.00
>  0.00
>  33.00
>  0.00
>   *std.dev*
>  323.37
>  0.00
>  27.95
>  0.00
>  172.19
>  1,162.76
>  0.00
>  25.92
>  0.00
>   *min*
>  139
>  0
>  3
>  0
>  2
>  125
>  0
>  15
>  0
>   *max*
>  17,719
>  0
>  892
>  0
>  14,616
>  22,565
>  0
>  1,389
>  0
>   
> The above data was computed by processing the log file that has repeating 
> entries like this:
>
> 18:25:17.364UTC 917364997 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-10:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
>  
> -> doRequest
> 18:25:17.365UTC 917364997 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-10:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
>  
> <- doRequest
> 18:25:17.365UTC 917365026 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-10:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
>  
> Entering doWrite
> 18:25:17.365UTC 917365026 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-10:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
>  
> Leaving doWrite
> 18:25:17.365UTC 917365077 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-10:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
>  
> Ack with queuelen=0
> 18:25:17.365UTC 917365173 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-3:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
>  
> Entering doRead
> 18:25:17.365UTC 917365173 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-3:akka.io.TcpOutgoingConnection:akka://RxMongo/system/IO-TCP/selectors/$a/0]
>  
> Leaving doRead
> 18:25:17.365UTC 917365202 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-3:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
>  
> -> doReply
> 18:25:17.365UTC 917365202 DEBUG 
> [RxMongo-akka.actor.default-dispatcher-3:rxmongo.driver.AkkaIOChannel:akka://RxMongo/user/RxMongo-Supervisor-1/Connection-2/ChannelRouter-3/$a]
>  
> <- doReply
> ...

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

[akka-user] Many concurrent network connections

[Adam]

I'll refer you to here: http://doc.akka.io/docs/akka/2.3.9/dev/io-layer.html

It says Akka IO is designed with the requirement of "scalability to millions of 
concurrent connections".

Of course, this typically requires tuning (including at the OS level), but 
sounds like 50k should be supported. I don't know if there was an actual test 
(millions sounds very challenging to me) to prove this to be working, but maybe 
someone of the Akka team can add that bit.

-- 
>>  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: Best practices for selecting or creating actor

[Adam]

First of all, you shouldn't ever block like this, as you do with Await.

As for your question - this sounds like something the parent actor should 
be responsible for.
I'm not even sure the code above works (it at least never occurred to me to 
try to create an actor using a full path as I always understood the docs as 
if it shouldn't be possible).
I think allowing the parent actor to determine if one of his children 
exists or not is cleaner.
It also has direct access to this through the actor context, so the answer 
is immediate.



On Sunday, April 5, 2015 at 10:50:28 PM UTC+3, Fatih Dönmez wrote:
>
> Hi,
>
> I want to create an actor if it didn't created already. To check its 
> existence I use actorSelection. If there is no actor defined by the path, I 
> create a new one with actorOf.
> Is this approach correct? How can I improve the design? Here is the code I 
> come up with currently;
>
> val fullPath: String = path.format(appId)
> var starter: ActorRef = null
> implicit val timeout = Timeout(5 seconds)
>
> try {
>   starter = 
> Await.result(context.actorSelection(fullPath).resolveOne,FiniteDuration(5,TimeUnit.SECONDS))
> } catch {
>   case e: ActorNotFound => {
> starter = context.actorOf(Props(new StarterNode(customer, appId)), 
> name = fullPath)
> logger.info("Actor [" + fullPath + "] creating for first time")
>   }
>   case e: Exception => logger.error("Actor [" + fullPath + "] 
> selection failed",e)
> }
>
> //TODO
> if(starter != null) {
>   starter ! event
> } else {
>   logger.warn("Starter node failed with timeout")
> }
>
>  
>

-- 
>>  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] Overriding default configuration

[Adam]

First of all, regardless of inclusion, you need your build to exclude this 
application.conf file from jars. There's not much point for a configuration 
file that can't be easily modified. It should instead be in a folder (e.g. 
./conf) that is added to your classpath.

Then, you can either add your own file with an include directive for 
application.conf and load your file as the main one via the system property, or 
you can have your build rename the original application.conf (e.g. to 
some-lib.conf) and name your file application.conf and again use the include 
directive with the name you picked.

-- 
>>  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] Number of actors

[Adam]

Hi,

First of all, actors are very lightweight and you can have many of them, while 
an ActorSystem is heavyweight and you should not have many of that (typically 
you'd have one).

As for the pattern you describe - it all depends on the fine details, but if I 
had to implement a service that needs to get a set of details and was permitted 
(and required) to return partial results depending on some timeout, I'd have 
one actor to manage the request, sending the smaller sub requests and I'd 
indeed use the scheduler to cut this off if tge timeout expires.

It might be useful for you to take a look at the aggregator pattern referenced 
from the docs. It has a lot in common with this.

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

[akka-user] Re: High variance in response times when using Akka

[Adam]

As far as high variance - Have you tried looking into GC performance?
I don't know what "around 2ms" means, but if that's the expected max ET 
you're looking for, GC could make this very difficult to achieve.

I would try to use JMH in order to isolate the CPU intensive work and 
optimize whatever algorithm you have there.
Also, I would try to tweak with how you distribute the work.
You may very well find that not distributing it will help you achieve 
better performance.




On Thursday, April 23, 2015 at 1:37:27 PM UTC+3, Josh F wrote:
>
> By the way, I am measuring the latency as the time from when the request 
> handler actor receives the ProcessRequest message to the time when the 
> request handler actor receives all 4 PartialResults for that request.
>
> Also, I am using Akka 2.3.9
>
>


-- 
>>  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] What happens to unhandled(message)?

[Adam]

Unhandled is mainly useful for troubleshooting. Akka won't check if you 
actually did something with the message or not. It also doesn't force you to 
call unhandled and probably (never tried this) does't prevent you from calling 
unhandled multiple times. The documentation goes into detail regarding what 
exactly happens when you call unhandled.

Akka likewise has no "black magic" that checks your logic (e.g. through byte 
code injection). If you've failed to call become or do anything else you should 
have done, the you have a bug and Akka provides the tools to help you track it 
down. For example, calls to unhandled can be translated to debug messages via 
configuration.

-- 
>>  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: Reasons why Logback is recommended for Akka logging

[Adam]

Hi,

Where I work, we're using Akka with log4j2 (through slf4j binding) in 
production.
We're handling billions of daily requests and so far it works flawlessly :-)

On Thursday, May 21, 2015 at 10:55:22 AM UTC+3, monika singhal wrote:
>
> Anyone tried log4j2 with Akka ? 
>
> Thanks,
> Monika
>
>
>

-- 
>>  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] Instrumenting Akka

[Adam]

You can take 2 heap dumps a day or more apart and then use Eclipse MAT to 
compare them (there's a compare basket feature that is very useful in such 
cases).

Actually there's a good chance that even a single heap dump will suffice if the 
JVM has been running for long enough. Try to use the leak suspects report. It 
usually points to the right place.

-- 
>>  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] DynamoDB snapshot plugin?

[Adam]

 

There’s actually one thing you need to take into account when using 
DynamoDB for persistence.

I've been bitten by this a few times when using other Amazon services.


The Java SDK provided by Amazon includes two interfaces: synchronous and 
asynchronous.

I imagine you’d prefer to use the asynchronous API as part of an Akka 
application, but unlike what you often encounter with other such dual APIs, 
the asynchronous API in this case is implemented as a wrapper around the 
synchronous API (using a thread pool) which uses blocking IO. What I’m at 
least used to with other NoSQL clients is having things the other way 
around – an asynchronous client that uses non-blocking IO and a synchronous 
wrapper around it, but that’s not currently the case with the Amazon Java 
SDK. 

 

Given that each operation is actually an HTTP call to the amazon service 
(not sure if there's any batching going on internally, but probably not), 
they can get pretty pricy.

You will need to make sure that you don’t send requests to Amazon faster 
than the client can handle it.

It’s not just a question of overflowing the thread pool, you can also get 
terrible latency for some of the requests this way as they get queued in 
your JVM, which depending on your system, might not be acceptable.

Another option is to make the HTTP calls using your own non-blocking 
client, but that comes with a larger price tag for development time.


And then again, perhaps it's not really an issue in your case and you won't 
even come close to suffering from this.


On Saturday, June 20, 2015 at 8:36:09 PM UTC+3, Bill Goldsworthy wrote:
>
> OK, good to know, thanks!
>
> On Friday, June 19, 2015 at 11:24:50 AM UTC-5, Konrad Malawski wrote:
>>
>> Hi Bill,
>> I don't see a reason why such implementation wouldn't make sense - in 
>> fact many of the other NoSQL stores nowadays are very "dynamo inspired" :-)
>> So I'd say it's just a matter of actually sitting down and implementing 
>> it.
>>
>> PS: We're in the middle of the final adjustment phase in Akka Persistence 
>> (plugin APIs *slightly* affected), after which Persistence will soon become 
>> a stable module (yay!).
>>
>> -- Konrad
>>
>> On Fri, Jun 19, 2015 at 4:20 PM, Bill Goldsworthy  
>> wrote:
>>
>>> Greetings,
>>>
>>> Is there a DynamoDB snapshot plugin for akka-persistence available 
>>> anywhere? There is not one listed on the community page and my searches 
>>> have been fruitless. If not, is this because of technical limitations with 
>>> DynamoDB or simply because one hasn't been created yet?
>>>
>>> Thank you,
>>> Bill Goldsworthy
>>>
>>> -- 
>>> >> 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.
>>>
>>
>>
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka  @ 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: how do I use the scala repl to inspect a "in java written" actor system.

[Adam]

scala -cp 

On Monday, June 29, 2015 at 11:58:14 AM UTC+3, john@gmail.com wrote:
>
> Sorry that  I know so little about scala. 
> I have written a java akka system which uses maven for dependeny 
> management.
>
> I would now like to inspect my configuration (Typesafe Config Library 
> ) with a scala repl. 
> This is described in 
> http://doc.akka.io/docs/akka/2.3.11/general/configuration.html 
> "Logging of Configuration"
>
>
> How do I import my jar into the scala repl so that I can inspect with the 
> repl my cofig?
>
>
>
>

-- 
>>  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-http/spray REST API documentation?

[Adam]

Looks like there's something for spray:

http://github.com/gettyimages/spray-swagger

I imagine there's nothing for Akka HTTP, seeing as it's not even officially 
released yet.

-- 
>>  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] Performance question

[Adam]

The general answer similar questions usually get here is that you'll have to 
measure, but here are a few comments:

1. I'd check what's causing these spikes. The usual suspect is GC.
2. You didn't mention what handling such a request means. Optimally with 2 
cores you have 2000ms per second worth of processing (of course you will have a 
bit less left for you), so if your requests spend the entire 20ms doing actual 
processing, you can't surpass 100 reqs/sec.
If on the other hand you only spend 2ms in the JVM and an extra 18 waiting 
(where waiting means freeing the thread to handle other actors) for some non 
blocking IO operation, then your max is 1000 (and so on).
3. My experience, on my hardware, has been that routers can easily surpass 1500 
reqs/sec, but I refer you to my first sentence...

-- 
>>  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 dispatcher threads get deadlock on log4j classloading

[Adam]

It can be due to a variety of reasons, but there's an implicit lock when 
loading classes and tools that instrument byte codes can sometimes hit this.

Can you post the entire thread dump?
Usually it's very easy to pin point the deadlock from thrrad dump.

-- 
>>  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] Setting akka log level from log4j

[Adam]

I've worked around this by starting an actor that polls a regular slf4j logger 
and then changes the akka log level at run time through the event bus.

It works well enough, although it means selective log levels still incur a high 
overhead, regardless of logging frequency and it also means that enabling 
selective debug logs is a bit more cumbersome than what you must be used to.

I can share the code if that sounds like a reasonable solution in your case.

I think another option is using an asynchronous logger, but then if you want to 
use the data Akka populates in the MDC for akka loggers, you'll have to add it 
on your own.

-- 
>>  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: Setting akka log level from log4j

[Adam]

https://gist.github.com/adamhonen/8863088641df095cce96

Here, I hope that helps.

On Tuesday, August 25, 2015 at 11:52:18 AM UTC+3, Dennis Jönsson wrote:
>
>
>
> Den måndag 24 augusti 2015 kl. 18:58:26 UTC+2 skrev Adam:
>>
>> I've worked around this by starting an actor that polls a regular slf4j 
>> logger and then changes the akka log level at run time through the event 
>> bus.
>>
>> It works well enough, although it means selective log levels still incur 
>> a high overhead, regardless of logging frequency and it also means that 
>> enabling selective debug logs is a bit more cumbersome than what you must 
>> be used to.
>>
>> I can share the code if that sounds like a reasonable solution in your 
>> case.
>>
>> I think another option is using an asynchronous logger, but then if you 
>> want to use the data Akka populates in the MDC for akka loggers, you'll 
>> have to add it on your own.
>>
>
>
>
> Thanks Adam, I would be interested in looking at the code. The only 
> solution I found sofar has been to run debug log level in AKKA at all times 
> and then filter the output through log4j. But that means Akka will have to 
> do alot of unnessecary work all the time. 
>

-- 
>>>>>>>>>>  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] Can Akka actors deadlock?

[Adam]

What kind of web container (if any are you using)?

I'd say using ask and blocking on it is still an improvement with pre 3.0 
servlets.

With asynchronous servlets you can push the AsyncContext down in a message or 
use as in the ask future's onComplete callback.

With other frameworks (Netty, Jetty, Akka HTTP, non blocking 3.1 servlets, 
etc.) things will be even better.

There's just no need to use ask in other places, That's all. In other words it 
makes perfect sense to use it for the integration point between your existing 
blocking code and your new Akka based code and slowly change code to or add new 
asynchronous code. 

-- 
>>  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: system.scheduler.scheduleOnce consumes Heap over time

[Adam]

You can easily check what Roland suggested.

   1. Setup the frequency of the scheduling to be very fast so memory will 
   grow quickly.
   2. connect with visualvm\jconsole to the jvm and initiate gc manually.
   3. Compare the trend of memory of the moments right *after the GC* and 
   see if it's really going up
   4. If you do think there a leak, I'd take a heap dump of live objects 
   and use Eclipse MAT to pin point the retained set with its respective GC 
   root.
   

On Friday, September 4, 2015 at 11:02:02 PM UTC+3, Salvatore Rapisarda 
wrote:
>
> Hi Jeff,
>
> I'm having the same problem. And I did the same, I was thinking it was my 
> application but is the Akka actors that use all the memory ... What can I 
> do?
>
> Salvo
>
> On Tuesday, 12 May 2015 07:02:51 UTC+1, Jeff Steinmetz wrote:
>>
>> I thought there was something specific I was doing wrong in an 
>> application I have deployed in development, which eventually needs to be 
>> production ready.
>>
>> Over time, the Akka actor system slowly consumes all available memory.  I 
>> assumed it was a memory leak that I introduced, but as it turns out, even 
>> the sample Typesafe "hello-akka" app demonstrates the same heap consumption.
>>
>> http://www.typesafe.com/activator/template/hello-akka
>>
>>
>> If you let the sample application above run for a "very long", the heap 
>> usage slowly grows, and is never released.  Although, it is "Very Slow"
>> Since it is set to send a message to the "greeter" only every 1 second, 
>> this isn't very apparent.  
>>
>> I simplified the pattern I am using in an actual application, that 
>> demonstrates the same issue, but at an accelerated rate.
>> This is modeled after the "Scheduling Periodic Messages" pattern 
>> described here:
>>
>> http://doc.akka.io/docs/akka/snapshot/scala/howto.html
>>
>>
>> The full sample code to recreate the memory consumption, with heap usage 
>> logging is available at the gist below.  (note: if you start with the 
>> hello-akka sample application, and replace "HelloAkkaScala.scala" with this 
>> gist below, you can reproduce.  You will need to add to your build.sbt the 
>> following (as mentioned in the comments at the top of the gist)
>>
>>   "com.kenshoo" %% "metrics-play" % "2.3.0_0.1.9"  
>>
>> https://gist.github.com/jeffsteinmetz/bbccb4815858620ab5a2
>>
>> You may need to let it run for about 1 to 2 minutes before you see the 
>> "initial" bump in heap usage.  After that, you will see it slowly climb and 
>> never back down.
>> Note - the metrics calls are not required, and do not cause the memory 
>> leak - you can watch system memory without this library and see the same 
>> issue.
>>
>> I've tried a few versions of Akka, with the same results.  In production, 
>> a similar (real world) application eventually consumes all memory.
>>
>> Hoping for a little insight on the Akka internals, and potential solution.
>>
>> J
>>
>>
>>
>>
>>
>>

-- 
>>  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] Creating a reconnecting TCP client

[Adam]

Hi,

I've been looking for a way to create a client that upon disconnection will 
try to reconnect.
I've done this in the past with RxJava observables, but I'm not sure how to 
do this using Akka Streams.

I saw some code examples where PushStage is being used to implement this, 
but the code samples are old (the API has changed) and I'm not sure exactly 
how to migrate them correctly.
In the code examples, it seems like past versions of the API allowed 
outgoing TCP connections to be handled using a function (by calling 
handleWith), which means a lazy approach could be used.
I *think* this is no longer possible.

So I figured I can get the same effect with an approach similar to what 
I've used in the past with Rx observables - create a Source of TCP outgoing 
connection flows.
Essentially what I need is similar to a theoretic Source.repeat[T](gen: 
()=>T).
There's no such method on Source, so I implemented this using 
ActorPublisher.
I plan to also have some delay between re-connection attempts with an 
exponential backoff and also support multiple target hosts, but for now I 
only want to immediately reconnect to the same address.

If I didn't care about how many connections my client actually opens at the 
same time, I could say this approach works.
In actuality I do, of course, care and I only want a single connection to 
be open at any given time.
Unfortunately, the Request objects my ActorPublisher receives contain 
numbers larger than 1.

Is there a way to force the downstream flow to only ask for a single item 
at a time?
Alternatively, is there actually a better way to achieve my original goal 
(a TCP client that reconnects)?

-- 
>>  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: Proposed major simplification of the Akka Streams FlowGraph APIs

[Adam]

 

Hi,

 

I like most of the described changes.

Here are my personal reservations:

 

1. I prefer a single method name with many overloads over many method names 
that say what are the arguments.

 

2. I think the usage of from in two places (e.g. BidiFlow.fromXYZ and 
Builder.from(...), might be confusing. 

The latter makes a lot of sense, so the former can be renamed to something 
else. Being more used to RxJava\RxScala, I kind of like “of” which is very 
succinct and intuitive.

Of course BidiFlow is just an example, in the list of renames there are 
lots of fromXYZ methodz. I would replace them all with “of”.

This way when you need to create something, you always know to look for an 
“of” method, or whatever consistent name you pick (this sort of works in 
conjunction with my first comment).

 

3. I think loosing addEdge will make it harder for new comers to learn the 
DSL, which is already not trivial (at least in my eyes as  compare it to 
RxJava\RxScala).

Usually having less options can make things simpler, but in this case I 
know I’ve used the addEdge method in order to try and make sense of how to 
use the Akka streams DSL.

Adam
On Saturday, October 17, 2015 at 11:57:25 PM UTC+3, √ wrote:
>
> Hi everyone,
>
> I'm proposing the following (breaking) changes to the FlowGraph-related 
> APIs, in order to make it consistent, with a smaller surface area and with 
> more obvious demarcation of power-level for "dropping down to"/"tapping 
> into" FlowGraph-mode.
>
> Most, if not all, of the migration can be mechanically applied (I know 
> because I did it in the codebase).
>
> See the PR for details: https://github.com/akka/akka/pull/18700
>
> -- 
> Cheers,
> √
>

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

Re: [akka-user] Re: Behavior of Akka when you sleep in an actor

[Adam]

I don't understand the purpose of "keeping the actor busy".
Why not use the actor system's scheduler in order to implement the delay?

Do you actually want to use CPU or other resources?

The only thing to pay attention to is that the scheduler, has a certain 
precision, so the delay may turn out to be slightly larger than aimed for.

For testing purposes, BTW, depending on the situation, I sometimes use a count 
down latch instead of timed delays. When possible, it makes the tests much 
faster to execute.

-- 
>>  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] Modeling synchronous startup behavior

[Adam]

Hi,

In my system I have an initialization sequence that must take place at a 
certain order.
Basically I don't want to open my system for incoming requests, before all 
services are properly started.
So what I needed is sort of similar to what you describe here.

I've implemented it without ask.
Whenever a "service" actor is started it starts initialization in preStart 
and ultimately sends a ServiceStarted back to it's parent.
As I sometimes have a hierarchy of such services, some of them do not 
immediately reply from preStart as they themselves wait for of their 
dependencies to reply with ServiceStarted.
During this sequence I have a receive timeout set in the waiting Actors and 
I remove it once they are fully initialized.

In my case this all takes place within the same JVM, so I didn't bother 
with Acks, so overall it's not too complex.

I hope this helps.



On Monday, October 19, 2015 at 6:16:51 PM UTC+3, Rich Henry wrote:
>
> All the other components are thread-safe.
>
> I just need an order of operations including the actorOf call, so coming 
> full circle, my original plan was to use some kind of initialization 
> message with the ask pattern to sync it up.
>
> I was trying to figure out if this is the best i can do.
>
>
>
>
> On Monday, October 19, 2015 at 11:00:58 AM UTC-4, √ wrote:
>>
>> Hi Rich,
>>
>> On Mon, Oct 19, 2015 at 4:50 PM, Rich Henry  wrote:
>>
>>> I would if it told me when that chain of events starts and stops 
>>> relative to the actorOf call itself.
>>>
>>
>> actorOf is asynchronous so that's completely separate from the lifecycle.
>>  
>>
>>>
>>> My actor needs to register with another non-actor subsystem before i 
>>> interact with it, so If i write code like...
>>>
>>> val subsys = new SubSys()
>>> val a = system.actorOf(Props(classOf[MyActor], subsys)) // constructor 
>>> registers with subsys
>>> subsys.go()
>>>
>>> There is a race condition as the constructor for my actor doesn't get 
>>> called before .go(). 
>>>
>>
>> Is `subsys` threadsafe? Can your MyActor send a message somewhere to 
>> indicate that it has registered with subsys?
>>  
>>
>>>
>>>
>>> On Monday, October 19, 2015 at 10:24:32 AM UTC-4, √ wrote:
>>>


 On Mon, Oct 19, 2015 at 4:11 PM, Rich Henry  wrote:

> I guess that's the why of question 2. Im not clear when the different 
> lifecycle phases, like preStart, occur. 
>
> I would assume preStart occurs after object construction, and is 
> asynchronous to the system call used to create the actor, is that not so?
>
>
 Does the documentation help?

 http://doc.akka.io/docs/akka/2.4.0/scala/actors.html#Actor_Lifecycle

  

> On Monday, October 19, 2015 at 9:40:44 AM UTC-4, √ wrote:
>>
>> Hi Rich,
>>
>> and why can't it be executed in preStart()?
>>
>> On Mon, Oct 19, 2015 at 3:20 PM, Rich Henry  
>> wrote:
>>
>>> I had seen a previous post that didn't really seem to come to any 
>>> definite conclusion about this subject.
>>>
>>> I have some synchronous behavior I need to accomplish during my 
>>> actor's construction, but the constructor is called asynchronously.
>>>
>>> 1) Is the accepted way to do this to use an initialization message 
>>> of some kind with the ask pattern?
>>>
>>> 2) Is there any documentation beyond the short section in the manual 
>>> that talks about actor lifecycle specifics?
>>>
>>> -- 
>>> >> 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.
>>>
>>
>>
>>
>> -- 
>> Cheers,
>> √
>>
> -- 
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: 
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: 
> https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google 
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



 -- 

Re: [akka-user] ActorSelection vs ActorRef

[Adam]

But that is not really accurate, isn't it?

When restarted the ActorRef is still perfectly valid and you only need to watch 
actors in case you have reason to believe that they will be terminated. Also, 
messages don't get lost during the restart, because the mailbox isn't restarted 
(well messages can always get "lost". I mean the great majority of them)

Am I wrong?
If I am, my system has been magically staying up through all sorts of issues 😄

-- 
>>  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] OutOfMemoryError due to too much logging

[Adam]

Hi,

I sometimes see this issue where I want to switch logs to DEBUG, but due to 
the large number of messages the JVM will crash on OutOfMemory which turns 
out to be due to the accumulation of logging events.
Most logging frameworks have the ability to drop messages beyond a certain 
number and so do Akka unbounded mailboxes.

Is there a way to achieve this with Akka logging as well?
The behavior of the non blocking unbounded mailbox is what I have in mind 
(logging frameworks usually add a warning of some kind telling you that 
messages are being dropped, but I can manage without this for now).

Alternatively, I could just using my logger directly.
It's asynchronous anyway. The only issue with that is that I find the extra 
MDC data of actor path very useful when looking at piles of DEBUG logs.
It makes zeroing in on a single transaction very simple.

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

[akka-user] Re: OutOfMemoryError due to too much logging

[Adam]

Hi,

I've read it in the past, but was hoping it's not accurate (I'm already 
using an asynchronous logger as the backend).
It basically says that no - there is no way to achieve what I want with 
Akka Logging, because while an asynchronous backend may help, the messages 
still go through some sort of unbounded queue.
So in the case of a fast producer (lots of logging requests) and a slow 
consumer (logging backend reading from this queue), you will still get an 
OutOfMemoryError.

OK, so I guess I'll just use those loggers directly and I'll have to 
populate the MDC on my own.
Probably not that much work anyway.

Thanks!

On Monday, December 14, 2015 at 10:53:13 AM UTC+2, Johan Andrén wrote:
>
> Hi Adam,
>
> I think what you are describing is covered in the logging docs: 
> http://doc.akka.io/docs/akka/2.4.1/scala/logging.html#Loggers and 
> http://doc.akka.io/docs/akka/2.4.1/java/logging.html#Loggers
>
> It could probably be more clear though, but the system behaving bad with 
> high logging load and configuring an async appender and dropping DEBUG and 
> INFO messages on high load is mentioned.
>
> --
> Johan Andrén
> Typesafe -  Reactive apps on the JVM
> Twitter: @apnylle
>
> On Sunday, December 13, 2015 at 5:15:36 PM UTC+1, Adam wrote:
>>
>> Hi,
>>
>> I sometimes see this issue where I want to switch logs to DEBUG, but due 
>> to the large number of messages the JVM will crash on OutOfMemory which 
>> turns out to be due to the accumulation of logging events.
>> Most logging frameworks have the ability to drop messages beyond a 
>> certain number and so do Akka unbounded mailboxes.
>>
>> Is there a way to achieve this with Akka logging as well?
>> The behavior of the non blocking unbounded mailbox is what I have in mind 
>> (logging frameworks usually add a warning of some kind telling you that 
>> messages are being dropped, but I can manage without this for now).
>>
>> Alternatively, I could just using my logger directly.
>> It's asynchronous anyway. The only issue with that is that I find the 
>> extra MDC data of actor path very useful when looking at piles of DEBUG 
>> logs.
>> It makes zeroing in on a single transaction very simple.
>>
>

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

[akka-user] Rejections in Akka HTTP Java API

[Adam]

Hi,

I see Rejections are only described in the Scala version of the docs.
Is that on purpose?
What are my options using the Java API in order to customize rejections?

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

[akka-user] Akka HTTP performance for short lived connections

[Adam]

Hi,

I'm wondering if there's an expected (even rough) date for when Akka HTTP 
will have similar (or hopefully better :-) ) performance as other HTTP 
libraries\frameworks like Spray or Play.
Specifically, I'm more interested in the scenario of short lived 
connections, which I remember was said to not yet be optimized in one of 
the previous release's release notes.

For example, for my local test I've used ab with a simple Hello World 
handler that just serializes a small json as a response.

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

Re: [akka-user] Akka HTTP performance for short lived connections

[Adam]

OK, thanks.

So just to be certain - in the meantime, is it expected that I'll see Akka HTTP 
perform ~100 times worse (or let's just say "much worse") than Play framework 
for such cases?

I was hoping it's actually something that I'm doing wrong because I was 
expecting it to be worse per the README, but still at the same order of 
magnitude.

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

[akka-user] Re: Akka HTTP performance for short lived connections

[Adam]

Sure.
I first did one round of 100k requests and then another.
These are the results of the second round:

ab -c 400 -n 10 -m GET http://localhost:3000/hello?name=Bob
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1 requests
Completed 2 requests
Completed 3 requests
Completed 4 requests
Completed 5 requests
Completed 6 requests
Completed 7 requests
Completed 8 requests
Completed 9 requests
Completed 10 requests
Finished 10 requests


Server Software:akka-http/2.4.3
Server Hostname:localhost
Server Port:3000

Document Path:  /hello?name=Bob
Document Length:36 bytes

Concurrency Level:  400
Time taken for tests:   423.361 seconds
Complete requests:  10
Failed requests:0
Total transferred:  1880 bytes
HTML transferred:   360 bytes
Requests per second:236.21 [#/sec] (mean)
Time per request:   1693.444 [ms] (mean)
Time per request:   4.234 [ms] (mean, across all concurrent requests)
Transfer rate:  43.37 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:04  44.9  0 581
Processing:11 1686 219.7   15792278
Waiting:4 1024 442.4   10401684
Total: 11 1691 222.2   15802278

Percentage of the requests served within a certain time (ms)
  50%   1580
  66%   1594
  75%   1622
  80%   2059
  90%   2076
  95%   2088
  98%   2101
  99%   2114
 100%   2278 (longest request)




For the sake of comparison here's what I got with Play:

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1 requests
Completed 2 requests
Completed 3 requests
Completed 4 requests
Completed 5 requests
Completed 6 requests
Completed 7 requests
Completed 8 requests
Completed 9 requests
Completed 10 requests
Finished 10 requests


Server Software:
Server Hostname:localhost
Server Port:9000

Document Path:  /hello-world?name=Bob
Document Length:36 bytes

Concurrency Level:  400
Time taken for tests:   17.309 seconds
Complete requests:  10
Failed requests:0
Total transferred:  1580 bytes
HTML transferred:   360 bytes
Requests per second:5777.34 [#/sec] (mean)
Time per request:   69.236 [ms] (mean)
Time per request:   0.173 [ms] (mean, across all concurrent requests)
Transfer rate:  891.43 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   1.8  0 570
Processing:12   69  36.3 67 641
Waiting:1   38  35.9 37 639
Total: 12   69  36.3 67 641

Percentage of the requests served within a certain time (ms)
  50% 67
  66% 68
  75% 68
  80% 69
  90% 70
  95% 71
  98% 73
  99% 74
 100%641 (longest request)




On Monday, April 18, 2016 at 1:25:36 AM UTC+3, Andrew Gaydenko wrote:
>
> Adam, just curious, can you, please, supply some example ApacheBench 
> output?
>

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

Re: [akka-user] Re: Akka HTTP performance for short lived connections

[Adam]

Yeah, no code is rather silly really...

I've created this repository:

https://github.com/adamhonen/Akka-Http-performance-test

I didn't get a chance to try the suggestions above yet, though.


On Monday, April 18, 2016 at 10:25:00 PM UTC+3, Konrad Malawski wrote:
>
> I see some results, but no code that is being benchmarked – please always 
> post benchmarked code together with benchmark, otherwise it's hard to tell 
> what's actually going on.
>
> On Mon, Apr 18, 2016 at 9:19 PM, Johan Andrén  > wrote:
>
>> Yet another thing to test could be to pre-fuse your Request => Response 
>> flow, first, and then run that with autoFusing turned on or off. Locally I 
>> get the best improvement with pre-fusing and no autoFusing. Looks like this:
>>
>>   implicit val materializer = 
>> ActorMaterializer(ActorMaterializerSettings(system))
>>
>> val routes = 
>>   path("benchmark") {
>> get {
>>   complete("ok")
>> }
>>   }
>>
>> val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes
>>
>> val prefused = Fusing.aggressive(flow)
>>
>> Http().bindAndHandle(
>>   handler = Flow.fromGraph(prefused),
>>   interface = "localhost",
>>   port = 9000)
>>
>> --
>> John Andrén
>> Akka Team, Lightbend Inc.
>>
>>
>> On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
>>>
>>> One thing that could be interesting to try out if you want to achieve as 
>>> high throughput as possible where each new request is a new connection with 
>>> the current akka-http version is to disable autoFusing (which is pretty 
>>> costly). That can be done when you create the materializer like this: 
>>>
>>>   
>>> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>>>
>>> This will of course come at the cost where persistent connections get a 
>>> performance hit instead.
>>>
>>> --
>>> John Andrén
>>> Akka Team, Lightbend Inc.
>>>  
>>>
>>> On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>>>>
>>>> Adam, thanks!
>>>>
>>>> Very informative. I also have found handy to use almost empty response 
>>>> to estimate the whole request-response chain itself (starting from now 
>>>> abandoned tiscaf [1] and rising rps up to almost 90K on humble workstation 
>>>> :) ).
>>>>
>>>> [1] http://gaydenko.com/scala/tiscaf/httpd/
>>>>
>>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka HTTP performance for short lived connections

[Adam]

Small update - disabling auto fuse, or pre-fusing (with & without auto 
fusing) has an effect (BTW I could not find a way to do this with the java).
Performance is improved by up to 50%.

However, it's still not in the same order of magnitude as other libraries.
It's still at least 1 second for the fastest requests.

On Tuesday, April 19, 2016 at 12:25:24 AM UTC+3, Adam wrote:
>
> Yeah, no code is rather silly really...
>
> I've created this repository:
>
> https://github.com/adamhonen/Akka-Http-performance-test
>
> I didn't get a chance to try the suggestions above yet, though.
>
>
> On Monday, April 18, 2016 at 10:25:00 PM UTC+3, Konrad Malawski wrote:
>>
>> I see some results, but no code that is being benchmarked – please always 
>> post benchmarked code together with benchmark, otherwise it's hard to tell 
>> what's actually going on.
>>
>> On Mon, Apr 18, 2016 at 9:19 PM, Johan Andrén  
>> wrote:
>>
>>> Yet another thing to test could be to pre-fuse your Request => Response 
>>> flow, first, and then run that with autoFusing turned on or off. Locally I 
>>> get the best improvement with pre-fusing and no autoFusing. Looks like this:
>>>
>>>   implicit val materializer = 
>>> ActorMaterializer(ActorMaterializerSettings(system))
>>>
>>> val routes = 
>>>   path("benchmark") {
>>> get {
>>>   complete("ok")
>>> }
>>>   }
>>>
>>> val flow: Flow[HttpRequest, HttpResponse, NotUsed] = routes
>>>
>>> val prefused = Fusing.aggressive(flow)
>>>
>>> Http().bindAndHandle(
>>>   handler = Flow.fromGraph(prefused),
>>>   interface = "localhost",
>>>   port = 9000)
>>>
>>> --
>>> John Andrén
>>> Akka Team, Lightbend Inc.
>>>
>>>
>>> On Monday, April 18, 2016 at 9:11:10 PM UTC+2, Johan Andrén wrote:
>>>>
>>>> One thing that could be interesting to try out if you want to achieve 
>>>> as high throughput as possible where each new request is a new connection 
>>>> with the current akka-http version is to disable autoFusing (which is 
>>>> pretty costly). That can be done when you create the materializer like 
>>>> this: 
>>>>
>>>>   
>>>> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>>>>
>>>> This will of course come at the cost where persistent connections get a 
>>>> performance hit instead.
>>>>
>>>> --
>>>> John Andrén
>>>> Akka Team, Lightbend Inc.
>>>>  
>>>>
>>>> On Monday, April 18, 2016 at 1:06:58 PM UTC+2, Andrew Gaydenko wrote:
>>>>>
>>>>> Adam, thanks!
>>>>>
>>>>> Very informative. I also have found handy to use almost empty response 
>>>>> to estimate the whole request-response chain itself (starting from now 
>>>>> abandoned tiscaf [1] and rising rps up to almost 90K on humble 
>>>>> workstation 
>>>>> :) ).
>>>>>
>>>>> [1] http://gaydenko.com/scala/tiscaf/httpd/
>>>>>
>>>> -- 
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> Cheers,
>> Konrad 'ktoso' Malawski
>> Akka <http://akka.io/> @ Lightbend <http://lightbend.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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka HTTP documentation about asynchronous completion of routes

[Adam]

Hi,

I'm looking at the docs trying to find an example of how to create a route 
that does not complete the result synchronously from the route tree, but 
rather relies on some other asynchronous chain of events.
All I can find is this page: 
http://doc.akka.io/docs/akka/2.4/java/http/routing-dsl/routes.html

That's not really enough to get started easily...
Actually I think some of the methods mentioned there don't really exist.
For example: Route::asyncHandler.

Am I missing something here?
Does a simple example exist and I simply can't find it?
The activator code for Akka HTTP micro-service also seems to be out of 
date, so I cannot use that either.
I actually have some preexisting (POC grade) code that relied on 2.4.4 
(unfortunately it was also hard to find what to do the first time around) 
and I'm now converting it to 2.4.9 and yet it's still quite hard to easily 
find what to do.

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

[akka-user] Re: Akka HTTP documentation about asynchronous completion of routes

[Adam]

Ultimately I was able to find a group of related directives.

So this for example works:

...

public Route route() {
 return parameterOptional("name", optName -> {
  String name = optName.orElse(_defaultName);
  return parameterOptional("times", optTimes -> {
   int times = optTimes.map(Integer::parseInt).orElse(1);
   final Marshaller marshaller = 
Jackson.marshaller();
   return completeOKWithFuture(futureSayHello(name, times), marshaller);
  });
 });
}

//convert the Observable to a completeionStage
public CompletionStage futureSayHello(final String name, final int 
times) {
...






On Monday, September 5, 2016 at 5:28:19 PM UTC+3, Adam wrote:
>
> Hi,
>
> I'm looking at the docs trying to find an example of how to create a route 
> that does not complete the result synchronously from the route tree, but 
> rather relies on some other asynchronous chain of events.
> All I can find is this page: 
> http://doc.akka.io/docs/akka/2.4/java/http/routing-dsl/routes.html
>
> That's not really enough to get started easily...
> Actually I think some of the methods mentioned there don't really exist.
> For example: Route::asyncHandler.
>
> Am I missing something here?
> Does a simple example exist and I simply can't find it?
> The activator code for Akka HTTP micro-service also seems to be out of 
> date, so I cannot use that either.
> I actually have some preexisting (POC grade) code that relied on 2.4.4 
> (unfortunately it was also hard to find what to do the first time around) 
> and I'm now converting it to 2.4.9 and yet it's still quite hard to easily 
> find what to do.
>
> 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka HTTP performance in 2.4.9

[Adam]

Hi,

I've previously seen bad performance form Akka HTTP for a simple ping/pong 
scenario (which I realize according to the release notes is still a 
relatively bad scenario for Akka HTTP), but the results I'm getting are bad 
enough that I'm wondering if my test is even valid.

Here's my code:

package com.example.rest

import akka.NotUsed
import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.model._
import akka.stream.scaladsl.{Flow, Keep, RunnableGraph, Sink, Source}
import akka.stream.{ActorMaterializer, ActorMaterializerSettings, Fusing}

import scala.concurrent.Future
import scala.io.StdIn

object WebServer extends App {
  implicit val system = ActorSystem()
  implicit val materializer =  
ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
  implicit val executionContext = system.dispatcher

  val response = HttpResponse(entity = 
HttpEntity(ContentTypes.`text/plain(UTF-8)`,"Ok"))
  val requestHandler: HttpRequest => HttpResponse = {
case _ => response
  }

  val flow: Flow[HttpRequest, HttpResponse, NotUsed] = Flow[HttpRequest] map 
requestHandler
  val prefused = Fusing.aggressive(flow)
  val httpHandler: Flow[HttpRequest, HttpResponse, NotUsed] = 
Flow.fromGraph(prefused)

  if (args(0) == "http"){
runHttpServer()
  } else {
runPingPong(args(1).toInt)
  }

  def runHttpServer() = {
val bindingFuture = Http().bindAndHandle(handler = httpHandler, interface = 
"127.0.0.1  ", port = 3000)

println("Type RETURN to exit")
StdIn.readLine()

bindingFuture
  .flatMap(_.unbind()) // trigger unbinding from the port
  .onComplete(_ => system.terminate())
  }

  def runPingPong(times: Int) = {
val ping = HttpRequest().withUri(Uri("/"))

val graph: RunnableGraph[Future[Int]] = Source(1 to times)
  .map(_ => ping)
  .via(httpHandler)
  .map(_ => 1)
  .toMat(Sink.fold[Int, Int](0)((a, b) => a + 1))(Keep.right)

val startTime = System.nanoTime()
val count: Future[Int] = graph.run()

count.onComplete(res => {
  if (res.isFailure) {
Console.err.println(s"failed with: ${res.failed}")
  } else {
println(s"ran for ${res.get} times")
val et = System.nanoTime() - startTime
val etMillis = et / 100.0
println(s"et: ${etMillis}ms")
  }
  system.terminate()
})
  }
}

The in memory scenario (runPingPong) yields the following results on my local 
windows machine:

ran for 10 times
et: 322.150515ms


Running ab to test actual local HTTP calls get me this:

ab -c 400 -n 10 -m GET http://127.0.0.1:3000/

This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1 requests
Completed 2 requests
Completed 3 requests
Completed 4 requests
Completed 5 requests
Completed 6 requests
Completed 7 requests
Completed 8 requests
Completed 9 requests
Completed 10 requests
Finished 10 requests


Server Software:akka-http/2.4.9
Server Hostname:127.0.0.1
Server Port:3000

Document Path:  /
Document Length:2 bytes

Concurrency Level:  400
Time taken for tests:   139.083 seconds
Complete requests:  10
Failed requests:0
Total transferred:  1620 bytes
HTML transferred:   20 bytes
Requests per second:719.00 [#/sec] (mean)
Time per request:   556.332 [ms] (mean)
Time per request:   1.391 [ms] (mean, across all concurrent requests)
Transfer rate:  113.75 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:01  24.7  0 593
Processing:13  552 394.65622144
Waiting:2  388 347.15261583
Total: 13  554 395.25622144

Percentage of the requests served within a certain time (ms)
  50%562
  66%586
  75%639
  80%   1047
  90%   1065
  95%   1096
  98%   1560
  99%   1574
 100%   2144 (longest request)


I was able to use the same approach with other frameworks (e.g. Play & 
Vertx) and got results which are much better.
I see in the 2.4.9 release notes that (on different hardware) 160K reqs/sec 
ping/pong requests were achieved, so what I'm seeing on my machine is 
really weird to me.
Is there something fundamentally wrong with my test above?
It would also be nice to see the code & configuration which was used to 
test 2.4.9's performance on EC2, if that's available somewhere.

Adam

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

Re: [akka-user] Akka HTTP performance in 2.4.9

[Adam]

Thanks!

Adding -k indeed fixes this right away:

ab -k -c 400 -n 10 -m GET http://127.0.0.1:3000/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 1 requests
Completed 2 requests
Completed 3 requests
Completed 4 requests
Completed 5 requests
Completed 6 requests
Completed 7 requests
Completed 8 requests
Completed 9 requests
Completed 10 requests
Finished 10 requests


Server Software:akka-http/2.4.9
Server Hostname:127.0.0.1
Server Port:3000

Document Path:  /
Document Length:2 bytes

Concurrency Level:  400
Time taken for tests:   3.401 seconds
Complete requests:  10
Failed requests:0
Keep-Alive requests:10
Total transferred:  1670 bytes
HTML transferred:   20 bytes
Requests per second:29403.12 [#/sec] (mean)
Time per request:   13.604 [ms] (mean)
Time per request:   0.034 [ms] (mean, across all concurrent requests)
Transfer rate:  4795.23 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   2.8  0 509
Processing: 0   11  62.6  61566
Waiting:0   11  62.6  61566
Total:  0   11  62.8  61566

Percentage of the requests served within a certain time (ms)
  50%  6
  66%  8
  75%  8
  80%  9
  90% 13
  95% 16
  98% 26
  99% 32
 100%   1566 (longest request)


P.S.  - I wasn't familiar with wrk, but, of course, I realize running on 
the local machine is not really valid.
I only used this method to pick up on really basic issues (like this 
example of not using persistent connections illustrates perfectly)



On Tuesday, September 6, 2016 at 5:39:02 PM UTC+3, Konrad Malawski wrote:
>
> Without looking at the code, two things to fix right away in your 
> methodology:
>
> 1) You're running `ab` without persistent connections (also known as 
> "useless mode").
> Please run: `ab -k` to use keep-alive connections, which is what all http 
> clients and browsers do.
>
> 2) Please do not benchmark using the same host for running the app and 
> load generator...
> You're stealing resources from the http server as you're load generator is 
> trying to hit it as hard as it can, and the other way around.
> The benchmark will be completely skewed by that.
>
> ab is also not very good in general, use wrk instead - a more modern load 
> generator.
>
> -- 
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 6 September 2016 at 16:34:22, Adam (adam...@gmail.com ) 
> wrote:
>
> Hi,
>
> I've previously seen bad performance form Akka HTTP for a simple ping/pong 
> scenario (which I realize according to the release notes is still a 
> relatively bad scenario for Akka HTTP), but the results I'm getting are bad 
> enough that I'm wondering if my test is even valid.
>
> Here's my code:
>
> package com.example.rest
>
> import akka.NotUsed
> import akka.actor.ActorSystem
> import akka.http.scaladsl.Http
> import akka.http.scaladsl.model._
> import akka.stream.scaladsl.{Flow, Keep, RunnableGraph, Sink, Source}
> import akka.stream.{ActorMaterializer, ActorMaterializerSettings, Fusing}
>
> import scala.concurrent.Future
> import scala.io.StdIn
>
> object WebServer extends App {
>   implicit val system = ActorSystem()
>   implicit val materializer =  
> ActorMaterializer(ActorMaterializerSettings(system).withAutoFusing(false))
>   implicit val executionContext = system.dispatcher
>
>   val response = HttpResponse(entity = 
> HttpEntity(ContentTypes.`text/plain(UTF-8)`,"Ok"))
>   val requestHandler: HttpRequest => HttpResponse = {
> case _ => response
>   }
>
>   val flow: Flow[HttpRequest, HttpResponse, NotUsed] = Flow[HttpRequest] map 
> requestHandler
>   val prefused = Fusing.aggressive(flow)
>   val httpHandler: Flow[HttpRequest, HttpResponse, NotUsed] = 
> Flow.fromGraph(prefused)
>
>   if (args(0) == "http"){
> runHttpServer()
>   } else {
> runPingPong(args(1).toInt)
>   }
>
>   def runHttpServer() = {
> val bindingFuture = Http().bindAndHandle(handler = httpHandler, interface 
> = "127.0.0.1  ", port = 3000)
>
> println("Type RETURN to exit")
> StdIn.readLine()
>
> bindingFuture
>   .flatMap(_.unbind()) // trigger unbinding from the port
>   .onComplete(_ => system.terminate())
>   }
>
>   def

[akka-user] Enjoying Akka HTTP performance

[Adam]

Hi,

I'd just like to share my satisfaction from Akka HTTP performance in 2.4.10.
I'm diagnosing some low level Node.js performance issues and while running 
various tests that only require the most basic "Hello World" style code, I 
decided to take a few minutes to check how would Akka HTTP handle the same 
work.
I was quite impressed with the results, so I thought I'd share.

I'm running two c4.large instances (so two cores on each instance) - one 
running the HTTP service and another running wrk2.
I've tested only two short sets (seeing as I have other work to do):

   1. use 2 threads to simulate 100 concurrent users pushing 2k 
   requests/sec for 5 minutes
   2. use 2 threads to simulate 100 concurrent users pushing 20k 
   requests/sec for 5 minutes

In both cases, the tests are actually executed twice without a restart in 
between and I throw away the results of the first run.

The first run is just to get JIT and other adaptive mechanisms to do their 
thing.

5 minutes seems to be enough based on the CPU behavior I see, but for a 
more "official" test I'd probably use something longer.


As for the code, I was using vanilla Node code - the kind you see as the 
most basic example (no web frameworks or anything) but for Akka, I used the 
high level DSL.


Here's the Code:


*Akka HTTP*


package com.example.rest

import akka.actor.ActorSystem
import akka.http.scaladsl.Http
import akka.http.scaladsl.server.Directives._
import akka.stream.ActorMaterializer


case class Reply(message: String = "Hello World", userCount: Int)

object MyJsonProtocol
  extends akka.http.scaladsl.marshallers.sprayjson.SprayJsonSupport
with spray.json.DefaultJsonProtocol {

  implicit val replyFormat = jsonFormat2(Reply.apply)
}

object FullWebServer {
  var userCount = 0;

  def getReply() = {
userCount += 1
Reply(userCount=userCount)
  }

  def main(args: Array[String]) {
implicit val system = ActorSystem()
implicit val materializer = ActorMaterializer()
import MyJsonProtocol._

val route =
  get {
complete(getReply())
  }

// `route` will be implicitly converted to `Flow` using 
`RouteResult.route2HandlerFlow`
val bindingFuture = Http().bindAndHandle(route, "0.0.0.0", 3000)
println("Server online at http://127.0.0.1:3000/";)
  }
}


*Node*

var http = require('http');

let userCount = 0;
var server = http.createServer(function (request, response) {
userCount++;
response.writeHead(200, {"Content-Type": "application/json"});
const hello = {msg: "Hello world", userCount: userCount};
response.end(JSON.stringify(hello));
});

server.listen(3000);

console.log("Server running at http://127.0.0.1:3000/";);

(to be more exact there's also some wrapping code because I'm running this in a 
cluster so all cores can be utilized)


So for the first test, things are pretty much the same - Akka HTTP uses 
less CPU (4-6% vs. 10% in Node) and has a slightly lower average response 
time, but a higher max response time.

Not very interesting.


The second test was more one sided though.


The Node version maxed out the CPU and got the following results:


Running 5m test @ http://srv-02:3000/
  2 threads and 100 connections
  Thread calibration: mean lat.: 215.794ms, rate sampling interval: 1623ms
  Thread calibration: mean lat.: 366.732ms, rate sampling interval: 1959ms
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 5.31s 4.48s   16.66s65.79%
Req/Sec 9.70k 0.87k   10.86k57.85%
  5806492 requests in 5.00m, 1.01GB read
Requests/sec:  19354.95
Transfer/sec:  3.43MB


Whereas for the Akka HTTP version I saw each core using ~40% CPU throughout 
the test and I had the following results:

Running 5m test @ http://srv-02:3000/
  2 threads and 100 connections
  Thread calibration: mean lat.: 5.044ms, rate sampling interval: 10ms
  Thread calibration: mean lat.: 5.308ms, rate sampling interval: 10ms
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 1.83ms1.27ms  78.91ms   95.96%
Req/Sec10.55k 1.79k   28.22k75.98%
  5997552 requests in 5.00m, 1.00GB read
Requests/sec:  19991.72
Transfer/sec:  3.41MB


Which is not a huge increase over 2K requests/sec:


Running 5m test @ http://srv-02:3000/
  2 threads and 100 connections
  Thread calibration: mean lat.: 1.565ms, rate sampling interval: 10ms
  Thread calibration: mean lat.: 1.557ms, rate sampling interval: 10ms
  Thread Stats   Avg  Stdev Max   +/- Stdev
Latency 1.07ms  479.75us   8.09ms   62.57%
Req/Sec 1.06k   131.65 1.78k79.05%
  599804 requests in 5.00m, 101.77MB read
Requests/sec:   1999.33
Transfer/sec:347.39KB



In summary, I know this is far from a conclusive test, but I was still 
quite excited to see the results.

Keep up the good work!

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>

[akka-user] foreach in akka-streams 0.7

[Adam Warski]

Hello,

I recently migrated some code from old reactive streams to 0.7, and as part 
of that I replaced .foreach with a combination of .map (where the function 
resulted in Unit) and .consume().

Roland in a tweet 
(https://twitter.com/rolandkuhn/status/512143662676193280) says that: 
"foreach is a Sink type now", which I don't really understand :). Is there 
some different way to implement foreach? (the foreach usage I have is to 
handle connections from stream-tcp)

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] foreach in akka-streams 0.7

[Adam Warski]

Got it, thanks! Updated the code :)

Adam

On Wednesday, September 17, 2014 2:50:23 PM UTC-7, Konrad Malawski wrote:
>
> Hello Adam,
> yes, there is: .withSink(ForeachSink(el => ).run()
> ​
> The sink also holds a future which you can watch for completion, see: 
> http://doc.akka.io/api/akka-stream-and-http-experimental/0.7/?_ga=1.32419708.350209094.1396869304#akka.stream.scaladsl2.ForeachSink
>
> Hope this helps!
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
> <http://typesafe.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.

Re: [akka-user] Realtime (as in Electronics) processing in Akka and Garbage Collection's Effect to It

[Adam Retter]

I have not had time to watch this yet, but perhaps it may be of some
interest - https://vimeo.com/105888905

On 17 October 2014 08:39, Koray Al  wrote:
> Hello All,
>
> Our application is nearly offline, it doesn't need to communicate with
> remote servers etc. The only obligation they have is to communicate with the
> hardware that are in the same gigabit network in realtime. So the load is
> nearly at the same level all the time. We also already have more memory than
> it needs. (in fact currently the application is using %8 of the computer
> memory at most)
>
> I have checked out my application with jHiccup (which Adam suggested)
> running for a day and it seems that the highest hiccup duration is 65
> milliseconds. It is acceptable for my application ( but it will not be, if I
> try to implement the realtime part I was asking for ) A friend of mine also
> suggested checking out the garbage collection suggestions for Apache Kafka
> and Twitter Storm. ( https://gist.github.com/mrflip/5958028 ) I will monitor
> the system with suggestions from there.
>
> After watching Konrad's link, I am now sure that I am way over my head :)
> But I think using optimizations suggested by experts will surely help.
>
> It looks like I will have to use C++ for that kind of realtime applications,
> but I will resist as long as I can :)
>
> Regards,
> Koray
>
> On Thursday, October 16, 2014 3:57:42 PM UTC+3, Alec Zorab wrote:
>>
>> I'm not sure I'd say it was the *most* important factor - if you're
>> spending a lot of time talking to a database or waiting for packets to cross
>> the atlantic then you may have other problems to contend with, but certainly
>> at the 5ms scale, GC can have a very significant impact.
>>
>> GC monitoring and tuning on the jvm is an art unto itself - google's
>> probably the best way to familiarise yourself with it, but if you just want
>> to get  a quick and dirty feel for what's going on, the VisualGC plugin for
>> VisualVM is useful.
>>
>> On 16 October 2014 13:30, Koray Al  wrote:
>>>
>>> @Alec
>>>
>>> So when 5ms is the target, you are saying that the GC becomes the most
>>> important factor for the system's performance. Do you have any suggestion
>>> (book/website etc.) for me to check out for this matter? I have my
>>> application currently running in a high traffic environment and I would love
>>> to monitor GC pauses periodically if I knew how :)
>>>
>>> @Adam
>>>
>>> Thank you for the suggestion, I also came across similar JVMs but the
>>> cost seems to be unapplicable for me since most of my applications do not
>>> run in a central server, instead it runs on a lot of nodes.
>>>
>>> @Conrad
>>>
>>> Thank you for the link, this is exactly what I am looking for since I
>>> have no idea what to check for my system's performance. In the meantime I
>>> was checking out Kamon since my application generates and kills a lot of
>>> actors and I need a way to monitor actor counts, transaction times etc.
>>>
>>> I will check out all your suggestions.
>>>
>>> Regards,
>>> Koray
>>>
>>>
>>> On Wednesday, October 15, 2014 3:24:53 PM UTC+3, Akka Team wrote:
>>>>
>>>> Hi Koray,
>>>> I concur with the other guys – these kinds of skills are very specific.
>>>> It's certainly doable, and there's loads of companies using both the JVM
>>>> and/or Akka for these kinds of systems, but it requires a lot of thinking /
>>>> monitoring / tweaking to get these super high performance apps.
>>>> Here's a talk from the Twitter guys I really liked which shows a bit of
>>>> the resources and techniques one has to apply when building such apps:
>>>> Twitter-Scale Computing with OpenJDK (youtube).
>>>>
>>>> These topics are the fun and interesting part, so you're in for a ride -
>>>> enjoy it. :-)
>>>>
>>>> --
>>>> Konrad
>>>>
>>>> Akka Team
>>>> Typesafe - The software stack for applications that scale
>>>> Blog: letitcrash.com
>>>> Twitter: @akkateam
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the arc

[akka-user] Stopping a reactive stream

[Adam Warski]

Hello,

is there a way to stop a reactive "running" reactive stream, e.g. by making 
it watch some other actors, and when they are dead, die as well?

This might or might not be associated with the components of the stream 
itself; in my current scenario I have a sink which is a reactive tcp 
connection. I don't seem to be getting any errors (at least logged) by 
shutting down the other side of the tcp connection, however I do get 
"outside" errors, from the cluster/remoting watch - so I could use that to 
restart the whole thing, if only I could make some "supervisor hierarchy" 
for the stream.

-- 
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] Stopping a reactive stream

[Adam Warski]

On Thursday, October 30, 2014 11:15:50 AM UTC+1, Akka Team wrote:
>
> Hi Adam,
>
> This might or might not be associated with the components of the stream 
>> itself; in my current scenario I have a sink which is a reactive tcp 
>> connection. 
>>
>
> What do you mean by a reactive tcp connection here? Is it an Akka  TCP 
> stream? 
>

Established using akka.stream.io.StreamTcp.
 

> I don't seem to be getting any errors (at least logged) by shutting down 
>> the other side of the tcp connection, however I do get "outside" errors, 
>> from the cluster/remoting watch - so I could use that to restart the whole 
>> thing, if only I could make some "supervisor hierarchy" for the stream.
>>
>
> Streams have a built-in onComplete/cancel signal that is invoked when 
> things terminate. Akka TCP provides those signals when the TCP connection 
> goes away. I need to know more about the setup you have to see what is the 
> problem.
>
> There was a problem though related to Windows that "connection reset by 
> peer" events were lost, there is a bugfix/workaround pending for that, to 
> be released with 2.3.7. If you are running Windows there is a high 
> likeliness that you hit that bug.
>

I'm not running Windows (MacOS), but how could these signals be handled? I 
was looking for some handlers in the value returned by run() (e.g. 
onComplete, onError), but it seems not much is there :)

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] Stopping a reactive stream

[Adam Warski]

Sure :) I'm using streams 0.9, scaladsl2 and I want to add failure 
detection to that:

https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Sender.scala

Adam

On Thursday, October 30, 2014 12:04:23 PM UTC+1, Akka Team wrote:
>
> Hi Adam,
>
>
>> I'm not running Windows (MacOS), but how could these signals be handled? 
>> I was looking for some handlers in the value returned by run() (e.g. 
>> onComplete, onError), but it seems not much is there :)
>>
>
> Which version of Akka Stream are you using and which version of the 
> scaladsl? How does your pipeline look like, what is the sink element (the 
> thing in which you pipe TCP into).
>
> In general, a code snippet would help a lot.
>
> -Endre
>  
>
>>
>> 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+...@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.
>>
>
>
>
> -- 
> Akka Team
> Typesafe - The software stack for applications that scale
> Blog: letitcrash.com
> Twitter: @akkateam
>  

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

Re: [akka-user] Stopping a reactive stream

[Adam Warski]

There's an OnCompleteDrain :) (btw. - sink, drain, subscriber - a lot of 
names ;) )

How do I use broadcast, thought? I can see it can be a vertex in the graph, 
but how to add it?

So I'll end up with sth like this:

   /---> sink1 (output 
stream)
source --> trans1 --> broadcast --<
   \---> sink2 (on 
complete drain)

Will the failure of sink1 propagate to a completion of the whole stream? In 
theory it could continue in a "crippled" way (with only one branch 
remaining).

Thanks!
Adam

On Thursday, October 30, 2014 1:22:41 PM UTC+1, Akka Team wrote:
>
> Hi Adam,
>
> You can use broadcast to split out the stream going into the Sink, and 
> then attach to that side of the graph an OnCompleteSink which takes a 
> function callback: Try[Unit] ⇒ Unit which is called during normal and 
> failure termination.
>
> -Endre
>
> On Thu, Oct 30, 2014 at 12:31 PM, Adam Warski  > wrote:
>
>> Sure :) I'm using streams 0.9, scaladsl2 and I want to add failure 
>> detection to that:
>>
>>
>> https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Sender.scala
>>
>> Adam
>>
>> On Thursday, October 30, 2014 12:04:23 PM UTC+1, Akka Team wrote:
>>>
>>> Hi Adam,
>>>
>>>
>>>> I'm not running Windows (MacOS), but how could these signals be 
>>>> handled? I was looking for some handlers in the value returned by run() 
>>>> (e.g. onComplete, onError), but it seems not much is there :)
>>>>
>>>
>>> Which version of Akka Stream are you using and which version of the 
>>> scaladsl? How does your pipeline look like, what is the sink element (the 
>>> thing in which you pipe TCP into).
>>>
>>> In general, a code snippet would help a lot.
>>>
>>> -Endre
>>>  
>>>
>>>>
>>>> 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+...@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.
>>>>
>>>
>>>
>>>
>>> -- 
>>> Akka Team
>>> Typesafe - The software stack for applications that scale
>>> Blog: letitcrash.com
>>> Twitter: @akkateam
>>>  
>>  -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@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.
>>
>
>
>
> -- 
> Akka Team
> Typesafe - The software stack for applications that scale
> Blog: letitcrash.com
> Twitter: @akkateam
>  

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

Re: [akka-user] Stopping a reactive stream

[Adam Warski]

> On Thu, Oct 30, 2014 at 1:43 PM, Adam Warski  > wrote:
>
>> There's an OnCompleteDrain :) (btw. - sink, drain, subscriber - a lot of 
>> names ;) )
>>
>
> Drain is no longer there (as a name at least) and you should usually not 
> see a Subscriber ;)
>

It is in 0.9, but as I understand it's not in master :)
 

> How do I use broadcast, thought? I can see it can be a vertex in the 
>> graph, but how to add it?
>>
>
> An example:
>
>   FlowGraph { implicit b ⇒
> val bcast = Broadcast[Int]("broadcast")
> Source(List(1, 2, 3)) ~> bcast
> bcast ~> Flow[Int] ~> Sink(s1)
> bcast ~> Flow[Int] ~> Sink(s2)
>   }.run()
>

Thanks, I'll try that.
  

> So I'll end up with sth like this:
>>
>>/---> sink1 
>> (output stream)
>> source --> trans1 --> broadcast --<
>>\---> sink2 (on 
>> complete drain)
>>
>> Will the failure of sink1 propagate to a completion of the whole stream? 
>> In theory it could continue in a "crippled" way (with only one branch 
>> remaining).
>>
>
> True, in this setup sink2 will get the termination event of "source" but 
> will not get the canceled event of sink1. Internally it is configurable if 
> broadcast should continue or not in this case but this is not exposed to 
> the users (it continues by default now).
>

So even if sink1 fails, the whole setup will continue? So using sink2 (on 
complete sink/drain) won't have any effect? Is there a way to detect errors 
in such case then?
 

> Btw, in your TCP example you don't use the inputStream of the connection, 
> if you use that stream it will give you the termination events of the TCP 
> connection (normal/error). Output stream can only say "cancelled" but not 
> why.
>

Well this application only sends data, so I don't need the input stream for 
anything.

Even supposing broadcast does work, shouldn't there be some other way to 
detect and handle failures/errors/completions? E.g. wouldn't it make sense 
to add a callback to run()? Or make run() return some kind of Future? 
Creating an artificial broadcast just to detect errors seems not optimal :)

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] Stopping a reactive stream

[Adam Warski]

>
> So even if sink1 fails, the whole setup will continue? So using sink2 (on 
>> complete sink/drain) won't have any effect? Is there a way to detect errors 
>> in such case then?
>>
>
> Sink2 will detect the failure of source, but not of sink1. Currently there 
> is no way to detect it, because most people expect the broadcast to 
> continue instead of failing. We can make it configurable though.
>

Right, I can imagine needing both. Similar to a one-for-one and one-for-all 
failover strategy when using actor supervisor hierarchies.

Btw. the javadoc for Broadcast currently says: " It will not shutdown until 
the subscriptions for at least two downstream subscribers have been 
established.". Why two? Shouldn't it be either one or all? :)
 

> You should be aware though that using the stream TCP you *don't* get an 
> error event from the outputStream anyway, you only get notified that it has 
> cancelled (Reactive Streams specify only cancel as an event propagated from 
> downstream to upstream), but not the reason why. See my other answer a bit 
> below before you panic :)
>

Would it make sense to add something to the current API which could detect 
such failures?
 

> Btw, in your TCP example you don't use the inputStream of the connection, 
>>> if you use that stream it will give you the termination events of the TCP 
>>> connection (normal/error). Output stream can only say "cancelled" but not 
>>> why.
>>>
>>
>> Well this application only sends data, so I don't need the input stream 
>> for anything.
>>
>
> This is not true, you always need to connect something to the input 
> stream, because it is the thing that carries the termination events of the 
> *TCP 
> stream pair* -- i.e. failures in outputs will be also reported on this 
> channel.
>
> You don't need to do anything with the input data though, you can just 
> attach an OnComplete Drain/Sink (whatever it is named in that version ;) ), 
> that will discard all data anyway, but will not clog the inbound TCP 
> buffers even if the remote part happens to send things, and you will get 
> the TCP termination events in the callback you provided to OnComplete
>

Ok, that's in fact much nicer, I didn't like the approach of broadcasting 
just to detect errors :). I'll try that in the evening.
 

> Even supposing broadcast does work, shouldn't there be some other way to 
>> detect and handle failures/errors/completions? E.g. wouldn't it make sense 
>> to add a callback to run()? Or make run() return some kind of Future? 
>> Creating an artificial broadcast just to detect errors seems not optimal :)
>>
>
> There is a common misconception here. Imagine a setup like this:
>
>   inputFile -> someProcessing -> outputFile
>
> Now imagine that we provided an API that gives a completion future after 
> you call run(). Now if that future completes, would that mean that writing 
> to the file finished? Unfortunately no, since the completion of a Reactive 
> Streams means that no elements in flight anymore and everyone is aware of 
> that, but this does not imply that all the buffers of the outputFile writer 
> has been flushed and the file has been closed.
>
> This is exactly why Akka Streams provide Sinks (formerly Drains) that can 
> return a completion Future (or whatever they want to return) of their own 
> that is completely library dependent -- for example a file writer Sink can 
> give a Future that represents the event while the file has been completely 
> closed.
>

So each sink should provide a sink-dependent way of letting the user know 
when things are "done" or "cancelled". Doesn't it mean that there should be 
a way to provide a callback or sth like that when creating the specific 
Subscriber, here it's implemented by the TCP extension? E.g. a Future or 
similar as part of the binding: StreamTcp.OutgoingTcpConnection?

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] Stopping a reactive stream

[Adam Warski]

Ok, so getting closer, seems to work :) Thanks a lot for the help.

On the sender side I added a separate flow for the input stream, attached 
an on complete drain and I get the callback. One small thing, even if I 
kill the other side of the connection, the callback contains a Success(()).

On the receiver side I added the forking (broadcast), and I'm getting the 
callback when the other side is killed.
 
>
> Doesn't it mean that there should be a way to provide a callback or sth 
>> like that when creating the specific Subscriber, here it's implemented by 
>> the TCP extension? E.g. a Future or similar as part of the binding: 
>> StreamTcp.OutgoingTcpConnection?
>>
>
> The input stream conveys all the information you need about closing 
> events, I don't see the need currently for a side-channel. We prefer to 
> keep as much as possible in-stream and not out-of-stream. Since TCP is a 
> stream in itself it works quite well, unlike with the file example I had 
> where there is a pure sink. That said, we might add more functionality if 
> needed but the design goal is to keep these external signals minimal.
>

Sure, this makes sense. Having as little of an additional protocol as 
possible is certainly nice. Though the fact that a socket died doesn't 
always require protocol support (I mean, often you will know that a socket 
isn't working without sending special pings or such). So this could get 
exposed to the user.

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.

[akka-user] Reactive actor-actor communication

[Adam Warski]

Hello,

I was looking at AtLeastOnceDelivery and what problems it might have when 
the destination actor dies or becomes slow. Apart from the obvious 
out-of-memory which would eventually happen (and which can be solved with a 
smarter ALOD version which flushes excess data to disk), there's also the 
problem of an increasing load of messages when the destination is 
unavailable: every new message is retried, and retried, and retried, and 
this adds up ... wouldn't it be a perfect place for a reactive message 
stream?

Are "reactive message streams" between actors anything that has been 
considered? (I know that for sure it's not implemented, but just wondering 
in general, if it makes sense.) This could be especially useful if the 
actors are on separate nodes - "reactive remoting".

One problem here would be handling routers. Let's say we have an A actor 
streaming messages to two B actors:

  /-- B1
A --- R --- <
  \-- B2

where R is a router. Now the router would have be smart about the demand 
coming from B1 and B2: sum the demand and return it to A, and when A sends 
messages, split them according to the earlier requests.

Going even further (and that is the original problem that I was wondering 
about), let's say we have a pool of A-actors (potentially on different 
cluster nodes using e.g cluster sharding) and a pool of B-actors (again 
potentially on different cluster nodes). The goal is to have a reliable 
message stream between the A-actors and the B-actors. The additional 
complication here is that there's no central router, so even if there was a 
reactive message stream available between any two nodes, the B-actors would 
have no idea how to split the demand between the A-actors. Or maybe the 
direction I'm heading with this is somehow wrong? :)

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] Reactive actor-actor communication

[Adam Warski]

 hosts, and using Kafka they can stream 
messages reliably). With Kafka's delivery methods you bind each consumer to 
a number of partitions, so it would be as you describe, kind of 
point-to-point streams, which get re-balanced when a node goes down.

Going this route, there could be a cluster-singleton service which assigns 
B-actors to A-actors, and creates streams between those two. These could be 
the "reactive message streams" from above. And to solve the 
demand-splitting problem (when a B has two As assigned), there could be 
simply more consumer-actors then producer-actors.

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] Reactive actor-actor communication

[Adam Warski]

I opened GH issues and I see Konrad beat me to 
it: https://github.com/akka/akka/issues/16348 :)

Adam

On Wednesday, November 19, 2014 8:36:41 AM UTC+2, rkuhn wrote:
>
> Hi Adam,
>
> your initial point of creating a growing (and maybe thundering) herd of 
> retries is a good one and it would be better if we would limit the number 
> of messages to be resent. Could you open a ticket for that?
>
> Thanks,
>
> Roland 
>
> Sent from my iPhone
>
> On Nov 18, 2014, at 04:08, Adam Warski > 
> wrote:
>
> Hey,
>
> It would be more complicated to "replace" AtLeastOnceDelivery with your 
>> demand-driven proposal - the entire point of ALOD is that it fights back 
>> the fact that messages can get lost and nodes can go down.
>> Effectively what you're proposing is to switch from "re-sending until I 
>> get confirmations" (push) to "pulling all the time" (pull), the catch here 
>> is – "*what if the demand messages get lost?*", so you'd have to add 
>> re-delivery of the demand tokens themselves anyway.
>>
>
> True, the demand can get lost as well. Hmm... and that would be in fact a 
> problem of any "reactive stream" between remote actors. This would make 
> things more complex, but still doable, in a peer-to-peer setting at least 
> (without routers). And would help with the potential flooding of the 
> destination when it comes back after being absent for a longer time. But as 
> I understand it's not complete non-sense ;) 
>
> By the way - isn't dropping demand messages a problem also in the current 
> remote-streams implementation?
>  
>
>> Also imagine that you're trying to send M1 to A1, the A node goes down, 
>> it restarts. You could keep redelivering the M1 message, which would 
>> trigger the *starting* of the A1 actor (it could be persistent actor, in 
>> a shard, which starts when it gets a message),
>> then the push mode of ALOD will revive this A1 guy and deliver the M1 
>> message. This would not work in a just pull based model - you'd have to 
>> revive *everyone* on A after a restart just in order to start asking 
>> around in the cluster if someone didn't have a message they wanted to send 
>> to these A# actor – where as with the "retry (push)" model, they are just 
>> started whenever there really is some message to be delivered to them, no 
>> need to start them and "ask around".
>>
>
> Sure, as we move away from peer-to-peer to more actors things do get more 
> complex, but then, if you want to have back-pressure, you need some kind of 
> feedback. I'd see it as a tradeoff - either lazily started actors, or 
> backpressure.
>
> If the sharded actors are aggregate roots, for example, then lazy loading 
> makes perfect sense. But if these are workers, of which there are a couple 
> per host, then this wouldn't be a problem. Just depends on the type of work 
> they are supposed to do.
>  
>
>> I'd also like to make sure what you mean by "reactive" when you use it in 
>> this proposal – I assume you mean the *reactive*-streams "reactive", as 
>> in "abides to the reactive streams protocol", and akka-streams of course 
>> drive those using messaging (in most cases).
>>
>
> Yes, reactive streams, mental shortcut :)
>  
>
>> If so, then yes – we do plan to support reactive-streams over the 
>> network, in our case those will be actor's and messages of course, and yes, 
>> we'll need to implement a reliable redelivery transport for those messages.
>>
>
> Great to hear :)
>  
>
>> We're not there yet, but we definitely will cross that bridge when we get 
>> there :-)
>>
>> Let's move on to the Router example;
>> Well, this is pretty much what we deal with nowadays with elements like 
>> Broadcast 
>> <https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/javadsl/FlowGraph.scala#L165>
>>  
>> / Balance 
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fakka%2Fakka%2Fblob%2Frelease-2.3-dev%2Fakka-stream%2Fsrc%2Fmain%2Fscala%2Fakka%2Fstream%2Fjavadsl%2FFlowGraph.scala%23L209&sa=D&sntz=1&usg=AFQjCNFSrMR25-LKR9NaD5WOGaYkn7az4g>
>>  and *FlexiRoute* 
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fakka%2Fakka%2Fblob%2Frelease-2.3-dev%2Fakka-stream%2Fsrc%2Fmain%2Fscala%2Fakka%2Fstream%2Fjavadsl%2FFlexiRoute.scala&sa=D&sntz=1&usg=AFQjCNF5wRj3RGifRFHYYzVy6qJr7Fb17A>
>> .
>> Especially FlexiRoute should be of interest for you (in this example).

Re: [akka-user] Reactive actor-actor communication

[Adam Warski]

>
> sorry it took my a while to get to this email - been consuming the "least 
> responded / oldest" email from the list throughout the week, not sure it 
> this worked well or not yet... :-)
>
no problem, it's open-source, no SLAs ;)
 

> By the way - isn't dropping demand messages a problem also in the current 
>>> remote-streams implementation?
>>>
>> There is no remote akka streams yet.
> If you mean tcp then the demand is just generated "by the socket" - not 
> through passing tokens over the network.
>
ah I see, turns out I should have studied the code carefully (and TCP as 
well probably ;) )
 

> Right, well, originally I was wondering if Akka could replace 
>>> Kafka+Zookeeper's message streams (which can be used to implement the 
>>> scenario above: where there's a pool of producers, and a pool of consumers, 
>>> all potentially on different hosts, and using Kafka they can stream 
>>> messages reliably). With Kafka's delivery methods you bind each consumer to 
>>> a number of partitions, so it would be as you describe, kind of 
>>> point-to-point streams, which get re-balanced when a node goes down. 
>>>
>> Going this route, there could be a cluster-singleton service which 
>>> assigns B-actors to A-actors, and creates streams between those two. These 
>>> could be the "reactive message streams" from above. And to solve the 
>>> demand-splitting problem (when a B has two As assigned), there could be 
>>> simply more consumer-actors then producer-actors.
>>>
>> This sounds like a very interesting use case.
> Would be awesome if you could tinker around it. 
>
Random fact is that Kafka is *so much used everywhere* that it definitely 
> would find users/contributors I think :-)
>
great, always good to validate ideas :)

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] Reactive actor-actor communication

[Adam Warski]

> By the way - isn't dropping demand messages a problem also in the current 
>>> remote-streams implementation?
>>>
>> There is no remote akka streams yet.
> If you mean tcp then the demand is just generated "by the socket" - not 
> through passing tokens over the network.
>

So as I understand back-pressure is implemented as described here: 
http://doc.akka.io/docs/akka/2.3.7/scala/io-tcp.html (with propagation to 
the writer side by using TCP buffers), right? If the subscriber doesn't 
generate demand, this will result in suspending reading from the socket?

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.

[akka-user] [streams 1.0-M1]

[Adam Warski]

Hello,

I'm migrating to the latest streams, the new client-server stream tcp flow 
does require some mind-bending (switching from req-response to a flow both 
on the client and the server), but I got it working except one thing I 
don't like. 

I have a client (Sender) which sends out messages to the server (Broker), 
and these messages are then forwarded to an actor-sink. There are no 
replies. Still, I need some kind of Source to complete the server-side 
flow. Moreover, I'm using stream-completion to detect that the server 
(Broker) died or otherwise disappeared. So I need a Source that is never 
completed and has no elements. Currently I'm using 
FutureSource(Promise().future), but this seems like a bit of a hack (though 
the good side is it's working ;) ).

The code is here:
https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Broker.scala#L34

Any thoughts? :)

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.

[akka-user] Re: [streams 1.0-M1]

[Adam Warski]

Seems I forgot to actually write the title, sorry ;) It should be sth like 
"No-element never-completed source"

Adam

On Thursday, December 11, 2014 11:33:42 AM UTC+1, Adam Warski wrote:
>
> Hello,
>
> I'm migrating to the latest streams, the new client-server stream tcp flow 
> does require some mind-bending (switching from req-response to a flow both 
> on the client and the server), but I got it working except one thing I 
> don't like. 
>
> I have a client (Sender) which sends out messages to the server (Broker), 
> and these messages are then forwarded to an actor-sink. There are no 
> replies. Still, I need some kind of Source to complete the server-side 
> flow. Moreover, I'm using stream-completion to detect that the server 
> (Broker) died or otherwise disappeared. So I need a Source that is never 
> completed and has no elements. Currently I'm using 
> FutureSource(Promise().future), but this seems like a bit of a hack (though 
> the good side is it's working ;) ).
>
> The code is here:
>
> https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Broker.scala#L34
>
> Any thoughts? :)
>
> 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] Re: [streams 1.0-M1]

[Adam Warski]

Done, issue added: https://github.com/akka/akka/issues/16547

Adam

On Monday, December 15, 2014 12:16:17 PM UTC+1, Björn Antonsson wrote:
>
> Hi Adam,
>
> Yes, that seems to bit awkward. And yes that part of the TCP API also 
> feels a bit backwards. I think that we need to revisit these things when 
> designing the bidirectional flows 
> <https://github.com/akka/akka/issues/16416> that more properly represent 
> a TCP connection in this case. But for now I think that there is no nice 
> workaround. Maybe we still would need that kind of source though. Would you 
> mind opening a ticket?
>
> B/
>
> On 11 December 2014 at 11:34:57, Adam Warski (ad...@warski.org 
> ) wrote:
>
> Seems I forgot to actually write the title, sorry ;) It should be sth like 
> "No-element never-completed source" 
>
> Adam
>
> On Thursday, December 11, 2014 11:33:42 AM UTC+1, Adam Warski wrote: 
>>
>> Hello, 
>>
>> I'm migrating to the latest streams, the new client-server stream tcp 
>> flow does require some mind-bending (switching from req-response to a flow 
>> both on the client and the server), but I got it working except one thing I 
>> don't like. 
>>
>> I have a client (Sender) which sends out messages to the server (Broker), 
>> and these messages are then forwarded to an actor-sink. There are no 
>> replies. Still, I need some kind of Source to complete the server-side 
>> flow. Moreover, I'm using stream-completion to detect that the server 
>> (Broker) died or otherwise disappeared. So I need a Source that is never 
>> completed and has no elements. Currently I'm using 
>> FutureSource(Promise().future), but this seems like a bit of a hack (though 
>> the good side is it's working ;) ).
>>
>> The code is here:
>>  
>> https://github.com/adamw/reactmq/blob/master/src/main/scala/com/reactmq/Broker.scala#L34
>>  
>> Any thoughts? :)
>>
>> 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+...@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.
>
>
> -- 
> Björn Antonsson
> Typesafe <http://typesafe.com/> – Reactive Apps on the JVM
> twitter: @bantonsson <http://twitter.com/#!/bantonsson>
>
>

-- 
>>>>>>>>>>  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] Duplicator example from the docs

[Adam Warski]

Hello,

I'm reading through the streams docs, and I'm currently on the first 
Duplicator example 
(http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala/stream-customize.html)

I'm wondering if there are any guarantees on the order of calling onPush() 
and onPull()? For example, that onPush() won't be called twice in 
succession, but that onPush() and onPull calls are interleaved? Otherwise 
we may end up not duplicating elements (since we only remember the last 
one).

I guess this depends if there is any buffering around a custom 
push-pull-stage, but I would expect it to have a default buffer of awaiting 
elements?

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.

[akka-user] [cluster] minimum number of members and cluster-singleton

[Adam Warski]

Hello,

I was wondering how to avoid split-brain issues when using a cluster 
singleton and automatic downing.
Wouldn't it make sense to add a "min-nr-of-members" setting to the 
singleton? That is, the singleton wouldn't start unless there's a given 
number of members in the cluster online. That would solve the split brain 
problem with singletons.

I know there is the per-role "min-nr-of-members" setting, which impacts the 
startup of the cluster as a whole, and maybe this could be re-used 
(currently if nodes start up, and then some die (leaving a smaller number 
than the setting alive), the singleton starts up anyway).

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] [cluster] minimum number of members and cluster-singleton

[Adam Warski]

Something like downing all members if there's no quorum? I was thinking 
about that, but there are two problems:
- under the current cluster specification, is there a way to resurrect a 
node? Wouldn't "smarter downing" require you to add a new state, something 
like "suspended" (waiting for enough members to be in the same state)?
- wouldn't this be too global? a per-singleton setting doesn't impact the 
cluster as a whole, you can have in a single cluster some services which 
require a quorum, and others which can operate even in a split brain 
scenario

If I get some free time I'd be happy to work on the issue, I assume master 
is a good starting point?

Adam

On Friday, January 2, 2015 3:58:37 PM UTC+1, Patrik Nordwall wrote:
>
> Hi Adam,
>
> We have been thinking that this should be handled with a "smarter" downing 
> strategy, but since it would be easy to implement it in the singleton 
> manager as you propose I think we should consider it. It has already been 
> requested in issue: https://github.com/akka/akka/issues/16535
>
> Cheers,
> Patrik
>
> On Tue, Dec 30, 2014 at 1:07 PM, Adam Warski  > wrote:
>
>> Hello,
>>
>> I was wondering how to avoid split-brain issues when using a cluster 
>> singleton and automatic downing.
>> Wouldn't it make sense to add a "min-nr-of-members" setting to the 
>> singleton? That is, the singleton wouldn't start unless there's a given 
>> number of members in the cluster online. That would solve the split brain 
>> problem with singletons.
>>
>> I know there is the per-role "min-nr-of-members" setting, which impacts 
>> the startup of the cluster as a whole, and maybe this could be re-used 
>> (currently if nodes start up, and then some die (leaving a smaller number 
>> than the setting alive), the singleton starts up anyway).
>>
>> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe <http://typesafe.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
>  

-- 
>>>>>>>>>>  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] Duplicator example from the docs

[Adam Warski]

Ok, if there's only one ball, that answers the question. Thanks! :)

Adam

On Thursday, January 1, 2015 10:00:27 AM UTC+1, Akka Team wrote:
>
> Hi Adam,
>
> PushPull stage callbacks are never concurrent. Also, if a stage calls 
> ctx.Push then it will receive eventually an onPull, and whenever it calls 
> ctx.pull, it will receive an onPush eventually (of course completion events 
> can come at any time).
>
> I'm wondering if there are any guarantees on the order of calling onPush() 
>> and onPull()? For example, that onPush() won't be called twice in 
>> succession, but that onPush() and onPull calls are interleaved? Otherwise 
>> we may end up not duplicating elements (since we only remember the last 
>> one).
>>
>
> You can imagine a series of stages like a pipe and a bouncing ball. When 
> receiving onPush() the ball just bounced into that segment of the pipe. If 
> you call ctx.push as a response to this, then the ball just continues 
> downwards. If you call ctx.pull, then it will bounce back upwards. There is 
> only one "ball" (unless you use DetachedOps but they are an advanced 
> concept).
>
> Currently there is no exposed API to fuse multiple operations into such a 
> synchronous pipeline so all stages will run in a separate actor, but that 
> does not change their behavior (a single stage in an actor is actually 
> three stages, two boundary ones that talk to the actor, and your stage 
> sandwiched in-between) so the above mental model works.
>
> These stages are completely unbuffered and there is only one activated 
> stage at a given time (in a given synchronous island).
>
>  
>
>>
>> I guess this depends if there is any buffering around a custom 
>> push-pull-stage, but I would expect it to have a default buffer of awaiting 
>> elements?
>>
>
> There is never an implicit buffer there, unless you put your own explicit 
> buffering stage.
>
> -Endre
>  
>
>>
>> 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+...@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.
>>
>
>
>
> -- 
> Akka Team
> Typesafe - The software stack for applications that scale
> Blog: letitcrash.com
> Twitter: @akkateam
>  

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

[akka-user] akka-http underlying threading

[Adam Shannon]

This thread in spray-user [0] got me curious about akka-http's current and
future usage of the low level mechanisms. I'm not very familiar with
akka-io underpinnings, but does it use a similar single thread for even
notifications off of the socket? If so I assume that akka-http eventually
gets down to that same point. Is this the plan going forward, or perhaps is
there some other strategy that will be used?

[0]: https://groups.google.com/forum/#!topic/spray-user/avYhEFYsvcg

-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

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

Re: [akka-user] akka-http underlying threading

[Adam Shannon]

Not really sure. I didn't see much in the akka-io docs for how it's
currently implemented. I did find some information from some papers after
some related google searches.

On Wed, Feb 18, 2015 at 7:05 AM, Roland Kuhn  wrote:

> What other strategy do you have in mind?
>
> 17 feb 2015 kl. 20:50 skrev Adam Shannon :
>
> This thread in spray-user [0] got me curious about akka-http's current and
> future usage of the low level mechanisms. I'm not very familiar with
> akka-io underpinnings, but does it use a similar single thread for even
> notifications off of the socket? If so I assume that akka-http eventually
> gets down to that same point. Is this the plan going forward, or perhaps is
> there some other strategy that will be used?
>
> [0]: https://groups.google.com/forum/#!topic/spray-user/avYhEFYsvcg
>
> --
> Adam Shannon | Software Engineer | Banno | Jack Henry
> 206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337
>
> --
> >>>>>>>>>> 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe <http://typesafe.com/> – Reactive apps on the JVM.
> twitter: @rolandkuhn
> <http://twitter.com/#!/rolandkuhn>
>
>  --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Adam Shannon | Software Engineer | Banno | Jack Henry
206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337

-- 
>>>>>>>>>>  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: What are some suggestions for building a GUI for an Akka app?

[Adam Mackler]

On Tuesday, April 17, 2012 5:09:20 PM UTC-4, Bruce wrote:
>
> Are there any examples of someone using Akka + Swing that someone can 
> point me to?  Are there any other approaches that are relatively simple 
> that someone can suggest?
>

Here is a simple example of using Akka + Swing by Arnost 
Valicek<http://stackoverflow.com/users/458832/arnost-valicek>
.

http://stackoverflow.com/questions/15203758/asynchronous-ui-update-with-swing#15218597

--
Adam Mackler
 

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

[akka-user] Documentation suggestion regarding Swing

[Adam Mackler]

I'm in the process of learning GUI programming using Swing.  "Programming 
in Scala" 2nd ed. by Odersky, et al, gives a limited introduction, then 
advises: "There are also many tutorials on the original Java Swing 
framework, on which the Scala wrapper is based," (p. 798), with a reference 
to "The Java Tutorials <http://docs.oracle.com/javase/tutorial/uiswing/>." 
 This Java documentation, in turn, has a lesson, "Concurrency in 
Swing<http://docs.oracle.com/javase/tutorial/uiswing/concurrency/>," 
which refers to the Java class, 
javax.swing.SwingWorker<http://docs.oracle.com/javase/6/docs/api/index.html?javax/swing/SwingWorker.html>.
 
 I therefore looked for the Scala equivalent, and found the Scala class 
*SwingWorker*<http://www.scala-lang.org/api/current/index.html#scala.swing.SwingWorker>,
 
and noticed it is deprecated.  The explanation in the Scaladocs is that it 
"Depends 
on the deprecated package scala.actors."  My understanding is that 
*scala.actors* is deprecated because it is being replaced by akka Actors, 
suggesting that the proper way to work through the Java lesson on Swing 
concurrency involves understanding something about Akka.  I did find an 
answer on stackoverflow showing an example of Akka + 
Swing<http://stackoverflow.com/questions/15203758/asynchronous-ui-update-with-swing#15218597>,
 
but it would be nice to have the confidence that comes from knowing a 
particular pattern is officially endorsed.

I convey the foregoing narrative for the purpose of explaining why someone 
in my position, that is learning the Scala side of Swing by following the 
Java documentation, will be directed to Akka.  As far as I can see the Akka 
documentation makes no mention of Swing.  My suggestion is that some 
reference to Swing be added to the Akka documentation, perhaps either an 
example if appropriate, or an explanation of why an example would not be 
appropriate.  Either way it would provide some continuation to what seems 
to be to be an abrupt termination in a trail of documentation that begins 
in what might be the most commonly-used introductory text on the Scala 
language.

Thanks,
--
Adam Mackler

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

Re: [akka-user] Documentation suggestion regarding Swing

[Adam Mackler]

On Monday, December 30, 2013 11:13:42 PM UTC-5, √ wrote:
>
> https://gist.github.com/viktorklang/2422659
>
> And
>
> https://gist.github.com/viktorklang/2422443
>

Thank you for those examples.  Question: the *swingactors.scala* file 
contains a reference to class *FrameActor*.  What is that?

--
Adam Mackler

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

Re: [akka-user] New Android app that uses Akka

[Adam Mackler]

Hi Tim:

Thanks for your interest.  It's been a while since I looked at this code, 
so it's not very fresh in my memory.  Also, I'm not fully certain I'm 
understanding your question, so I'll just tell you some stuff, and 
hopefully what you want to know is in there.

My assessment of the "way" to integrate Akka and Android is that each 
framework has an essential base class and its own message-passing 
mechanism.  Those classes are *Actor* and *Activity* respectively.  The 
message-passing is done in Akka, as you know, using *tell*, a.k.a. "*!*". 
 The native mechanism for passing messages in Android is by passing a 
*Runnable* to 
*Handler.post()*<http://developer.android.com/reference/android/os/Handler.html#post(java.lang.Runnable)>.
 
 Integrating Akka + Android works nicely by figuring out where the Actor 
instances need to *post* messages to *Activity*s.  I know I'm being very 
vague since, again, this is not fresh in my mind, but if I were preparing a 
lecture on integrating Akka and Android, that would be the first thing I 
would want to explain in detail.

The next thing to understand is that one of my requirements for the 
Metronome app was to require no special permissions.  As best I remember, 
the only way to make sure the app would stop making sounds if an incoming 
phone call occurs without requiring a permission to read the phone state 
was to cause it to stop whenever the *Activity* is hidden.  Since the 
purpose of a *Service* is to continue running when an app's *Activity* is 
hidden, I did not want to use a *Service*, but that is a direct consequence 
of my desire to avoid requiring any special permissions.  Obviously if 
you're making an app for internal corporate use, special permissions is not 
something you would be worried about, thus no such limit on *Service* use 
would exist.

Finally, you mention the need for the app to respond to external events 
regardless of its state.  Without knowing the essence of the debate you're 
having, my first reaction is that my attention would go toward configuring 
the *AndroidManifest.xml* file so that your app responds to events as 
needed, even if the device has just been rebooted and the driver has not 
yet started the app.  That might involve starting a *Service*automatically.  
Depends on the specifics of how the events are making their 
way to the device.

Knowing as little as I do about your specific requirements, I can say it 
sounds as if your implementation ought to be very straightforward, and the 
fault-tolerance that is possible with Akka can make your app very resilient 
to the connectivity interruptions your app can expect while operating on 
the road with the drivers.

--
Adam Mackler

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

[akka-user] StackOverflow with long actor path name.

[Adam Shannon]

Hello all,

I've found out that I can get a StackOverflow exception when creating and
using an actor with a long path name. It looks like this may just be due to
a recursive call in the java.util.Regex library? Does anyone have any
suggestions other than just not making such long path names?

https://gist.github.com/adamdecaf/8790506

-- 
Adam Shannon
Software Engineer
University of Northern Iowa
Senior -- Computer Science & Mathematics
http://ashannon.us

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

Re: [akka-user] StackOverflow with long actor path name.

[Adam Shannon]

That's the route we're going to use now. We previously had the uuids all
there to make debugging a bit easier. Thanks!


On Mon, Feb 3, 2014 at 1:31 PM, √iktor Ҡlang  wrote:

> Sounds like a weird bug, on the other hand, you should probably stop
> creating such long names.
> The name should be short and to the point, it's not a place to put a
> base64-encoded payload (or worse ;))
>
>
> On Mon, Feb 3, 2014 at 8:24 PM, Adam Shannon  wrote:
>
>> Hello all,
>>
>> I've found out that I can get a StackOverflow exception when creating and
>> using an actor with a long path name. It looks like this may just be due to
>> a recursive call in the java.util.Regex library? Does anyone have any
>> suggestions other than just not making such long path names?
>>
>> https://gist.github.com/adamdecaf/8790506
>>
>> --
>> Adam Shannon
>> Software Engineer
>> University of Northern Iowa
>> Senior -- Computer Science & Mathematics
>> http://ashannon.us
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>> >>>>>>>>>> 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/groups/opt_out.
>>
>
>
>
> --
> Cheers,
> √
>
> * ——— **Viktor Klang*
> *Chief Architect - **Typesafe <http://www.typesafe.com/>*
>
>  Twitter: @viktorklang
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
> >>>>>>>>>> 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/groups/opt_out.
>



-- 
Adam Shannon
Software Engineer
University of Northern Iowa
Senior -- Computer Science & Mathematics
http://ashannon.us

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: http://akka.io/faq/
>>>>>>>>>>  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/groups/opt_out.

Re: [akka-user] StackOverflow with long actor path name.

[Adam Shannon]

That sounds like it would help. I didn't see anything in the docs about
there being a max length for actor path names. I haven't dug into the code
around path creation / lookup to try and find a fix.


On Mon, Feb 3, 2014 at 1:52 PM, √iktor Ҡlang  wrote:

> Perhaps it would make sense to not only fix the regex if possible, but
> also put a reasonable cap on the name length to make sure that the paths
> are representable as strings?
>
>
> On Mon, Feb 3, 2014 at 8:34 PM, Adam Shannon  wrote:
>
>> That's the route we're going to use now. We previously had the uuids all
>> there to make debugging a bit easier. Thanks!
>>
>>
>> On Mon, Feb 3, 2014 at 1:31 PM, √iktor Ҡlang wrote:
>>
>>> Sounds like a weird bug, on the other hand, you should probably stop
>>> creating such long names.
>>> The name should be short and to the point, it's not a place to put a
>>> base64-encoded payload (or worse ;))
>>>
>>>
>>> On Mon, Feb 3, 2014 at 8:24 PM, Adam Shannon  wrote:
>>>
>>>> Hello all,
>>>>
>>>> I've found out that I can get a StackOverflow exception when creating
>>>> and using an actor with a long path name. It looks like this may just be
>>>> due to a recursive call in the java.util.Regex library? Does anyone have
>>>> any suggestions other than just not making such long path names?
>>>>
>>>> https://gist.github.com/adamdecaf/8790506
>>>>
>>>> --
>>>> Adam Shannon
>>>> Software Engineer
>>>> University of Northern Iowa
>>>> Senior -- Computer Science & Mathematics
>>>> http://ashannon.us
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>> >>>>>>>>>> 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/groups/opt_out.
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> √
>>>
>>> * ——— **Viktor Klang*
>>> *Chief Architect - **Typesafe <http://www.typesafe.com/>*
>>>
>>>  Twitter: @viktorklang
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>> >>>>>>>>>> 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/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Adam Shannon
>> Software Engineer
>> University of Northern Iowa
>> Senior -- Computer Science & Mathematics
>> http://ashannon.us
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/
>> >>>>>>>>>> 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/groups/opt_out.
>>
>
>
>
> --
> Cheers

[akka-user] Props Factory

[Adam Marcionek]

I've been trying to use the recommended factory method for defining props 
as indicated here: http://doc.akka.io/docs/akka/2.2.3/scala/actors.html   I 
tried it on my own class and it failed with the same type mismatch as seen 
below, so I went straight to the demo code using two definitions for props:

import akka.actor.Actor
import akka.actor.Props

object DemoActor {
  /**
   * Create Props for an actor of this type.
   * @param name The name to be passed to this actor’s constructor.
   * @return a Props for creating this actor, which can then be further 
configured
   * (e.g. calling `.withDispatcher()` on it)
   */
  def props(name: String): Props = Props(classOf[DemoActor], name)
  //def props(name: String): Props = Props(new DemoActor(name))
}
 
class DemoActor(name: String) extends Actor {
  def receive = {
case x ⇒ // some behavior
  }
}

The first "props" definition fails a compile time error: 

error: type mismatch;
 found   : 
Class[Seven10.hydra.core.scala.DemoActor](classOf[Seven10.hydra.core.scala.DemoActor])
 required: () => akka.actor.Actor
  def props(name: String): Props = Props(classOf[DemoActor], name)

The 2nd one compiles fine, but from what I read is not 
recommended.(https://www.assembla.com/spaces/akka/tickets/3764-doc--revise-advice-for-props-factory-methods#/activity/ticket:)
 
 I'm using Netbeans with the scala plug-in. Any help is appreciated.


-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: http://akka.io/faq/
>>  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/groups/opt_out.

[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] [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<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Freactive-streams%2Freactive-streams%2Fissues%2F45&sa=D&sntz=1&usg=AFQjCNEPPvBVRxCWoDYTDt7ggdEt1ljBbA>
> 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] [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 <https://github.com/akka/akka/issues/15135> 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 Monday, May 26, 2014 2:25:52 PM UTC+2, Konrad Malawski wrote:
>
> One thing unanswered from the previous email:
>
> 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?
>
> In theory reactive streams aim to be usable between frameworks - so an Rx 
> Producer would be consumable in akka-streams and vice-versa.
> So, yes it's ok to provide your own Producers (like from a database etc).
> Internally we have some more abstractions which make implementing these 
> easier, but I'm not aware of plans of exposing them any time soon - for 
> starters we need to update akka-streams to the updated reactive-streams 
> interfaces.
>

I see, but then I have to implement the subscription management etc myself 
- which I guess can be tricky ;) But why not try.

Thanks for the help!

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.