Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 21 18:54
    peirens-bart closed #4095
  • Oct 21 18:46
    Aaronontheweb closed #5310
  • Oct 21 18:16

    Aaronontheweb on dev

    Bump Akka.MultiNode.TestAdapter… (compare)

  • Oct 21 18:16

    Aaronontheweb on nuget

    (compare)

  • Oct 21 18:16
    Aaronontheweb closed #5335
  • Oct 21 16:10

    dependabot[bot] on nuget

    (compare)

  • Oct 21 16:10
    dependabot[bot] closed #5299
  • Oct 21 16:10
    dependabot[bot] commented #5299
  • Oct 21 16:10
    dependabot[bot] labeled #5336
  • Oct 21 16:10
    dependabot[bot] opened #5336
  • Oct 21 16:10

    dependabot[bot] on nuget

    Bump Google.Protobuf from 3.17.… (compare)

  • Oct 21 16:10
    dependabot[bot] labeled #5335
  • Oct 21 16:10

    dependabot[bot] on nuget

    Bump Akka.MultiNode.TestAdapter… (compare)

  • Oct 21 16:10
    dependabot[bot] opened #5335
  • Oct 21 13:18

    Aaronontheweb on dev

    Fix DefaultResizer for suspende… (compare)

  • Oct 21 13:18
    Aaronontheweb closed #5333
  • Oct 21 13:18
    Aaronontheweb closed #5327
  • Oct 21 13:17
    Aaronontheweb labeled #5334
  • Oct 21 13:17
    Aaronontheweb labeled #5334
  • Oct 21 13:17
    Aaronontheweb opened #5334
carnogursky
@carnogursky
Hi, please, could someone advise how to implement SSL certificates to the TCP communication (Akka.IO)?
Bartosz Sypytkowski
@Horusiath
@carnogursky I'm working on it. The closest approach would be to implement DotNetty's style TlsHandler as akka actor
carnogursky
@carnogursky
@Horusiath Thank you. Please, could you give me some more detailed hint? I do not know how TslHandler in DotNetty works...
Bartosz Sypytkowski
@Horusiath
@carnogursky this is a pretty complex stuff, I'm not sure if you want to dig deep into it. TLS needs its handshaking and secure stream handled - so far, only mature API for SSL in .NET is SslStream. However in akka actors and IO streams talks via ByteString. Because of that we need an adapter stream between actor and SslStream.
carnogursky
@carnogursky
@Horusiath It looks like DotNetty has a solution, which can be implemented easier? Had checked theis examples of server, you suggested it coulf be implemented as Actor?
Bartosz Sypytkowski
@Horusiath
DotNetty has a solution, but it's easier only if you want to use DotNetty directly
Jalal EL-SHAER
@jalchr
@Horusiath in DistributedData ... why would a 'Get' operation throw exception rather than returning null for a specific key ?
2017-10-09 01:17:37,203 [71] ERROR Akka.Actor.OneForOneStrategy - One or more errors occurred.
System.AggregateException: One or more errors occurred. ---> Akka.DistributedData.DataDeletedException: Cannot retrieve data under key [146324.mpg]. It has been permanently deleted and the key cannot be reused.
   at Akka.DistributedData.DistributedData.<GetAsync>d__13`1.MoveNext()
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at System.Threading.Tasks.Task`1.get_Result()
   at Archive.VideoProcessing.Akka.VideoProviderWatcherActor.<Watch>b__10_4(FileFinished msg)
   at lambda_method(Closure , Object , Action`1 , Action`1 , Action`1 , Action`1 , Action`1 , Action`1 , Action`1 , Action`1 , Action`1 , Action`1 )
   at Akka.Tools.MatchHandler.PartialHandlerArgumentsCapture`11.Handle(T value)
   at Akka.Actor.ReceiveActor.ExecutePartialMessageHandler(Object message, PartialAction`1 partialAction)
   at Akka.Actor.ReceiveActor.OnReceive(Object message)
   at Akka.Actor.UntypedActor.Receive(Object message)
   at Akka.Actor.ActorBase.AroundReceive(Receive receive, Object message)
   at Akka.Actor.ActorCell.ReceiveMessage(Object message)
   at Akka.Actor.ActorCell.Invoke(Envelope envelope)
