On 7 Apr 2017, at 14:20, Galder Zamarreño <galder(a)redhat.com>
wrote:
--
Galder Zamarreño
Infinispan, Red Hat
> On 30 Mar 2017, at 18:33, Dan Berindei <dan.berindei(a)gmail.com> wrote:
>
> On Thu, Mar 30, 2017 at 3:51 PM, Galder Zamarreño <galder(a)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/do...
>> [2]
https://github.com/galderz/datagrid-patterns/blob/master/server-config/or...
>> [3]
https://github.com/galderz/datagrid-patterns/blob/master/analytics-stream...
>> [4]
https://github.com/galderz/datagrid-patterns/blob/master/analytics-stream...
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev