Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 23:11
    Aaronontheweb commented #4128
  • 22:50
    Aaronontheweb synchronize #4128
  • 22:21
    Aaronontheweb synchronize #4128
  • 22:19
    Aaronontheweb synchronize #4128
  • 21:03
    Aaronontheweb synchronize #4128
  • 20:57
    Aaronontheweb synchronize #4128
  • 20:39
    dependabot-preview[bot] synchronize #3985
  • 20:39

    dependabot-preview[bot] on nuget

    Bump FsCheck.Xunit from 2.9.0 t… (compare)

  • 20:39
    dependabot-preview[bot] edited #3985
  • 20:39
    dependabot-preview[bot] synchronize #3986
  • 20:39

    dependabot-preview[bot] on nuget

    Bump NUnit from 3.6.1 to 3.12.0… (compare)

  • 20:39
    dependabot-preview[bot] synchronize #4066
  • 20:39

    dependabot-preview[bot] on nuget

    Bump FSharp.Quotations.Evaluato… (compare)

  • 20:38
    dependabot-preview[bot] synchronize #4149
  • 20:38
    dependabot-preview[bot] edited #3986
  • 20:38
    dependabot-preview[bot] edited #4066
  • 20:38

    dependabot-preview[bot] on nuget

    Bump Hyperion from 0.9.11 to 0.… (compare)

  • 20:38
    dependabot-preview[bot] edited #4149
  • 20:37
    dependabot-preview[bot] edited #4149
  • 20:37
    dependabot-preview[bot] edited #3986
Aaron Stannard
@Aaronontheweb
the ActorCell or mailbox maybe
ActorCell has the best information probably
if not there then overriding the AroundReceive base method
on your actors
Bart de Boer
@boekabart
The thing with AroundReceive is that... it's actually the moment of telling that's interesting as well
most interesting and consistent, as multiple Tells will always be in the right order then.
But Dispatcher can't have the hook as it handles entire mailboxes, and Monitoring , well, requires changes to each actor as well...
Going to look at Cell
Andrew Young
@ayoung
as far as you guys know, compatibility between nodes running in .NET Framework and .NET Core isn't a problem, right?
Cluster nodes, that is.
Bart de Boer
@boekabart
@ayoung IIRC it is not supported at all (serialization issues with at least one of the serializers)
Arjen Smits
@Danthar
@ayoung @boekabart Im not aware of any issues? If you use the same serializer on each side, it should not be an issue. Best approach would be to use protobuff all the way through.
/cc @alexvaluyskiy ?
Roman Golenok
@shersh
Guys, is Akka.IO ready for production?
I still see TBD in documantation for classes.
Alex Valuyskiy
@alexvaluyskiy
@shersh yes, it is ready. TBD is related only for XML Documentation, not for the API itself
Paweł Bańka
@pmbanka

Hi, I have a question related to Stash. I don't understand this piece of docs:

The IWithUnboundedStash interface implementation of PreRestart will call UnstashAll(), which is usually the desired behavior.

(http://getakka.net/articles/actors/receive-actor-api.html#stash) Does this happen automagically when I implementIWithUnboundedStash on my actor? Where is this logic defined? I can't find it...

yeah, seems like it, since BeforeIncarnated is a

Plugin behavior applied to underlying <paramref name="actor"/> instance before the actor is being recycled.

Paweł Bańka
@pmbanka
While I'm at it, another question - why is UntypedActor API "recommended for C# 7 users"? Because of better switch support?
Aaron Stannard
@Aaronontheweb
@shersh yep, we use it in our products
@pmbanka I still use ReceiveActor mostly myself
but yeah, C# 7 makes working with the UntypedActor much more bearable
but ReceiveActor can do things switch cannot, such as matching on generics
Paweł Bańka
@pmbanka
thanks @Aaronontheweb. The docs left me quite confused about the difference and whether one of them should be preferred (and why)
Bart de Boer
@boekabart
So is the bottom line that ReceiveActor is likely to be 'heavier' than necessary for C# 7 code?
Aaron Stannard
@Aaronontheweb
@pmbanka which page of the docs?
Paweł Bańka
@pmbanka
@Aaronontheweb the workflow was like that: 1) click http://getakka.net/articles/actors/receive-actor-api.html, start reading. It starts with actors, blah blah, then defining, props, all that jazz. Ok, but I see there is also another API. So I go to 2) http://getakka.net/articles/actors/untyped-actor-api.html, see the beginning is the same, scroll down, creating actors, props, etc. 3) realize that these APIs seem very similar, start hunting down what is the difference, notice OnReceive in one and pattern match in the other one 4) notice the info on top of UntypedActor API page about C# 7, confirming it is mostly about the switch (?)
I think it would be nice to put some section somewhere explainig why are there 2 different APIs, what is the difference and pros/cons
especially since googling akka.net receive actor vs untyped actor does not return anything about the why
Aaron Stannard
@Aaronontheweb
@pmbanka well then
I've been overdue for some technical blog posts on Petabridge's site
sounds like a good one lol
on the official website we mostly just try to give you an explanation for how things work
and what the different tools are meant to be used for
we don't editorialize them much
Stephen Newman
@goodisontoffee

