[infinispan-dev] Executing server tasks that contain POJOs

[Galder Zamarreño]

FYI, I've created these JIRAs to improve some of the issues highlighted here:
https://issues.jboss.org/browse/ISPN-7710
https://issues.jboss.org/browse/ISPN-7711

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 7 Apr 2017, at 14:20, Galder Zamarreño <galder at redhat.com> wrote:
> 
> 
> --
> Galder Zamarreño
> Infinispan, Red Hat
> 
>> On 30 Mar 2017, at 18:33, Dan Berindei <dan.berindei at gmail.com> wrote:
>> 
>> On Thu, Mar 30, 2017 at 3:51 PM, Galder Zamarreño <galder at redhat.com> wrote:
>>> Hi all,
>>> 
>>> For a demo I'm giving next week, I'd like to show how to use distributed streams via a remote server task. All server tasks that we have in testsuite rely on primitives but in my case I wanted to use POJOs.
>>> 
>>> To do that, I needed to get compatibility mode working in such way that those POJOs could be unmarshalled for the server task. Since in another demo I'm showing Protostream based POJOs, I thought I'd try to use that as mechanism to unmarshall POJOs server side.
>>> 
>>> We have a test for such scenario [1], but the reality (running on a proper server) is anything that simple. Here's a list of things I've found out while creating a WordCount example that relies on a POJO:
>>> 
>>> 1. Out of the box, it's impossible to set compatibility marshaller to org.infinispan.query.remote.CompatibilityProtoStreamMarshaller [1] because "org.infinispan.main" classloader can't access that class. I worked around that by tweaking the module.xml to have an optional dependency to "org.infinispan.remote-query.server" module.
>>> 
>> 
>> I know Sanne also wanted to add one of the query modules as an
>> optional dependency to the core module for a similar reason, but it
>> seems really hacky.
> 
> Yeah, might be a bit hacky but it's just a configuration change as opposed to a code change.
> 
>> Could the server create the GlobalConfigurationBuilder with a
>> classloader that has access to the query module instead?
> 
> Hmmm, not sure. I mean, in theory you could plug any marshaller, even com.acme.WhateverMarshaller, so it's not really an issue about having access to the query module, but having access a module that contains that marshaller.
> 
>> Alternatively, I know ModularClassResolver prefixes class names with
>> the slot and module name, and can load a class from any module. Maybe
>> we could also allow a slot:module:class format everywhere the
>> configuration currently accepts a class name?
> 
> That could be handy. I'm about to create a JIRA on this, so I'll add it as an idea to it.
> 
>> 
>>> 2. After doing that, I had to register the protofile and associated classes remotely in the server. Again, there's no out of the box mechanism for that, so I created a remote server task that would do that [3].
>>> 
>>> 3. Finally, with all that in place, I was able to complete the WordCount test [4] with a final caveat: the return of the word count, and words protofile registration, tasks return objects that are not marshalled by the compatibility marshaller, so I had to make sure that the remote cache manager used for those tasks uses the default marshaller.
>>> 
>>> Clearly we need to improve on this, and we have plans to address these issues (with new upcoming transcoding capabilities), but I thought it'd be worth mentioning the problems found in case anyone else encounters them before transcoding is in place.
>>> 
>>> Cheers,
>>> 
>>> [1] https://github.com/galderz/datagrid-patterns/blob/master/server-config/domain/domain.xml#L139
>>> [2] https://github.com/galderz/datagrid-patterns/blob/master/server-config/org.infinispan.main_module.xml#L18
>>> [3] https://github.com/galderz/datagrid-patterns/blob/master/analytics-stream/tasks-server/src/main/java/test/WordsProtoTask.java
>>> [4] https://github.com/galderz/datagrid-patterns/blob/master/analytics-stream/tasks-client/src/test/java/test/WordCountTest.java
>>> --
>>> Galder Zamarreño
>>> Infinispan, Red Hat
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev