Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 07 11:49
    IgorFedchenko commented #4085
  • Dec 07 10:31
    IgorFedchenko commented #4085
  • Dec 07 08:36
    IgorFedchenko commented #4085
  • Dec 06 20:57
    IgorFedchenko commented #4085
  • Dec 06 20:32
    IgorFedchenko commented #4085
  • Dec 06 20:01
    IgorFedchenko commented #4085
  • Dec 06 19:55
    IgorFedchenko commented #4085
  • Dec 06 16:22
    Aaronontheweb labeled #3997
  • Dec 06 16:22
    Aaronontheweb closed #3997
  • Dec 06 16:20
    IgorFedchenko commented #3997
  • Dec 06 16:08
    IgorFedchenko commented #4085
  • Dec 06 15:50
    Aaronontheweb assigned #4085
  • Dec 06 15:50
    Aaronontheweb labeled #4085
  • Dec 06 15:50
    Aaronontheweb labeled #4085
  • Dec 06 15:49
    Aaronontheweb closed #4032
  • Dec 06 14:58
    IgorFedchenko commented #4032
  • Dec 06 14:57
    IgorFedchenko opened #4085
  • Dec 05 17:21
    Aaronontheweb synchronize #4079
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb labeled #4084
Bartosz Sypytkowski
@Horusiath
try setup auto-down, also AFAIK issue may be an order in which seed nodes are defined. @Aaronontheweb any ideas?
Jose Carlos Marquez
@oeaoaueaa
is it wrong to have "self" in the seed nodes?
Bartosz Sypytkowski
@Horusiath
no, it should be ok. But the problem with hanging join may be caused by some of the unreachable nodes not being marked as down, but @Aaronontheweb would need to confirm that
Aaron Stannard
@Aaronontheweb
after taking a look at the cluster code
think I found an issue
gotta confirm a behavioral thing real quick
it's an easy fix if it is what I think it is
looks like this issue comes up when a JoinSeedNodes operation starts and the InitJoin doesn't get delivered right away at startup (possible when two nodes try to connect to each other immediately)
we have a reliable delivery mechanism set up for that InitJoin command
but I just realized that it may not be implemented correctly due to how ReceiveTimeout works :(
setting up a reproduction test for this will be.... fun
have to guarantee that a specific message gets dropped the first time around :p
Aaron Stannard
@Aaronontheweb
Opened #2584
Damian Reeves
@DamianReeves
In TestKit, is there a way for me to expect a spcific message type without caring what messages came before it?
I see I can expect a specific message instance with ExpectMessageAnyOf
is FishForMessage what I'm looking for?
John Nicholas
@MrTortoise
lo, hows akka with .net core? can i do a local actor system in it?
simply want to prove it to a collegue pulling stuff from event store and wanging it into elastic
Arjen Smits
@Danthar
@MrTortoise .net core support is coming, soonish. If you scroll up you can find some people who have already worked with the stuff thats in the current dev branch. And we have the nightlies you can use.
John Nicholas
@MrTortoise
@Danthar thanks. will mooch
Graham Ambrose
@gambrose
@DamianReeves you can set an IgnoreMessages function to ignore any messages that you are not interested in, then ExpectMsg the message you want. This is what I do but... there maybe a better way.
Nick Chamberlain
@heynickc
@DamianReeves FishForMessage is also a viable option:
[Fact]
public void Expect_message_after_a_few()
{
    var actor = Sys.ActorOf(Props.Create(() => new EchoActor()));
    var probe = CreateTestProbe();
    actor.Tell("Yo!", probe.Ref);
    actor.Tell("Hey!", probe.Ref);
    actor.Tell("Wasup!", probe.Ref);
    actor.Tell("Hello!", probe.Ref);
    actor.Tell("Nevermind...", probe.Ref);

    probe.FishForMessage(msg => (string) msg == "Nevermind...");
}
Weston
@ronnyek
so I am interested in having akka.net handle tcp listening, taking the inbound messages and treating them as reactive streams
is the examples with the telnet listener technically akka.io stuff?
Bartosz Sypytkowski
@Horusiath
@ronnyek there's a simple example which uses akka.io actors. But once we fix everything related to akkadotnet/akka.net#2405 I think, that streams will be a much better approach
Weston
@ronnyek
will streams be able to listen on tcp or websockets or anything like that?
I thought streams solved different problems
any eta on 1.2?
months
ballpark
weeks
quarters =)
Deniz İrgin
@Blind-Striker
or ... When it’s done :P
Weston
@ronnyek
I realize its done when its done, but I dont know if I need to just wait for that because its around the corner
or if its a long ways off I need to investigate other stuffs
Ricky Blankenaufulland
@ZoolWay
Hi! Wanted to hear if you have situation where you need a class/recordtype which is mutating (changing state) and nearly the same class as immutable to send it through Akka messages. If I encounter this, is it a code smell, an anti-pattern? If not, how do you name both? Customer and CustomerMutating? CustomerImmutable and Customer? CustomerFrozenand CustomerState?
Deniz İrgin
@Blind-Striker
I just quoted from Blizzard :) we have similar issue too and waiting for 1.2
@ronnyek
Bartosz Sypytkowski
@Horusiath
ETA v1.2 was 2 days ago ;)
Aaron Stannard
@Aaronontheweb
@Horusiath are we still waiting on NuGet support for that? cc @Silv3rcircl3
Bartosz Sypytkowski
@Horusiath
@ronnyek Akka.Streams will expose listener interface
basically TCP connection handler will be represented as source/sink for the stream
Dmitri Pavlenkov
@dpavlenkov
@ZoolWay I would append Message to anything immutable and sendable
Ricky Blankenaufulland
@ZoolWay
@dpavlenkov You mean like an audit of changes? Feels like a bit of overkill if I just have user objects and their presence changes during the day.
Dmitri Pavlenkov
@dpavlenkov
The pattern is for services to own objects and to modify them exclusively, and to communicate through messages, even changes to them.
Or copy, I guess
Ricky Blankenaufulland
@ZoolWay
Hm, to replace my cached immutable Customer with a new immutable Customer instance where the change is reflected?
Weston
@ronnyek
@Horusiath so soonish
Dmitri Pavlenkov
@dpavlenkov
@ZoolWay yeah, much safer. Models are really messages
Ricky Blankenaufulland
@ZoolWay
Thanks for sharing. It seems unconventional but I feel there are some good advantages in this approach. I'll try out