Re: [akka-user] Abridged summary of akka-user@googlegroups.com - 10 updates in 5 topics

[Joseph Mansigian]

Hello Victor,

Thank you for your reply.  Based on your response I think that I did not
express very well what I am seeking.  Being able to have the servlet send a
message to an actor and vice versa would be perfectly Okay.  I am searching
for some code that would be a model of how to effect this interaction in
which the servlet would always initiate the interaction with a message and
then the actor would reply.  What I am saying is I don't know the technique
for sending and receiving messages from inside a servlet.  Would be greatly
helped by example.  Perhaps I should look at some Play code that must do
this.  Thank you for your attention to this.

Joe Mansigian

On Sun, Oct 18, 2015 at 1:33 PM,  wrote:

> akka-user@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Today's topic summary
> View all topics
> 
>
>- Proposed major simplification of the Akka Streams FlowGraph APIs
><#1507c032c1327adf_group_thread_0> - 4 Updates
>- No Tests to run for MultiJvm <#1507c032c1327adf_group_thread_1> - 2
>Updates
>- No Tests to run for MultiJvm <#1507c032c1327adf_group_thread_2> - 1
>Update
>- Behavior of Akka when you sleep in an actor
><#1507c032c1327adf_group_thread_3> - 1 Update
>- Servlet and Actor <#1507c032c1327adf_group_thread_4> - 2 Updates
>
> Proposed major simplification of the Akka Streams FlowGraph APIs
> 
> Viktor Klang : Oct 17 10:57PM +0200
>
> 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 ...more
> 
> Adam : Oct 18 12:36AM -0700
>
> 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 ...more
> 
> Viktor Klang : Oct 18 01:14PM +0200
>
> Hi Adam,
>
> Thanks for your feedback!
> Responses inline
>
>
> > I like most of the described changes.
>
> > Here are my personal reservations:
>
> > 1. I prefer a single method name with many overloads ...more
> 
> "אדם חונן" : Oct 18 06:57PM +0300
>
> Ah.. I didn't think of that type erasure issue. Makes sense.
>
> RxJava doesn't have a graph DSL as far as I know.
> I'm guessing you'd have to use Subjects to implement something similar to
> ...more
> 
> Back to top <#1507c032c1327adf_digest_top>
> No Tests to run for MultiJvm
> 
> Harit Himanshu : Oct 17 10:18PM -0700
>
> Hello everyone,
>
> I started learning akka-cluster today and was trying to write the
> multi-ivm
> test.
> I followed all through the document but when I run my application, I see
>
>
> ...more
> 
> matheuslima...@gmail.com: Oct 18 08:22AM -0700
>
> You need create the node class:
> class:
>
> class SimpleClusterListenerSpecMultiJvmNode1 extends
> SimpleClusterListenerSpec
> class SimpleClusterListenerSpecMultiJvmNode2 extends ...more
> 
> Back to top <#1507c032c1327adf_digest_top>
> No Tests to run for MultiJvm
> 
> Harit Himanshu : Oct 17 10:16PM -0700
>
> Hello everyone,
>
> I started learning akka-cluster today and was trying to write the
> multi-ivm
> test.
>
> I followed all through the document ...more
> 
> Back to top <#1507c032c1327adf_digest_top>
> Behavior of Akka when you sleep in an actor
> 
> Konrad Malawski : Oct 18 02:29AM +0200
>
> On Thu, Oct 15, 2015 at 4:44 AM, Fahimeh Rahemi 
> wrote:
>
> > Please let me see if I 

Re: [akka-user] Why is aroundReceive protected[akka]?

[Konrad Malawski]

Hi Jan!

Yes, it's definitely one of those 
"Do not do this because you will most likely shoot yourself in the foot"?
methods, and we believe it's much safer to keep it internal than to make it 
public, thus encouraging devs to use it (and end up in around-what-hell).

We have used it very heavily in Akka Persistence and while with one level of 
inheritance it's still easy to wrap your head around it, it gets pretty hard 
once there's multiple traits involved.



For application development I'd highly recommend either explicit function 
handling (chaining, or wrapping) or using child actors to perform other 
"additional work" that you might need to do.



Hope this explains things :-)

-- 
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] Why is aroundReceive protected[akka]?

[Jan Algermissen]

Hi,

