Why AKKA Microkernel

[Peter Wolf]

Hello, 

In keeping with the "What are the advantages of XXX" theme...  What does the Microkernel add?

How is using the Microkernel different from just running "java class"?

I am searching for a way to deploy across a large number of Amazon machines.  These machines will be dynamically created/destroyed as I need more bandwidth.  Is Microkernel the correct tool for this problem?  If not, what should I be reading about?

Thanks

Peter

[√iktor Ҡlang]

Hi Peter,

On Wed, Jan 22, 2014 at 1:38 AM, Peter Wolf <opu...@gmail.com> wrote:

Hello, 

In keeping with the "What are the advantages of XXX" theme...  

Advantage is a comparison. What are you comparing with?

 

What does the Microkernel add?

http://doc.akka.io/docs/akka/2.2.3/scala/microkernel.html

 

How is using the Microkernel different from just running "java class"?

Everything on the JVM is "just running "java class"" - it's the only way to start a Java program.

 

I am searching for a way to deploy across a large number of Amazon machines.  These machines will be dynamically created/destroyed as I need more bandwidth.  Is Microkernel the correct tool for this problem?  If not, what should I be reading about?

You can definitely do this.

 

Thanks

Peter

--
>>>>>>>>>> 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+...@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/groups/opt_out.

--

Cheers,

√

———————

Viktor Klang

Chief Architect - Typesafe

Twitter: @viktorklang

[Michael Pavlovsky]

IMO, Microkernel was a really _BAD_ idea.

I have a very long list of items that i hate about it but instead of bitching I would really like to hear from Victor Klang what was the primary set of use-cases that this component was supposed to implement. Only then, one could judge its pros and cons.

Dear Victor, please shad some light ... 

P.s: when i complain i usually have the following set of aspects in my mind: deployment, monitoring, side by side provisioning , componentisation, versioning, Standard class loading, multi node clustering support , configuration loading, osgi

[Peter Wolf]

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 <classpath> <class>".  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

[Oleg Zhurakousky]

Well, my name may not be Victor, but let me give it a shot ;), since I actually had to work on similar thing on the unrelated product.

Akka is a framework and a programming model. This means it could be used as part of any of your existing application (Web, Console etc.) or your new application could itself be Akka-based from the get go.

Now, if I am including Akka as part of my WAR, then I would most definitely include akka/scala and related JARs in the WAR's classpath (e.g., lib directory). Its simple and straight forward since WAR deployment/runtime model and backing application server does the rest (e.g., creates app class loader, loads classes as needed, starts the app etc.) as long as you follow the conventions the underlying model dictates. 

But what about stand alone? Suddenly all of these concerns that the developer didn't have to worry about by relying on some standard development/deployment/runtime model are back to be the concerns of such developer. Sure we are all (or some of us) smart and bright enough to take care of it . . . create our own launcher, make it classpath-aware, possibly even creating a dedicated classloader to support multiple and isolated deployments within the single JVM. It's certainly not the most difficult task, but why? Why do I need to worry about it every time I have a standalone app requirement? The concerns would most likely be the same and having framework to address them is not such a bad idea. In fact its not even original. Lots of frameworks have this.

Having said that, I'll attempt to guess that your disappointment with Akka's Microkernel has more to do with it laking certain features that you want/need. Again, just a guess, but if so, then may be the real question should be more related to discussing such missing features or patches to the existing features.

Cheers

Oleg

--

[√iktor Ҡlang]

Hi Michael,

On Wed, Jan 22, 2014 at 6:55 PM, Michael Pavlovsky <michael....@gmail.com> wrote:

IMO, Microkernel was a really _BAD_ idea.

