I agree, but I would like to add that as described in the migration guide
the old 2.2.x akka dist plugin can be used to package akka 2.3.x
applications.
/Patrik
On Sun, Aug 17, 2014 at 9:20 PM, Konrad Malawski kt...@typesafe.com wrote:
Sure, agreed – feel free to add this requirement to the
On Fri, Aug 15, 2014 at 5:50 PM, Prakhyat Mallikarjun prakhyat...@gmail.com
wrote:
Hi patrik,
Glad you understood my point.
Thanks for your suggestions and point of view. It will help me.
If old stock of events are removed it will save lot of disk space.
But I am curious,
How taking
Looks like something similar was answered in this thread:
https://groups.google.com/d/msg/akka-user/6hyDUn4RHOE/6UFsM-Gm4VwJ
/Patrik
On Sun, Aug 17, 2014 at 7:20 AM, Shawn j...@shawntalbert.com wrote:
Patrik, would you kindly elaborate on why akka-sbt-plugin was retired?
sbt-native-packager
On Mon, Aug 18, 2014 at 1:04 AM, Glenn Grant gl...@welcomer.me wrote:
Thanks for the pointers Patrik. Already read through most of them before,
but the distributed pub/sub one was new to me :)
I'm thinking as always there isn't necessarily going to be an 'easy
solution', just read the docs
Hi Roland,
A few more questions for clarification...
On Sat, Aug 16, 2014 at 10:11 PM, Vaughn Vernon vver...@shiftmethod.com
wrote:
Hi Roland,
Welcome back to the discussions :)
I think you stated most of this very thoroughly. There are probably a few
points lost in translation between
Hi Shawn,
the migration guide talks about this briefly, in short the akka-sbt-plugin from
2.2.x works just fine for other versions including 2.3.x, but you are right
that we’ll have to expand on deployment documentation. We have planned to work
on this later this year, if someone beats us to
Glad you found it, and thanks for sharing the solution for later archeologists!
Regards,
Roland
17 aug 2014 kl. 17:38 skrev Gaurav Sharma gsharm...@gmail.com:
Fixed the problem -
The solution to my problem was in this link that I stumbled upon -
Hi Shawn,
one consideration is that Akka (as a toolkit) does not really need all that
much special handling. The simplest way is to use akka.Main as the main class
and tell native packager to call that with the class name of your application
supervisor actor and you’re all set (see here for an
Hi,
The registerService call right now only uses DistributedPubSubMediator.Put.
There is no difference at all at the moment. There might be in the future
though.
B/
On 18 August 2014 at 07:10:31, JasonQ (quqingm...@gmail.com) wrote:
Hello,
Per my understanding after going through AKKA
Hi,
I'm not exactly sure what you are trying to achieve, but you need to use
classes and not instances. See inline comments.
B/
On 16 August 2014 at 08:24:43, workingdog (ringowathe...@gmail.com) wrote:
import akka.actor.{Actor, ActorRef, ActorSystem, Props}
case class Register(handler:
18 aug 2014 kl. 10:27 skrev Patrik Nordwall patrik.nordw...@gmail.com:
Hi Roland,
A few more questions for clarification...
On Sat, Aug 16, 2014 at 10:11 PM, Vaughn Vernon vver...@shiftmethod.com
wrote:
Hi Roland,
Welcome back to the discussions :)
I think you stated most of
When I send 300, 000 message from one actor to another (all local), more
than 90% time of first the source actor is spent in
Dispatcher.registerForExecution(), inside it, there is
executorService.execute(mbox)
The Mailbox.run will first try to process pending messages, when there is
no pending
300.000 messages sounds like you have a configuration issue.
See this benchmark: https://github.com/plokhotnyuk/actors
On Mon, Aug 18, 2014 at 4:21 PM, Sean Zhong clock...@gmail.com wrote:
When I send 300, 000 message from one actor to another (all local), more
than 90% time of first the
Revise the typo.
When I send 300, 000 message from one actor to another (all local actors),
more than 90% time of the source actor is spent in
Dispatcher.registerForExecution(), inside it, there is call
executorService.execute(mbox)
The Mailbox.run() logic looks like this: It will first try
On Mon, Aug 18, 2014 at 3:38 PM, Roland Kuhn goo...@rkuhn.info wrote:
18 aug 2014 kl. 10:27 skrev Patrik Nordwall patrik.nordw...@gmail.com:
Hi Roland,
A few more questions for clarification...
On Sat, Aug 16, 2014 at 10:11 PM, Vaughn Vernon vver...@shiftmethod.com
wrote:
Hi Roland,
registerForExecution has to be called for every message.
See the link I sent for both benchmark numbers and configuration for
throughput.
On Mon, Aug 18, 2014 at 4:25 PM, Sean Zhong clock...@gmail.com wrote:
Revise the typo.
When I send 300, 000 message from one actor to another (all local
I think there is a difference.
The benchmark you showed have no flow control. the receiver actor mailbox
will always have message. So, Mailbox.run() will only resubmit itself when
throughput is met(1024 in the test case).
So, take the throughput number from the benchmark 8,189,290 ops/s,
On Mon, Aug 18, 2014 at 5:12 PM, Sean Zhong clock...@gmail.com wrote:
I think there is a difference.
The benchmark you showed have no flow control. the receiver actor mailbox
will always have message. So, Mailbox.run() will only resubmit itself when
throughput is met(1024 in the test case).
Now we often mention causal ordering as something that would be a great
goal for a distributed system, sometime in the future, but never seem to
talk about achieving it. To that end I would like to naively suggest a way
that it may possibly be implemented.
The implementation is to simply
Hi Roland (and everyone),
Welcome back Roland - I hope you had a great vacation.
Thank you for your post.
Here’s my response summary:
I believe Akka needs to allow actors to:
(i) persist events with as much information as efficiently possible on the
write side to allow the store to
Sorry about that formatting, something happened (with the EOLs) when I
pasted from a text editor.
--
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
Java apps work fine under Raspberry Pi.
I had Akka running, remoting, joining cluster etc. without problem.
On Mon, Aug 18, 2014 at 10:44 AM, Tristan Slominski
tristan.slomin...@gmail.com wrote:
I think there seems to be an implicit assumption that actors = akka. It
seems to me the
Hi,
I guess that a downside of 3 is that it makes it less suitable to use in
ClusterSharding (in ClusterSharding you cannot pass instance specific props to
an actor).
So my preference (especially with domain actors) is to create the actor and
initialize it with a command. All domain
thanks *Björn,*
*exactly what I was looking for.*
On Saturday, 16 August 2014 16:24:40 UTC+10, workingdog wrote:
With Akka I would like to do something like this:
class MyTestClass ... {
def register[A : Handler](handler: A) = channel !
I'm keen to hear other people's thoughts on the choice of an event store
for Akka Persistence for doing CQRS.
As mentioned in my other post, I believe that Akka Persistence only
provides part of the story for CQRS (but a very important part) and that
other stores will most likely be needed
Right, so going with the actors = akka assumption then :)
On Monday, August 18, 2014 1:58:59 PM UTC-5, Dragisa Krsmanovic wrote:
Java apps work fine under Raspberry Pi.
I had Akka running, remoting, joining cluster etc. without problem.
On Mon, Aug 18, 2014 at 10:44 AM, Tristan Slominski
Thanks Björn.
So if I have an Actor which need receive message from both a Mediator and a
ClusterClient, should I call both put and registerService in case there's
some change in the future or only call registerService is enough?
On Monday, August 18, 2014 8:16:44 PM UTC+8, Björn Antonsson
I developed a Play webapp using Akka actors by mixing Java and Scala
classes. It runs on Raspberry Pi without problems.
Best regards,
giovanni
On Tue, Aug 19, 2014 at 2:57 AM, Dragisa Krsmanovic dragis...@gmail.com
wrote:
Java apps work fine under Raspberry Pi.
I had Akka running, remoting,
28 matches
Mail list logo
