Add ability to specify scheduler implementation in configuration

[stefansedich]

This PR should allow the configs akka.scheduler.implementation value to actually be used and it will default to the DedicatedThreadScheduler, a few things to note still:

• I had to change the constructor of the old TaskBasedScheduler to add the ActorSystem param so that it could remain to be used if someone chose to.
• I did not update the documentation around this in Pigeon.conf as it feels like it is still in a bit of flux, I would like to go ahead and implement the LightArrayRevolverScheduler directly from the JVM Akka and bring that across, but will open a discussion around this. End result being is that the documentation in the default config still does not make any sense.

This solves my big issue for now in that the implementation can be selected by config, but there is still some work to get it nailed, @rogeralsing what are your thoughts on doing a direct port of the LightArrayRevolverScheduler as closely as we can? I am happy to do this if we all agree it is a good idea. Or do we just want to finish off the DedicatedThreadScheduler and wrap some tests around it?

Cheers
Stefan

[stefansedich]

Also can we just delete the TaskBasedScheduler?

[rogeralsing]

Also can we just delete the TaskBasedScheduler

I think we can. there is really no reason to use that one anymore.

btw. there are some failing tests for the TestScheduler

[stefansedich]

Haha damn @rogeralsing bitten by VS2015 and R#9 it implemented my test scheduler as if I had all the new shiny features, I will have to fix this tomorrow I left my laptop at work tonight :)

[rogeralsing]

cc @akkadotnet/developers anyone know what the build error is about?

[stefansedich]

Weird, can we kick off another build and see what happens?
On 22 May 2015 5:44 pm, "Roger Johansson" [email protected] wrote:

cc @akkadotnet/developers
https://github.com/orgs/akkadotnet/teams/developers anyone know what
the build error is about?

—
Reply to this email directly or view it on GitHub
#994 (comment).

[Aaronontheweb]

@akkadotnet/developers sometimes TeamCity can't parse out the exact error right there on the front page. When this happens I check the build log (one of the navigation tabs on that page) and scroll to the bottom.

Here's what I found:

[22:24:21][Step 1/1]
[22:24:21][Step 1/1] Results Top Level Tests
[22:24:21][Step 1/1] ------- ---------------
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertEqual_should_succeed_on_equal
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertEqual_should_throw_on_not_equal
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertEqualWithComparer_should_succeed_on_equal
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertEqualWithComparer_should_throw_on_not_equal
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertFalse_should_succeed_on_false
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertFalse_should_throw_on_true
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertTrue_should_succeed_on_true
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.AssertTrue_should_throw_on_false
[22:24:21][Step 1/1] Passed Akka.TestKit.VsTest.Tests.AssertionsTests.Fail_should_throw
[22:24:21][Step 1/1] Failed Akka.TestKit.VsTest.Tests.TestKitTests.Expect_a_message
[22:24:21][Step 1/1] 9/10 test(s) Passed, 1 Failed
[22:24:21][Step 1/1]
[22:24:21][Step 1/1] Summary
[22:24:21][Step 1/1] -------
[22:24:21][Step 1/1] Test Run Failed.
[22:24:21][Step 1/1] Passed 9
[22:24:21][Step 1/1] Failed 1
[22:24:21][Step 1/1] ----------
[22:24:21][Step 1/1] Total 10
[22:24:21][Step 1/1] Results file: D:\BuildAgent\work\49b164d63843fb4\TestResults\SYSTEM_WIN-FPCUM9UDOV2 2015-05-21 22_24_21.trx
[22:24:21][Step 1/1] Test Settings: Default Test Settings
[22:24:21][Step 1/1]
[22:24:21][Step 1/1] MSTest test run failed for D:\BuildAgent\work\49b164d63843fb4\src\contrib\testkits\Akka.TestKit.VsTest.Tests\bin\Release\Akka.TestKit.VsTest.Tests.dll
[22:24:22][Step 1/1] Running build failed.
[22:24:22][Step 1/1] Error:
[22:24:22][Step 1/1] System.Exception:
[22:24:22][Step 1/1] MSTest test run failed for D:\BuildAgent\work\49b164d63843fb4\src\contrib\testkits\Akka.TestKit.VsTest.Tests\bin\Release\Akka.TestKit.VsTest.Tests.dll
[22:24:22][Step 1/1] at [email protected](Int32 exitCode) in C:\code\fake\src\app\FakeLib\UnitTest\MSTest.fs:line 96
[22:24:22][Step 1/1] at Fake.MSTest.MSTest(FSharpFunc2 setParams, IEnumerable1 assemblies) in C:\code\fake\src\app\FakeLib\UnitTest\MSTest.fs:line 99
[22:24:22][Step 1/1] at [email protected](Unit _arg10) in D:\BuildAgent\work\49b164d63843fb4\build.fsx:line 226
[22:24:22][Step 1/1] at Fake.TargetHelper.runSingleTarget(TargetTemplate`1 target) in C:\code\fake\src\app\FakeLib\TargetHelper.fs:line 411

Looks like one of the unit tests for the MSTest version of Akka.TestKit failed.

[rogeralsing]

Do the rest of us have access to restart builds?

[Aaronontheweb]

@rogeralsing not currently. Only authenticated users can do that. I'd propose adding something similar to Akka's CI robot for that.

But I don't think this is an intermittent failure - this is the first time I've ever seen a TestKit test fail.

[rogeralsing]

this is the problem, the scheduler needs to be configured after the provider so the dedicated thread scheduler can access the provider

[rogeralsing]

I found the cause for this, the configurescheduler have been moved so it configures the scheduler and tries to start the dedicated thread scehduler too early when some system things have not yet been set up (e.g. termination task)

[stefansedich]

Ah dangit, I will fix that up. I wasnt sure if we wanted to die if the
scheduler could not be created or keep going, I will change it to log.

Cheers
Stefan
On 23 May 2015 4:07 am, "Roger Johansson" [email protected] wrote:

I found the cause for this, the configurescheduler have been moved so it
configures the scheduler and tries to start the dedicated thread scehduler
too early when some system things have not yet been set up (e.g.
termination task)

—
Reply to this email directly or view it on GitHub
#994 (comment).

[stefansedich]

Seriously I can't win here. That test failure looks to be a timeout and I hope not related to these changes. And that test runs locally....