Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:55
    Aaronontheweb opened #4273
  • 00:42
    Arkatufus synchronize #4253
  • 00:40
    Arkatufus commented #4253
  • 00:37
    Arkatufus synchronize #4253
  • 00:32
    Aaronontheweb synchronize #4270
  • 00:24
    Aaronontheweb milestoned #3735
  • 00:24
    Aaronontheweb demilestoned #3735
  • 00:24

    Aaronontheweb on dev

    unregister AppDomain.ProcessExi… (compare)

  • 00:24
    Aaronontheweb closed #3846
  • 00:24
    Aaronontheweb closed #3735
  • Feb 27 23:27
    Aaronontheweb edited #4272
  • Feb 27 23:27
    Aaronontheweb edited #4272
  • Feb 27 23:26
    Aaronontheweb opened #4272
  • Feb 27 23:14
    Aaronontheweb closed #2229
  • Feb 27 23:14
    Aaronontheweb commented #2229
  • Feb 27 23:14
    Aaronontheweb commented #3791
  • Feb 27 23:13
    Aaronontheweb closed #3791
  • Feb 27 23:13
    Aaronontheweb commented #3791
  • Feb 27 23:13
    Aaronontheweb demilestoned #4120
  • Feb 27 23:12
    Aaronontheweb labeled #4120
ilhadad
@ilhadad
@Horusiath Thanks for your help - we figured it out. The issue is related to the serialization/deserialize process! As it turns out if you have a dictionary of some object the object must have a default constructor. If it does not somehow the deserialization process fails. We even tried sending the message without the default constructor and that too also failed. SO... a default constructor is needed. Painful!
Bartosz Sypytkowski
@Horusiath
@ilhadad strange, I've got a lot of messages without default constructors and I'm pretty sure it was never an issue
ilhadad
@ilhadad
@Horusiath It also seems that the immutabledictionary cannot be sent over the wire while a regular dictionary is not a problem. Wierd. Can I use a regular dictionary?
Bartosz Sypytkowski
@Horusiath
yes, unless you modify it after putting into a message. If you have that risk, simply do .ToDictionary() call to create a copy of it.
ilhadad
@ilhadad
ok thanks for all your help.
morioma
@morioma

To handle remote disconnection I did something like this

signalRSelection = Context.ActorSelection("akka.tcp://api@127.0.0.1:4545/user/signalr");
signalRSelection.Tell(message);

So, I am forcing a Context.ActorSelection before tell. I am thinking this should work although there could be performance issue.
However, this doesn't seems to work all the time. (It works the first time the remote disconnected).
Anyway to do this kind of if(disconneted){ connect(); }?
(I am aware the watch for Terminated method. However, I have trouble finding the right time to ActorSelection again, because the remote could be still not available. )

morioma
@morioma
(I tried Cluster too, however, a bug regarding cluster broadcast group is prevent me to use it).
Vagif Abilov
@object
I've read recommendations to be extra careful when choosing serializer for persistent actors, and it makes sense - nobody wants past events to become unreadable. So I am rethinking our persistence serializer choice - we switched to Wire after Akka.NET 1.0.7 came with a warning that JSON.NET will be obsolete, but I am becoming more in favour of plain JSON documents that we will always be able to retrieve and parse into some internal type. So I am a bit confused with these recent Akka warnings about switching to Wire. Should we really? What will be the consequences for using JSON.NET? Or should we just use a different lib to read/write JSON documents?
Bartosz Sypytkowski
@Horusiath
@object general advise here is to have separate serializers for inter-cluster communication and for persistence, as these two things have a different priorities. When it comes to JSON.NET - it's a nightmare for case of Akka.NET. It's very slow, has big memory footprint, and it's unreliable in many cases (especially F# data structures and some weird combinations of system.collections.immutable and surrogate mechanism).
Vagif Abilov
@object
@Horusiath so what would you recommend for persistence serializer to ensure long lifetime of encoded events? And if Json docs are OK what handles them better than JSON.NET?
Bartosz Sypytkowski
@Horusiath
it depends on you. Some people like to use json as format for event sourcing - I personally would choose it only when it has native support from database (i.e. postgres, mongodb, eventstore). Otherwise I would go for something schema-driven, like Protocol Buffers, MS Bond or Avro. But tbh it's a matter of personal opinion.
Vagif Abilov
@object
I see. I've been also looking at Protocol Buffers. And in case of Json ServiceStack seems to be quite fast. When it comes to language type support, I am drifting to a conclusion that we should say goodbye to fancy F# types as journal event types and instead use adapters (like some Scala Akka article suggests) to convert to representation close to serialization protocol.
Kris Schepers
@schepersk
Hmm, if a name my sql server persistence plugin something else then "sql-server", it doesn't seem to work.. Anyone else having this problem?
Kris Schepers
@schepersk
akka {
  persistence {
    journal {
      sql-server {
    class = "Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer"
    plugin-dispatcher = "akka.actor.default-dispatcher"
    connection-string = "Data Source=(local);Initial Catalog=HelloClusterSharding;Integrated Security=SSPI"
    connection-timeout = 30s
    schema-name = Sharding
    table-name = EventJournal
    auto-initialize = on
    timestamp-provider = "Akka.Persistence.Sql.Common.Journal.DefaultTimestampProvider, Akka.Persistence.Sql.Common"
    metadata-table-name = Metadata
      }
    }
  }
}
this works..
but when I replace the "sql-server" with something else, it doesn't..
Kris Schepers
@schepersk

