implementation detail.
On Friday, August 8, 2014 1:18:52 PM UTC+1, Konrad Malawski wrote:
That also works, yes.
I was unsure if sending the client your failure was OK for you.
On 8 August 2014 at 14:16:34, Lawrence Wagerfield (
lawr...@dmz.wagerfield.com javascript:) wrote:
Hi Konrad,
Many
what I suggested.
Happy hakking!
On Fri, Aug 8, 2014 at 2:21 PM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript: wrote:
It's not the exact code, but the notion is the client receives either a
success or failure message, not both. In reality I log the exception
alongside
I have problem that involves synchronising outbound messages from a parent
actor and its child actor. This particular problem is with regards to
forwarding failure messages to clients.
Here is the example:
I have a service actor that receives a request from a client actor*.*
The service
`, is that not the
case?
On Thu, Aug 7, 2014 at 8:59 AM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript: wrote:
I have problem that involves synchronising outbound messages from a
parent actor and its child actor. This particular problem is with regards
to forwarding failure
sends, but then the master *knows *that the
job was successful.
There are optimisations around this scheme one could apply, but as I
understand this thread, we're talking *local *system here.
Hope this helps!
On Thu, Aug 7, 2014 at 4:30 PM, Lawrence Wagerfield
lawr
I would like to utilise Logback's MDC feature while still making use of
Akka for asynchronous logging.
The logging documentation
http://doc.akka.io/docs/akka/snapshot/scala/logging.html hints the
following:
1. val log: DiagnosticLoggingAdapter = Logging(this);
However, the above method
Most of my tests currently following this format:
expectMsg(...)
expectMsg(...)
expectNoMsg(100.millis)
The justification is that any additional/unexpected outputs from an actor
are a bug. This follows the same mentality as ScalaMocks, in that a call to
an unexpected method will fail the test.
Actor (the
FulfilRegistration class with my suggested modification) and during test
you can have that inject the right stub actors quite naturally.
Regards,
Roland
28 maj 2014 kl. 18:00 skrev Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript::
I had an Actor whose code grew
Ah yes, I had forgot to remove that!
Good suggestion on using self-typing to abstract-away implementation detail
:D
The code is looking a lot better now guys, and there's no funny business!
Thanks!
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Using TestActorRef on implementations of Processor (and
EventsourcedProcessor) appears to introduce a deadlock at the point of
calling into the snapshot store actor.
The result is an actor-under-test that never completes recovery.
I have worked-around this issue by providing
with Akka-Persistence - use the plain
TestKit and it’s probes and other utils.
// We had such issue reported, and marked as won’t fix
https://github.com/akka/akka/issues/15293
On Wed, May 28, 2014 at 4:20 PM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript: wrote:
Using
advertise against exposing your ActorContext - it's scary what
could happen with it being accessed from outside of the respective actor.
What's your use case? Perhaps there is a better way to test / abstract it?
On Wed, May 28, 2014 at 4:56 PM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com
https://github.com/akka/akka/issues/15279
On Friday, May 23, 2014 12:24:59 PM UTC+1, Konrad Malawski wrote:
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
My EventsourcedProcessor needs to redo some operation if it was only half
completed.
The events in my system are as follows, where the first event marks the
beginning of a transaction, and the latter two are mutually exclusive
outcomes:
UserRegistrationSubmitted
UserRegistered
Thank you, exactly what I needed :)
On Friday, May 23, 2014 4:30:40 PM UTC+1, Konrad Malawski wrote:
Hello Lawrence!
No additional callback is provided, but there is a nice pattern that
effectively provides the same functionality:
Please check the section of the docs about recovery status:
That should be:
self ! Recover()
On Friday, May 23, 2014 4:50:25 PM UTC+1, Lawrence Wagerfield wrote:
Ahh brilliant :)
One thing I'm struggling with though:
I'm looking through the source for Processor and I don't understand how
calling sender ! Recover() is optional, given the initial
What are the guidelines around implementing FSMs with EventsourcedProcessor
actors?
At first glance I am assuming the two cannot be mixed together, so would I
need to create a child actor FSM and offload messages to that?
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Processor at all), see
https://github.com/akka/akka/issues/15230.
Regards,
Roland
14 maj 2014 kl. 22:21 skrev Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript::
Akka documentation highlights that actor state is reset on
failurehttp://doc.akka.io/docs/akka/snapshot/general
scenarios and document which one serves what purpose.
Regards,
Roland
9 maj 2014 kl. 23:58 skrev Lawrence Wagerfield
lawr...@dmz.wagerfield.comjavascript:
:
Yes, precisely what I was wondering, although probably not as well
articulated!
I am curious as, to my limited knowledge, RAFT
I read this tweet from Martin Krasser this morning:
#Akka-persistence is optimized for making stateful actors durable (at very
high transaction rates), not for implementing durable queues
I am confused as akka-persistence is comparable to other event sourcing
Fascinating and very helpful!
Out of interest, where does RAFT sit on the aforementioned spectrum? I only
ask as there's a few Akka RAFT implementations floating around...
On Monday, May 5, 2014 7:07:16 AM UTC+1, shikhar wrote:
I have been hacking on a discovery plugin for
* algorithm I can use to estimate this time,
highlighting the most significant variables?
Greatly appreciate the feedback,
Lawrence
On Wednesday, April 23, 2014 9:21:53 PM UTC+1, Patrik Nordwall wrote:
On Wed, Apr 23, 2014 at 9:15 PM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript
That's fantastic, thanks!
On Thursday, April 24, 2014 3:16:09 PM UTC+1, Patrik Nordwall wrote:
On Thu, Apr 24, 2014 at 9:37 AM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript: wrote:
Hi Patrik,
Thanks for the info. I saw the Google Compute Engine post only last week
How can I determine the maximum length of time cluster membership state
will be inconsistent for across an Akka Cluster, assuming no further
membership changes beyond the point we start measuring?
I imagine this will depend on several variables: some configurable within
Akka, and some that
My question is the same as 'Cluster Singleton
Nightmarehttps://www.mail-archive.com/akka-user@googlegroups.com/msg00513.html'
- I just really want to clarify how this thread was left...
Is it true that the singleton manager always takes
`maxHandOverRetries*retryInterval` (seconds) before it
Thanks for clarifying Patrik, and thanks for pointing out the ticket (and
also for implementing this feature !) :)
On Tuesday, April 22, 2014 6:43:27 PM UTC+1, Patrik Nordwall wrote:
On Tue, Apr 22, 2014 at 5:53 PM, Lawrence Wagerfield
lawr...@dmz.wagerfield.com javascript: wrote:
My
26 matches
Mail list logo