---> (Inner Exception #0) Akka.DistributedData.DataDeletedException: Cannot retrieve data under key [146324.mpg]. It has been permanently deleted and the key cannot be reused.
   at Akka.DistributedData.DistributedData.<GetAsync>d__13`1.MoveNext()<---
Stijn Herreman
@stijnherreman
@alexvaluyskiy any idea if it's possible to have packages that can target netstandard1.6 (like Akka.Remote), additionally also target netstandard2.0? The NETStandard.Library 1.6 package is a meta package and suffers from dependency bloat (few dozen dependencies), this was fixed in the 2.0 package. Since my application targets net461, I managed to work around this by first manually installing NETStandard.Library 2.0 and then updating Akka.Remote.
But probably not every users realises they can do this, so perhaps it's possible to help them out. I'm not sure though if NuGet is smart enough to pick the highest possible target, when installing a package (e.g. it should pick netstandard2.0 if possible, over netstandard1.6)
Bartosz Sypytkowski
@Horusiath
@jalchr
  1. null should be returned in v1.3.1
  2. DistributedData methods are meant to be used outside actor context, inside actors using traditional message passing is a lot faster. Also message based API is bigger and gives more power i.e. you can subscribe to receive updates of target CRDT as they come.
  3. Keep in mind that DistributedData is not meant for high volume of data. If you want to use it for message delivery, you may eventually run out of memory.
Jalal EL-SHAER
@jalchr
@Horusiath I'm using DistributedData to track state across multiple nodes that share same 'file processing'. I'm using it like a "Shared Dictionary". So its a kind of acknowledgement at the business level. The processing of files takes time, so performance is not an issue.
When you say "run-out-of-memory", do you mean that state is never cleaned ? I'm ensuring that I remove everything that is marked as "done processing". Are we safe ?
OysteinKoppang
@OysteinKoppang

Hi. I'm trying to secure a akka.net remote system with the new SSL support.

There are two actor systems, that both talk to each other with remote actor selections.

System A's config:

remote {
  dot-netty.tcp {
    port = 11293
    hostname = "127.0.0.1"
    enable-ssl = true
    maximum-frame-size = 4000000b
    ssl {
      suppress-validation = true
        certificate {
          path = "C:\\foo\\bar.pfx" 
          password = "baz"
          flags = ["user-key-set"]
        }
    }
  }
}

System B's config:

"remote": {
  "dot-netty.tcp": {
    "port": 11292,
    "hostname": "127.0.0.1",
    "enable-ssl": true,
    "maximum-frame-size": "4000000b",
    "ssl": {
      "suppress-validation": true,
      "certificate": {
        "path": "C:\\foo\\bar.pfx",
        "password": "baz",
        "flags": [ "user-key-set" ]
      }
    }
  }
}

When system B tries to do an actor selection using the address:
akka.ssl.tcp://FooSystem@127.0.0.1:11293/user/FooActor

An error is thrown:
'No transport is loaded for protocol: [akka.ssl.tcp], available protocols: [akka.tcp]'

Any ideas why this is happening?

Aaron Stannard
@Aaronontheweb
weird
no idea offhand
would you please file an issue? We'll try to reproduce it
Arturo Sevilla
@arturosevilla
Hi, I've introduced a behavioral change in the Serilog adapter, which I believe is currently inconsistent with the docs, and now is more ad-hoc with how you expect a logger to behave, could someone care to comment on this change? akkadotnet/Akka.Logger.Serilog#33
Deniz İrgin
@Blind-Striker

hi, we updated our applications akka version from 1.1.3 to 1.3.1 and change helios to dot-netty.tcp. We also updated Akka.Serialization.Hyperion from 1.1.3.32-beta to 1.3.1-beta.

After we started our cluster we getting error below ;

Cannot find serializer with id [9]. The most probable reason is that the configuration entry 'akka.actor.serializers' is not in sync between the two systems.

        serializers {
          hyperion = "Akka.Serialization.HyperionSerializer, Akka.Serialization.Hyperion"
        }

        serialization-bindings {
         "System.Object" = hyperion
        }
Bartosz Sypytkowski
@Horusiath
@Blind-Striker serializerId=9 is by default used by distributed pub sub message serializer. Check if you for sure added fallback to DistributedPubSub.DefaultConfig()
Deniz İrgin
@Blind-Striker
@Horusiath Where should we add this configuration. We using hocon for configuring our applications
Bartosz Sypytkowski
@Horusiath
you can put it as a fallback right before sending configuration to actor system
murat mert
@muratmert
@Blind-Striker can you add actor config section ?
Deniz İrgin
@Blind-Striker
So do i need to add this lines before creating actor system ;
  var section = (AkkaConfigurationSection)ConfigurationManager.GetSection("akka");
        var clusterConfig = section.AkkaConfig;
        clusterConfig.WithFallback(DistributedPubSub.DefaultConfig());

        _actorSystem = ActorSystem.Create("notificationSystem", clusterConfig);
@muratmert i have 3 different nodes
Deniz İrgin
@Blind-Striker
@Horusiath we added DistributedPubSub.DefaultConfig() as fallback but we still getting same error
Stijn Herreman
@stijnherreman
I have an actor that needs to handle one type of message only, RetrieveFoo, to retrieve a resource from a REST API. Once the resource is retrieved, it is cached indefinitely. Is this a good case for using async/await (and thus blocking the actor), or should I still attempt to use PipeTo and keep track in some way of RetrieveFoo messages that need to be responded to?
I want to avoid multiple requests to retrieve the resource.
Stijn Herreman
@stijnherreman
After thinking about this some more, I think I can just store a task in a variable when receiving the first message and use PipeTo, and then for all subsequent messages skip creating the task and just use PipeTo on the existing task. That should work even when the task is completed already.
Stijn Herreman
@stijnherreman
I came up with the following (initial) implementation. It feels a bit awkward to use ContinueWith but maybe that's of my habit to use async/await.
    public sealed class Specification
        : ReceiveActor
    {
        private readonly IClient specsDataServiceClient;

        private Task<Messages.Models.Specification> modelTask;

        public Specification(IClient specsDataServiceClient)
        {
            this.specsDataServiceClient = specsDataServiceClient ?? throw new ArgumentNullException(nameof(specsDataServiceClient));

            this.Receive<GetSpecification>(message => this.GetSpecification(message));
        }

        private void GetSpecification(GetSpecification message)
        {
            if (modelTask == null)
            {
                var getSpecificationTask = this.specsDataServiceClient.Specification_GetSpecificationAsync(message.SpecificationId);
                var getOperationsTask = this.specsDataServiceClient.Operations_GetOperationsForSpecIdAsync(message.SpecificationId);
                var getTestsTask = this.specsDataServiceClient.Test_GetTestsForSpecIdAsync(message.SpecificationId);

                var modelTask = Task.WhenAll(getSpecificationTask, getOperationsTask, getTestsTask)
                    .ContinueWith(_ =>
                    {
                        return new Messages.Models.Specification(getSpecificationTask.Result, getOperationsTask.Result, getTestsTask.Result);
                    });
            }

            var senderClosure = this.Sender;
            modelTask.PipeTo(senderClosure);
        }
    }
Arsene
@Tochemey
@stijnherreman Since you are using Actor if it is possible simply use the synchronous version of your function call.
@stijnherreman Also if you can explain in details what you want to do I can be of a help.
Stijn Herreman
@stijnherreman
@Tochemey no sync versions available unfortunately. The IClient implementation code is generated by a third-party tool, from an OpenAPI (Swagger) spec.
Arsene
@Tochemey
@stijnherreman Okay
Stijn Herreman
@stijnherreman
I was reading http://gigi.nullneuron.net/gigilabs/asynchronous-and-concurrent-processing-in-akka-net-actors/ (and the previous article), about using ReceiveAsync or using PipeTo.
Arsene
@Tochemey
@stijnherreman That is cool
Stijn Herreman
@stijnherreman
Basically, the actor is responsible for retrieving a REST resource and supplying it back to whoever asked for it. But it should only ever retrieve the resource once, and then respond with the cached resource.
Arsene
@Tochemey
@stijnherreman From the Rest API controller use Ask<> to send the message to the Actor.
Stijn Herreman
@stijnherreman
@Tochemey ok, I'll take a look at that. I had previously read that Ask<> should be avoided, but to be honest I haven't taken a proper look at it yet.
Thank you :)
Arsene
@Tochemey
Then within the Actor where you are doing async stuff use:
CheckAsync().ContinueWith(task =>
                                {
                                    var response = task.Result;
                                    return response;
                                },
                                TaskContinuationOptions.AttachedToParent &
                                TaskContinuationOptions.ExecuteSynchronously).PipeTo(
                                closure);
@stijnherreman I have a production app using Rest API and Akka.NET
@stijnherreman CheckAsync() is a function that is running asynchronously.
@stijnherreman closure = Sender
Stijn Herreman
@stijnherreman
I'll read the article, it looks like a good resource.
Arsene
@Tochemey
@stijnherreman These articles have helped to be grounded in the Ask/PipeTo pattern
Arjen Smits
@Danthar
@stijnherreman avoid ask if you can. In your scenario. Why not use the Become feature.
So you receive a request for your REST data. You detect that you dont have it in cache
Arsene
@Tochemey
@Danthar from REST API controller I think Ask is the best bet.