I'm trying to use a different sql server persistence for cluster sharding.
I have my sharding config set up like this:

cluster {
  sharding {
    least-shard-allocation-strategy.rebalance-threshold = 3
    journal-plugin-id = "akka.persistence.journal.sql-server"
    snapshot-plugin-id = "akka.persistence.snapshot-store.sql-server"
  }
}

but I would like to replace the "sql-server" name with, let's say "sql-server-sharding"

Damian Reeves
@DamianReeves
If I'm starting a new green field project with Akka and F#, should I start with Akka.FSharp or should I go right to Akkling?
morioma
@morioma

To handle remote disconnection I did something like this

signalRSelection = Context.ActorSelection("akka.tcp://api@127.0.0.1:4545/user/signalr");
signalRSelection.Tell(message);

So, I am forcing a Context.ActorSelection before tell. I am thinking this should work although there could be performance issue.
However, this doesn't seems to work all the time. (It works the first time the remote disconnected).
Anyway to do this kind of if(disconneted){ connect(); }?
(I am aware the watch for Terminated method. However, I have trouble finding the right time to ActorSelection again, because the remote could be still not available. )

Association to [akka.tcp://api@127.0.0.1:4545] having UID [221449129] is irrecoverably failed. UID is now quarantined and all messages to this UID will be delivered to dead letters. Remote actorsystem must be restarted to recover from this situation.
It seems that the remote server is quarantined, is there a way to prevent the remote server being quarantined?

Bartosz Sypytkowski
@Horusiath
@schepersk currently journals are identified internally by their type - the workaround here is to create custom journal (i.e. inheriting from Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer) and replace it's type as a class name for configuration section used by cluster sharding
Boban
@bobanco

@morioma i would use the actor selection to get the remote actor ref once on example on Actor.PreStart() and watch for the termination of the remote actor, when the remote actor dies, you can introduce a behavior like Reconnecting/ Registering and schedule the reconnect within some interval like 5secs on example.

here is some code which comes out of my mind now:

        protected override void PreStart()
        {

            Context.Become(Registering());
            Self.Tell(new LookupForServiceProvider());//LookupForService provider is just a simple message to tell yourself to start the actor selection

        }

private UntypedReceive Registering()
        {
            return message =>
            {
                if (message is RegisteredToServiceProvider)
                {
                          var registered = (RegisteredToServiceProvider) message;
                    Console.WriteLine("Registered to the service provider, Path: {0}",registered.ServiceProviderRef.Path);

                     //do some useful things here, mb switch to a different behavior where you can operate normaly
                      Context.Watch(registered.ServiceProviderRef);
                    Context.Become(Registered(registered.ServiceProviderRef));
                 }
                  else if (message is UnableToRegister)
                {
                    // we are not able to connect now, try reconnect within some time, and also stay into the same behavior.
                    Context.System.Scheduler.ScheduleTellOnce(_lookupTimeout,Self, new LookupForServiceProvider(), Self);
                }
                 else if (message is LookupForServiceProvider)
                {
                    var self = Context.Self;
                    try
                    {
                        Context.ActorSelection(sericeProviderPath)
                            .ResolveOne(_lookupTimeout)
                            .ContinueWith<IServiceLookupResult>(x =>
                            {
                                try
                                {
                                    var serviceProvider = x.Result;
                                    return new RegisteredToServiceProvider(serviceProvider);

                                }
                                catch (AggregateException ex)
                                {
                                    return new UnableToRegister();
                                }
                            }).PipeTo(self);
                    }
                    catch (Exception)
                    {
                        Self.Tell(new UnableToRegister());
                    }
                }
        }
}

private UntypedReceive Registered(IActorRef serviceProvider)
        {
            return message =>
            {
                  if (message is Terminated)
                {
                    var terminated = (Terminated)message;
                    if (terminated.ActorRef.Equals(serviceProvider))
                    {

                        Context.Become(Registering());
                        Self.Tell(new LookupForServiceProvider());
                        Console.WriteLine("Message Service provider is down, auto reconnect in {0} secs.", _lookupTimeout.TotalSeconds);
                    }
               }
sorry for bad formatting, but i wrote the code directly here, hope this will help you
morioma
@morioma
@bobanco Thank you the method and the code. I will try it out :+1:
Kris Schepers
@schepersk
@Horusiath I see.. I thought I could avoid creating another custom plugin..
Kris Schepers
@schepersk
@Horusiath Also, inheriting from Akka.Persistence.SqlServer.Journal.SqlServerJournal, Akka.Persistence.SqlServer won't work because you can't replace the SqlServerJournalEngine where the settings are loaded..
Kris Schepers
@schepersk
Or am I missing something here?
Kris Schepers
@schepersk
@Horusiath Maybe I should also mention I want to use 2 flavours of sql-server persistence, one for the aggregate event stream, and another one for sharding persistence..
Vagif Abilov
@object
@Horusiath I agree with your remarks about my PR (#1900). Should I submit a new PR and close this one or there is another way?
Marc Piechura
@marcpiechura
@object you can change and push to your branch as you did before, this updates the PR automatically
no need for a new PR
Vagif Abilov
@object
@Silv3rcircl3 thanks!
qwoz
@qwoz
I'd like to send messages to actors on a schedule and I'd also like to persist this between system restarts. Has anybody come up with a clever solution to do that, taking into account when things were last run, when they're due to run again, etc.?
I'm aware of schedule tell... this is more about the restartable persistence aspect of it.
qwoz
@qwoz
The scenario if it helps: I'm building a reminder kind of service that anybody can use to remind them to do something and there could end up being tens of thousands of reminders at any time. The reminders might be for one message 20 minutes from now, might be every 5 minutes, might be every day at 8:03 AM, might be every last Friday of every second month at midnight. Accuracy isn't too important so if something is off by some number of seconds or minutes that's okay. But outages, restarts, etc. must not cause a reminder to be missed. Basically some kind of reliable cron daemon for actors.
Boban
@bobanco
@qwoz you can use Quartz.Net and Akka.NET to achieve that, as you said you could persist the incoming messages which will come to the actor manager, after message is persisted you could put into the quartz and you're done, now at the other side when you will do a recovery from restarts you could simply put back the reminders to the quartz or you can also achieve the same without akka persistence, but you will need to create your mechanism for storing the reminders to the disks or to the DB when they are created, and on restart you could overwrite the PreStart() method and start the recovery of the reminders yourself, basicly its really easy to achieve these kind of things with akka with writing just couple of lines code. :smile:
qwoz
@qwoz
Thanks @bobanco ... if I understand it correctly, you're suggesting that upon a system restart, I would need to explicitly recreate instances of all the reminder actors, and have each reminder actor be responsible for loading up Quartz with its own schedule? I looked into Quartz briefly and it seems to have its own persistence mechanism for schedules (to a DB, rather than its RAM-based store). Perhaps it's possible to hook into that mechanism to recreate an instance of the specific reminder actor whose schedule has triggered rather than going through what I assume would be a relatively expensive operation of iterating over every single instance just to load up Quartz again. Or am I misunderstanding?
Boban
@bobanco
@qwoz yes you can use quartz persistence as well, i haven't used quartz persistence so i can not give any info regarding how good is it, btw in this case you will just need a tiny wrapper on the quartz scheduler into single actor, you could even use akka cluster singleton tool and you can make sure that only 1 isntance is running trough the cluster if you are going on that way. Also quartz has support for clustering as well but based on my experience it doesn't work well, so if i were you i would go with akka cluster and quartz, so you will get the benefits of both worlds. But to summarize i would say it depends mostly on your requirements etc.
Maxim Cherednik
@maxcherednik

Hi guys,
updated recently to 1.0.7 and now I see quite strange behaviour from the cluster:

  1. There is a seed node and a worker node
  2. When worker node joins the cluster, I see this kind of logs on the seed node:
    [INFO][4/24/2016 12:22:21 PM][Thread 0016][[akka://riskengine/system/cluster/core/daemon]] Node [akka.tcp://riskengine@10.0.0.10:4053] is JOINING, roles [riskenginewidget]
    [INFO][4/24/2016 12:22:21 PM][Thread 0014][[akka://riskengine/system/cluster/core/daemon]] Leader is moving node [akka.tcp://riskengine@10.0.0.10:4053] to [Up]
    [INFO][4/24/2016 12:22:22 PM][Thread 0015][[akka://riskengine/system/cluster/core/daemon]] Leader is moving node [akka.tcp://riskengine@10.0.0.10:4053] to [Up]

This line: Leader is moving node... Sometimes I see it twice, sometimes 3 times. Is this expected?

Hyungho Ko
@hhko
Hi. I want to use Akka.Hocon nuget package for my project's config.
My project is also using Akka.NET nuget package.
Akka.Hocon is using the same namespaces and class names with Akka.NET.
so, Compiler generates ambiguous reference errors.
How to solve it? ]
Marc Piechura
@marcpiechura
@hhko if you use Akka you don't need the hocon package yet, we have an issue for this #1419
Hyungho Ko
@hhko
@Silv3rcircl3 Thank you for good information.
Section name is fixed on 'akka' in both Akka.NET and Akka.Hocon.
I think if it is not fixed, Akka.Hocon can be more flexible library.
Vladimir Sergienko
@vss1001
Hi gents, I have spent some time reviewing the options out there I am settled on using Akka.NET on my next project.
The one area that I have a question on at the moment relates to the security of over-the-web remoting.
Due to the nature of the application each client company's app instance will be running on its own VM with its own DB persistence for data that it is the "sole point of truth" however it will need to share parts of this data in real-time with an arbitrary and dynamically changing list of other company's app instances. I have to ensure that the communication between these app instances is secure but due to the dynamic interconnection I can't have predefined VPNs as suggested on http://getakka.net/docs/remoting/security . I am planning on deploying the app instances on ASP.NET Core RC1 on Ubuntu docker containers, is Akka.NET port to .net Core anywhere close to reliable or should I target Mono/ some other key recommendations?
Any suggestions on how I can ensure communication encryption / security for remote messages? Is it possible or viable at the moment to use DotNetty with Akka.NET instead of Helios to take advantage of TLS?
Toshko Andreev
@Ravenheart
greetings guys
how do i remove Json.NET as the defaul serializer
i'm following the bootcamp tutorials
and everything works OK, but theres a warning that json.net will be removed as default serialzier soon
Marc Piechura
@marcpiechura
@Ravenheart it's explained in the docs here
Marc Piechura
@marcpiechura
@vss1001 we have an issue for .net core #992, @Aaronontheweb is working on replacing Helios with dotnetty, don't know what's the actual status is but until then the current solution is, as far as I know, to keep your ActorSystem secured behind a web api that supports your security concerns
Dave Sansum
@dave-sansum

I have a question around dependency injection. In the akka.net docs it has the following "When scoping actor type dependencies using your DI container, only TransientLifestyle or InstancePerDependency like scopes are supported. This is due to the fact that Akka explicitly manages the lifecycle of its actors. So any scope which interferes with that is not supported."

What I want to figure out is why when akka manages the lifecycle of the actors does it also needs to do the same for dependencies? We're currently starting out with Akka in a hybrid environment so are injecting current components in to the actors. We've been hitting issues where singleton components are forced to instances (in the Ninject DI library specifically via BeginBlock) so we're ending up with say multiple db connections rather than using the singleton pool?

We can implement our own DI resolver to solve this which is fine but we're intrigued to know why this is the case in the first place as it's surely not a responsibility of the Akka framework to manage it's dependencies?

Thanks in advance