On Mon, Mar 24, 2014 at 8:46 PM, Justin du coeur wrote:
> This has been stewing for a few hours, so I'm going to follow up:
>
> On Mon, Mar 24, 2014 at 12:27 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>>
>> I think opposite. It is easier to let each Aggregate decide, e.g. by
On Mon, Mar 24, 2014 at 8:33 PM, Michael Kohout wrote:
> Hazzah! I look forward to updating to 2.3.1 :-)
>
> Thanks so much for your handholding through my stupid little problems
> Mike
>
> You're welcome. Happy hakking!
/Patrik
> On Monday, March 24, 2014 2:00:00 PM UTC-5, Patrik Nordwall wro
This has been stewing for a few hours, so I'm going to follow up:
On Mon, Mar 24, 2014 at 12:27 PM, Patrik Nordwall wrote:
>
> I think opposite. It is easier to let each Aggregate decide, e.g. by using
>>> ReceiveTimeout.
>>>
>>
Slightly different question: are there other reasons to favor puttin
Hazzah! I look forward to updating to 2.3.1 :-)
Thanks so much for your handholding through my stupid little problems
Mike
On Monday, March 24, 2014 2:00:00 PM UTC-5, Patrik Nordwall wrote:
>
>
>
>
> On Mon, Mar 24, 2014 at 6:54 PM, Michael Kohout
>
> > wrote:
>
>> Hi Patrik-
>>
>> Yup, now it
On Mon, Mar 24, 2014 at 6:54 PM, Michael Kohout wrote:
> Hi Patrik-
>
> Yup, now it worked. I had to get the cluster seed nodes set up correctly
> and then it looks like it works.
>
Glad to hear that.
>
> Next, I've got to create the proxy. Have Typesafe/other committers
> considered adding
Hi Patrik-
Yup, now it worked. I had to get the cluster seed nodes set up correctly
and then it looks like it works.
Next, I've got to create the proxy. Have Typesafe/other committers
considered adding a configurable proxy that could do this out of the box?
It seems like a common pattern.
On Mon, Mar 24, 2014 at 5:20 PM, Justin du coeur wrote:
> On Mon, Mar 24, 2014 at 12:08 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> On Mon, Mar 24, 2014 at 4:57 PM, Justin du coeur wrote:
>>
>>> Yep, that's roughly the design I'm thinking of, with the addition that
>>> the Mana
On Mon, Mar 24, 2014 at 12:08 PM, Patrik Nordwall wrote:
> On Mon, Mar 24, 2014 at 4:57 PM, Justin du coeur wrote:
>>
>> Yep, that's roughly the design I'm thinking of, with the addition that
>> the Manager keeps track of when it most recently received a message for
>> each Aggregate, and has a s
On Sat, Mar 22, 2014 at 1:43 PM, Kallin Nagelberg <
kallin.nagelb...@gmail.com> wrote:
> Thanks for the answer Patrik :)
>
Actually, that one was me, not Patrik. Threads getting tangled in the
email.
> You're actually cluing into what I'm really interested in here; creating a
> highly scalable
On Mon, Mar 24, 2014 at 4:57 PM, Justin du coeur wrote:
> On Sat, Mar 22, 2014 at 2:48 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> 22 mar 2014 kl. 03:03 skrev Justin du coeur :
>>
>> Now I want these Conversations to time out, with the Manager shutting
>> down the child after s
Nice!
On Mon, Mar 24, 2014 at 4:55 PM, Boris Capitanu wrote:
> Anyway, one thing to try is to set "akka.remote.backoff-interval" to a
>> larger value while setting the send-buffer-size to 1024000b. I would try
>> with backoffs 0.5s and 1s. While 1s is not a very good setting, it is a
>> good wa
>
> Anyway, one thing to try is to set "akka.remote.backoff-interval" to a
> larger value while setting the send-buffer-size to 1024000b. I would try
> with backoffs 0.5s and 1s. While 1s is not a very good setting, it is a
> good way to test our hypothesis.
>
I've used the backoff-interval =
On Sat, Mar 22, 2014 at 2:48 PM, Patrik Nordwall
wrote:
> 22 mar 2014 kl. 03:03 skrev Justin du coeur :
>
> Now I want these Conversations to time out, with the Manager shutting down
> the child after some period of inactivity. Is there an established trait
> for managing this?
>
> Not that I kno
Oops... I meant the second "for" was supposed to be "for j = 1 to i" (not
to N) :-)
--
>> 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.g
Hi Boris,
On Mon, Mar 24, 2014 at 4:19 PM, Boris Capitanu wrote:
> Thank you, Patrik.
>
> I think you hit the nail in the head with that ticket. I wanted to write
> earlier that this felt like behavior you see when you have two nested "for"
> loops:
>
> for i = N to 1
> for j = 1 to N
>
On Mon, Mar 24, 2014 at 4:02 PM, Boris Capitanu wrote:
> Hi Endre,
>
> My preliminary tests playing with the following settings show no
> improvement (but in some cases even worse performance):
>
> send-buffer-size = X
> server-socket-worker-pool = {
> pool-size-min = Y
>
Hi Boris,
Thank you for trying out! Patrik I think figured out the reason (described
in the ticket). This is very much related to backpressure since the
messages get piling up in the EndpointWriter which continuosly stashes and
unstashes an ever growing amount of messages (gets to O(n^2) eventuall
Thank you, Patrik.
I think you hit the nail in the head with that ticket. I wanted to write
earlier that this felt like behavior you see when you have two nested "for"
loops:
for i = N to 1
for j = 1 to N
do_something
The stash-unstash cycle you pointed out effectively behaves like the
Great, thanks guys for pointing me in the right direction!
On Monday, March 24, 2014 10:53:23 AM UTC-4, Patrik Nordwall wrote:
>
> The big difference is that when using akka-persistence the messages are
> not stored immediately when placed in the mailbox. When you receive the
> Persistent messag
Hi Endre,
My preliminary tests playing with the following settings show no
improvement (but in some cases even worse performance):
send-buffer-size = X
server-socket-worker-pool = {
pool-size-min = Y
pool-size-max = Y
}
client-socket-worker-pool = {
I have created the ticket that I still think is valid:
https://www.assembla.com/spaces/akka/tickets/3960
/Patrik
On Mon, Mar 24, 2014 at 3:17 PM, Akka Team wrote:
> Hi Boris,
>
> I'll test the settings that Endre pointed out and see what difference
>> those settings make.
>>
>
> Please report
The big difference is that when using akka-persistence the messages are not
stored immediately when placed in the mailbox. When you receive the
Persistent message in the Processor you know that it has been stored. The
sender can let go of the responsibility when it has received an explicit
acknowle
Hi Jan,
You can have only one persistence plugin per system so if you implement an
SQL based storage plugin it will be shared by all persistent components. It
might be a working solution to have a plugin that delegates to an
"ordinary" storage for normal messages, and stores a specific subset of
m
Hi Logan,
I took a look into the akka-persistence documentation and from what I can
> gather the goal of the project is to store processed messages so that an
> actor's state can be rebuilt upon an actor's restart, while I'd like to
> store unprocessed messages so they can be processed upon an ac
Hello,
I was looking to use durable mailboxes in a new akka project. Looking
through the documentation, it appears these have been dropped in favour of
akka-persistence.
I took a look into the akka-persistence documentation and from what I can
gather the goal of the project is to store process
Hi Boris,
I'll test the settings that Endre pointed out and see what difference those
> settings make.
>
Please report back what you have found. Also, I forgot to mention, but
there is another setting that controls the thread-pool (dispatcher) for the
remoting subsystem (this is independent of th
Is it "normal" to create a custom journal and snapshot mechanism for
prespecified messages? Or should journal and snapshot implementations be
generic -- that is, they should be able to handle any type of message and state
- much like the default leveldb one?
--
>> Read the docs: h
Is it "normal" to create a custom journal and snapshot mechanism for
prespecified messages? Or should journal and snapshot implementations be
generic -- that is, they should be able to handle any type of message and state
- much like the default leveldb one?
--
>> Read the docs: h
> Neither networked nor multithreaded applications have constant
> performance. Thread scheduling artifacts, cache effects, timing issues in
> handoffs, network congestion, retransmissions etc.
>
Yes, that all makes sense... except that the network congestion and
retransmission part should no
Bumping this, but I'll add a question about backpressure. For a new TCP
project, would you still recommend Akka IO over say Akka + Netty given that
Pipelines is deprecated and reactive streams is not ready?
On Fri, Mar 21, 2014 at 8:42 PM, Richard Rodseth wrote:
> I've never done any sort of TC
Happy hAkking!
On Mon, Mar 24, 2014 at 1:06 PM, Roger Varley
wrote:
> Doh! Why didn't I think of that :) Thanks Viktor.
>
>
>
> On Monday, March 24, 2014 11:45:45 AM UTC+2, √ wrote:
>
>> Hi Roger,
>>
>> what about creating and registering as handler, an Actor that first
>> delegates to the handl
Doh! Why didn't I think of that :) Thanks Viktor.
On Monday, March 24, 2014 11:45:45 AM UTC+2, √ wrote:
>
> Hi Roger,
>
> what about creating and registering as handler, an Actor that first
> delegates to the handler you are using now, and then switches over to
> another actor later?
>
>
>
>
>
Oh, yeah I can see that as a valid reason to reuse an id I guess - if
that's the apps requirements.
If one would want to have multiple users with the same username, an simple
id could be appended to the username I guess - both flows easily supported
by akka-persistence :-)
--
Cheers,
Konrad Malaw
Hi Roger,
what about creating and registering as handler, an Actor that first
delegates to the handler you are using now, and then switches over to
another actor later?
On Mon, Mar 24, 2014 at 10:33 AM, Roger Varley
wrote:
> Hi
>
> I'm just starting to create a client/server app using Akka TCP
Hi
I'm just starting to create a client/server app using Akka TCP over a
socket. I've got it basically working, but what I want to know is, once
I've registered a handler with the Server socket with
TcpMessage,register(), can I change the handler by issuing a second
TcpMessage.register() messa
On Mon, Mar 24, 2014 at 8:30 AM, Patrik Nordwall
wrote:
> Hi Boris,
>
> Thanks for packing it in a reproducible sample. As Viktor points out the
> Java serializer is one of the prime suspect for bottlenecks in remote
> communication. Here you have found something that I think can be improved
> in
Neither networked nor multithreaded applications have constant performance.
Thread scheduling artifacts, cache effects, timing issues in handoffs,
network congestion, retransmissions etc.
My suggestion is to take out the known slow parts first. Then measure and
tune.
On Mar 24, 2014 8:31 AM, "Bori
On Sun, Mar 23, 2014 at 11:06 AM, Raymond Roestenburg <
raymond.roestenb...@gmail.com> wrote:
> There is no support yet for attachments in akka-camel. There is already a
> ticket for it: https://www.assembla.com/spaces/akka/tickets/1214
> I'm planning to start working on this (finally) this week.
Hi Jan,
On Sun, Mar 23, 2014 at 12:38 PM, Jan Vincent Liwanag
wrote:
> Consider an actor 'BankAccount' which receives messages:
>
>
>- Deposit(amount, branchName, time)
>- Withdraw(amount, branchName, time)
>- GetBalance
>
> Within the actor, I only keep the balance as part of the sta
Konrad,
Got it; thanks.
A use case that comes to my mind is user registration: There's a
UserProfile actor, of course with a unique username, 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
>
>
> Then you are likely to benchmark the slowness of Java Serialization.
>
>
Viktor, thank you for your feedback. I'm not convinced the serializer is
at fault with this. Regardless of how inefficient the serializer is, it
should not take a variable amount of time to serialize identical objec
Hi Boris,
Thanks for packing it in a reproducible sample. As Viktor points out the
Java serializer is one of the prime suspect for bottlenecks in remote
communication. Here you have found something that I think can be improved
in Akka remoting.
I can see that major time is consumed in EndpointWri
42 matches
Mail list logo
