Thanks! yes very helpful. So for non persistent actors that used persistent
channels, they just now extend Redelivery?
On Friday, June 20, 2014 2:24:20 PM UTC-7, Konrad Malawski wrote:
>
> Hello Scott,
> As I've briefly hinted during the ScalaDays presentation (and of course
> all discussions ha
Hello Peter,
nope, while the new event-bus is not itself an actor, is uses an actor to
handle subscription / unsubscription / death in an asynchronous way.
It’s an interesting thought, but we have not done enough benchmarking (yet), to
know if it’s a viable option.
The primary driver for this ch
Small hint: it is very simple to have PersistentActor to behave exacly like
Processor did (if you have such an use case) - simply persist all the
incoming messages right away in the 1st line of your receive handlers.
On Fri, Jun 20, 2014 at 11:23 PM, Konrad Malawski
wrote:
> Hello Scott,
> As I
Hello Scott,
As I've briefly hinted during the ScalaDays presentation (and of course all
discussions have been public before on akka-user), the changes are (mostly,
but not limited to):
Removal:
* removal of `Processor` (Command Sourcing),
* removal of `Channel` and `PersistentChannel` because the
Can someone give/link to the cliff notes of the upcoming persistence
changes?
Is it along the lines of Processor => EventsourcedProcessor and Channel
=> Stream?
What else?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/
In order to interface with a very specific piece of software I need one actor
to be within a particular ThreadGroup. How can this be accomplished?
I could do this if I could specify the ThreadFactory that is part of Dispatcher
prerequisites, but all of this is marked final.
Can anyone comment?
Interesting. Does that mean the EventBus is an actor in 2.4.x and easier to
extend?
On Friday, 20 June 2014 17:59:09 UTC+1, Konrad Malawski wrote:
>
> Yes it does remove dead actors.
>
> In* 2.3.x* this is implemented using the now deprecated `isTerminated`
> calls on the actor refs (impl is in
Yes it does remove dead actors.
In 2.3.x this is implemented using the now deprecated `isTerminated` calls on
the actor refs (impl is in ActorClassification).
And in 2.4.x (not yet released, but the feature is implemented already) the
clean up happens via DeathWatch (so we’re able to avoid call
I've already started designing the price publisher api for an actor based
system.
One question about EventBus does it detect subscribers that have died and
remove them from the publication list?
On Friday, 20 June 2014 17:19:07 UTC+1, Konrad Malawski wrote:
>
> Hello Peter,
>
> I’m leaning tow
Hello Peter,
I’m leaning towards implementing this as Actors actually, but it’s
certainly possible to extend event-buses with what you require.
Just make sure to delegate to super first.
In your case you could reply to it right from the subscribe.
Please remember that a Bus is NOT an Actor, so yo
In your example the workers have no way to tell that all work (assigned to
them) has been done: How should they know that they will only ever receive some
100 messages?
Instead the router has to trigger closing down the workers, e.g. via sending a
PoisonPill. Or, instead of using a group router
Was going to use EventBus to publish prices to actors until I realised
actors arriving at party late don't get to see the last price and have to
wait for the next one to be published.
Are there any extensions that re-publish the last message to new
subscribers?
Alternatives
Roll my own publis
Yes it is defined in sbt. We can run the application in sbt (a wired issue
though: we can run the application using "restart" command but not "run"
command). We generated the IntelliJ project files using "gen-idea" (in sbt
shell).
On Friday, June 20, 2014 2:29:30 AM UTC-7, Akka Team wrote:
>
>
>
> val workers = Vector.fill(10)(system.actorOf(Props[Worker]))
> val router =system.actorOf(Props().withRouter(RoundRobinRouter(workers)))
>
for( i<- 1 to 1000)router ! message
'message' send to all workers(Worker Actor) to process. Now what code
should I write so that I will
Hello,
first of all I'd like to say that I'm still quite new to scala and akka,
but very motivated and impressed of what can be achieved with these :)
So - the matter is as follows - my friend and me are building a server
monitoring app with a web ui. We're aware that there are many products in
Hi Pramod,
On Fri, Jun 20, 2014 at 2:32 PM, Pramod Ransing
wrote:
> I want to terminate router only after all childs finishes their work... So
> how wud I know that all childs have finished their tasks.
>
Let's make them send notifications that they have been finished, and have a
manager that
I want to terminate router only after all childs finishes their work... So
how wud I know that all childs have finished their tasks.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
This means that the IntelliJ project was not properly configured and is
missing the akka-actor-2.2.4_2.10.jar artifact. Is the dependency defined
in sbt?
-Endre
On Thu, Jun 19, 2014 at 10:16 PM, S. Zhou wrote:
> I am new to Akka. We use SBT to compile Scala. After use gen-idea, I
> import the
Hi,
No, the meaning of concurrentConsumers is defined and implemented by the
SEDA component (http://camel.apache.org/seda.html) Akka cannot change the
meaning of that. In an actor system you probably gain nothing from using
this functionality, since you can just immediately forward an incoming
mes
Hi Anton,
My Play knowledge is a little bit hazy here, but the first nesting level
closes over "Akka.system.scheduler" inside the "schedule" callback and I
think that causes the problem with Play reloads. Just a guess.
But anyhow, this kind of nesting looks very fishy. I would rather do an
Actor
Hi Jonathan
The proper solution I think is to not let the mailboxes grow too large and
implement a backpressure channel instead. You can have your consumers
pulling for (batches) of jobs, or acknowledging (possibly batched)
explicitly, or just by having a Backoff signal.
In general this is exactl
Hi Troy,
First of all, take a look at this section that describes how addressing
works: http://doc.akka.io/docs/akka/2.3.3/general/addressing.html
> apnsService works fine, but if i did wrote the same code, using path
> "user/stream-service" then of course it wouldn't work because context is
> l
Hi Greg,
You might be looking for this:
http://doc.akka.io/docs/akka/2.3.3/scala/logging.html#Logging_to_stdout_during_startup_and_shutdown
-Endre
On Thu, Jun 19, 2014 at 2:06 AM, tigerfoot wrote:
> Hello,
>
> I'm using Slf4j (logback) and always get the following output on startup:
>
> [test
Hi,
This seems like a timed out Ask, but I have no clue where it might come
from. The target of the ask is an HTTP actor, so it might be a connection
or bind request?
-Endre
On Wed, Jun 18, 2014 at 10:36 PM, tigerfoot wrote:
> Hello,
>
> I have some test code that uses a SimpleRoutingApp. Af
Hi Nikolay,
Have you tried instead to encode your mailbox requirement on the actors
themselves?
http://doc.akka.io/docs/akka/2.3.3/scala/mailboxes.html#Requiring_a_Message_Queue_Type_for_an_Actor
I find that approach much easier, and I think it is the preferred way when
using special semantics
Hi Ashley
On Wed, Jun 18, 2014 at 5:20 PM, Ashley Aitken wrote:
>
> Hi Patrick,
>
>
> On Wednesday, 13 November 2013 03:19:08 UTC+8, Patrik Nordwall wrote:
>>
>>
>> The order could, in our case, as well be claim-earnings-2 events followed
>> by claim-earnings-1 events.
>>
>>
>> Ok, then it can
Hi,
I think the AskTimeoutException is not related to being in a multi-jvm test
apart from maybe being slower. I suspect that the startup times might be
longer then you expect, and 1s timeout is just too short. I would increase
it to 3s.
-Endre
On Wed, Jun 18, 2014 at 4:32 PM, tigerfoot wrote:
Hi,
Creating an ActorSelection is very cheap, but you can still gain from
caching them if you want to save on allocations. Sending through
ActorSelections is more expensive than through ActorRefs, so I would
consider using them instead. (You can use the Identify message to retrieve
the ActorRef be
Hi Prashant,
I need to check, but if I recall correctly we depend on an artifact in
akka-zeromq that is not available in 2.11
-Endre
On Tue, Jun 17, 2014 at 7:54 AM, Prashant Sharma
wrote:
> Hi,
>
> Subject says it all. I can find this artifact for scala 2.10 but not for
> scala 2.11. Is ther
Hi Felipe,
For some reason akka-remote is denied from binding to a listen port that is
why it fails starting. Since you posted this stacktrace:
akka.remote.RemoteTransportException: Startup failed
at
akka.remote.Remoting.akka$remote$Remoting$$notifyError(Remoting.scala:128)
at akka.remote.Remoti
30 matches
Mail list logo
