estion ?
>>
>> On Wednesday, September 13, 2017 at 1:32:13 AM UTC+4:30, Yaroslav Klymko
>> wrote:
>>>
>>> Hi guys,
>>>
>>> I'm wondering are there any plans to provide integration between akka
>>> streams and PersistentActor
tries.get(id) match {
> case None => Left("entry is missing")
> case Some(entry) =>
> if (entry.name == newName) Left("old and new names are
> equal")
> else Right(Done)
> }
>
> }
> }
> }
>
4:10 AM UTC+2, Patrik Nordwall wrote:
>
>
>
> On Fri, Oct 20, 2017 at 5:29 PM, Yaroslav Klymko <t3h...@gmail.com
> > wrote:
>
>>
>> On Friday, October 20, 2017 at 4:44:35 PM UTC+2, Patrik Nordwall wrote:
>>>
>>>
>>>
>>> On Thu, O
On Friday, October 20, 2017 at 4:44:35 PM UTC+2, Patrik Nordwall wrote:
>
>
>
> On Thu, Oct 19, 2017 at 2:52 PM, Yaroslav Klymko <t3h...@gmail.com
> > wrote:
>
>>
>>
>>
>> On Thursday, October 19, 2017 at 9:33:59 PM UTC+2, Patrik Nordwall wrote:
&g
transition might look like `onRecoveryCompleted: State =>
PersistentBehavior[Command, Event, State]`
What do you think ?
> On Thu, Oct 19, 2017 at 5:48 AM, Yaroslav Klymko <t3h...@gmail.com
> > wrote:
>
>> I also have other concern regarding.
>>
>>
| DropEvent | DropCmd
But this logic enforces users to apply events after persistence and rely on
exceptions.
Please let me know in case I'm wrong, I'd really like to understand your
logic :)
On Wednesday, October 18, 2017 at 10:28:43 PM UTC+2, Yaroslav Klymko wrote:
>
> I think re
service, and it's better to not mixing that concern with the
> construction of the command handlers.
>
> /Patrik
>
>
> On Wed, Oct 18, 2017 at 2:54 PM, Yaroslav Klymko <t3h...@gmail.com
> > wrote:
>
>> Hi guys,
>> Not sure this is the right place to
Hi guys,
Not sure this is the right place to ask:
I'm looking into akka typed for persistence and wondering whether we really
need onRecoveryCompleted at
https://github.com/akka/akka/blob/master/akka-typed/src/main/scala/akka/typed/persistence/scaladsl/PersistentActor.scala#L174
Why not just
Oh indeed, looks like that is a bad example.
Using custom messages will make sure `handler` passed to `persistAll` is
executed.
Thanks.
On Tuesday, September 26, 2017 at 11:33:46 AM UTC+2, Konrad Malawski wrote:
>
> Sure Konrad, that's more like an example.
>
> The example is very specific, and
Malawski wrote:
>
> Don’t use PoisonPill, but your protocol level messages to signal “plz
> stop”, which is best practice anyway,
>
> —
> Konrad `kto.so` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 26 September 2017 at 17:25:43, Yaros
Hi Guys,
Do I understand correctly that there is high chance to have events
persisted without handlers performed if persistent actor stopped?
ref ! cmd
journal ! WriteMessages
ref ! PoisonPill
deadLetters <- WriteMessagesSuccess
Is it intendant? Are there any plans to fix or improve this
Hi guys,
Recently we had an issue in live with one of three our nodes, so eventually
we restarted it. Then after 2 days running it was unexpectedly quarantined,
without any other strange misbehaviours.
Some facts to rebuild history:
1. We have seed-nodes configured in exact order: [node1,
Hi guys,
I'm wondering are there any plans to provide integration between akka
streams and PersistentActor ?
The feature I'm interested in particular is `FlowOps.batch`, so I could
batch commands, while events are being persisted, and then persist all
events produced by stashed commands
ve cores the performance will only be worse. You
> also want to leave some cores for other tasks in your application, such as
> processing the actual messages.
>
> /Patrik
>
>
>
> On Mon, May 1, 2017 at 8:30 PM, Yaroslav Klymko <t3h...@gmail.com
> > wrote:
>
>&
artery
>
> - inbound-lanes and outbound-lanes.
>
> --
> Johan
> Akka Team
>
> On Fri, Apr 28, 2017 at 12:45 PM, Yaroslav Klymko <t3h...@gmail.com
> > wrote:
>
>> Hi guys,
>>
>> Do I understand correctly that we have a single instance of
>> `End
Hi guys,
Do I understand correctly that we have a single instance of
`EndpointReader` actor per connection ?
Thus deserialisation of remote messages being done sequentially, so we can
hit this bottleneck much faster then a network throughput limits?
--
>> Read the docs:
Hi guys,
Just curious about reasoning to make `default-plugin-dispatcher` as
default-plugin-dispatcher {
type = PinnedDispatcher
executor = "thread-pool-executor"
}
Why not a fork-join-executor ?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
; change the state of the GraphStage to forward messages 1-to-1.
>
> Johannes
>
> On Tuesday, September 20, 2016 at 4:00:23 PM UTC+2, Yaroslav Klymko wrote:
>>
>> Basically I'd like to prepend something, but at the moment first
>> ByteString received, I mean that prepend
.g. by wrapping the complete
> connection flow with a custom GraphStage that would be able to receive all
> kinds of signals.
>
> HTH
> Johannes
>
>
>
> On Thursday, September 15, 2016 at 12:32:02 PM UTC+2, Yaroslav Klymko
> wrote:
>>
>> Either my question i
Either my question is silly or there is no easy answer.
On Saturday, September 10, 2016 at 3:57:33 PM UTC+3, Yaroslav Klymko wrote:
>
> Hi guys,
>
> I'm trying to figure out on how to trigger some logic at the moment TCP
> connection established, and preferably *before traffic
Hi guys,
I'm trying to figure out on how to trigger some logic at the moment TCP
connection established, and preferably *before traffic goes*
Initial code looks like this:
Tcp(system).outgoingConnection(???, ???).join(flow).runWith(source, sink)
As far as I can see I need to access
in the
> HTTP sources to look at, this one:
>
> https://github.com/akka/akka/blob/fbfc8b4c58ecc8820e06d68114e7d41f82c3de32/akka-http-core/src/main/scala/akka/http/impl/util/One2OneBidiFlow.scala
>
> --
> Johan
> Akka Team
>
> On Wed, Sep 7, 2016 at 2:26 PM, Yaroslav Kl
Hi Guys,
Is there somewhere an example of stateful BidiFlow ?
--
>> 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
Well done Tim!
On Sunday, August 30, 2015 at 7:55:33 AM UTC+3, Tim Harper wrote:
>
> Op-Rabbit (the Akka-based messaging library for RabbitMQ) v1.0.0-RC1 has
> been released. There have been a *lot* of changes since the first
> milestone release. To name a few:
>
>- AckedStream extracted to
Hi folks,
I'm wondering whether *journal.max-message-batch-size* should be used to
batch events passed to *persist() *method ?
It is ignored now, is it expected?
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
,
Konrad 'ktoso’ Malawski
Akka http://akka.io @ Typesafe http://typesafe.com
On 27 July 2015 at 10:34:03, Yaroslav Klymko (t3h...@gmail.com
javascript:) wrote:
Hi folks,
I'm wondering whether *journal.max-message-batch-size* should be used to
batch events passed to *persist()* method
, March 29, 2015 at 5:04:50 AM UTC-4, Yaroslav Klymko wrote:
The minimal app to reproduce this:
import akka.actor.{Actor, ActorSystem, Props}
import akka.pattern.ask
import akka.util.Timeout
import scala.concurrent.duration._
object MemoryLeakApp extends App {
val system = ActorSystem
So PrmiseActorRef is leaking and keeps reference on Promise
WriteEventsCompleted, still I'm not able to find a combination of
dispatchers/actors to reproduce on simple example.
On Saturday, March 28, 2015 at 9:33:15 PM UTC+2, Yaroslav Klymko wrote:
Hi guys,
I have a very strange problem
= Timeout(3.seconds)
while (true) {
actor ? Request
}
}
class MyActor extends Actor {
def receive = {
case _ =
val actor = sender()
context.watch(actor)
actor ! Response
}
}
On Sunday, March 29, 2015 at 12:03:43 PM UTC+3, Yaroslav Klymko wrote:
Hi guys,
Root
Hi guys,
Root cause of my issue has been found, in short it is caused by *context
watch sender()*, where the sender is PrmiseActorRef.
On Sunday, March 29, 2015 at 10:33:47 AM UTC+3, Yaroslav Klymko wrote:
So PrmiseActorRef is leaking and keeps reference on Promise
WriteEventsCompleted
Hi guys,
I have a very strange problem, it was originally spotted by @gfduszynski
https://github.com/EventStore/EventStore.Akka.Persistence/issues/11
Here is a problematic line of code
believe of the akka-evenstore bridge)
On Sunday, May 18, 2014 9:31:16 PM UTC+1, Yaroslav Klymko wrote:
Cool, thx, this is what I was looking for.
On Sunday, May 18, 2014 10:58:00 PM UTC+3, ahjohannessen wrote:
Hi,
This might be what you are looking for:
https://github.com/krasserm/akka
Akka persistance deals with messages. It's up to you to define the way of
serialization. The best option for storing objects in event store is using
json serializer.
You can read more about this
here: http://doc.akka.io/docs/akka/2.3.2/scala/serialization.html
On Tuesday, May 20, 2014
Cool, thx, this is what I was looking for.
On Sunday, May 18, 2014 10:58:00 PM UTC+3, ahjohannessen wrote:
Hi,
This might be what you are looking for:
https://github.com/krasserm/akka-persistence-testkit
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hi guys,
I'm wondering are there any drawback on using Identify and ActorIndentity
reply for flow control mechanism.
Why I want to use Identify ActorIndentity - because those are implicitly
implemented in all actor.
So let's say producer is sending messages with high rate to consumer, and
. Is that correct?
Cheers
Oleg
On Sun, Feb 2, 2014 at 7:56 AM, Yaroslav Klymko t3h...@gmail.comjavascript:
wrote:
Hi guys,
I'm wondering are there any drawback on using Identify and ActorIndentity
reply for flow control mechanism.
Why I want to use Identify ActorIndentity - because
...@gmail.comwrote:
So, 'throttling' would be a better term for that.
Have you look at this:
http://letitcrash.com/post/28901663062/throttling-messages-in-akka-2
Cheers
Oleg
On Sun, Feb 2, 2014 at 8:31 AM, Yaroslav Klymko t3h...@gmail.com wrote:
I would not say to batch, just to have ability
thx Patrik
On Sunday, 2 February 2014 19:50:46 UTC+2, Patrik Nordwall wrote:
On Sun, Feb 2, 2014 at 4:12 PM, Yaroslav Klymko t3h...@gmail.comjavascript:
wrote:
Took a look on
http://letitcrash.com/post/28901663062/throttling-messages-in-akka-2
So I want to have a ActorIdentity reply
38 matches
Mail list logo