looking at akka-streams ActorPublisher recently, I found the approach to 
implement actor 'base-behavior' using aroundReceive quite elegant and much 
more natural than partial function chaining.

Is there a reason this approach is limited to Akka internals (aroundReceive 
is protected[akka])?

Is it to say "If you override this, please think in terms of creating an 
akka extension" or is it to say "Do not do this because you will most 
likely shoot yourself in the foot"?

Jan

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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

[Harit Himanshu]

A dumb question. I was in such a situation recently and have been sleeping 
threads in Java. I got so much used to it that now I had trouble telling 
Actor what "heavy work" it should do to stay busy. 

My solution was File.createTempFile("someRandom", "txt") couple of thousand 
time (so Actor was busy doing something I did not care). The problem was it 
was creating all these files. 

What other ways people have kept their actors busy (pretending they are 
doing a lot for work)? This is just for tests I am asking for.

On Saturday, October 17, 2015 at 5:30:13 PM UTC-7, Konrad Malawski wrote:
>
>
> On Thu, Oct 15, 2015 at 4:44 AM, Fahimeh Rahemi  > wrote:
>
>> Please let me see if I understand your answer correctly, do you mean that 
>> if I use thread.sleep(5000) inside an actor, the actor does not leave it's 
>> thread at all? and the thread is idle and jobless for 5 seconds?
>>
>
> Yeah, exactly. It effectively renders that thread useless for around 5 
> seconds – don't do that ;-)
>
>
> -- 
> Konrad
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: [akka-stream] How to get materialization result in partial flow

[Alexey Romanchuk]

The problem with this solution is absence of actorRef during upstream 
complete. Any ideas how to get it?

пятница, 16 октября 2015 г., 15:18:51 UTC+6 пользователь Alexey Romanchuk 
написал:
>
> Finally ended with 
>
> ```scala
> val managedMySource = FlowGraph.partial(MySource()) {
> implicit b => source =>
>   val control = b.add(Flow[Command]])
>   val zip = b.add(Zip[ActorRef, Command])
>   
> b.materializedValue.map(Source.repeat).flatten(FlattenStrategy.concat) ~> 
> zip.in0
>   
> control.outlet ~> zip.in1
>
>   zip.out ~> Sink.foreach[(ActorRef, Command)] {
> case (ref, cmd) => ref ! cmd
>   }
>
>   FlowShape(control.inlet, source.outlet)
> }
> ```
>
> Any ideas or comments?
>
>
> пятница, 16 октября 2015 г., 11:48:27 UTC+6 пользователь Alexey Romanchuk 
> написал:
>>
>> Hey hAkkers!
>>
>> I need your advise in akka streams materialization question.
>>
>> I have custom protocol source `MySource` of type`Source[String, 
>> ActorRef]` which accepts messages to control protocol via ActorRef after 
>> materialization. Example of message is something like connect to server or 
>> change parameters of existing connection and so on.
>>
>> Creation of flow with this API is easy:
>>
>> ```
>> val actor = MySource().to(Sink.ignore).run
>> actor ! SomeCommand()
>> ```
>>
>> Next, I have `Source[Command, Unit]` and I want to be able to connect it 
>> to `MySource`. So I need to lift `MySource` from source to `Flow`:
>>
>> ```
>> val source: Source[String, ActorRef] = ???
>>
>> //some magic with custom stage or partial flow here and
>> val controlledSource: Flow[Command, String, ActorRef] = ???
>> ```
>>
>> I tried to do it with partial flow:
>>
>> ```
>>   val flow = FlowGraph.partial() { implicit b =>
>> import FlowGraph.Implicits._
>> val mySource = MySource
>> val commandsInput = Sink.foreach[Command](???) //I need ActorRef here 
>> :(
>> FlowShape(b.add(commandsInput).inlet, b.add(mySource).outlet)
>>   }
>> ```
>>
>> but to connect commands with source I need result of materialization.
>>
>> Any ideas how to keep `Source[String, ActorRef]` and have `Flow[Command, 
>> String, ActorRef]`?
>>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: No Tests to run for MultiJvm

[Harit Himanshu]

Thank you friend, that worked well and I was able to run my first multi-ivm 
test. Here is what my test 

 
code looks like.

When I run it, I get

$ sbt clean compile test

