I forgot:)
6) Add Publisher:actual: Option[T]. That must return last emitted event -
None if no was emitted.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
Hi,
Hi Team,
I an working on a solution involving akka persistence and DDD/CQRS. The app
is configured with cassandra journal plugin to source the events.Snapshots
will also be stored in cassandra. Application is designed to have sharded
single writers. These single writers will eventually
Simeon, deadletters in akka streams is probably not a problem on your side,
but it is something we must improve
https://github.com/akka/akka/issues/15163.
/Patrik
On Thu, Aug 14, 2014 at 4:50 PM, Simeon Fitch fi...@datamininglab.com
wrote:
In case there’s interest from other’s, here’s an
Update: I thinking about consistent zip and that name (zip) is wrong for
case which I try describe. It must be a consistent version of `product`.
Product of two streams (not product of elements in one stream).
Something like List(consistentFlow1, consistentFlow2).product
--
Read the
Thank you. I will check it out.
I'm also considering Bouncy Castle.
And I'm wondering if I actually need DTLS to encrypt the datagrams...
Dne čtvrtek, 14. srpna 2014 16:35:03 UTC+2 Will Sargent napsal(a):
I don't think there is a Java implementation of DTLS. There is this
wrapper:
Some pointers into the documentation...
On Thu, Aug 14, 2014 at 4:46 AM, Greg Flanagan ventis...@gmail.com wrote:
I'm not qualified to address your questions directly but I find a good
place to start when looking for akka patterns is the typesafe activator.
Here
Hi Prakhyat,
Grow faster than what? Event sourcing is not a silver bullet. If it does
not fit your use case you should use something else. I don't have the
bandwidth to advice in application specific design question in this open
source forum, but Typesafe offers commercial support.
Regards,
Hi Prakhyat,
I created an test benchmark which have two layers, source actors shuffle
data to target actors. I add metrics in the source actors to determine how
many messages are passed to downstream target actors. That is for message
throughput. I then place the source actors and target
7:) For unbounded streams sometimes you need method to kill them
explicitly. So `consume` and `onComplete` must returns Subscriber.
--
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 have a question to a distributed EventSource system:
Let's say I have a fixed number of nodes (3) because I want to balance
load. Each node has a persistent actor which should write to cassandra the
events which have been created and update their inner state afterwards. Now
I'm asking
On Fri, Aug 15, 2014 at 12:15 AM, Evgeniy Ostapenko sml...@gmail.com
wrote:
четверг, 14 августа 2014 г., 21:03:57 UTC+4 пользователь √ написал:
On Thu, Aug 14, 2014 at 5:53 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
четверг, 14 августа 2014 г., 18:59:51 UTC+4 пользователь √
On Fri, Aug 15, 2014 at 10:11 AM, Evgeniy Ostapenko sml...@gmail.com
wrote:
7:) For unbounded streams sometimes you need method to kill them
explicitly. So `consume` and `onComplete` must returns Subscriber.
If you want that you can most definitely introduce either:
A) a timeout operation in
пятница, 15 августа 2014 г., 12:46:20 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:15 AM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
четверг, 14 августа 2014 г., 21:03:57 UTC+4 пользователь √ написал:
On Thu, Aug 14, 2014 at 5:53 PM, Evgeniy Ostapenko
пятница, 15 августа 2014 г., 12:47:39 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 10:11 AM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
7:) For unbounded streams sometimes you need method to kill them
explicitly. So `consume` and `onComplete` must returns
On Fri, Aug 15, 2014 at 11:50 AM, Evgeniy Ostapenko sml...@gmail.com
wrote:
пятница, 15 августа 2014 г., 12:46:20 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:15 AM, Evgeniy Ostapenko sml...@gmail.com
wrote:
четверг, 14 августа 2014 г., 21:03:57 UTC+4 пользователь √
On Fri, Aug 15, 2014 at 11:56 AM, Evgeniy Ostapenko sml...@gmail.com
wrote:
пятница, 15 августа 2014 г., 12:47:39 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 10:11 AM, Evgeniy Ostapenko sml...@gmail.com
wrote:
7:) For unbounded streams sometimes you need method to kill them
пятница, 15 августа 2014 г., 14:04:16 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 11:50 AM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
пятница, 15 августа 2014 г., 12:46:20 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:15 AM, Evgeniy Ostapenko
пятница, 15 августа 2014 г., 14:06:14 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 11:56 AM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
пятница, 15 августа 2014 г., 12:47:39 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 10:11 AM, Evgeniy Ostapenko
Everyone has different use-cases, that doesn't mean that everyone should
have their own APIs.
Ok. But Api can be pluggable. It will be nice to have ability reuse code
when extends api.
It sounds like you are doing something Akka Streams (or Reactive Streams)
have never intended to
Nonsense. That statement is isomorphic to saying that unbounded streams
are meaningless.
Ok. Show me use case when you need concat two unbounded streams (which
never will stopped).
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hi Martin,
On Fri, Aug 15, 2014 at 10:39 AM, Martin Jöhren m.joeh...@gmail.com wrote:
Hi,
I have a question to a distributed EventSource system:
Let's say I have a fixed number of nodes (3) because I want to balance
load. Each node has a persistent actor which should write to cassandra
Thanks Patrik!
Just one more question, what do you mean by If you use remote sends the
actor selection traversal will unlikely be the bottleneck?
On Thursday, August 14, 2014 11:53:53 AM UTC-4, Patrik Nordwall wrote:
Hi Paul,
I think you have identified the two options and understood the
On Fri, Aug 15, 2014 at 12:42 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
Nonsense. That statement is isomorphic to saying that unbounded streams
are meaningless.
Ok. Show me use case when you need concat two unbounded streams (which
never will stopped).
Just because it is unbounded
пятница, 15 августа 2014 г., 15:31:40 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:42 PM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
Nonsense. That statement is isomorphic to saying that unbounded streams
are meaningless.
Ok. Show me use case when you need
Thanks Patrik!
Am Freitag, 15. August 2014 13:14:55 UTC+2 schrieb Patrik Nordwall:
Hi Martin,
On Fri, Aug 15, 2014 at 10:39 AM, Martin Jöhren m.jo...@gmail.com
javascript: wrote:
Hi,
I have a question to a distributed EventSource system:
Let's say I have a fixed number of nodes (3)
On Fri, Aug 15, 2014 at 1:40 PM, Evgeniy Ostapenko sml...@gmail.com wrote:
пятница, 15 августа 2014 г., 15:31:40 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:42 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
Nonsense. That statement is isomorphic to saying that unbounded
On Fri, Aug 15, 2014 at 12:39 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
Everyone has different use-cases, that doesn't mean that everyone should
have their own APIs.
Ok. But Api can be pluggable. It will be nice to have ability reuse code
when extends api.
It sounds like you are
пятница, 15 августа 2014 г., 15:57:07 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:39 PM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
Everyone has different use-cases, that doesn't mean that everyone should
have their own APIs.
Ok. But Api can be pluggable.
On Fri, Aug 15, 2014 at 2:22 PM, Evgeniy Ostapenko sml...@gmail.com wrote:
пятница, 15 августа 2014 г., 15:57:07 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:39 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
Everyone has different use-cases, that doesn't mean that everyone
Sorry, unfortunately I couldn't improve on it and at some point gave up
(had other important things to do). I have a colleague which did additional
experimentation. I will ask him to contribute if he can.
On Tuesday, August 12, 2014 8:37:10 PM UTC+2, Ahmad Alkilani wrote:
hi Victor, any
On Fri, Aug 15, 2014 at 1:24 PM, Paul Cleary pclear...@gmail.com wrote:
Thanks Patrik!
Just one more question, what do you mean by If you use remote sends the
actor selection traversal will unlikely be the bottleneck?
I mean that the performance difference between ActorRef and
пятница, 15 августа 2014 г., 16:26:46 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 2:22 PM, Evgeniy Ostapenko sml...@gmail.com
javascript: wrote:
пятница, 15 августа 2014 г., 15:57:07 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 12:39 PM, Evgeniy Ostapenko
On Fri, Aug 15, 2014 at 3:21 PM, Evgeniy Ostapenko sml...@gmail.com wrote:
пятница, 15 августа 2014 г., 16:26:46 UTC+4 пользователь √ написал:
On Fri, Aug 15, 2014 at 2:22 PM, Evgeniy Ostapenko sml...@gmail.com
wrote:
пятница, 15 августа 2014 г., 15:57:07 UTC+4 пользователь √
Hi patrik,
Very unkind response...but let me clarify in interest of the discussion.
I am not discussing my application specific use case. It is totally akka
persistence related but taking no sql dbs sizing in picture.
My post is not a critic on akka persistence. Let me clarify I want to use
Thanks Patrick, I'll try that and report back (after my holidays..)
Cheers,
Sander
On Thursday, August 14, 2014 11:57:32 AM UTC+2, Sander Mak wrote:
I was thinking about how to create PersistentActor instance that
represents a domain entity, with some initial state that is not determined
So we're talking about a naming issue? Since `merge` changes order?
Perhaps mergeRandom?
It make sense if you have two ordered streams. But if one or both
unordered then `merge` and `mix` comes identically and you lose api
transparency.
You suppose that result stream semantic defines
On Fri, Aug 15, 2014 at 4:08 PM, Prakhyat Mallikarjun prakhyat...@gmail.com
wrote:
Hi patrik,
Very unkind response...but let me clarify in interest of the discussion.
Excuse me. I guess I didn't read your questions literally as questions, but
as negative statements.
I am not discussing
The error probably lies with the remote system, i.e. not the one from which you
have provided the log snippet.
Regards,
Roland
11 aug 2014 kl. 17:42 skrev ryan walsh ryanjoewa...@gmail.com:
I am using a clusterclient to communicate between a remote cluster and this
app. The remote cluster
On Fri, Aug 15, 2014 at 4:52 PM, Evgeniy Ostapenko sml...@gmail.com wrote:
So we're talking about a naming issue? Since `merge` changes order?
Perhaps mergeRandom?
It make sense if you have two ordered streams. But if one or both
unordered then `merge` and `mix` comes identically and you
RDBMS maintains just the state as relational tables.
This is false, most RDBMSes maintains transaction logs.
http://en.wikipedia.org/wiki/Transaction_log
On Fri, Aug 15, 2014 at 5:12 PM, Patrik Nordwall patrik.nordw...@gmail.com
wrote:
On Fri, Aug 15, 2014 at 4:08 PM, Prakhyat Mallikarjun
No worries: thanks for sharing your findings!
7 aug 2014 kl. 15:00 skrev Sean Zhong clock...@gmail.com:
I finally find out it is all out remote dispatcher parallism setting! when I
change parallelism-max to 10, the performance is greatly improved.
default-remote-dispatcher: {
Hi patrik,
Glad you understood my point.
Thanks for your suggestions and point of view. It will help me.
If old stock of events are removed it will save lot of disk space.
But I am curious,
How taking snapshot will get rid of old events? When framework takes snapshots
does it delete old
Hi Prakhyat,
With DDD and CQRS, the state changes storage and publication are key part of
the architecture. When you don't need the DDD part, you could use a persistence
processor that handles the transactions (still possible to do cqrs in that way)
Although your story makes me wonder, when
Dear hakkers,
unfortunately it took me a long time to catch up with akka-user to this point
after the vacation, but on the other hand this made for a very interesting and
stimulating read, thanks for this thread!
If I may, here’s what I have understood so far:
In order to support not only
Isn't it because ActorPath has uid cached for some reason?
https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/ActorPath.scala#L137
On Monday, August 11, 2014 10:45:42 AM UTC+4, Patrik Nordwall wrote:
Hi Johan,
Thanks for creating a small sample and nice logs. From
Hi Ashley,
most of my response is already in my recent post, what you are describing are
topics that are not coupled to a persistenceId and the ability to consume them
in other actors as a stream of events since a given position in the log. One
thing below resonates with me, and that is that
Hi Ashley,
14 aug 2014 kl. 19:30 skrev Ashley Aitken amait...@gmail.com:
Sorry, another question.
Not at all!
It seems to me that currently PersistentViews recover by reprocessing (or at
least considering) all their PersistentActor's events each time they are
created.
Please correct
Hi Prakhyat,
others have already provided good answers, I’d like to add one more point: if
you build an OLTP system for “millions of transactions” then you’ll have to
make a pretty big investment in case of an RDBMS solution just to cover the
license fees; with that kind of money you can buy a
Hi,
I am looking for guidance on how to deal with exceptions with the Producer
end-point. I am aware of Akka's supervision strategy, however it does not
seem to work in my case.
The setup:
I am using akka-camel (2.3.4) in conjunction with camel-rabbitmq (2.13.2)
to publish messages to a
49 matches
Mail list logo
