Akka Artery

[Gavin Baumanis]

Hi Gang,

I was getting started with a technology pilot and was planning on using akka clustering.

I started by creating a separate conf file for akka module / section.

Since it is relatively new in the development phase - we initially plan on keeping everything updated as new versions of Scala / Akka and Play are released... So that we're at the very latest possible versions before we have to start doing appropriate "versioning" of dependencies. So  changes in config - even in code use are expected at this stage...

While going through the documentation and attempting to configure an Akka cluster, I came across a configuration file;

Stating that "artery" was the new 'way" for akka remoting.

So now , I have some (hopefully) quick questions, please...

 * Should I use the new artery or not?

 * The artery version of the conf file has an "actor" space...

      Should this namespace be in the "actor.actor" config file? - or dopes it belong with the remote config?

 * Does it "completely replace the initial "actor" conf example file?

Lastly and probably the most import one is - is there some appropriate documentation / discussions about artery? Particularly if the advice is to go with that version of remoting?

As is always the case...

Thanks very much in advance!

-Gavin.

[Konrad Malawski]

Hi Gavin,

the question boils down to when you expect to hit prod.

We're still working on improving stability and production-hints-on-configuring/debugging Artery.

In general since this sounds like a new project I would suggest you start using Artery and provide us with feedback if something feels off.

Please note that changing the remoting subsystem is exactly _zero_ code changes :-) If you want to step back and use the old TCP based one you can with the flip of a switch (akka.remote.artery.enabled = off).

I assume you've seen: http://doc.akka.io/docs/akka/2.4/scala/remoting-artery.html 

The question on "Does it completely replace the initial actor conf example file" sounds a bit weird - it is the same file, artery simply has it's own configuration section: http://doc.akka.io/docs/akka/2.4/general/configuration.html#akka-remote

Happy hakking!

-- 
Konrad `ktoso` Malawski
Akka @ Lightbend

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to 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.

[Konrad Malawski]

You may also want to track our blog, as we're publishing things about Artery internals there:

http://blog.akka.io/artery/2016/12/02/streams-in-artery 

http://blog.akka.io/artery/2016/12/05/aeron-in-artery

Those were rather light, we have some pretty advanced stuff in there which we'll want to blog about eventually – watch the blog ;-)

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@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,

[Gavin Baumanis]

Hi Konrad,

Thanks very much for the details.

I am happy to use the new tech and report anything that I find, of course...

The question on "Does it completely replace the initial actor conf example file" sounds a bit weird - it is the same file, artery simply has it's own configuration section: http://doc.akka.io/docs/akka/2.4/general/configuration.html#akka-remote

As the documentation reads;

"Each Akka module has a reference configuration file with the default values."

So... What I have done is "literally" take the configuration examples as individual files and "included" them ALL within application.conf

include "akka-actor.conf"
include "akka-agent.conf"
include "akka-camel.conf"
include "akka-cluster.conf"
include "akka-cluster-metrics.conf"
include "akka-cluster-sharding.conf"
include "akka-cluster-tools.conf"
include "akka-distributed-data.conf"
include "akka-http.conf"
include "akka-multinode-testkit.conf"
include "akka-persistence.conf"
include "akka-remote.conf"include "akka-testkit.conf"

where I have (hopefully I am using the right term) the different namespaces separated.

in the artery flavoured akka.remote example config file is;

