Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 16:52
    Aaronontheweb commented #4989
  • 16:17
    dependabot[bot] labeled #5283
  • 16:17
    dependabot[bot] opened #5283
  • 16:17

    dependabot[bot] on nuget

    Bump Google.Protobuf from 3.17.… (compare)

  • 16:07
    Arkatufus synchronize #5282
  • 16:07
    Arkatufus opened #5282
  • 15:10
    Arkatufus opened #5281
  • 14:28
    Martin-Molinero commented #4989
  • 13:30
    Aaronontheweb commented #4989
  • 13:30
    Aaronontheweb milestoned #5279
  • 13:30

    Aaronontheweb on dev

    Add backward compatibility to P… (compare)

  • 13:30
    Aaronontheweb closed #5280
  • 13:30
    Aaronontheweb closed #5279
  • Sep 15 23:25
    Arkatufus synchronize #5280
  • Sep 15 23:13
    Arkatufus synchronize #5280
  • Sep 15 23:13
    Arkatufus opened #5280
  • Sep 15 22:46
    Arkatufus labeled #5279
  • Sep 15 22:46
    Arkatufus unlabeled #5279
  • Sep 15 22:46
    Arkatufus labeled #5279
  • Sep 15 22:46
    Arkatufus opened #5279
Bart de Boer
@boekabart
What I notice, is that my poco with a long and an exception will serialize fine if exception==null, but not if it's populated with eg. new Exception("boomcrash")
Andreas Dirnberger
@Zetanova
@boekabart yes, just create them, or map the exception to an ErrorInfo type, that is fully seriazlizable, I needed to do this for WCF and angularJS
Bart de Boer
@boekabart
That's what I was planning, indeed. just investigating all my use cases now to see what kind of info I need 'on the other side'
Thanks again for the help
Andreas Dirnberger
@Zetanova
@boekabart internaly are exception the best, but the going outside of the AppDomain it gets near allways problematic. Then it is better to map them.
Ralf
@Ralf1108
public static class ActorSystemExtensions
{
public static IEnumerable<object> QueryAllUserActors(this ActorSystem system, object message)
{
using (var inbox = Inbox.Create(system))
{
system.ActorSelection("user/*").Tell(message, inbox.Receiver);
            while (true)
            {
                object response;

                try
                {
                    response = inbox.Receive(TimeSpan.FromSeconds(1));
                }
                catch (TimeoutException)
                {
                    break;
                }

                yield return response;
            }
        }
    }
}
ups...
just for reference.. yesterday I tried to query all user actors. With help from here I got this and it works nice
`public static class ActorSystemExtensions
{
public static IEnumerable<object> QueryAllUserActors(this ActorSystem system, object message)
{
using (var inbox = Inbox.Create(system))
{
system.ActorSelection("user/*").Tell(message, inbox.Receiver);
            while (true)
            {
                object response;

                try
                {
                    response = inbox.Receive(TimeSpan.FromSeconds(1));
                }
                catch (TimeoutException)
                {
                    break;
                }

                yield return response;
            }
        }
    }
}`
cant get the code to be properly formatted
`public static class ActorSystemExtensions
{
public static IEnumerable<object> QueryAllUserActors(this ActorSystem system, object message)
{
using (var inbox = Inbox.Create(system))
{
system.ActorSelection("user/*").Tell(message, inbox.Receiver);
            while (true)
            {
                object response;

                try
                {
                    response = inbox.Receive(TimeSpan.FromSeconds(1));
                }
                catch (TimeoutException)
                {
                    break;
                }

                yield return response;
            }
        }
    }
}`
Ralf
@Ralf1108
I think yesterday I found a way to mark messages to not influence the RecieveTimeout of an actor
but i dont find it again
does anybody knows the way this worked? maybe an marker interface for the messag?
Ralf
@Ralf1108
ok.. searching through akka source didn't discover this. Maybe I only read this in a forum entry.
so as a new feature... does it make sense to support a marker interface for messages which doesn't influence the idle timeout of the actor which was set via "Context.SetReceiveTimeout()" ?
I am thinking about management messages like "GetStatistics". If an actor recieves that message he can answer that but it should not extend the idle timeout for passivate the actor
Andreas Dirnberger
@Zetanova
@Ralf1108 the ReceiveTimeout message should be only an event and not an command. The actor should "only" react to this event and so to check it's state
Ralf
@Ralf1108
yes but as I understand if I set a recieve timeout for an actor and the actor doesn't recieve any other message in this time a "RecieveTimout" message is send to this actor by the scheduler
I use this "RecieveTimout" message to passivate the actor
now if I send only a management message to the actor I dont want it to extend the "RecieveTimeout" timespan.
Andreas Dirnberger
@Zetanova
@Ralf1108 yes, if you need to free the actor because of some pressure, implement a shutdown command, that u can send from the coordinator
if the actor can passivate it will, if not it will ignore the shutdown and receivetimeout
even if u ignore on command like GetStatistics for the receivetimeout, the sender of GetStatistics dont know if its alive or not, the coordinator would need to reply or start the actor
Chris Ochs
@gamemachine
Anyone have suggestions for a good azure setup for realtime/stateful/low latency apps?
Ralf
@Ralf1108
check this scenarios:

