vlingo-net / xoom-net-common Goto Github PK

This is the feature that has to be ported from JVM implementation referenced by this commit: vlingo/xoom-common@9c92728

It has to be based on Newtonsoft.Json

BasicCompletesTest.TestTimeoutBeforeOutcome() test occasionally fails. My guess is, it is a Thread related issue. It only fails when we run all the tests in parallel. We may need to try running them in parallel multiple times to see it fail. That makes it difficult to debug. Here is a link to a recent failure: https://ci.appveyor.com/project/VlingoNetOwner/vlingo-net-common/builds/20983605/tests

The goal is to use new C#8 features like default interface implementation and nullable types which helps a lot porting java code to .net.

• Change TargetFramework to TargetFrameworks in csproj, listing netstandard2.0;netstandard2.1

• Add <LangVersion>latest</LangVersion>

• Add <Nullable>enable</Nullable>

• Change TargetFramework to TargetFrameworks in csproj, listing netcoreapp3.0 for test project

• Finish #49

• Finish #50

This issue has to be investigated. Some examples:

04/30/2020 09:35:52.196 [21] vlingo-net/actors[Debug]: DeadLetter[Actor[type=ConsoleLoggerActor address=Address[Id=11, Name=(none)]].Close()]
856The active test run was aborted. Reason: Test host process crashed : Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
857   at System.Threading.TimerQueueTimer.Change(UInt32 dueTime, UInt32 period)
858   at System.Threading.Timer.Change(Int64 dueTime, Int64 period)
859   at System.Threading.Timer.Change(TimeSpan dueTime, TimeSpan period)
860   at Vlingo.Common.Scheduler.SchedulerTask`1.Run()
861   at Vlingo.Common.Scheduler.SchedulerTask`1.Tick(Object state)
862   at System.Threading.TimerQueueTimer.<>c.<.cctor>b__23_0(Object state)
863   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
864--- End of stack trace from previous location where exception was thrown ---
865   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
866   at System.Threading.TimerQueueTimer.CallCallback(Boolean isThreadPool)
867   at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
868   at System.Threading.TimerQueue.FireNextTimers()
869   at System.Threading.TimerQueue.AppDomainTimerCallback(Int32 id)

According to the following template

language: csharp
jobs:
  include:
    - os: linux
      dotnet: 3.0.100
      mono: none
    - os: osx
      osx_image: xcode11
      dotnet: 3.0.100
      mono: none
sudo: false  # use the new container-based Travis infrastructure
script:
  - dotnet restore ./src/Vlingo.UUID.sln;
    dotnet build ./src/Vlingo.UUID.sln;
    dotnet test ./src/Vlingo.UUID.Tests/Vlingo.UUID.Tests.csproj;

notifications:
  slack: vlingo-platform-net:kwiEEBuUpRnz2rYYYstTBpXr

While implementing Vlingo.Http this piece of code below has produced cast exception error:

_stage.ActorOf<IUser>(_stage.World.AddressFactory.From(userId))
                .AndThenTo(user => user.WithName(new Name(nameData.Given, nameData.Family)))
                .OtherwiseConsume(noUser => Completes.With(Response.Of(Response.ResponseStatus.NotFound, UserLocation(userId))))
                .AndThenConsume(userState => {
                _repository.Save(userState);
                Completes.With(Response.Of(Response.ResponseStatus.Ok, JsonSerialization.Serialized(UserData.From(userState))));
            });

And the error produced is as follows:

consoleLogger[Error] [Exception]: Unable to cast object of type 'Action`1[Vlingo.Common.ICompletes`1[Vlingo.Http.Tests.Sample.User.Model.UserState],Vlingo.Common.ICompletes`1[Vlingo.Http.Tests.Sample.User.Model.UserState]]' to type 'Action`1[Vlingo.Http.Tests.Sample.User.Model.IUser,Vlingo.Http.Tests.Sample.User.Model.IUser]'.
consoleLogger[Error] [StackTrace]:    at Vlingo.Common.BasicCompletes`1.AndThenToInternal[TF,TO](TimeSpan timeout, Optional`1 failedOutcomeValue, Func`2 function)
   at Vlingo.Common.BasicCompletes`1.AndThenTo[TO](Func`2 function)
   at Vlingo.Http.Tests.Sample.User.UserResource.ChangeName(String userId, NameData nameData) in C:\Sources\GitHub\vlingo-net-http\src\Vlingo.Http.Tests\Sample\User\UserResource.cs:line 52

• Argon2
• BCrypt
• SCrypt

The corresponding Java implementation vlingo/xoom-common@c0640ce

The resulting Task should be awaited when closing the mailbox and any catches exceptions should be logged.

https://github.com/vlingo-net/vlingo-net-common/blob/a551e337108702c54aed97346f14a6bfc207950f/src/Vlingo.Common/Message/AsyncMessageQueue.cs#L43

This can be easily demonstrated by the following UT:

[Fact]
        public void TestOnClientAndServerSetupWhenClientIsFaster()
        {
            var ints = new List<int>();
            var completeInteger = NewEmptyCompletes<int>().AndThen(i =>
            {
                ints.Add(i);
                return i;
            }).Repeat();
            var expected = Enumerable.Range(0, 1000).ToList();

            var server = new Thread(() => expected.ForEach(i => completeInteger.With(i)));

            server.Start();
            server.Join();

            var intHashSet = new HashSet<int>(ints);
            var expectedHashSet = new HashSet<int>(expected);

            expectedHashSet.RemoveWhere(h => intHashSet.Contains(h));
            Assert.Empty(expectedHashSet);
        }

Here Repeat() is only executed one time where it should be executed every time an output is set.

PackageLicenseUrl is deprecated. Now we should use PackageLicenseFile.

Also we need to update other properties like tags, etc.

This issue is opened to track the following one declared in actors vlingo-net/xoom-net-actors#63

How current implementation of ICompletes may fail :

1. When the service calls with(outcome) there may or may not be actions functions registered. If there are any then the service thread will execute the ones that are there.
2. If during 1 the client thread is registering a function and it sees that the outcome is set, it will try to execute functions, but it can't if the service is already executing them.
3. If the service is executing functions and runs out of functions, it will give up and return.
4. When the client has exclusive access to the completes and it is registering a new function, it will execute any earlier registered functions and the one it just registered.
5. The client will continue doing 4 until there are no more functions registered.
6. If 1 is happening and the client has already registered all functions, the service thread will execute all of them.

In fact the clients registration of continuations and server execution may kick in unpredictable times. If we use the same instance (as we curerntly do) the transformations applied by the client, may happen before the transformations applied by the actor which is confusing and complicated to ensure consistent ordering of the transformations to be applied. One of the problems is that this is certainly due to the fact that the same instance of BasicCompletes is passed between the client and the server:

1. The proxy creates the instance of BasicCompletes and returns it to the client
2. The same instance is passed to the server through LocalMessage where the server may start executing actions and set results
3. Before the client has time to register all the continuations.

The goal would be to bind the success/error of the completes that the actor method returns to the completes that is handed back to the client by the proxy. This should place in the consumer function that the proxy also creates and put into the actor’s mailbox.

Points to consider:

• mailbox.Send(new LocalMessage... should not require the instance of BasicCompletes created in the proxy. Just the consumer function handed to the client should be enough.
• Actor may complete with a value and apply transformations before returning to the client
• client should see the results once the server returns (no intermediate results)
• client can still register continuations once he has the server returned the value. It doesn't matter at that point

This may also eliminate the need for the CompletesEventually. Today the issue is that CompletesEventually(); followed by Completes().AndThen() or Completes.Await() etc. results an exception being thrown (and swallowed later) which leads to hanging, too. That it hangs silently is really bad

This can be demonstrated with the following test

[Fact]
        public void TestOnClientAndServerSetupWhenServerIsFaster()
        {
            var ints = new List<int>();
            var completeInteger = NewEmptyCompletes<int>();
            var expected = Enumerable.Range(0, 1000).ToList();

            var server = new Thread(() => expected.ForEach(i => completeInteger.With(i)));
            var client = new Thread(() => completeInteger.AndThen(i =>
            {
                ints.Add(i);
                return i;
            }).Repeat());
            
            server.Start();
            Thread.Sleep(10);
            client.Start();

            server.Join();
            client.Join();

            var intHashSet = new HashSet<int>(ints);
            var expectedHashSet = new HashSet<int>(expected);

            expectedHashSet.RemoveWhere(h => intHashSet.Contains(h));
            Assert.Empty(expectedHashSet);
        }

As you can see client is late by 10ms with processing. Attaching a continuation is too late because the server has already processed the continuation on its end.

On the JVM this is supported by the SinkAndSourceBasedCompletes but needs to be run agains the regular implementation of BasicCompletes in order to confirm that both has the same behavior.

For anyone with a spare hour or so, this is a pretty simple contribution.

Support Task<T> as a valid type in the ProxyGenerator. Inside the ProxyGenerator you will see the current Completes<T> support, and this type can be added along side it pretty easily.

NOTE: Task<T> will not be used for vlingo-net-platform internals or public APIs. We will continue to use Completes<T> for core vlingo-net-platform protocols. Consumers will for sure want to use Task<T> as a return type in their protocols. We will provide sufficient warnings in the docs regarding the use of Task<T>, but some will think it's a great idea and insist on its support.

This issue is imported from : https://github.com/vlingo-net/vlingo-net-actors/issues/51

There is a situation in xoom-net-symbio tests where Await() is called on the top parent ICompletes expression but is resolved before the nested one computes it's result. Consider this line

_journal.JournalReader("test").AndThenTo(reader => reader.StreamAll()).Await()

Once the outcome of AndThenTo is computed (reader in that case) the Await() unlocks where it should wait for the result of StreamAll(). There workaround is to split the lines like the following:

var reader = _journal.JournalReader("test").Await();
var all = reader?.StreamAll().Await();

It should be fixed

The should be able instead of doing async/await to send the result of Task<T> to actors Complets like :

httpClient.GetAsync(...).AndThenTo(result => do something)

The operation above returns ICompletes<T> meaning that internally AndThenTo sends a message to the actor with the result of the asynchronous operation.

Related to #48

Make changes according to this template

version: 0.0.{build}
image:
  - Visual Studio 2019
  - Ubuntu
configuration: Release
skip_commits:
  message: /.*\[ci\-skip\].*/ 
before_build:
  - dotnet restore src/Vlingo.UUID.sln
build:
  project: src/Vlingo.UUID.sln
  verbosity: minimal
  publish_nuget: true
test_script:
  - dotnet test src/Vlingo.UUID.Tests
deploy:
  - provider: NuGet
    api_key:
      secure: keYt7U6hDEIBzKLfVMts/6deGh0bqJdcjhlO2mWEJ04SRIS0Y6+e3EjszsRqq5nJ
    skip_symbols: true
    artifact: /.*\.nupkg/
    on:
      branch: master
notifications:
  - provider: Webhook
    url: https://webhooks.gitter.im/e/2b56d1ca84637acb9ee8
    method: POST
    on_build_success: true
    on_build_failure: true
    on_build_status_changed: true