akka {
  actor {
    serializers {
...

so what i was asking was does that configuration belong in akka.actor.conf

Should I be using those values to overwrite / replace the same "path" of configuration that is in the default akka.actor.conf file?

I am just now thinking that I have been too literal.... but nonetheless

Perhaps a paragraph of how to use the example conf files might clear up the confusion for those that don't have an intimate knowledge of akka as a starting point.

As always, thanks for your time and advice!

-Gavin

[Konrad Malawski]

"Each Akka module has a reference configuration file with the default values."

So... What I have done is "literally" take the configuration examples as individual files and "included" them ALL within application.conf

include "akka-actor.conf"
include "akka-agent.conf"
include "akka-camel.conf"[...]

Oh :-) You don't need to do that. The defaults are loaded... by default :-)

Read more about how config works here: https://github.com/typesafehub/config

Basically each project has reference.conf, they all get merged, applied, and then your application.conf gets applied.

You don't need to touch or import any reference.conf, they're loaded by default. You only need to override what you want in application.conf

[Gavin Baumanis]

Hi Konrad,

Naturally - I am aware that the defaults ARE defaults.

But for the purpose of documenting the config and providing the alternative choices too (Which the example configs do a pretty good job of)

It "seemed harmless" to literally include the default values.

But I am certainly happy with only include the config you need, when you need it.

Thanks for the help.

-Gavin.

[Patrik Nordwall]

Artery config belongs to akka-remote

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@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.

--

Patrik Nordwall
Akka Tech Lead
Lightbend -  Reactive apps on the JVM
Twitter: @patriknw

[Gavin Baumanis]

Hi Patrik,

I am aware that artery is the new remote.

My query was more about having duplicate config items at the same "path" - in different conf files.

In that the example conf file for artery also includes configs items at akka.actor.xxx

which are also in the akka.actor.conf example conf file : 

Which one wins? 

Which one is correct?

Anyway : I think I have it resolved now - by not using ALL the config files and just having the configuration needed ONLY.

Thanks!

-Gavin.

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.

[Konrad Malawski]

I actually think doing it manually like this will end up being way more confusing... 

The reference.conf / application.conf style is rather well established in Akka or Scala apps and provides minimal boilerplate.

Reference is defaults "application always wins".

Who "wins" is well known here and also well documented in typesafe-config, please read its docs.

-- 
Konrad `ktoso` Malawski
Akka @ Lightbend

[Gavin Baumanis]

I guess it is all moot now that I have stripped away the defaults and only have "changes".

On Saturday, 7 January 2017 01:34:27 UTC+11, Konrad Malawski wrote:

I actually think doing it manually like this will end up being way more confusing... 

The reference.conf / application.conf style is rather well established in Akka or Scala apps and provides minimal boilerplate.

Reference is defaults "application always wins".

Who "wins" is well known here and also well documented in typesafe-config, please read its docs.

But for the fact that I am Including the files - so aren't they ALL in application.conf?

The documentation reads that there is a merging, and which file wins, given a specific set of filenames, only. It does not elaborate on includes.

I think there is a documentation update that could be made, to clear it up...

And I am happy to propose some text and create a pull request, too.

But... I don't know the facts to actually write about...

(with no regard to grammar / style guides etc...)

Given;

application.conf includes these 2 lines only.


include "1.conf"
include "2.conf"


If there are any duplicate settings / paths.....
* 2.conf will always win or
* included files are always loaded in order they appear (so 1 is loaded and then 2) and...
* the last added duplicate path / setting is always the setting used.

Again for my use-case - it doesn't matter - I have altered what  / how I was doing configuration, so that I specifically only have "positive" changes within application.conf (without duplicates).

As always, thanks for your h

[Alan Burlison]

On 06/01/2017 10:15, Konrad Malawski wrote:

> You may also want to track our blog, as we're publishing things about
> Artery internals there:
> http://blog.akka.io/artery/2016/12/02/streams-in-artery
> http://blog.akka.io/artery/2016/12/05/aeron-in-artery

I notice you are using Aeron as part of the implementation. Will that be
mandatory, or optional? In my experience (Hadoop, Spark),
platform-dependent binary dependencies such as Aeron are problematic for
platforms other that Linux/x86 because multiple, often difficult to fix
endian and alignment issues.

It appears the main focus of Aeron is performance. There are other cases
where the focus is on cross-platform rather than performance, a
pure-Java is going to be preferable in those cases.

--
Alan Burlison
--

[Patrik Nordwall]

The Netty TCP based remoting is still supported, and is the default until Arterty has been battle tested. We will eventually phase out the old implementation, and we'll see if we need an alternative to Aeron.

In what environment have you seen that Aeron does not work? It works on Windows. It's Java, no native.

/Patrik

--
>>>>>>>>>>      Read the docs: http://akka.io/docs/
>>>>>>>>>>      Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>>      Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to 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.

[Alan Burlison]

On 07/01/2017 12:54, Patrik Nordwall wrote:

> In what environment have you seen that Aeron does not work? It works on
> Windows. It's Java, no native.

I haven't used Aeron myself, it was a general observation about
JNI-based packages on non-x86 architectures, e.g. SPARC.

What made me think that Aeron had a JNI dependency was the mention of
C++ and CMake. If that's just an optional requirement, great :-)

--
Alan Burlison
--

[Patrik Nordwall]

That is for the c++ client as far as I know, and that is not used by Akka.

[Alan Burlison]

On 07/01/2017 16:31, Patrik Nordwall wrote:

> That is for the c++ client as far as I know, and that is not used by Akka.

Ah, good to hear, thank you for the clarification :-)

--
Alan Burlison
--