[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
From what I can see, its not just about concurrency, right? STM is probally used in conjunction with Cassandra...? Cheers, Tim On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote: I wonder why STM in a message passing concurrency model where things supposed to be immutable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
Hi. On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote: From what I can see, its not just about concurrency, right? STM is probally used in conjunction with Cassandra...? Right. Even though messages in the actor model are immutable the actors are not. If they were they would be almost useless. The actor model is great for some use cases but terrible for others. I have many times felt like I would like to have a transactional compositional message flows. This is an attempt to solve that problem (and some other problems as well). The STM is working with managed data structures like TransactionalMap/ Vector/Ref. Accessing them outside a tx yields an error. The STM also understand and works with asynchronous messaging something that is not trivial. I think there is some synergy between both Lift and Goat Rodeo. Would love to see what could come out of that. I am open for all suggestions/ crazy ideas. Thank, Jonas. Cheers, Tim On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote: I wonder why STM in a message passing concurrency model where things supposed to be immutable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
Instead of:
class MyActor extends Actor {
makeTransactionRequired …
}
woudn't it be clean to have:
trait TxRequired
{
self : TransactionManagement =
makeTransactionRequired
}
class MyActor extends Actor with TxRequired
{
}
On Mon, Jul 13, 2009 at 11:04 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi.
On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote:
From what I can see, its not just about concurrency, right? STM is
probally
used in conjunction with Cassandra...?
Right. Even though messages in the actor model are immutable the
actors are not. If they were they would be almost useless.
The actor model is great for some use cases but terrible for others. I
have many times felt like I would like to have a transactional
compositional message flows. This is an attempt to solve that problem
(and some other problems as well).
The STM is working with managed data structures like TransactionalMap/
Vector/Ref. Accessing them outside a tx yields an error. The STM also
understand and works with asynchronous messaging something that is not
trivial.
I think there is some synergy between both Lift and Goat Rodeo. Would
love to see what could come out of that. I am open for all suggestions/
crazy ideas.
Thank, Jonas.
Cheers, Tim
On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote:
I wonder why STM in a message passing concurrency model where things
supposed to be immutable.
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
By the way, installing AKKA requires currently some hand-waving to add
dependencies that are not resolved:
com.facebook.fb303-1.0.jar
org.apache.cassandra:cassandra:jar:0.4.0-dev
Or is my Maven just b0rked?
On Mon, Jul 13, 2009 at 11:15 AM, Viktor Klang viktor.kl...@gmail.comwrote:
Instead of:
class MyActor extends Actor {
makeTransactionRequired …
}
woudn't it be clean to have:
trait TxRequired
{
self : TransactionManagement =
makeTransactionRequired
}
class MyActor extends Actor with TxRequired
{
}
On Mon, Jul 13, 2009 at 11:04 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi.
On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote:
From what I can see, its not just about concurrency, right? STM is
probally
used in conjunction with Cassandra...?
Right. Even though messages in the actor model are immutable the
actors are not. If they were they would be almost useless.
The actor model is great for some use cases but terrible for others. I
have many times felt like I would like to have a transactional
compositional message flows. This is an attempt to solve that problem
(and some other problems as well).
The STM is working with managed data structures like TransactionalMap/
Vector/Ref. Accessing them outside a tx yields an error. The STM also
understand and works with asynchronous messaging something that is not
trivial.
I think there is some synergy between both Lift and Goat Rodeo. Would
love to see what could come out of that. I am open for all suggestions/
crazy ideas.
Thank, Jonas.
Cheers, Tim
On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote:
I wonder why STM in a message passing concurrency model where things
supposed to be immutable.
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
All jars are in the ./lib dir. Running the kernel from ./bin dir works
out of the box. Put apps in the ./deploy dir.
If you want I build it using maven you have install some missing libs
that are not in any public maven repo (and all these jars are in
lib). .
Easiest way is simply to download the distro from the downloads
section.
Hope it helps.
/Jonas
On Jul 13, 12:43 pm, Viktor Klang viktor.kl...@gmail.com wrote:
By the way, installing AKKA requires currently some hand-waving to add
dependencies that are not resolved:
com.facebook.fb303-1.0.jar
org.apache.cassandra:cassandra:jar:0.4.0-dev
Or is my Maven just b0rked?
On Mon, Jul 13, 2009 at 11:15 AM, Viktor Klang viktor.kl...@gmail.comwrote:
Instead of:
class MyActor extends Actor {
makeTransactionRequired …
}
woudn't it be clean to have:
trait TxRequired
{
self : TransactionManagement =
makeTransactionRequired
}
class MyActor extends Actor with TxRequired
{
}
On Mon, Jul 13, 2009 at 11:04 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi.
On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote:
From what I can see, its not just about concurrency, right? STM is
probally
used in conjunction with Cassandra...?
Right. Even though messages in the actor model are immutable the
actors are not. If they were they would be almost useless.
The actor model is great for some use cases but terrible for others. I
have many times felt like I would like to have a transactional
compositional message flows. This is an attempt to solve that problem
(and some other problems as well).
The STM is working with managed data structures like TransactionalMap/
Vector/Ref. Accessing them outside a tx yields an error. The STM also
understand and works with asynchronous messaging something that is not
trivial.
I think there is some synergy between both Lift and Goat Rodeo. Would
love to see what could come out of that. I am open for all suggestions/
crazy ideas.
Thank, Jonas.
Cheers, Tim
On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote:
I wonder why STM in a message passing concurrency model where things
supposed to be immutable.
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
Thanks. Good idea. I'll add this option.
On Jul 13, 11:15 am, Viktor Klang viktor.kl...@gmail.com wrote:
Instead of:
class MyActor extends Actor {
makeTransactionRequired …
}
woudn't it be clean to have:
trait TxRequired
{
self : TransactionManagement =
makeTransactionRequired
}
class MyActor extends Actor with TxRequired
{
}
On Mon, Jul 13, 2009 at 11:04 AM, Jonas Bonér jbo...@gmail.com wrote:
Hi.
On Jul 13, 9:51 am, Timothy Perrett timo...@getintheloop.eu wrote:
From what I can see, its not just about concurrency, right? STM is
probally
used in conjunction with Cassandra...?
Right. Even though messages in the actor model are immutable the
actors are not. If they were they would be almost useless.
The actor model is great for some use cases but terrible for others. I
have many times felt like I would like to have a transactional
compositional message flows. This is an attempt to solve that problem
(and some other problems as well).
The STM is working with managed data structures like TransactionalMap/
Vector/Ref. Accessing them outside a tx yields an error. The STM also
understand and works with asynchronous messaging something that is not
trivial.
I think there is some synergy between both Lift and Goat Rodeo. Would
love to see what could come out of that. I am open for all suggestions/
crazy ideas.
Thank, Jonas.
Cheers, Tim
On 13/07/2009 07:25, marius d. marius.dan...@gmail.com wrote:
I wonder why STM in a message passing concurrency model where things
supposed to be immutable.
--
Viktor Klang
Java Specialist
Scala Loudmouth
Lift Committer
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: ANN: Akka Actor Kernel: RESTful Distributed Persistent Transactional Actors
Jonas, How do you see Akka integrating with Lift and/or GoatRodeo? On first impression there seem to be a few overlaps that could fit together nicely. Or maybe a bit of code sharing. Tyler On Jul 12, 6:58 pm, Jonas Bonér jbo...@gmail.com wrote: Hi guys. I just released the first iteration of the Akka Actor Kernel (or whatever it is). It is still early days and there is a lot still to do. I would be grateful for any kind of feedback, both on the code as well as the APIs, semantics or vision. Here is a short overview of what it currently does: * The Actor model and supervisor hierarchies Actors with Erlang OTP-style supervisors and “embrace failure/let-it-crash” semantics to allow implementation of asynchronous, non-blocking and highly fault-tolerant systems. Sort of SEDA in a box with highly configurable and monitorable (JMX and w3c) thread pools and message queues. * Software Transactional Memory (STM) Software Transactional Memory for composable message flows. Distributed transactions will come very soon, backed up by ZooKeeper. The STM works with both persistent datastructures and in-memory datastructures (see below). * BASE: Eventually Consistent Distributed persistence Akka provides a Eventually Consistent Transactional Persistent Map, Vector and Ref. Backed up by the Cassandra highly scalable, eventually consistent, distributed, structured key-value store. Akka will add support for Terracotta, Redis, Memcached, Voldemort, Tokyo Cabinet/Tyrant and Hazelcast shortly. New nodes can be added and removed on the fly to support true scaling of cluster. The addition of Terracotta and Hazelcast will allow for atomic (ACID) transactions (non-BASE). * REST Actors can be exposed as REST services through JAX-RS. * Remoting Actors can be defined and started on remote nodes, supporting both remote failures and supervision/linking. Enabling another dimension of fault-tolerance. * Java and Scala API Both a Java API through Active Objects and annotations as well as a Scala API with Erlang-style Actors with pattern matching etc. * Microkernel Akka has a microkernel that embeds the Actor management, Persistence service, REST integration, JMX management and Remote service. Simply drop your application in the /deploy directory and start up the kernel and you should be able to access your Actors through REST. Start with reading the docs and play with the samples. Docs:https://github.com/jboner/akka/wikis/ Downloads:https://github.com/jboner/akka/downloads Code:https://github.com/jboner/akka/tree/master Some of the stuff we are planning on adding are listed at the bottom of the docs page. Thanks. -- Jonas Bonér twitter: @jboner blog: http://jonasboner.com work: http://crisp.se work: http://scalablesolutions.se code: http://github.com/jboner --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
