These are chat archives for akkadotnet/akka.net

15th
Dec 2017
jalchr
@jalchr
Dec 15 2017 08:17
@Horusiath
Can you state advantages of using Akka.Cluster.Discovery.Consul for cluster seed node discovery ?
Is it a replacement of lighthouse or a complement or something else :) ?
Bart de Boer
@boekabart
Dec 15 2017 10:35
@Horusiath in Persistence.SqlServer - is there any way to prevent getting the timeout getting a connection from the pool ?
I mean - it can't be true that the application logic has to 'throttle' its calls to Persist(async) in order to prevent this!?!?
(actually, we've seen the same with Postgres as well)
aren't calls to Persist just translate to akka messages to the Journal Actor underwater, which handles them as fast as it can? Meaning - it can't be flooded?
Bart de Boer
@boekabart
Dec 15 2017 10:43
... shouldn't the persistence 'system' (either the plugin or the base) just limit the concurrency of Db writes?
Bart de Boer
@boekabart
Dec 15 2017 11:09
Looking at the code in both AsyncWriteJournal and SqlJournal , it seems that everything is aimed at as many concurrent connections as possible instead: AsyncWriteJournal can create multiple WriteMessagesAsync tasks in parallel, each having optionally multiple AtomicWrites which in turn expand to a DbConnection each...
Maxim Cherednik
@maxcherednik
Dec 15 2017 12:44
One more time: hey @Aaronontheweb shall I have a look into this: akkadotnet/akka.net#3208
Bartosz Sypytkowski
@Horusiath
Dec 15 2017 15:39
@boekabart timeouts are still possible, if number of incoming write requests is high. If you have many concurrent writers (persistent actors), using batching journal could help there.
Bartosz Sypytkowski
@Horusiath
Dec 15 2017 15:45
@jalchr essentially Akka.Cluster.Discovery does several things:
  • It puts a node discovery onto 3rd party service (in existing case, consul). With it you don't need to have lighthouse, you could provide consul address instead.
  • Every Akka.NET cluster node using this plugin will be registered within consul as service. So you can use consul web UI to check for them, including TTL-based health checks.
  • You can also configure nodes to use consul service registry as a source of truth for a cluster state - this means, that if consul will detect node as offline, connected nodes will down it as well.
Aaron Stannard
@Aaronontheweb
Dec 15 2017 15:45
@maxcherednik go for it
sorry guys, been working nonstop on customer stuff
finally finished yesterday
coming back up for air on the OSS stuff now
@Horusiath I haven't looked at the code yet, but the problem people had historically with trying to bootstrap clusters using something like Consul
is that the first time you start a cluster, the "first seed node must be up" rule is designed to prevent a split brain from happening at startup
if the seed node orders are totally different on a node-by-node basis when you boot a cluster for the first time
that rule can't be enforced
and anything can happen
you essentially introduce a moving part where there isn't and shouldn't be one
Maxim Cherednik
@maxcherednik
Dec 15 2017 15:49
ok, planing to simplify the remoting a bit :)
Aaron Stannard
@Aaronontheweb
Dec 15 2017 15:49
so if the view Consul has of the cluster is different as nodes boot up at slightly different times
changes and thus reports different seed node orders back to the other nodes who are starting
what's your solution to that?
the Lighthouse approach is dead simple: bootstrap the seeds first and then never touch them on deployment
eliminates the entire problem category
Bartosz Sypytkowski
@Horusiath
Dec 15 2017 15:52
@Aaronontheweb consul offers distributed lock/lease acquisition, and I'm using it to establish first initial node in the cluster.
Aaron Stannard
@Aaronontheweb
Dec 15 2017 15:54
do you have a unit test that proves that this works?
(I know Consul works)
Bartosz Sypytkowski
@Horusiath
Dec 15 2017 15:54
it's not ideal, but it works. The more irritating stuff is that consul reaction and convergence times are worse than pure akka.net - detecting dead nodes can take up to a minute
Aaron Stannard
@Aaronontheweb
Dec 15 2017 15:54
gotcha
well, keep at it
hopefully people will find it useful!
I'm thinking about using your new Reminders package in my current project
was going to use Quartz instead
but since I'm already planning on using Akka.Persistence yours seems simpler
stevemesser
@stevemesser
Dec 15 2017 17:49

Should you be able to apply a custom dispatcher to a router?

I am trying to isolate the database actors in their own threadpool.

I have the following hocon

    custom-dedicated-dispatcher 
    {
        type = PinnedDispatcher
        throughput = 10
    }

    custom-datastore-dispatcher 
    {
        type = ForkJoinDispatcher
        throughput = 85
        dedicated-thread-pool 
        {
            thread-count = 4
            threadtype = background
        }
    }

    akka 
    {
        actor
        {
            deployment
            {
                **# this appears to work - verified in the debugger**
                /engineroot/httpserver
                {
                  dispatcher = custom-dedicated-dispatcher                  
                }

                **# this appears to work - verified in the debugger**                
                /logstore
                {
                    dispatcher = custom-datastore-dispatcher 
                }

                **# this doesn't work - debugger still shows the default dispatcher** 
                /engineroot/httpserver/dispatcher/processor/datastorepool
                {
                    dispatcher = custom-datastore-dispatcher    
                    router = round-robin-pool
                    nr-of-instances = 4
                }
            } # deployment
        } # actor
    } # akka