bedrock-coherence 12.2.1 - streams and remote collectors may not work #372
Comments
brianoliver
added
Priority: Major
Type: Defect
Module: Coherence Testing Support
and removed
Module: Coherence
labels
|
Definitely an issue with Lambda serialization with Bedrock. In the meantime the following work-around works. Instead of the assertion: You can instead do the following: This submits a lambda containing the expression to be evaluated to any cluster member and asserts that the result is as expected. This is instead of Bedrock attempting to capture the internal state of Coherence and then submit that. |
|
Thank you for response. The workaround works fine in this simple case. But I'm affraid that it will not be enough in some more real-life scenario. |
brianoliver
changed the title
|
One of the challenges is "where" things like collectors actually execute. In the case above, it seems clear that they are running "Remotely", but is that remotely across the cluster, or remotely in the Cluster Member that Bedrock is interacting with (or both). Consider the .stream().forEach(Consumer) case. Should the Consumer be executed in the Bedrock application, in the Cluster Member that Bedrock is interacting with, or in each of the Cluster Members managing data? I think the answer should be, in the Bedrock (testing?) application, which follows what the Coherence API does. However this means that Bedrock needs to "stream" the results back from the Cluster Member it is interacting with and then invoke the Consumer locally in your application. A bit challenging but not impossible. It's entirely possible however that another interpretation of the semantics is required, perhaps that the Consumer is executed in the Cluster Member(s) themselves? So looking at the stream() and collective pipeline APIs, it's clear that each of the methods may require some careful interpretation as to where something should be executed. For now it might be challenging to provide an (easy/opaque) universal solution for all methods. Fortunately though some of the recent work we've done with streaming support (over RemoteChannels) will help us should we need to solve things on an each individual basis. |
|
There is one more lambda serialization issue that I've found. I tried to use lambda expression as It works fine when cluster is started using the But I suspect it might be some problem with Oracle Coherence itself (not Bedrock) since I was facing the same issue when using Littlegrid (in fact, it was the primary reason why I started evaluation of Bedrock). Please, feel free to move this to another issue if you think it is not strictly connected to the original case of this issue. |
|
Let's raise this issue as something separate (ie: now covered by issue #387). I think it's more likely to do with either the child-first-class loader (the same technique is used by LittleGrid and Bedrock) and/or the use of Lambdas themselves. Confirmed that this above issue #387 is in fact a Java issue, nothing to do with Coherence, Bedrock or Littlegrid (but there's decent work arounds) |
I wanted to try new Coherence Stream API using bedrock-coherence. I've created a test case (based on
AbstractCoherenceClusterBuilderTest.shouldAccessNamedCache()) with simple call tonamedCache.stream().collect(RemoteCollectors.counting()):But it results in throwing
ClassNotFoundException. The full stack trace is:I suspect that it is not only remote collectors issue, but some more general problem with lambdas.
The text was updated successfully, but these errors were encountered: