Hi Alistair,
On Wed, Jan 22, 2014 at 9:31 AM, Alistair George
wrote:
> OK, so I think we're agreed that storage per remote node is bounded. The
> next question is whether the number of remote nodes is bounded.
>
>- In theory, yes: there are only a finite number of IP:port
>combinations
>
Hi Alistair,
On Wed, Jan 22, 2014 at 9:31 AM, Alistair George
wrote:
> OK, so I think we're agreed that storage per remote node is bounded.
>
No, as number of actors is not bounded. (You can go OOM from creating
enough actors locally)
> The next question is whether the number of remote nodes i
OK, so I think we're agreed that storage per remote node is bounded. The
next question is whether the number of remote nodes is bounded.
- In theory, yes: there are only a finite number of IP:port combinations
- In practice no: it's a very big number
- In my use case yes: I'm dealing wit
On Tue, Jan 21, 2014 at 7:50 PM, Alistair George wrote:
> My plan for this was to have a proxy for NodeB watch state in NodeA. In
> normal (connected) operation it just remembers the current watch states
> (Actor Ax is/isn't watching Actor By) and passes the messages on to NodeB.
> If disconnect
My plan for this was to have a proxy for NodeB watch state in NodeA. In
normal (connected) operation it just remembers the current watch states
(Actor Ax is/isn't watching Actor By) and passes the messages on to NodeB.
If disconnected it just remembers the watch state. On reconnect, it sends a
NodeA & NodeB are communicating
NodeB disappears (not acking)
NodeA still has things it needs to propagate to NodeB (watching actors on
that node etc), so they need to be buffered, also, if there are ordering
requirements it means that other things may not be transmitted/received
before other thing
I don't see where the unbounded buffer is needed. I'd be grateful for a bit
of explanation, especially since it looks like I'm going to have to
implement this stuff :)
On Tuesday, January 21, 2014 12:40:19 PM UTC, √ wrote:
>
> And it also introduces the need for unbounded buffering, i.e. memory
And it also introduces the need for unbounded buffering, i.e. memory leaks.
On Tue, Jan 21, 2014 at 1:01 PM, Akka Team wrote:
> Hi Alistair,
>
>
>
>
>>> I'm not sure this is desirable behaviour. I shouldn't have to restart a
>> process just to recover from a comms failure. After all, nothing in
Hi Alistair,
>> I'm not sure this is desirable behaviour. I shouldn't have to restart a
> process just to recover from a comms failure. After all, nothing in the
> process has failed, and it may be providing services to other clients that
> have not suffered any comms failure. They shouldn't ha
We respectfully disagree then. Akka's design in this regard is highly
deliberate.
On Jan 21, 2014 12:35 PM, "Alistair George"
wrote:
>
>
> On Tuesday, January 21, 2014 8:44:17 AM UTC, Akka Team wrote:
>>
>> Hi Alistair,
>>
>>
>> On Tue, Jan 21, 2014 at 8:38 AM, Alistair George wrote:
>>
>>> Hi Ak
On Tuesday, January 21, 2014 8:44:17 AM UTC, Akka Team wrote:
>
> Hi Alistair,
>
>
> On Tue, Jan 21, 2014 at 8:38 AM, Alistair George
>
> > wrote:
>
>> Hi Akka,
>>
>> Thanks for the reply. One question: if (in 2.3) a remote actor system
>> becomes permanently quarantined, what do I have to do
"At some point you just have to move on..."
On Jan 21, 2014 9:44 AM, "Akka Team" wrote:
> Hi Alistair,
>
>
> On Tue, Jan 21, 2014 at 8:38 AM, Alistair George <
> alistairgeor...@gmail.com> wrote:
>
>> Hi Akka,
>>
>> Thanks for the reply. One question: if (in 2.3) a remote actor system
>> becomes
Hi Alistair,
On Tue, Jan 21, 2014 at 8:38 AM, Alistair George
wrote:
> Hi Akka,
>
> Thanks for the reply. One question: if (in 2.3) a remote actor system
> becomes permanently quarantined, what do I have to do to re-establish
> communication once the comms problem is fixed?
>
First of all, quar
Hi Akka,
Thanks for the reply. One question: if (in 2.3) a remote actor system
becomes permanently quarantined, what do I have to do to re-establish
communication once the comms problem is fixed? Do I have to restart the
remote actor system? Or the local one? Or both?
Cheers
Alistair
On Mon
Hi Alistair,
On Thu, Jan 16, 2014 at 9:30 AM, Alistair George
wrote:
> If I set up a watch on a remote actor (one on a remote actor system) and
> the network between me and the remote system fails, I get a Terminated
> message almost immediately. In fact, the remote actor hasn't terminated,
>
T
On Thursday, January 16, 2014 8:42:45 AM UTC, Björn Antonsson wrote:
>
> Hi Alistair,
>
> On Thursday, 16 January 2014 at 09:30, Alistair George wrote:
>
> If I set up a watch on a remote actor (one on a remote actor system) and
> the network between me and the remote system fails, I get a Ter
Hi Alistair,
On Thursday, 16 January 2014 at 09:30, Alistair George wrote:
> If I set up a watch on a remote actor (one on a remote actor system) and the
> network between me and the remote system fails, I get a Terminated message
> almost immediately. In fact, the remote actor hasn't termin
If I set up a watch on a remote actor (one on a remote actor system) and
the network between me and the remote system fails, I get a Terminated
message almost immediately. In fact, the remote actor hasn't terminated,
and I can still use the ActorRef to send messages to it once comms are
restore
18 matches
Mail list logo
