Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 05 17:21
    Aaronontheweb synchronize #4079
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb labeled #4084
  • Dec 05 17:20
    Aaronontheweb milestoned #4084
  • Dec 05 17:20

    Aaronontheweb on dev

    Remove string interpolation fro… (compare)

  • Dec 05 17:20
    Aaronontheweb closed #4084
  • Dec 05 17:20
    Aaronontheweb commented #4084
  • Dec 05 15:43
    ismaelhamed opened #4084
  • Dec 04 23:34

    Aaronontheweb on dev

    Made cleanup call thread-safe (… (compare)

  • Dec 04 23:34
    Aaronontheweb closed #4081
  • Dec 04 23:34
    Aaronontheweb closed #4020
  • Dec 04 19:08
    Aaronontheweb commented #4079
  • Dec 04 18:35
    maratoss review_requested #4079
  • Dec 04 18:26
    maratoss synchronize #4079
  • Dec 04 07:42
    jiyeongj edited #4083
  • Dec 04 06:45
    jiyeongj opened #4083
  • Dec 04 06:35
    dependabot-preview[bot] labeled #130
  • Dec 04 06:35
    dependabot-preview[bot] opened #130
  • Dec 04 06:35

    dependabot-preview[bot] on nuget

    Bump System.Data.SqlClient from… (compare)

  • Dec 03 19:10
    Aaronontheweb synchronize #4081
Roger Johansson
@rogeralsing
ah, that should probably be possible to solve using the surrogate mechanism now. eg. FSExpressionDecider (containing expressions) -> FSExpressionDeciderSurrogate containing expressions pre serialized by fs pickler and stored as a string base64 or whatever in the surrogate., then the other way around, turn the base64 string into expressions and recreate the FSExpressionDecider
Bartosz Sypytkowski
@Horusiath
yes, but still it will work only for special case (Deciders), while leaving potential hole for other types of messages using expressions
jcwrequests
@jcwrequests
@rogeralsing That is and awesome way to do diagrams and map system flow and that is definitely more useful the any UML diagram.
jcwrequests
@jcwrequests
@Aaronontheweb @rogeralsing @Horusiath @HCanber @stefansedich The DI patch is working even with the AutoFac. Currently I am putting together some examples using the containers. Currently I have implement examples with HashPool and one with Child Actors for @tomstaijen. I want to add a few more examples and clean things up a bit before putting in a proper PR. @tomstaijen If you are interested or can't wait for the PR you can check out the latest here
Roger Johansson
@rogeralsing
/all are we really handling supervision correctly when it comes to restarting children? e.g. lets say we have the structure a -> b -> c where c is stashable. and actor c throws, b supervises but escallate to a.. A decides to restart b, b will now recreate c and thus we loose any stashing as it is no longer the same c.. is this the behavior in jvm akka too?
Bartosz Sypytkowski
@Horusiath
I think we should remove scheduling functions from F# API, after new schedulers API they have basically no value added
Bartosz Sypytkowski
@Horusiath
also @HCanber what is the relation between Scheduler and Scheduler.Advanced? Some tips, when which of them should be used?
Aaron Stannard
@Aaronontheweb
@rogeralsing you mean is it the right behavior for an actor to kill off its children during restarts?
jcwrequests
@jcwrequests
@Aaronontheweb Do you think I should add more examples or do you think this is enough? Any Advice before I put in my PR. Thanks
Aaron Stannard
@Aaronontheweb
I think that's probably good @jcwrequests
Roger Johansson
@rogeralsing
@aaronontheweb, yes. It is always only the direct children of the decidung supervisor that restarts, grand* children are completely replaced
Not saying this is wrong, just checking if that is the expected behavior. It could be suprising if you have stashing and the actor throws and you loose all messages because the exception was escalated
Aaron Stannard
@Aaronontheweb
@rogeralsing I've thought that this is weird behavior too to be honest
Håkan Canberger
@HCanber
@Horusiath The operations directly under Scheduler only contains scheduling Tells, while Advanced contains scheduling actions.
Roger Johansson
@rogeralsing
Is there any way to show the build bot result in some other way? it is super duper spammy in the github notification log.. 75% buildbot events, 25% human interaction
spam.png
Bartosz Sypytkowski
@Horusiath
@rogeralsing :+1:
F# API, 40 lines to create actor system, define and create parent/child actors and define custom supervisor strategy
Bartosz Sypytkowski
@Horusiath
also after merging #732 I want to pull few more changes (including breaking one) before release
Bartosz Sypytkowski
@Horusiath
This message was deleted
jcwrequests
@jcwrequests
Bartosz Sypytkowski
@Horusiath
today I saw, that canonical akka-io has been integrated into core akka package
do you think, we should do so with our implementation?
Roger Johansson
@rogeralsing
Wasnt it always like that? Since they started akka.io?
Aaron Stannard
@Aaronontheweb
@rogeralsing I think I can configure the build bot not to comment
and have it use the status API
just changed it on the PR build configuration
it'll still comment on dev and master at the moment
going to see what it actually does :p
hahaha wow... every time we run the full SandCastle build we get about 110mbs worth of artifacts
that's a lot
Aaron Stannard
@Aaronontheweb
bah, not seeing the status show up
going to have to dick around with the configuration on TeamCity some more when I get back
Robert Mircea
@robertmircea
I am working on an async socket connection handling code using akka (somehow inspired from akka-io). What's the best way to communicate with the actor from a socket operation callback? For example, I want to inform the actor from socket callback when data was read or when connection broke.
Natan Vivo
@nvivo
@jcwrequests Got it, thanks.
jcwrequests
@jcwrequests
PR is has now been submitted to patch the DI implementation. akkadotnet/akka.net#733. I tried using the new Git For WIndows application for pull request. Seems to work nicely. @Aaronontheweb @rogeralsing @Horusiath @HCanber if I need to make any other changes or you need additional documentation just let me know.
Bartosz Sypytkowski
@Horusiath

@robertmircea I think your question is too general. Depending on what you want to get done, different solutions applies.

I was trying to port Akka.IO from JVM to .NET - I remember, that I've got serious problems with integrating akka threading model with async sockets (first tried a way similar to cannonical Akka, but Java NIO cannot be reflected directly in .NET) and that @Aaronontheweb already encouraged them when he was creating Helios, but I don't remember specifics

Robert Mircea
@robertmircea
@Horusiath I have this async socket receive code:
//this code is part of the actor
var receiveSaea = new SocketAsyncEventArgs();
                receiveSaea.Completed += ReceivedCompleted;
                receiveSaea.AcceptSocket = socket;
socket.ReceiveAsync(receiveSaea);
[...]

//later, this callback is called when socket read is completed
private void ReceivedCompleted(object sender, SocketAsyncEventArgs e)
{
    var connectionInfo = e.UserToken as ConnectionInfo;
    if (connectionInfo == null)
        throw new InvalidOperationException("Could not find a reference to ConnectionInfo");

    if (e.SocketError != SocketError.Success)
    {
        log.Error("IO error while receiving data over socket: " + e.SocketError);
        //TODO: I need to tell the calling actor to shutdown itself, but I cannot use Context.Stop(connectionInfo.Sender) here
        return;
    }
Basically I need to have somehow access to Context in order to stop the actor, but inside the callback Context is not available
ConnectionInfo contains an ActionRef to the actor.
I've skipped the instantiation code
Roger Johansson
@rogeralsing
There are a few options, 1) .net async api for a taskbased, (if socket does not have that, TPL provides helpers to convert old async events to task), and then use .PipeTo(Self) on that task.. 2) use a closure that binds a copy of Context in a local var.. 3) download the latest source and use our new TPL support
var context = Context;
var receiveSaea = new SocketAsyncEventArgs();
                receiveSaea.Completed += ReceivedCompleted;
                receiveSaea.AcceptSocket = socket;
