So why not just run Akka outside of an Application Server and configure the thread pools in Akka?
On Fri, Jan 31, 2014 at 3:21 PM, Tin Tvrtković <[email protected]> wrote: > 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. ;) > > > On Thursday, January 30, 2014 11:25:04 PM UTC+1, √ wrote: > >> Why do you prefer to use those thread pools? >> >> >> On Thu, Jan 30, 2014 at 11:06 PM, Tin Tvrtković <[email protected]>wrote: >> >>> 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! >>> >>> -- >>> >>>>>>>>>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
