Hello Ratika,
AFAIK (and shown in the linked page) Camel can configure such things by
simply appending more options to the `endpointURI`.
Akka-camel is simply passing it through to Camel, so anything that works
with plain Camel like this can be done with Akka-Camel.
Define your pollStrategy
Hi Maatary,
This is more of an architectural question, not really limited to Actors.
If I get that right you're worried about evolution in system B forcing
system A to evolve as well, but you'd rather not change both systems, as
essentially A can stay as is, right?
So instead of directly storing
Hi Oleg,
This is a bit confusing – why would you need this?
What is this supposed to be helping with?
The simplest way to get an execution context for a Future to run on is
`import context.dispatcher` which makes it run on the same dispatcher as
the Actor.
Of course, that's not always what you
inside Future
callbacks could be thread safe in the same way as usual actor message
handling code without Futures.
On Tuesday, August 5, 2014 11:32:45 PM UTC+7, Konrad Malawski wrote:
Hi Oleg,
This is a bit confusing – why would you need this?
What is this supposed to be helping
Hi Josh,
We didn't yet publish/document our actor / cluster protocols very
explicitly.
We'd like to do this at some point, so perhaps other impls could talk to an
akka cluster – no plans on when this might happen though.
This plays into an interesting story about exposing actors as services –
Hello Yann,
There is not “nulling” involved. The PersistentRepr acts as envelope for
your payload (your message), and adds some metadata to it (persistenceId
etc).
See details here:
https://github.com/akka/akka/blob/master/akka-persistence/src/main/scala/akka/persistence/Persistent.scala#L191
We
Hi Lawrence!
I think what you're looking for is the other overload of the Logging apply
method:
val log = Logging(system, classOf[MyCustomerLogger])
I hope this helps, happy hakking!
On Fri, Aug 1, 2014 at 2:03 PM, Lawrence Wagerfield
lawre...@dmz.wagerfield.com wrote:
I would like to
Both ways are perfectly fine, pick one and try to be consistent with it in
your codebase :-)
More info in the docs:
http://doc.akka.io/docs/akka/snapshot/scala/actors.html#initialization-patterns
On Fri, Aug 1, 2014 at 9:42 AM, Tim Pigden tim.pig...@optrak.com wrote:
I'm using actors to
Hello Soumya,
If you’re just getting started, stick to the released versions - such as
2.3.4 :-)
Also, persistence is developed and updated as part of the 2.3 release
cycle, new features will be available within 2.3 - no need to rush to 2.4
just yet :-)
While we do publish (timestamped)
I though you should also have a look at different patterns one can use to
implement waiting for something,
this has been discussed nicely in this thread: Waiting on multiple Akka
messages
).
On Fri, Jul 25, 2014 at 6:42 PM, Martin Simons mar...@lunikon.net wrote:
Am Donnerstag, 24. Juli 2014 11:51:57 UTC+2 schrieb Konrad Malawski:
I know I’ve just grown your to-read list by quite a bit, but I hope this
helps! :-)
Glad you did ;-)
I at least skimmed all the articles you posted
A and B relation).
Curious about your real world use cases in other words.
Less caring about ordering makes way for faster replays of course - so
that's what I'm after here (perhaps thinking to far ahead though).
-- k
W dniu poniedziałek, 28 lipca 2014 22:49:00 UTC+2 użytkownik Konrad
Malawski
Hello Greg,
short question - do you aim to provide something as powerful as quartz
using this?
I mean on monday at 13:02 etc. Because that's not really what our
scheduler is designed to do - we only work with in X amount of time.
Instead maybe you'd simply like to integrate quartz with akka, as
Hello Rich,
it is currently not possible to use FSM with PersistentActor.
We would like to provide this at some point (FSMs are certainly pretty and
useful), here’s the issue tracking this feature:
https://github.com/akka/akka/issues/15279
You’re welcome to either help us out in this one or just
Hello Rajesh,
There's a ton which could go wrong, firstly - we're not the database, so
you should explain how you use akka to persist these.
* do you mean you send 20k messages, and persist each one then?
* are database writes failing or are messages not delivered?
* who does the db writes? Do
Ticket about testkit created: https://github.com/akka/akka/issues/15571
Feel free to share need's and nice-to-have's there.
On Mon, Jul 21, 2014 at 9:50 AM, Carsten Saathoff cars...@kodemaniak.de
wrote:
Am Sonntag, 20. Juli 2014 16:14:53 UTC+2 schrieb Konrad Malawski:
By the way, we
be aware of the trade-offs this brings in.
On Mon, Jul 21, 2014 at 10:58 AM, Konrad Malawski kt...@typesafe.com
wrote:
Hello Rajesh,
There's a ton which could go wrong, firstly - we're not the database, so
you should explain how you use akka to persist these.
* do you mean you send 20k
Hi guys,
That's an interesting area you work in Greg :-)
You seem to already use work-pulling, so while small tweaks can be done
that seams the way to go for me.
And don't worry too much about the downloads until they actually clog
something - you can look at the threads using visualvm to get a
Hi Alex,
I'll answer in-line:
The idea is to have an application that I can clone depending on the load.
Yeap, exactly.
With akka persistence (event sourcing), if I clone an app I will have N
persistents actor with the same persistent id :
No, because actor creation should not be
Hello John,
I don't think there is an equivalent repo to this out there...
Although I assume you've seem this post
http://techblog.net-a-porter.com/2013/12/ask-tell-and-per-request-actors/ where
this code sample originates from?
The concepts are pretty generic, and I would recommend checking out
dimanche 20 juillet 2014 18:42:12 UTC+2, Konrad Malawski a écrit :
Without modifying the tested actor you could test (1) by sending an
Idenfity message to the selection (testedGuy/*),
and then expect exactly one ActorIdentity as response (expect it, and
then expectNoMsg).
I hope this helps
Hello Greg,
Yeah it's not really the most popular thing to do...
Can you share a bit more about the use case?
Are you downloading files in there or is the service just so slow (or is it
a stream of data)?
On Fri, Jul 18, 2014 at 8:54 AM, Greg Flanagan ventis...@gmail.com wrote:
I have an
Hi Vitaliy,
It seems the master is overloaded.
Do you have jvm monitoring in place to see if it's not in state of agony?
In other news, 2.3.4 prioritises hearbeats so missing hearbeat messages
(thus causing false positives on failure detection) because of overloaded
machine is less likely,
I
Actors use the default dispatcher, unless you’ve configured them (as
Martinas has shown) to use a different one.
If you want to configure all this from the code, pass around the dispatcher
nameto Props().withDispatcher(_).
On Fri, Jul 18, 2014 at 12:01 PM, folex 0xd...@gmail.com wrote:
So
Hi Mike,
The problem is you have not performed a 1:1 migration, instead you ended up
using what was previously known as EventsourcedProcessor, but you expected
to use the new Processor.
Using persist + PersistentActor, which is equivalent to the previous persist
in EventsourcedProcessor.
Since
Hi Sean,
I tried to replicate your problem, but seems to work as expected in my
sample app.
I've tried with an app like this:
https://gist.github.com/ktoso/c7382f3c88159f352b75
Which you can paste in the akka-sample-cluster-scala
https://typesafe.com/activator/template/akka-sample-cluster-scala
Hello Andrey,
Have you read the docs about recovery
http://doc.akka.io/docs/akka/2.3.4/scala/persistence.html#recovery ?
You can start recovery by sending an Recover(toSequenceNr: Long) message to
yourself.
We do not support ranged (as in “from 200 to 400”) playback, skipping
events (the “from
How about using some other EventBus?
You can create your own buses very easily, like that:
http://doc.akka.io/docs/akka/2.3.4/scala/event-bus.html
On Thu, Jul 17, 2014 at 2:45 PM, Leon Ma tutuf...@gmail.com wrote:
Hi,
I'd like to use EventStream to send my specific messages and I have my own
Hello Thomas,
That's more of an Activator than Akka question, but yes - the activator is
currently not able to inspect Akka `2.3.4`.
The activator team is aware and are working on upgrading their support for
the latest akka release.
In the mean time, you could try out akka 2.3.3 with the
Hi Ahmet,
Remote DeathWatch should trigger Terminated() messages even in case of
killing the other JVM.
In case of jvm / network failure, there’s a Failure Detector (with a
timeout) that will eventually kick in and send Terminated messages, this is
explained in detail in Remoting - watching remote
Hi Tal,
I think you should start out by analysing our akka-sample-cluster
https://typesafe.com/activator/template/akka-sample-cluster-scala activator
template,
it has a nice tutorial along with the code, it should get you started with
the basics :-)
- Since I assume (and hope) the source code
, Konrad Malawski wrote:
Hi Mike,
The problem is you have not performed a 1:1 migration, instead you ended
up using what was previously known as EventsourcedProcessor, but you
expected to use the new Processor.
Using persist + PersistentActor, which is equivalent to the previous
persist
Thanks Darshana, we're glad to hear you're enjoying akka :-)
Happy hakking!
On Tue, Jul 15, 2014 at 7:35 PM, Darshana Samanpura
darshanasamanp...@gmail.com wrote:
Dear Akka Leads and Team,
Direct Fn is a software solution provider for financial industry,
specializing in market data and
!
On Wed, Jul 16, 2014 at 11:07 AM, simafeng...@gmail.com wrote:
Thank you very much, Mala
But I have no idea about scala. Do you have code in java?Thanks
On Monday, July 14, 2014 7:25:02 PM UTC+8, Konrad Malawski wrote:
Hello there,
Since TypedActors are implemented as plain message sends
on this since you have worked both
on akka-persistence and akka-raft :) so I would appreciate your input.
Thanks,
-Moiz
On Monday, 7 July 2014 10:18:31 UTC-7, Konrad Malawski wrote:
Hello Moiz,
an event detached from it’s lineage does not make much sense for building
up state - which is how
will be performant.
I know you must have done more thinking on this since you have worked
both on akka-persistence and akka-raft :) so I would appreciate your input.
Thanks,
-Moiz
On Monday, 7 July 2014 10:18:31 UTC-7, Konrad Malawski wrote:
Hello Moiz,
an event detached from it’s lineage does
Hello John,
Just store the confirmations too:
case c @ Confirmation(deliveryId) =
persist(c) { _ = confirmDelivery(deliveryId) }
I also recommend watching our ScalaDays talk (Patrik at the 3/4 mark speaks
about the AtLeastOnceDelivery trait):
Hello Alexandre,
First things first: There *must not* be multiple persistent actors in the
system with the same persistentId.
There must be exactly one persistent actor writing to the journal using a
given persistent id.
Otherwise we can't guarantee any ordering. I mean you can start 2 separate
Just like Michael (quoting Patrik) said :-)
Also, please note that Passivate is *not *a feature of akka-persistence,
it's a feature of cluster sharding:
http://doc.akka.io/docs/akka/2.3.4/contrib/cluster-sharding.html
It's true however that it (and the entire cluster sharding) plays very well
Hello Jeff,
Basically I want to pile a bunch of messages into this mailbox and have the
actor process them when it can with a producer timeout restriction. I
know this is related to the Reactive Stream stuff, but I'm interested in
something near term and deciding if I should implement a
Hello there,
Since TypedActors are implemented as plain message sends (the message
representing the proxy method calls is called MethodCall), you can simply
do an untyped router, and then add a typed proxy before it:
TypedActor Router must {
work in {
val t1 = newFooBar
val t2 =
You know it's Victor's code if there's pigdogs inside :-)
PS: I'm not sure if this a pattern popular enough to embrace and add it to
the docs... Opinions?
On Mon, Jul 14, 2014 at 1:26 PM, √iktor Ҡlang viktor.kl...@gmail.com
wrote:
3 pigdog
On Mon, Jul 14, 2014 at 1:24 PM, Konrad Malawski
Viktor's* - I keep mistyping your name recently, don't know why. Sorry,
Viktor. ;-)
On Mon, Jul 14, 2014 at 1:26 PM, Konrad Malawski kt...@typesafe.com wrote:
You know it's Victor's code if there's pigdogs inside :-)
PS: I'm not sure if this a pattern popular enough to embrace and add
Hello Javier,
It's a bit hard to answer on event design questions when we discuss
Entity and Event :-)
But in general these events should have some meaning, not only
AttributeUpdated - as in BughtItem, ShippedThingy, ConfirmedPayment.
Play around with the granularity of your events, maybe you're
Hello Pavel,
It seems to me that you’re overdoing a lot inside that implementation.
I don’t really see what gain your own deliveryIds is meant to provide.
Let’s take a step back and look at the semantics of deliver and
confirmDelivery *during playback*.
During normal operation I think it’s clear
This thread motivated me to improve the documentation on these methods a
bit, progress can be tracked in this
issue: https://github.com/akka/akka/issues/15538
-- k
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Pull request here: https://github.com/akka/akka/pull/15540
On Mon, Jul 14, 2014 at 2:33 PM, Jonas Bonér jo...@jonasboner.com wrote:
On Mon, Jul 14, 2014 at 1:26 PM, Konrad Malawski kt...@typesafe.com
wrote:
You know it's Victor's code if there's pigdogs inside :-)
PS: I'm not sure
Could you give some more context about what you are trying to achieve?
On Mon, Jul 14, 2014 at 7:22 PM, Oleksandr Ryabuha ale...@gmail.com wrote:
How to detach a custom dispatcher ?
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hello Curtis!
Replies in-line :-)
1. What is the problem persistence is meant to solve? Is it just to be able
to recover actors after an error or crash or are there uses beyond that?
The Scala Days 2014 talk hinted at some kind of link between persistence
and queries that I didn't quite get.
Hi Juan,
Glad to hear you've picked persistence :-)
My immediate reaction would be to store each data point as an event - that
will make replaying and analysing the data simpler. It also means no need
to think about oh yeah, we were getting the data in batches, so it's
batches stored in the db.
Hello Moiz,
an event detached from it’s lineage does not make much sense for building
up state - which is how persistent actors are designed to be used.
An persistent actor’s state, and your “domain state”, should be built up
from such series of events (and snapshots).
We do support playback
Hello Tim!
The PersistentActor is not the guy with the lock, it’s the (LevelDB)
journal.
You only need 1 actor system running (and one journal) to test what you
want, example:
class MyPersistentActor(override val persistenceId: String) extends
PersistentActor {
// … persist events, handle
If I start a new PeristentActor with the same id as an existing one it will
just start in recovery mode regardless of the other one - right?
Yes, it'll recover that persistent state.
The other thing you could do is to act ! “boom” it to make it restart,
which also triggers the replay.
Refer to
Whoops, I thought this question was in the
https://groups.google.com/forum/#!topic/akka-user/RZrLVIKPPEg (unit-testing
persistent actor recovery) thread.
To clarify what I meant above, since it’s also relevant - the same class is
fine. What you do not want to have is multiple persistent
Samples in order of my preference :-)
Scala:
https://github.com/akka/akka/blob/release-2.3/akka-samples/akka-sample-persistence-scala/src/main/scala/sample/persistence/PersistentActorExample.scala
Java 8:
If at any point you catch yourself thinking 100%, re-read this post:
http://aphyr.com/posts/288-the-network-is-reliable of multiple multiple
failure examples with even redundant datacenter providers etc ;-)
On Thu, Jun 26, 2014 at 8:24 PM, √iktor Ҡlang viktor.kl...@gmail.com
wrote:
I'd even
Thanks for the snippet Alex.
To clarify how EventsourcedProcessor (persistence 2.3.3) differs from
PersistentActor (persistence 2.3.4):
You’d simply apply these sed rules:
s/EventsourcedProcessor/PersistentActor/g
s/val processorId/val persistenceId/g
We are releasing 2.3.4 sometime during this
Hello Alessandro,
We’ll be releasing 2.3.4 in a few days, it will include the new persistence
APIs (PersistentActor among them).
We will release for both 2.10 and 2.11 ( like we did for 2.3.3 -
Hello again,
We've been discussing this a bit more today, and I wanted to amend my tip,
since we'll be moving away from `deleteMessage`.
Another discussion explaining why? can be found here on
github: https://github.com/akka/akka/issues/15428
So my corrected advice would be somewhat among the
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
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
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 kt...@typesafe.com
wrote
Hello Troy,
Welcome to 2.3.3 :-)
Please refer to the cluster docs about Cluster Metrics
http://doc.akka.io/docs/akka/2.3.3/scala/cluster-usage.html#cluster-metrics
to
understand what that is used for.
Basically, the JVM does not provide very detailed information via JMX which
might be used by for
Hello Lee,
instead of rolling your own metrics library I would suggest using one of
the existing tools, such as:
cloud:
* *newrelic* https://docs.newrelic.com/docs/java/new-relic-for-java
open source (self-hosted):
* *kamon* http://kamon.io
* codahale metrics
Yes, perhaps I should explain our current workflow with these branches
actually:
master will eventually become akka 2.4.x
release-2.3 will eventually become akka 2.3.4 (and 2.3.5 if it’s needed
etc).
release-2.3-dev is used only for streams development. It is separate to
keep iterating /
(mymessage, threadLocalInfoThatINeed)
intercept receive : unwrapper MDCCtx, recover thread local info.
Thanks
Leon
在 2014年5月29日星期四UTC+8下午11时27分01秒，Konrad Malawski写道：
Hello Leon,
Well, the Scala way™ would rather be using plain total or partial
functions and composing them - I believe
, 2014 at 12:57 PM, Konrad Malawski kt...@typesafe.com
wrote:
So metrics.
I would suggest piggybacking on kamon: http://kamon.io/
Since the guys have many of the things figured out already - it's open
source so it should be possible to either get metrics from their pointcuts
or piggyback in some
Not exactly one, but yeah as little as possible.
This way of thinking will force your thinking towards creating these
hierarchies of actors which fail or survive together (kind of like the four
musketeers :-)).
And the gains have been outlined already - you are able to fail / restart /
isolate
Hello Allen,
have you had the chance to look into our akka-persistence
http://doc.akka.io/docs/akka/2.3.3/scala/persistence.html module?
Apps like you describe are very nicely modelled as events and “opposite
events” if you want to “undo”.
And direct answers to your questions:
- path - the
Hi Chris,
Thanks for noticing this! We have not previously supported two Scala
versions we this must have slipped our minds when doing the recent release.
I'll update the downloads page to include the links right away.
On Wed, May 28, 2014 at 10:37 AM, oxbow_lakes oxbowla...@gmail.com wrote:
Hello Lawrence,
Because of the processor’s inner workings (how it interacts with the
Journal) it does not make sense to test it using the *synchronous* test
utilities (such as TestActorRef).
Please do not use TestActorRef with Akka-Persistence - use the plain
TestKit and it’s probes and other
I have updated the site to link to both published zips -
http://akka.io/downloads/
Thanks again for noticing this! :-)
On Wed, May 28, 2014 at 11:10 AM, Konrad Malawski kt...@typesafe.comwrote:
Hi Chris,
Thanks for noticing this! We have not previously supported two Scala
versions we
?
Thanks,
Lawrence
On Wednesday, May 28, 2014 3:48:26 PM UTC+1, Konrad Malawski wrote:
Hello Lawrence,
Because of the processor’s inner workings (how it interacts with the
Journal) it does not make sense to test it using the *synchronous* test
utilities (such as TestActorRef).
Please do
Hello Jeroen,
Indeed the options that you have listed are the other available, thus
recommended, options. Truth be told, keeping a large cluster running does
require some more tooling, ops skills or people to take care of it.
In practice you could hook into monitoring services like Nagios or
Hello Andreas,
Yes, the Typesafe Console is being EndOfLife-ed.
JMX support is still around in some Akka modules. It depends which values
explicitly you're after, but for Cluster we have the ClusterJmx bean (here
it's
One thing unanswered from the previous email:
Is it in the spirit of akka-stream/reactive streams to implement your own
producers? Or should all producers (publishers) be created by the framework?
In theory reactive streams aim to be usable between frameworks - so an Rx
Producer would be
Hey Adam,
Patrik has right now opened a ticket and started exposing the ActorProducer
abstraction :-)
https://github.com/akka/akka/issues/15288 This will help a lot in
implementing external producers. :-)
On Mon, May 26, 2014 at 2:52 PM, Endre Varga endre.va...@typesafe.comwrote:
Hi Adam
-
Hello Lawrence,
Mixing FSM with EventsourcedProcessor is not directly supported - going
with a child actor is easiest way to get what you need I think.
The reason it's not easy to just mix-in both FSM and EP is because they
both do a lot around handling the `receive` for you so it may be tough
Hello Syed,
yes / no.
yes - it's possible to spin up a View for the same processorId on a
different node in the cluster. It can be used as a read-model.
no - it can not change into becoming a processor if the main processor
goes down. A view is a view.
The View's use-case is to be able to have a
Actors are thread safe inside them by definition.
The actor has one mailbox and processes the messages one by one from it.
We guarantee that fields are properly visible, even if the actor jumps
around threads - no need for CHM in the actor
On Thu, May 15, 2014 at 7:31 AM, Leon Ma
processed?
They can't be executed in parallel?
Thanks
Leon
在 2014年5月14日星期三UTC-7下午10时34分45秒，Konrad Malawski写道：
Actors are thread safe inside them by definition.
The actor has one mailbox and processes the messages one by one from it.
We guarantee that fields are properly visible, even
Nothing like that in TestKit, reason being - you don't usually interact
with Actors like that. I think the test should feel more like when this
happens, will it be restarted by it's parent? etc.
I'd rather structure the test like that, but maybe there's something I'm
missing in your use-case.
On
Is it possible to use Processor and FSM together?
Yes,
http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#state-machines
What problems are you seeing?
--
Cheers,
Konrad 'ktoso' Malawski
hAkker - Typesafe, Inc
http://www.scaladays.org/
--
Read the docs: http://akka.io/docs/
Hello Tim!
I think the docs should be mostly self contained - as in, if I'm in the
woods in Laponia with no WiFi, with the docs downloaded, I should be able
to figure out what I need from the docs :-)
You are very welcome to open issues and pull requests!
--
Cheers,
Konrad 'ktoso' Malawski
We also found 2 pretty cool blog posts (by Ben Howell) explaining akka's
event buses a bit today, see:
http://www.benhowell.net/examples/2014/04/18/scala-and-the-akka-eventstream/
--
Konrad `ktoso` Malawski
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hello Kuba,
Firstly, thanks for the Akka love! We 3 you too ;-)
Back to your questions:
Yes, the Actor would represent an Aggregate; and yes, it's a good idea to
spin up Actors for specific ID's, handle the command / event in it, and
emit more events signifying some business logic was performed
Hello Soumya,
You can use the scheduler the same way you’re already doing it from within
an Actor too.
// inside an Actor (Subscribe Actor)
context.system.scheduler.schedule(30.seconds, 30.seconds) {
// your publishing here
}
I hope this helps, happy hakking!
--
Cheers,
Konrad Malawski
Hello Jem,
We looked deeper into this and it seems that it’s both working as mendated
by the current design (I’ll explain in detail bellow), as well as there is
a way of forcing your desired behaviour (which totally makes sense in some
scenarios).
Analysis:
First let’s dissect your log and see
Hello there Andriy,
I think Christian on StackOverflow has already answered most questions
already :-)
As for the the “initialization dance” going on with Actors - there’s a few
patterns that can help:
http://doc.akka.io/docs/akka/2.3.1/scala/actors.html#initialization-patterns
But in
Hello Eric,
Is having the same actor system name required?
Yes, for a cluster to converge the cluster members should have the same
actorsystem-name.
I like to think of it as: the ActorSystem being the “universe” in which
Actors live, the cluster just allows them to live on different “planets”
Hello Chanan,
What Heiko said +1 :-)
The EventBus is strictly *local-only*, the reasons for that have been
explained a bit here:
https://groups.google.com/forum/#!searchin/akka-user/eventstream$20local/akka-user/gSO7s6587BQ/WQZGCGJrfq4J
Thanks for pointing out that it's not from the docs (
typo, I meant: ... not obvious from the docs
-- k
--
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
---
You received this message because you are
, which could be used as
actor name and/or processor id. Once a user decides to unregister, the user
profile might have to be deleted for privacy reasons and it should also be
possible to reuse the now free username. Does that make sense?
Heiko
On Sun, Mar 23, 2014 at 7:07 PM, Konrad Malawski
(at least to me), as it might
complicate reasoning about the system's state at some point in time…
--
Konrad Malawski
geecon.org / java.pl / krakowscala.pl / gdgkrakow.pl
From: Heiko Seeberger heiko.seeber...@gmail.com
Reply: akka-user@googlegroups.com akka-user@googlegroups.com
Date: 23 March 2014
by the `a`
actor replying to the wat message
--
Konrad Malawski
geecon.org / java.pl / krakowscala.pl / gdgkrakow.pl
From: glidester glides...@gmail.com
Reply: akka-user@googlegroups.com akka-user@googlegroups.com
Date: 21 March 2014 at 11:49:05
To: akka-user@googlegroups.com akka-user
I assumed the commented code was in the spirit of oh, and the commented stuff
didn't work out for me, plz help. :-)
--
Konrad Malawski
geecon.org / java.pl / krakowscala.pl / gdgkrakow.pl
From: √iktor Ҡlang viktor.kl...@gmail.com
Reply: akka-user@googlegroups.com akka-user@googlegroups.com
this helps!
--
Konrad Malawski
On Saturday, 8 March 2014 at 18:36, Andy C wrote:
Hi,
Most my stuff is reactive and async and Actors seems to be perfect to fit
the bill with an exception of a certain legacy I/O. It has to be handled
within Actor itself and it might take from seconds to even
@Matteo PR’s are public = https://github.com/akka/akka/pull/2014 :-)
--
Konrad
On Sunday, 23 February 2014 at 14:12, Matteo Cusmai wrote:
Can I see more about your proposal?
Please share the pr.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Pull requested here https://github.com/akka/akka/pull/2023
Tested on a few friends if it's understandable, seems to be ok :-)
--
cheers, k
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://akka.io/faq/
Search the archives: https://groups.google.com/group/akka-user
Hello Peter,
One idea you might give a spin is to extract actor behaviors into traits,
and compose behavior of a concrete actor using those.
This can work because `receive` is basically just a `PartialFunction[Any,
Unit]`, and those have a nice method called
801 - 900 of 903 matches
Mail list logo