[info] Loading project definition from 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/project

[info] Set current project to akka-cluster-investigation (in build 
file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/)

[success] Total time: 0 s, completed Oct 18, 2015 9:43:50 PM

[info] Updating 
{file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}cluster_simple...

[info] Updating 
{file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}akka-cluster-investigation...

[info] Resolving jline#jline;2.12.1 ...

[info] Done updating.

[info] Resolving jline#jline;2.12.1 ...

[info] Done updating.

[info] Compiling 2 Scala sources to 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/classes...

[success] Total time: 6 s, completed Oct 18, 2015 9:43:56 PM

[info] Compiling 1 Scala source to 
/Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/multi-jvm-classes...

[info] * SimpleClusterListenerSpec

[JVM-1] Run starting. Expected test count is: 2

[JVM-1] SimpleClusterListenerSpecMultiJvmNode1:

[JVM-1] - Illustrate how to start-up a cluster

[JVM-1] - show that SimpleClusterListener receives message

[JVM-1] [WARN] [10/18/2015 21:44:01.571] 
[SimpleClusterListenerSpec-akka.actor.default-dispatcher-16] 
[akka://SimpleClusterListenerSpec/user/controller/127.0.0.1:53775-server1] 
received dead letter from 
Actor[akka://SimpleClusterListenerSpec/deadLetters]: ClientDisconnected

[JVM-1] Run completed in 1 second, 889 milliseconds.

[JVM-1] Total number of tests run: 2

[JVM-1] Suites: completed 1, aborted 0

[JVM-1] Tests: succeeded 2, failed 0, canceled 0, ignored 0, pending 0

[JVM-1] All tests passed.

[info] Run completed in 37 milliseconds.

[info] Total number of tests run: 0

[info] Suites: completed 0, aborted 0

[info] Tests: succeeded 0, failed 0, canceled 0, ignored 0, pending 0

[info] No tests were executed.

[success] Total time: 5 s, completed Oct 18, 2015 9:44:01 PM


Thank you again for your help
+ Harit

On Sunday, October 18, 2015 at 8:22:46 AM UTC-7, matheus...@gmail.com wrote:
>
> You need create the node class:
> class:
>
> class SimpleClusterListenerSpecMultiJvmNode1 extends 
> SimpleClusterListenerSpec
> class SimpleClusterListenerSpecMultiJvmNode2 extends 
> SimpleClusterListenerSpec
>
> The class name always created using format XXXMultiJvmNodeN and you create 
> one class per node you want test
>
>
> On Sunday, October 18, 2015 at 5:18:08 AM UTC, Harit Himanshu wrote:
>>
>> Hello everyone,
>>
>> I started learning akka-cluster today and was trying to write the 
>> multi-ivm test.
>> I followed all through the document but when I run my application, I see
>>
>>
>> > ; reload ; clean ; compile ; multi-jvm:test
>> [info] Loading project definition from 
>> /Users/harit/IdeaProjects/libs/akka-cluster-investigation/project
>> [info] Set current project to akka-cluster-investigation (in build 
>> file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/)
>> [success] Total time: 0 s, completed Oct 17, 2015 10:08:45 PM
>> [info] Updating 
>> {file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}akka-cluster-investigation...
>> [info] Updating 
>> {file:/Users/harit/IdeaProjects/libs/akka-cluster-investigation/}cluster_simple...
>> [info] Resolving jline#jline;2.12.1 ...
>> [info] Done updating.
>> [info] Resolving jline#jline;2.12.1 ...
>> [info] Done updating.
>> [info] Compiling 2 Scala sources to 
>> /Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/classes...
>> [success] Total time: 1 s, completed Oct 17, 2015 10:08:46 PM
>> [info] Compiling 1 Scala source to 
>> /Users/harit/IdeaProjects/libs/akka-cluster-investigation/cluster_simple/target/scala-2.11/multi-jvm-classes...
>> [info] Passed: Total 0, Failed 0, Errors 0, Passed 0
>> [info] No tests to run for MultiJvm
>> [success] Total time: 1 s, completed Oct 17, 2015 10:08:47 PM
>>
>>
>>
>> It compiles the class but says no tests to run, My Test looks like  
>>
>> import akka.remote.testkit.{MultiNodeConfig, MultiNodeSpec}
>> import akka.testkit.ImplicitSender
>> import org.scalatest.{BeforeAndAfterAll, MustMatchers, WordSpecLike}
>>
>>
>> object SimpleClusterListenerSpecConfig extends MultiNodeConfig {
>>   val cluster = role("cluster")
>> }
>>
>> class SimpleClusterListenerSpec extends 
>> MultiNodeSpec(SimpleClusterListenerSpecConfig)
>> with WordSpecLike
>> with MustMatchers
>> with BeforeAndAfterAll
>> with ImplicitSender {
>>
>>   import SimpleClusterListenerSpecConfig._
>>
>>   override def initialParticipants: Int = roles.size
>>
>>   "A 

Re: [akka-user] Memory model, messages and remoting

[Viktor Klang]

Hi Florian,

On Sun, Oct 18, 2015 at 8:00 PM, olf sync  wrote:

> Thanks  √ for your response.
>
> I use https://github.com/romix/akka-kryo-serialization at the moment.
>
> I have a lot of actors on System B, which get messages from ONE actor from
> system A. They get all the same message and have to keep some information
> from inside the message inside the actor (but do not change the data). If
> they keep something referenced from the same message i could save a lot of
> memory.
>

I'm thinking it'd be simpler to have the one actor in system A send the
message once to one actor on system B, and have that actor forward the
message to the other actors.


>
> So I question myself, if I need some kind of additional memory actor, who
> keeps only one reference for all other actors or if akka can handle it
> itself.
>
> Cheers,
>
> Florian
>
>
> Am Freitag, 16. Oktober 2015 11:49:15 UTC+2 schrieb √:
>>
>> Hallo!
>>
>> The same instance would be serialized twice, it is up to the configured
>> Serializer implementation if it wants to memoize/cache etc it's up to it to
>> do so.
>>
>> On Fri, Oct 16, 2015 at 10:33 AM, olf sync  wrote:
>>
>>> Hallo everyone,
>>>
>>> first thanks for the great framework. I have a question about the akka
>>> memory model and remoting.
>>>
>>> If I have two hosts (A,B) and have the Actors A1,B1,B2, would the SAME
>>> message send from A1 to Actor B1 and A1 to B2 saved twice inside the memory
>>> model of Host B or only once?
>>> If I have only one host A and send messages between the actors inside
>>> the host the message would not be copied, right? Even if I activate  the
>>> option remoting?
>>>
>>> Best regards
>>>
>>> Florian Beckh
>>>
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to 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+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.
>



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

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

[Viktor Klang]

Hi Adam,

Thanks for your feedback!
Responses inline

On 18 Oct 2015 09:36, "Adam"  wrote:
>
> 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.

In general I do too, but with erasure and type inference it creates what
I've dubbed "Overloading overload" where the compiler (both Java and Scala)
will start spitting out nasty error messages with N signatures. Hardly
helpful for newcomers, I'd say!

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

That's an interesting proposal, I'll try it out locally and see how it
reads.

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

The reason for removing it is to not have multiple APIs for the same thing,
choice for the sake of choice is something I think creates more harm than
value.
As for RxJava, does it even have a graph dsl? link?

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

Besides the anti-bifurcation reason, what makes addEdge "easier" than the
DSL?
In general I am not for symbolic dsls but in the Scala DSL case it actually
reads very cleanly. My main concern with the symbolic DSL is that it almost
*requires* reading docs to even use it, which means also knowing that one
has to import the FlowGraph.Implicits._, I think moving the
FlowGraph.Implicits to the builder might help increase readability. Or
moving the arrows to the builder?

implicit builder => import builder.dsl._

Any other thoughts on improving the accessibility?

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

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Proposed major simplification of the Akka Streams FlowGraph APIs

[אדם חונן]

Ah.. I didn't think of that type erasure issue. Makes sense.

RxJava doesn't have a graph DSL as far as I know.
I'm guessing you'd have to use Subjects to implement something similar to
graphs there, but so far I've never had the need for that.
I guess what I usually do with RxJava is more similar to only ever using
Source from Akka Streams, although I'm pretty sure I'd have to use both
Source and Flow.
In my case, we're using RxJava because we're using Couchbase and the java
client is based on RxJava.
I guess our use case is much more similar to using Futures - we don't need
complex graphs for most of our system.

Methods are simply easier to find inside an IDE than symbols.
You start with "builder.", hit ctrl+space and there it is, with properly
named arguments and all.
But thinking of it further, it actually only matters if the code samples in
the documentation use it as well.
I mean, my starting point was from a code sample, so if that uses "~>" and
I fail to copy all parts (or the sample skips some parts under the
assumption that I already know them), it won't matter if addEdge is
available or not - my copied code won't work. It might make it clearer if
my mistake was to not have "builder =>".

Anyway, none of the above was what was most difficult to me.
I think the difficulties I had are sort of out of scope for this discussion.
I think it's mostly knowing what to use where.
With RxJava you have a huge amount of operators, which is sometimes
annoying, but it's a one stop shop, so when you're "stumbling in the dark"
(although the documentation also makes a difference), you're more likely to
bump into the right thing.
With Akka Streams things are cleaner, but are also found in different
places, so you have to look for them in more places.
I guess it's really a design choice. Akka Streams pushes you more towards
writing new composable components, which may be nice for the long run, but
less intuitive initially.

I'll try to be specific, although I find it hard to remember precisely -

   1. I often found myself *thinking* that I probably need to call
   builder.add(something) and I found myself unsure what that "something"
   should be.
   2. It's easy to miss stuff like that instead of flatMap, you often need
   to use join. Initially it takes browsing through lots of documentation
   pages. After a while you get used to where to look for it. I guess I'd say
   it's not as "search friendly" as Rx (for now).





On Sun, Oct 18, 2015 at 2:14 PM, Viktor Klang 
wrote:

> Hi Adam,
>
> Thanks for your feedback!
> Responses inline
>
> On 18 Oct 2015 09:36, "Adam"  wrote:
> >
> > 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.
>
> In general I do too, but with erasure and type inference it creates what
> I've dubbed "Overloading overload" where the compiler (both Java and Scala)
> will start spitting out nasty error messages with N signatures. Hardly
> helpful for newcomers, I'd say!
>
> >
> >
> > 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).
>
> That's an interesting proposal, I'll try it out locally and see how it
> reads.
>
> >
> >
> >
> > 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).
>
> The reason for removing it is to not have multiple APIs for the same
> thing, choice for the sake of choice is something I think creates more harm
> than value.
> As for RxJava, does it even have a graph dsl? link?
>
> >
> > 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.
>
> Besides the anti-bifurcation reason, what makes addEdge "easier" than the
> DSL?
> In general I am not for symbolic dsls but in the Scala DSL case it
> actually reads very cleanly. My main concern with the symbolic DSL is that
> it almost *requires* reading docs to even use it, which means also knowing
> that one has to import the FlowGraph.Implicits._, I think moving the
> FlowGraph.Implicits to the builder might help increase readability. Or
> moving the arrows to the builder?
>
> implicit builder => 

Re: [akka-user] Memory model, messages and remoting

[olf sync]

Thanks  √ for your response. 

I use https://github.com/romix/akka-kryo-serialization at the moment.

I have a lot of actors on System B, which get messages from ONE actor from 
system A. They get all the same message and have to keep some information 
from inside the message inside the actor (but do not change the data). If 
they keep something referenced from the same message i could save a lot of 
memory. 

So I question myself, if I need some kind of additional memory actor, who 
keeps only one reference for all other actors or if akka can handle it 
itself.

Cheers, 

Florian


Am Freitag, 16. Oktober 2015 11:49:15 UTC+2 schrieb √:
>
> Hallo!
>
> The same instance would be serialized twice, it is up to the configured 
> Serializer implementation if it wants to memoize/cache etc it's up to it to 
> do so.
>
> On Fri, Oct 16, 2015 at 10:33 AM, olf sync  > wrote:
>
>> Hallo everyone, 
>>
>> first thanks for the great framework. I have a question about the akka 
>> memory model and remoting.
>>
>> If I have two hosts (A,B) and have the Actors A1,B1,B2, would the SAME 
>> message send from A1 to Actor B1 and A1 to B2 saved twice inside the memory 
>> model of Host B or only once? 
>> If I have only one host A and send messages between the actors inside the 
>> host the message would not be copied, right? Even if I activate  the option 
>> remoting?
>>
>> Best regards
>>
>> Florian Beckh
>>
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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+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.