actor A
coordinator C

Scenario 1

  • A sets RecieveTimout(5 min)
  • A recieves no message in time
  • after 5 min scheduler send A "RecieveTimout" message
  • A sends "Passivate" message to coordinator
  • ...passivating is going on

Scenario 2

  • A sets RecieveTimout(5 min)
  • A has nothing to do for 4 min
  • A recieves a "management" message (should not influence RecieveTimout but now scheduler will extend RecieveTimout to 5 min again)
  • Passivating will be postponed to further 5 min -> Scenario 2 restarts
in scenario the passivating of the actor is postponed because there a unimportant management message
Andreas Dirnberger
@Zetanova
A sets RecieveTimout(1 min) => if(--retirement == 0) Passivate()
but i would even make on ReceiveTimeout: Self.Tell(Shutdown.Instance)
On Shutdown: if(CanPassivate) Passivate()
Ralf
@Ralf1108
so with the field "retirement " i have to handle this myself?
and when to increase the "retirement" counter? on each important message?
Andreas Dirnberger
@Zetanova
somehow to make some sort of Helper Classes that extends the actor with features
but i am not there jet by myself
Ralf
@Ralf1108
maybe my assumption was wrong. Is the RecieveTimeout canceled before each message is handled and I have to call "SetRecieveTimeout" everytime?
Andreas Dirnberger
@Zetanova
No, it is firing until u pass Null to it
Ralf
@Ralf1108
but if a message was handled the timeperiod is extendend to the value of the last "SetRecieveTimeout()"?
Andreas Dirnberger
@Zetanova
yes it will extened again but also mybe fired short before after the message
i am getting them in burts
and often delayed
Ralf
@Ralf1108
ok.. my idea was only to not extend the timeout period if message with specific marker interfaces were handled
Ralf
@Ralf1108
with "system.ActorSelection("user/*")" I only get the first hierarchy level of the actors
is there a way to specify all actors below users with all children?
and subchildren and grandchildren and so on ....
Vagif Abilov
@object
Hello, now with deprecation of PersistentViews I am a bit lost about capabilities to monitor state changes of persistent actors. We want to build a Web site that visualizes both journals and snapshots, i.e. it will display the flow of state changes across all actors (possibly also state snapshots). I've found a few examples using SingalR but they were limited to receiving events for some specific actors. But is there a way to receive system-wide state changes for persistent actors?
Bartosz Sypytkowski
@Horusiath
@Ralf1108 AFAIK there has been implemented marker interface to mark messages, which are not supposed to break receive timeout. However it may be not included in the latest release.
@object persistent views will be obsoleted in the favor of akka.persistence.query, which will allow to build streams on top of event journals - depending on the journal, you will be able to track mulitple different persistence ids with it
Vagif Abilov
@object
@Horusiath and until Persistence.Query is ported there is no built-in way to track persistence changes across multiple actors? Would you recommend reading journals and snapshots right from the physical data store (i.e. SQL Server) or there are less dirty ways?
Bartosz Sypytkowski
@Horusiath
there is persistent query mechanism for sql-based journals, standard message based, but I'm hoping to obsolete it once streams + persistence query will come out