For example, I'd like to get some clarification on the scope of the context object:
@Will, will the solution you provided in [2] deal with multiple JGroups marshalling request callbacks? Or is it only designed for a single marshalling request callback coming from JGroups tgat contains a CacheStatusResponse map? Since it's a thread local is not easy to see what's the lifespan of these instances stored in the thread local... The simplest thing would be to have a new context created for each JGroups marshalling request. However, more optimizations could be achieved from: 1. For non-transaction operations, a context per operation. So if a cache.put() results in two operations being serialized (get to return previous value, and put itself), then the context could expand those two serializations. 2. For transaction operations, a context per transaction. @Sanne, would this be enough for you? In your [4] dev post you seem to want to go beyond marshalling into how we'd keep references of objects in memory, e.g. if a String is repeated in many places, have a way to centralise that storage in memory itself. Cheers, [4] http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- Galder Zamarreño Infinispan, Red Hat > On 21 Apr 2016, at 10:07, Galder Zamarreño <gal...@redhat.com> wrote: > > Hey guys, > > Just a quick heads up about [1]. > > As I was looking at the marshalling code in core, I spotted the work done for > [2] and by extension [3]. > > I can certainly see the practicality of Will's solution in [2] which fitted > quite well with the current marshalling architecture, but as we rethink the > entire marshalling layer in [1], I'm wondering if a context-object where we > can track repeated fields like Strings, Addresses... would be more suitable. > For starters, we'd get rid of thread locals and could be more easily exposed > in other places. > > Any ideas or updates you have on the topic please let me know. > > Cheers, > > [1] https://issues.jboss.org/browse/ISPN-6498 > [2] https://issues.jboss.org/browse/ISPN-4979 > [3] https://issues.jboss.org/browse/ISPN-2133 > -- > Galder Zamarreño > Infinispan, Red Hat > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