socket.ReceiveAsync((sender,e) => {
 var connectionInfo = e.UserToken as ConnectionInfo;
    if (connectionInfo == null)
        throw new InvalidOperationException("Could not find a reference to ConnectionInfo");

    if (e.SocketError != SocketError.Success)
    {
        log.Error("IO error while receiving data over socket: " + e.SocketError);
        Context.Stop(connectionInfo.Sender)
        return;
    }
});
This message was deleted
This message was deleted
Robert Mircea
@robertmircea
is it ok to pass a reference to Context in ConnectionInfo?
Roger Johansson
@rogeralsing
yes, the context itself is threadsafe if you have a valid ref to it, it uses message passing internally to ensure thread safety.. so calling stop on it is ok
Robert Mircea
@robertmircea
I'll try that :)
Roger Johansson
@rogeralsing
but as you noticed, you can not access Context in a callback as the callback is not run in the actor concurrency constraint. but you can pass it as state to the callback
jcwrequests
@jcwrequests

@nvivo @Aaronontheweb I have been playing around with a few ideas dealing with calling Context.ActorOf<SomeActor>().Tell(message); from within an actor that was created using the DI Extension but that extension not being used by the extension method.

namespace Akka.Actor
{
     public static class ActorRefFactoryExtensions
     {
         public static ActorRef ActorOf<TActor>(this ActorRefFactory factory, string name = null) where TActor : ActorBase, new()
        {
            return factory.ActorOf(Props.Create<TActor>(), name: name);
        }
     }
 }

Every time I tried to make it transparent it just got messy. It's not to say it can't be done but I think it's not worth the effort. That being said I came up with my own prototype of an extension for the DI.Core that works but requires you to add the namespace which is kind of a compromise because @nvivo you were looking for something not requiring you to know that you are using the DI extension but I think it works. What do you think?

   public static ActorRef ActorOf<TActor>(this IActorContext context, string name = null) where TActor : ActorBase, new()
    {

        var producer = context.System.GetExtension<DIExt>();
        return context.ActorOf(producer.Props(typeof(TActor).Name),name);

    }

You still have to be careful but it turns this

   var producer = Context.System.GetExtension<DIExt>();
   Context.ActorOf(producer.Props("TypedWorker")).Tell(message);

Into this

  Context.ActorOf<TypedWorker>().Tell(message);