On 5 Jun 2015, at 14:15, Radim Vansa <rvansa(a)redhat.com>
wrote:
Is the marshalling comparison really fair? The lambda-table-based
approach removes the need for serializing the class definition, but in
practice - is the class definition always send around with each RPC?
^ We've extensively added Infinispan Externalizers (which use the Object Table
approach shown in MarshallingTests) to reduce the size of our payloads, and indeed for all
those, no class definitions are sent around. So, as long as the types of those are known
to us, we can use such approach and avoid expensive serialization.
NOTE: JBoss Marshalling's Externalizers are more expensive than ObjectTable based
approach but I can't remember why, it might be cos when you use those, it might send
the externalizer class' class definition around, but not sure.
If
it is so, it seems like a serious flaw of the current codebase, and not
something occurring only for the functional interface. In case that we
keep the marshallers around, we should marshall second RPC (with the
same lambda and another instance of the same captured class), and look
on the diff rather than on the first serialized instance.
^ Hmmm, not sure what you mean there exactly.
Radim
On 06/05/2015 11:44 AM, Galder Zamarreño wrote:
> Hi all,
>
> Thanks to all who contributed to the 1st draft revision. We've taken all that
input and created a separate Github project where we have prototytped the 2nd draft of the
advanced Java 8 based Infinispan API. The starting point for you should be FunctionalMap
[1].
>
> Here's a brief summary the major changes since the 1st draft:
>
> 1. FunctionalMap has been separated into 3 sub-interfaces, one for read only
operations, one for write only operations, and a final one for read-write operations. This
separation makes it clear the purpouse of each operation and adds a nice layer of type
safety, e.g. you can't write with a read-only map, or you can't read with a
write-only map.
>
> 2. Param has been added, which is equivalent to Infinispan Flag with the added
benefit that it can carry values. There's no such example right now but we could have
in the future.
>
> 3. MetaParam has been added. This is a much more flexible and extensible option
compared to the current Infinispan's Metadata.
>
> 4. For operations returning mutiple returns, or working on multiple elements,
we've exposed something called Traversable, which is a subset of Java's Stream.
See its javadoc to find out more. Kudos to Will for his work on distributed streams which
has helped hugely with the design of Traversable.
>
> 5. Listeners have been added, again separating between read-write and write-only
listeners (JCache does not offer read-only listeners, e.g. cache entry visited, and hence
I think we'll drop our cache entry visited listener at some point).
>
> 6. Will and I have explored marshalling aspects of lambdas, and there are some
interesting ways to reduce their costs by +90%! See MarshallingTest for different options
to marshall both capturing and non-capturing lambdas and their cost in terms of payload
sizes.
>
> Some final notes:
>
> * Please do read the javadocs, they contain a lot of information on the reasons
behind the design.
>
> * To find out how the different functional map variants are used, look at
ConcurrentMapDecorator and JCacheDecorator who use them to implement the ConcurrentMap and
javax.cache.Cache APIs respectively.
>
> * FunctionalMapTest contains examples on how to use functional map variants for other
operations which we deeply care about, e.g. Hot Rod atomic version-based replace
function.
>
> Special thanks to Mario Fusco (Java 8 In Action book co-author) for his feedback
throughout this 2nd draft design process.
>
> Cheers,
>
> [1]
https://github.com/infinispan/proto8/blob/master/src/main/java/org/infini...
> --
> Galder Zamarreño
> galder(a)redhat.com
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com