Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 21 16:16
    dependabot[bot] labeled #5285
  • Sep 21 16:16
    dependabot[bot] opened #5285
  • Sep 21 16:16

    dependabot[bot] on nuget

    Bump Fsharp.Core from 5.0.2 to … (compare)

  • Sep 20 18:36
    Zetanova commented #5230
  • Sep 20 18:18
    Zetanova commented #5230
  • Sep 20 16:06
    to11mtm commented #5230
  • Sep 20 15:24
    Aaronontheweb commented #5230
  • Sep 20 14:15
    to11mtm commented #5230
  • Sep 20 13:56
    tcs-devel commented #3261
  • Sep 18 08:45
    Zetanova commented #5152
  • Sep 18 07:37
    Zetanova synchronize #5152
  • Sep 18 07:15
    Zetanova commented #5273
  • Sep 18 05:12
    Zetanova synchronize #5273
  • Sep 18 04:51
    Zetanova synchronize #5273
  • Sep 17 16:56
    Aaronontheweb commented #5273
  • Sep 17 08:49
    Zetanova review_requested #5273
  • Sep 17 03:30
    Zetanova synchronize #5273
  • Sep 17 02:41
    Zetanova commented #5273
  • Sep 17 00:44
    Arkatufus closed #5284
  • Sep 16 21:14
    Arkatufus opened #5284
Bartosz Sypytkowski
@Horusiath
@Zetanova you could use stashing + round robin instead of smallest mailbox router?
Andreas Dirnberger
@Zetanova
I am currently using only create-child, send command + process, send response, stop
I would need something for the query-actors, if the load goes up they need to throutle quit a bit
Bart de Boer
@boekabart
@Horusiath I haven't [created protected constructor], but do I understand correctly that akka [default serializer] can only serialize 'custom' exceptions that I've explicitly decorated to be serializable? (and if yes, will Wire fix this?)
Bartosz Sypytkowski
@Horusiath
you could probably create demand driven pub/sub, so each subscriber must inform publisher/router that it's ready to receive the message (personally I've never used routers in production app)
@boekabart .NET have its own way of serializing exceptions based on protected constructor an ISerializable interface. All serializers wanting to serialize/deserialize exception, must work with that.
Andreas Dirnberger
@Zetanova
@Horusiath Then i will not use them :)
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