Really sorry to hear that :(

 

I have a very long list of items that i hate about it but instead of bitching I would really like to hear from Victor Klang what was the primary set of use-cases that this component was supposed to implement. Only then, one could judge its pros and cons.

The primary use-case was to create a bundle so one can easily package an Akka Application and deploy/run it somewhere else (without having to write launcher scripts or installing some kind of App Server).

 

Dear Victor, please shad some light ... 

P.s: when i complain i usually have the following set of aspects in my mind: deployment, monitoring, side by side provisioning , componentisation, versioning, Standard class loading, multi node clustering support , configuration loading, osgi

So in your list, the Microkernel meant to address: Deployment

We'd love to hear more about the issues you had with the Microkernel and what kind of features would be helpful to you.

Cheers,

√

 

On Tuesday, January 21, 2014 7:38:10 PM UTC-5, Peter Wolf wrote:

Hello, 

In keeping with the "What are the advantages of XXX" theme...  What does the Microkernel add?

How is using the Microkernel different from just running "java class"?

I am searching for a way to deploy across a large number of Amazon machines.  These machines will be dynamically created/destroyed as I need more bandwidth.  Is Microkernel the correct tool for this problem?  If not, what should I be reading about?

Thanks

Peter

--

>>>>>>>>>> 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+...@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/groups/opt_out.

[√iktor Ҡlang]

Exactly!

 

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+...@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/groups/opt_out.

[Michael]

1st. Viktor i am sorry for misspelling your name. 

Oleg, as i said, I have a long list of issues. Since I am going to use akka in production  I also have a set of solutions for my specific requirements.

My point is beyond simple one-time deployed desktop application. For this and for development I have large amount of workarounds.

The context of the original question was amazon based cluster deployment. It means it is not a game like deployment, you need to have a lot of additional things to call it a product that you can deploy to the cloud for real and provide services.

Each piece of code has its price - both development and maintenance. I don't see how Microkernel as something that is aligned to the goals that AKKA team trying to achieve. Maybe if I knew the architect's POV on this component i would 'feel' better. :)

I repeat, I don't want to add any feature to MK and I am not asking for features. It just seems wrong to me , that akka team maintain it. It reminds me xml support in scala. One more unfocused effort in controversial feature. 

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/HJiZIex_6v8/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/groups/opt_out.

--

Michael Pavlovsky

[√iktor Ҡlang]

On Wed, Jan 22, 2014 at 8:27 PM, Michael <michael....@gmail.com> wrote:

1st. Viktor i am sorry for misspelling your name. 

All is forgiven.

 

Oleg, as i said, I have a long list of issues. Since I am going to use akka in production  I also have a set of solutions for my specific requirements.

My point is beyond simple one-time deployed desktop application. For this and for development I have large amount of workarounds.

The context of the original question was amazon based cluster deployment. It means it is not a game like deployment, you need to have a lot of additional things to call it a product that you can deploy to the cloud for real and provide services.

Each piece of code has its price - both development and maintenance. I don't see how Microkernel as something that is aligned to the goals that AKKA team trying to achieve. Maybe if I knew the architect's POV on this component i would 'feel' better. :)

How'd you mean that it is not aligned?

 

I repeat, I don't want to add any feature to MK and I am not asking for features. It just seems wrong to me , that akka team maintain it. It reminds me xml support in scala. One more unfocused effort in controversial feature. 

I'd still like to know what things you require for your use-case?

Cheers,

√

--

[Adam]

You might want to look at 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 to run it as a service since at work I need to use Windows servers :(

~Adam~

--

[Michael]

Viktor, I think that Adam post demonstrates my point very well.

sbt-native-packager

deploy

osgi-bundle 

web-deployer 

sbt multi jvm , 

multi-node atmos

and the list is going on and on. They all trying to resolve the problem of deployment. Obviously they see the problem from different angles.

Deployment means a lot of things. And java community tries to standardize it so you could deploy the same logical bundle to tomcat/felix/ or run it as a server on windows / linux. After that you need to update your application which is also not an easy task. Multiply it by amount of nodes, multiple IP addresses / port allocation based on environment , etc. ... I want to see how long does it take to someone to deploy akka application with spray into equinox... After you deployed dozens of nodes you need to gather metrics  & monitor and restart it if it failed. Sometimes you need to restart your application due to disconnected akka nodes in the cluster (see mailing list topic on this issue). Also add to the picture deployment as a service on different Linuxes with different service startup mechanisms (ubuntu vs centos). MK init script must be rewritten anyway. MK class loader is a topic of discussion per se.

So my point is - akka needs to be packaged more friendlier to environment in which it runs (i.e. osgi)  and instead of augmenting MK it should adopt itself to the outside world. For instance run my war/wab  file so i can package once and run it everywhere. Without deploy folder / hardcoded '*.jar' extension / plainly loading all embedded jars / not respecting class path specifications of manifest etc...

If you want i can create a clean itemized list of issue but again, my point is that it might not be required.

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/HJiZIex_6v8/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/groups/opt_out.

--

Michael Pavlovsky

[√iktor Ҡlang]

Michael,

On Wed, Jan 22, 2014 at 9:38 PM, Michael <michael....@gmail.com> wrote:

Viktor, I think that Adam post demonstrates my point very well.

sbt-native-packager

deploy

osgi-bundle 

web-deployer 

sbt multi jvm , 

multi-node atmos

and the list is going on and on. They all trying to resolve the problem of deployment. Obviously they see the problem from different angles.

Deployment means a lot of things. And java community tries to standardize it so you could deploy the same logical bundle to tomcat/felix/ or run it as a server on windows / linux. After that you need to update your application which is also not an easy task.

Live upgrades is a pipe dream IMO.

 

Multiply it by amount of nodes, multiple IP addresses / port allocation based on environment , etc. ... I want to see how long does it take to someone to deploy akka application with spray into equinox... 

After you deployed dozens of nodes you need to gather metrics  & monitor and restart it if it failed. Sometimes you need to restart your application due to disconnected akka nodes in the cluster (see mailing list topic on this issue). Also add to the picture deployment as a service on different Linuxes with different service startup mechanisms (ubuntu vs centos). MK init script must be rewritten anyway. MK class loader is a topic of discussion per se.

So my point is - akka needs to be packaged more friendlier to environment in which it runs (i.e. osgi)  and instead of augmenting MK it should adopt itself to the outside world. For instance run my war/wab  file so i can package once and run it everywhere. Without deploy folder / hardcoded '*.jar' extension / plainly loading all embedded jars / not respecting class path specifications of manifest etc...

I agree with all your assessments of creating friendlier packaging except OSGi—to me it's a failed experiment.

 

If you want i can create a clean itemized list of issue but again, my point is that it might not be required.

I guess I still don't understand the major issue with the MK, it does exactly what it sets out to do. It's a very lightweight packaging of an Akka application in a distributable archive.

--

[Michael]

On Wed, Jan 22, 2014 at 4:14 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

I guess I still don't understand the major issue with the MK, it does exactly what it sets out to do. It's a very lightweight packaging of an Akka application in a distributable archive.

1. I think that it boils down to the next question: Should MK be part of AKKA or should it be part of some SBT plugin?

2. I will create an itemized list of what i consider as a bug/issue in ~ 2 classes of MK package. 

I used osgi as an example since it was an extremely painful experience. 

Thank you for a prompt response 

--

Michael Pavlovsky

[√iktor Ҡlang]

On Jan 22, 2014 11:07 PM, "Michael" <michael....@gmail.com> wrote:
>
>
> On Wed, Jan 22, 2014 at 4:14 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
>>
>> I guess I still don't understand the major issue with the MK, it does exactly what it sets out to do. It's a very lightweight packaging of an Akka application in a distributable archive.
>
>
> 1. I think that it boils down to the next question: Should MK be part of AKKA or should it be part of some SBT plugin?

That is a fair question

> 2. I will create an itemized list of what i consider as a bug/issue in ~ 2 classes of MK package. 
>

Great!

> I used osgi as an example since it was an extremely painful experience. 

Most people's experience with OSGi is painful-at least from what I've heard.

Cheers,
V

>
> Thank you for a prompt response 
>
> --
>
> Michael Pavlovsky
>