vlingo / xoom-common Goto Github PK

We realised after a long conversation that Completes<T> right now has an important issue that needs to be tackled: a Completes<T> pipeline can be run during the composition fase, because it runs potentially in different threads.

Our new proposal is to actually rework how Completes<T> works so it can be simplified, more efficient and easier to change. The design decisions that we want to take:

• Completes<T> composition will only be done in a single thread.
• Completes<T> execution will be lazy, it will be only run when there is an outcome and it's marked as ready.
• Completes<T> will be executed in a threadpool only if it's marked as ready and has an outcome.
• Completes<T> will separate two responsibilities: who is sending the outcome to the chain, and how the chain processes the outcome. For example, you can have a SingleSource<T> that will only emit a single outcome to the whole chain, and you can have also a RepeatableSource<T> that can emit up to N elements. We can build more sources from CompletableFuture<T> and other async components.
• Timeouts will act as gateways. We are not measuring the time we spend processing a step in the chain, but the deadline from an outcome to pass through the timeout gateway. So it will measure the time between outcomes.

Opinions and feedback are really appreciated.

It's also a good opportunity to work on the following issues and solve them:

• #15
• #14
• #13
• #12

Thanks for the wonderful vlingo-actors library :)

At present I am trying to port my pet project to vlingo platform. In one of my usecases, I want to be able to do something like Completes<Int> to Completes<String>. Completes as of now doesn't support map/flatmap. From the Completes interface I understand I could use andThenTo.

It would be really awesome if Completes interface makes this a little easier, do you have any plans to add map/flatmap?

Seems like this is the bug that you can easily reproduce with the following test:

@Test
  public void TestThatFailureOutcomeFails()
  {
    final Completes<Integer> completes = new BasicCompletes<>(new Scheduler());
    completes
            .andThen(new Integer(-100), (value) -> 2 * value)
            .andThen((x) -> andThenValue = x)
            .otherwise((x) -> failureValue = 1000);

    completes.with(-100);
    Integer completed = completes.await();

    assertTrue(completes.hasFailed());
    assertEquals(new Integer(-1), andThenValue);
    assertEquals(new Integer(1000), failureValue);
  }

The failedOutcomeValue from .andThen(new Integer(-100), (value) -> 2 * value) is not taken into account. When calling completes.with(-100); this line : https://github.com/vlingo/vlingo-common/blob/c858e9235d1912c1afc5fe5a881627955820a7f0/src/main/java/io/vlingo/common/BasicCompletes.java#L565 evaluates to null

As suggested by @VaughnVernon it might be that the second andThen overwrites the value with null because it is not nested but added up to the first andThen

There is a code-extension, class io.vlingo.common.Tuple4, which ist not updated in maven-repository, version 0-74 (not in sync).
This will cause an error in vlingo-examples.

Thanks

When starting out with either Completes<T> or CompletableFuture<T> and then transitioning to the other in the same pipeline, you can't get back to Completes<T> from CompletableFuture<T> because CompletableFuture<T> only returns CompletableFuture<T> instances.

This is a problem where with vlingo-http, for example, a RequestHandler must return a Completes<T> rather than CompletableFuture<T>.

The solution is for Completes<T> to support both Completes<T> and CompletableFuture<T> as parameters to the various forms of andThen() and andThenTo().

In time we may also choose to support CompletableFuture<T> for vlingo-http Request/Response.

P.S. We can't expect CompletableFuture<T> to support Completes<T> ever, so it's on us to support CompletableFuture<T>.

https://github.com/vlingo/vlingo-common/blob/master/src/main/java/io/vlingo/common/compiler/DynaFile.java#L14-L17

Gradle generate the classes in another folder, like out/production/classes. It causes vlingo to just be compatible to Maven projects.

Moved to trello https://trello.com/c/tpFGllQe/75

When there is an exception thrown prior to the receiverFrom(Exception) being registered on BasicCompletes<T> the outcome should be delayed until the registration is completed. If there is never a registration of receiverFrom(Exception) then the outcome will be unknown.

I would like to suggest a new feature of Complete composition.

I would like to create a new single Complete from a collection of Completes. This will support a fan-out design pattern, where the client may message multiple actors and need to await all the calls to finish (equivalent of Task.WhenAll). Another potential scenario to support is the equivalent of Task.WhenAny - the new Complete will trigger when the first of the source completes triggers.

The suggested interface (I don't know Java so please forgive any syntax errors):

static <T[]> Completes<T> whenAll(final Completes<T>[]) 
static <T> Completes<T> whenAny(final Completes<T>[]) 

It may be useful to have support for composing Completes of different generic types - the scenario here would involve querying multiple actors for different type of information and than aggregating results.

Scenario:

• Complete needs to be turned into a Completes
• If there is an error, invoke a .recoverFrom()

Imagine that the function inside the recovery handler returns a Completes

From inside the recoverFrom(), I would not want to do a await() on the inner Completes, I'd rather return the Completes directly, since that is what the outer code block is expecting as a result. Otherwise I need to do some kind of await() call just to return a Y which will just be turned into a Completes with the outcome already provided, making the thread block.