vlingo / xoom-lattice Goto Github PK

MD5*Ring and MurmurArrayHashRing excludeNode always fail with ArrayIndexOutOfBoundsException. nodeOf also fails with the same exception when the ring is empty. From what I see it the exact same algorithm copied over to all of these.

There are ignored tests which currently fail for these here: #12

In my example code, I have a single entity (shopping Cart) that has 3 events. On every 5th run or so the service spits out this error message. In the code, the regististration of the "CreatedEvent" adapter is made very clearly. There appears to be some kind of race condition that can cause the registration to not be considered and the "recovery error" to be logged. In my example this does not provable affect the actor, but it certainly should be investigated.

You can see this in my fork of the examples, using the branch feature/event-sourced-example
bwehrle/vlingo-examples@dbb629c
Please run this in a loop until you see the issue:

 mvn test -pl vlingo-ecommerce

To wait for this to happen you can run:

while true ; do mvn test -pl vlingo-ecommerce | grep Exception ; sleep 0.5 ; done & 

vlingo/actors: Message#deliver(): Exception: Stream not recovered for: CartEntity(cartEvents) because: Adapter not registrered for: io.vlingo.examples.ecommerce.model.CartEvents$CreatedEvent for Actor: Actor[type=CartEntity address=Address[id=135, name=cart-135]] sending: start()
vlingo/actors: io.vlingo.symbio.store.StorageException: Stream not recovered for: CartEntity(cartEvents) because: Adapter not registrered for: io.vlingo.examples.ecommerce.model.CartEvents$CreatedEvent
at io.vlingo.lattice.model.sourcing.Sourced.lambda$restore$7(Sourced.java:271)
at io.vlingo.common.BasicCompletes$BasicActiveState.handleException(BasicCompletes.java:501)
at io.vlingo.common.BasicCompletes$BasicActiveState.exceptionAction(BasicCompletes.java:490)
at io.vlingo.common.BasicCompletes.recoverFrom(BasicCompletes.java:148)

Moved vlingo-lattice to vlingo-lattice-core. See vlingo-lattice-core for the following.

The following tests must be converted to use AccessSafely rather than bare TestUntil:

• ExchangeTest
• TestExchangeReceiver1 (mock)
• TestExchangeReceiver2 (mock)
• DescribedProjection
• MockResultInterest (mock)
• StateProjectionDispatcherTest
• MockProjection
• CommandSourcedTest
• EventSourcedTest
• Result
• MockTextDispatcher
• StatefulEntityTest

Context:

https://github.com/vlingo/vlingo-examples/tree/master/vlingo-distributed-ping-pong

The problem is that when we run the Grid (on top of vlingo-cluster) there are various classes that cannot be found. These are fundamental, such as:

io.vlingo.actors.Actor

and sometimes:

io.vlingo.common.Completes

and other ones that are absolutely available.

This seems to be mostly because we use the JDK's Java compiler to dynamically compile generated protocol proxy classes. We have attempted various ClassLoader-based fixes but without results.

Given set of jar dependencies, the above demo/example is broken on all Java versions 8, 11, 13 on OSX; even with a fat jar it's still broken. Actually the jar Maven build:

maven-jar-plugin
maven-dependency-plugin

and fat jar:

maven-assembly-plugin

both seems to move the problem to other dependencies not being found at start up.

NOTE: To see the failure via vlingo-distributed-ping-pong you must remove all *__Proxy.java from package io.vlingo.pingpong.domain. Otherwise it always works. Caching the proxies in src/main is our current workaround.

At runtime, when dynamically generating proxies and then compiling them, the compiler can't find the standard platform classes imported by the proxies. The problem is exhibited only on certain platforms.

👍✅ Windows, with JDK 8, 11, and 13
👍✅Inside IntelliJ and Eclipse
👎⛔️ OSX, with JDK 8, 11, and 13
❓◻️ Linux, currently untested

It's possible that the ClassLoader related fix could be taking ideas from the OSS Eclipse project.