Running an Actor System inside a JEE 7 application server

[Tin Tvrtković]

Hello,

I'm contemplating whether running Akka inside of a JBoss/Wildfly 8 instance is a good idea. First of all, I'm kind of an Akka newbie so don't hesitate to correct me if any of my assumptions are incorrect.

I'm not really interested in using JCA; I'd much prefer using the new JSR 236 managed thread pools. Assuming I've configured my AS to provide me with an adequate executor service, is there a way to spawn an actor system it? Looking at the development Java API, there's an ActorSystem$ create method taking an execution context, which can be created from an executor service. Exactly what kind of thread pool does an actor system expect (bounded, unbounded...)?

Would this be a good way of embedding Akka? Am I missing something (like a detail that would render this whole exercize futile)? Is there a better/canonical way of doing something like this?

Thanks in advance, girls and guys!

[√iktor Ҡlang]

Why do you prefer to use those thread pools?

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

[Tin Tvrtković]

I guess the answer depends on what you would consider an alternative.

If you're wondering why I don't just let Akka manage its own threads: this is considered bad practice within an application server. There are also some corner cases which I don't feel like investigating now (and worrying about later, potentially).

If you're asking why I don't use JCA: I find it less flexible than JSR 236, it complicates the packaging (RARs and a ton of obscure XML, ugh...) and again I'd need to make Akka use an existing thread pool.

In other words, the reasons why JSR 236 was added in the first place. ;)

[√iktor Ҡlang]

So why not just run Akka outside of an Application Server and configure the thread pools in Akka?

[Tin Tvrtković]

I'm aware there are others, proper ways of running Akka. :)

Just embedding it like this would make it a much easier sell to the powers that be at the company.

[√iktor Ҡlang]

On Fri, Jan 31, 2014 at 6:28 PM, Tin Tvrtković <tinch...@gmail.com> wrote:

I'm aware there are others, proper ways of running Akka. :)

Just embedding it like this would make it a much easier sell to the powers that be at the company.

Well, I'd first start with the suggestion from me, and if that for some reason doesn't work, then you'll just have to create an ExecutionServiceConfigurator that uses your container to look up its thread pool.

[Patrik Nordwall]

On Fri, Jan 31, 2014 at 6:56 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Fri, Jan 31, 2014 at 6:28 PM, Tin Tvrtković <tinch...@gmail.com> wrote:

I'm aware there are others, proper ways of running Akka. :)

Just embedding it like this would make it a much easier sell to the powers that be at the company.

Well, I'd first start with the suggestion from me, and if that for some reason doesn't work, then you'll just have to create an ExecutionServiceConfigurator that uses your container to look up its thread pool.

Passing in the ExecutionContext to the ActorSystem (2.3.0-RC1) would also be a possibility, unless I have missed something.

/Patrik

--

Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

[√iktor Ҡlang]

On Fri, Jan 31, 2014 at 7:02 PM, Patrik Nordwall <patrik....@gmail.com> wrote:

On Fri, Jan 31, 2014 at 6:56 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Fri, Jan 31, 2014 at 6:28 PM, Tin Tvrtković <tinch...@gmail.com> wrote:

I'm aware there are others, proper ways of running Akka. :)

Just embedding it like this would make it a much easier sell to the powers that be at the company.

Well, I'd first start with the suggestion from me, and if that for some reason doesn't work, then you'll just have to create an ExecutionServiceConfigurator that uses your container to look up its thread pool.

Passing in the ExecutionContext to the ActorSystem (2.3.0-RC1) would also be a possibility, unless I have missed something.

Absolutely, very good point Patrik!

[√iktor Ҡlang]

Looks like Dario's feature was well-timed! :)

[Tin Tvrtković]

That sounds great and will be easy. So if I pass in an ExecutionContext, Akka will use only it for threads?

Does Akka care exactly what kind of thread pool is it (unbounded, fixed size...) or is it strictly application dependent?

Thanks, guys!

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/gbtC8Foo5zo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to akka-user+...@googlegroups.com.

[√iktor Ҡlang]

On Jan 31, 2014 7:58 PM, "Tin Tvrtković" <tinch...@gmail.com> wrote:
>
> That sounds great and will be easy. So if I pass in an ExecutionContext, Akka will use only it for threads?

If you want to make sure Akka doesn't create any threads then you'll have to create your own Scheduler too (the default creates its own thread)

Not sure if Akka IO can be made not to create any threads-you'll have to check.

I still recommend to ditch the AS.

Cheers,
V

[Oleg Zhurakousky]

FWIW, I do prefer the "ditch the AS" approach as well. The world did change quite a bit and IMHO the entire JEE model is flawed, but I don't wan to wake up the trolls ;), so I would suggest to actually look at the reasons (aside form Akka/Scala and everything else) as to why do you think you need AS in the first place and see if you can come up with at least one for which there would not be a simpler/lighter approach. 

Having said that and going back to your original question about ". . . good way of embedding Akka?", I am not sure if you aware of the JBoss modules. The concept existed in JBoss since v.3 and essentially enables you to deploy pretty much anything as an independent execution environment - including Akka system(s). 

[Tin Tvrtković]

First of all, thanks for all the input to everyone.

To everyone suggesting ditching the AS: you're preaching to the choir here, which is why I was trying to use Akka in the first place. Unfortunately, migrating from JBoss and the EE stack in general is unlikely to happen, at least on the project/product I'm working on.

I only have a perfunctory understanding of JBoss modules; we mostly use them to deploy system-wide libraries so all deployments can have them on the class path. I'll be sure to Google around based on your tip.

[√iktor Ҡlang]

Happy hAkking

Looking forward to hearing more on this journey of yours!

[Justin du coeur]

On Fri, Jan 31, 2014 at 5:49 PM, Tin Tvrtković <tinch...@gmail.com> wrote:

To everyone suggesting ditching the AS: you're preaching to the choir here, which is why I was trying to use Akka in the first place. Unfortunately, migrating from JBoss and the EE stack in general is unlikely to happen, at least on the project/product I'm working on.

The team ought to keep in mind that this probably isn't going to be a terribly unusual requirement, especially as Akka starts getting noticed more by larger and older (and more staid) companies.  The politics are often such that you either use the officially-sanctioned AS or you are simply out of luck.  Having spent some time trying to get third-party products integrated at banks, it can be a *major* headache, but it is what it is -- strong technical arguments, sadly, rarely win against entrenched IT bureaucracy...

[bryan hunt]

An impassioned 'cri du coeur' !

[Roland Kuhn]

Hi Justin,

Yes, you are right. But please forgive us for continuing the push towards using  less containers :-) At the same time 2.3.0 makes it easier to reuse a managed thread pool by passing it into the actor system.

Regards,

Roland

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

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
twitter: @rolandkuhn

[Rick Latrine]

Hi,

we are running JBoss apps for many years now (> 10 y) - don't ask me why.

But since Akka Version 2.0.x we have integrated actors to get rid of the static thread pools in that AS.

We need to adjust the pools at runtime and sometimes dynamically - without JMX.

But don't be surprised when you see that akka is dynamically adapting the number of threads according to number of cores.

I have never seen too many threads at all. Only JBoss is spawning senseless number of threads for each incoming request (but they will get it some day - undertow has learned something yet).

Finally when I see spray.io with web-sockets integrated into akka, I will push my company forward to abandon JEE at all.

Cheers

Rick