Hey hakkers!
I have a transformer step which perform some IO operations. Sure IO can
fails and currently I have no way to perform non blocking retry of failed
message.
What about introduction new flow/duct combinator which allows to
automatically perform n retries with some delay in case of tr
Ok I understood that each persistent actor have for name the id used for
the shard so there will as many persistent actor as users/shopping cart in
my exemple (if I use the persistent id used in the activator ie
self.path.parent.name + "-" + self.path.name) .
We can't have one persistent actor
Something that would improve the usability of the (generally great!)
documentation for me at least would be to have the "Contents" link go to
the main contents page for whichever language (Scala or Java) documentation
is being viewed, rather than going up 2 levels to the page that has links
to
In 2.3.3 I used AbstractProcessor. In 2.3.4 I've migrated
to AbstractPersistentActor.
On Wednesday, July 16, 2014 12:06:03 PM UTC-7, Konrad Malawski wrote:
>
> Hi Mike,
> Short: no, performance should be (and we have benchmarked it) to be on par
> with 2.3.3.
>
> Longer: Have you been using Pr
Hi Roland,
I'm AFK as well until Sun, will do next week.
Cheers,
Martin
Am 16.07.2014 16:51 schrieb "Roland Kuhn" :
> Hi Martin,
>
> I agree, streams should be a first class citizen in akka persistence. I'm
> afk right now, could you ensure that this is adequately represented in the
> issue trac
Hi Mike,
Short: no, performance should be (and we have benchmarked it) to be on par
with 2.3.3.
Longer: Have you been using Processor or EventsourcedProcessor?
* EventsourcedProcessor *is* PersistentActor, so performance is exactly the
same.
* Processor is PersistentActor+*persistAsync*.
Fill me
Hi!
I don't have any hard evidence (I would create a bug otherwise), but I feel
that new persistence implementation is slower than the previous one.
My persistent actor receives messages in big bursts. With 2.3.3 API the
processing was really fast. After I have migrated everything to 2.3.4 and
What can you tell us about the expected latency of your getData* calls?
What kind of call volume are you dealing with? I'm just trying to get a
sense of how much elegance you might need to trade to squeeze out perf.
On Wednesday, July 16, 2014 6:56:00 AM UTC-7, Adam wrote:
>
> Hi,
>
> I’m wond
Hi everyone, I'm building a library with actors to do some large-scale data
crunching.
I'm running my code on Amazon EC2 spot instances using StarCluster. The
program is unstable because the actor remoting sometimes drops:
While the code is running, nodes will disconnect one by one in a few
mi
Cheers to the community! Here are some principal questions about
akka-persistence:
I need to have full events log and access to its portions by starting
sequenceNr and limit. Is using akka-persistence a good practice for this?
If yes, what is the right way to access to journal log? Can I force
Thanks for your answer but there is something I don't understand on the
cluster sharding.
For exemple imagine that I have 2 nodes : A and B handling a shopping cart
(A and B are persistent actors). If I use the cluster sharding and my id is
the login of the user.
My shard resolver will for ex
Hi Martin,
I agree, streams should be a first class citizen in akka persistence. I'm afk
right now, could you ensure that this is adequately represented in the issue
tracker?
Thanks,
Roland
On July 16, 2014 8:08:57 AM CEST, Martin Krasser
wrote:
>
>On 16.07.14 05:25, Ashley Aitken wrot
Hi all,
I've been playing around with the Akka HTTP experimental release, handling
some POST requests. I've got a problem where using HttpEntity.toStrict
seems to cause a hang when performed in the pipeline. If I return a
different response from the pipeline that does not depend on the toStrict
You're most welcome,
happy hAkking!
On Wed, Jul 16, 2014 at 3:40 PM, Guylain Lavoie
wrote:
> Ok, Thanks!
>
>
> Guylain
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives
Hi,
I’m wondering what would be the best way to model services which
continually collect data from various sources until it finally has enough
to create an answer.
In synchronous pseudo code this would look like:
def myservice = {
val field1 = getData1().map(_.getField1)
val field2 = getDat
Ok, Thanks!
Guylain
--
>> 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
On Wednesday, July 16, 2014 7:09:06 AM UTC+1, Martin Krasser wrote:
>
> I think it makes sense to go into that direction and to require that all
> journal backend stores support that, so that user-defined event streams can
> be consumed both Akka-internally and by external consumers (that directl
Related: For raft I would use a local data store for each of the node's
logs, as the comitting and agreeing is something the protocol is supposed
to do - storing everyone's logs in the same db would miss the point of
having raft running I believe.
On Wed, Jul 16, 2014 at 12:57 PM, Konrad Malawski
Hello again, I seem to have missed this email somehow - sorry!
// Thanks for noticing my akka-raft project! :-)
About RAFT... The problem with RAFTs log is that in there a delete can
happen from the opposite side as you'd normally do in event sourcing.
So in event sourcing you only delete "until
Awesome - thanks for the quick reply!
You're right - the Transformer-Pull is probably not exactly what I need.
But I can make due with your other proposals for now.
Thx,
-Thomas
Am Mittwoch, 16. Juli 2014 11:11:36 UTC+2 schrieb drewhk:
>
> Hi!
>
>
> On Wed, Jul 16, 2014 at 10:49 AM, schoefts
The linked pull request includes a Java version, see:
https://github.com/akka/akka/pull/15540/files#diff-4161415cbe164e514bbc16114e346152R199
The docs are published automatically as snapshot:
http://doc.akka.io/docs/akka/snapshot/java/typed-actors.html#Typed_router_pattern
Happy hakking!
On We
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 a
Hi!
On Wed, Jul 16, 2014 at 10:49 AM, schoefts
wrote:
> Hi everyone,
>
> we are currently integrating Akka-Streams in an application.
>
> Looking at the current Flow DSL/API, I can see that Transformers
> (Flow#transform) allow to *synchronously* produce a number of
> output-messages from 1 mes
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 (the message
> representing the proxy method calls is called M
When !/tell returns to the caller, Akka is going to attempt to deliver the
message no matter what happens to the sender.
On Jul 16, 2014 9:22 AM, "Guylain Lavoie" wrote:
> Hello, thank you for the reply.
>
> I reread this section, and to my understanding, it talks about what
> happens to the mess
Hi everyone,
we are currently integrating Akka-Streams in an application.
Looking at the current Flow DSL/API, I can see that Transformers
(Flow#transform) allow to *synchronously* produce a number of
output-messages from 1 message.
abstract class Transformer[-T, +U] {
* /***
* * Invoked for
Hello, thank you for the reply.
I reread this section, and to my understanding, it talks about what happens
to the messages in the queue of the "to be stopped" actor.
It does not make any mention of what will happen to messages posted (and
not yet delivered) by the "to be stopped" actor into ano
27 matches
Mail list logo