Is there anyone out there that can help me get my head around the implications that leveraging persistence in an existing actor. I've changed the base class and am moving some "commands" over to the construct events, persist, process event pattern but am getting what "feels" like asynchronous processing of the event processing. Is it true to say that:

1) A message is received
2) Message is treated as a command and an event is created from the command
3) Persist is called supplying the event to persist and a handler to be invoked after successful persistence
4) Next message is pulled from the mailbox and processed
5) Persistence completes
6) Handler supplied in 3 is invoked with persisted event

That's how it feels, so I wonder if that is accurate, and is the fix to complete the moving over from messages to Commands/Events and it'll be okay.

Dave
@davenewza
Question around async methods which return data (to an Ask) and PipeTo: would using ContinueWith on faulted tasks be a reasonable way to 'catch' and handle exceptions thrown. Example:
            Receive<SomeRequest>(request =>
            {
                GetSomethingAsync(request)
                    .ContinueWith(t => new FailedResponse(t.Exception), TaskContinuationOptions.OnlyOnFaulted)
                    .PipeTo(Sender);
            });
Dave
@davenewza
if i try this, i get an empty Akka.Actor.Status.Failure message returned
Aaron Stannard
@Aaronontheweb
@davenewza ideally we should populate the exception into that Status.Failure message
part of the issue there though is that you'll never get anything on that PipeTo if the task succeeds normally I don't think
since PipeTo is continuing off of the OnlyOnFaulted Task
I have an example of what I usually do here...
// pipe the result of our markets to ourselves
            _exchangeFeedClient.HttpClient.Markets.GetProducts(cts.Token).ContinueWith<object>(tr =>
            {
                if (tr.IsCanceled || tr.IsFaulted)
                    return new Status.Failure(tr.Exception);
                return tr.Result;
            }).PipeTo(Self);
I have a catch-all continuation
that I use to handle any case
success or failure
and then my actor who receives this...
Receive<Status.Failure>(s =>
            {
                _currentRetryPolicy = _currentRetryPolicy.Retry(); // update the retry data
                _log.Warning(
                    "Request for list of exchange trade products timed out from {0}. Retrying in {1} seconds with {2} attempts remaining.",
                    _exchangeFeedClient.Endpoints.RestEndpointUri, _currentRetryPolicy.CurrentRetryInterval,
                    _currentRetryPolicy.RemainingAttempts);
                AcquireProductsFeed(_currentRetryPolicy.CurrentRetryInterval);
            }, failure => _currentRetryPolicy.CanRetry);

            Receive<Status.Failure>(s =>
            {
                _log.Error("ERROR: unable to contact exchange at {0} after {1} attempts. Aborting.",
                    _exchangeFeed.HttpClient.Endpoints.RestEndpointUri, _retryPolicyProvider.MaxNrOfAttempts);
                _currentRetryPolicy.Retry(); // throw a HopelessOperation exception on purpose
            }, failure => !_currentRetryPolicy.CanRetry);

            // Received data from the exchange API.
            Receive<ApiResult<IEnumerable<Product>>>(products =>
            {
                if (products.Status == HttpStatusCode.OK)
                {
                    _tradeProducts.AddRange(products.Result);
                    _log.Info("Received products from exchange: {0}", string.Join(",", _tradeProducts.Select(x => x.id)));
                    BecomePublishing();
                }
                else if (_currentRetryPolicy.CanRetry
                ) // something went wrong with our web request, but we have retry attempts remaining
                {
                    _currentRetryPolicy = _currentRetryPolicy.Retry(); // update the retry data
                    _log.Warning(
                        "Received error with our HTTP request ({0}): {1}. Retrying in {2} with {3} attempts left.",
                        products.Status, products.Message,
                        _currentRetryPolicy.CurrentRetryInterval, _currentRetryPolicy.RemainingAttempts);
                    AcquireProductsFeed(_currentRetryPolicy.CurrentRetryInterval);
                }
                else // web request failed, no retry attempts remaining
                {
                    _log.Error(
                        "ERROR: unable to contact exchange at {0} after {1} attempts. HTTP Status: {2}, Message: {3}. Aborting.",
                        _exchangeFeed.HttpClient.Endpoints.RestEndpointUri,
                        _retryPolicyProvider.MaxNrOfAttempts, products.Status, products.Message);
                    _currentRetryPolicy.Retry(); // throw a HopelessOperation exception on purpose
                }
            });
AcquireProductsFeed(_currentRetryPolicy.CurrentRetryInterval); causes me to re-run the task that failed
Aaron Stannard
@Aaronontheweb
and the _currentRetryPolicy thing is just a strategy class I wrote that implements various retry strategies