On 29 Feb 2016, at 14:35, Vittorio Rigamonti <vrigamon(a)redhat.com&gt; wrote: Hi All, Hi Galder JBasicMarshaller.h is not an intent to go further along the way to implement a c++ JBossMarshaller, it has the only goal to provide a working 'exec' operation. The c++ exec currently works only with integer and "small" string data types, user can easily extends the marshaller to other basic types. My current model of the exec use case is this one (maybe it's too simplistic so correct me if I'm wrong): a "user defined consumer" consumes data produced by a "user defined producer", so maybe it could worth to evaluate a solution where the framework provides a common standard for communication (stringified json? or JSObject for in memory 100% Java) and let the user handle it's own data. This is a proposal approach specific to the exec scope, I can't say if it can be extended as a general approach where marshalling is involved. Cheers, Vittorio ----- Original Message ----- From: "Galder Zamarreño" <galder(a)redhat.com&gt; To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; Sent: Monday, February 29, 2016 11:28:55 AM Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller Hi all, While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled. The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good. I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options: - For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO... - An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread... Any other ideas someone might have? Cheers, [1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/h... [2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src... -- 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

On 2 Mar 2016, at 17:23, Galder Zamarreño <galder(a)redhat.com&gt; wrote: Just an update: the prototype I worked on to add a 'datatype' metadata parameter to the script seems to be working, so I'll be sending a PR for inclusion in 8.2. Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 29 Feb 2016, at 19:46, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > > Hi all, > > I had a chat earlier with Tristan and he pointed me to the metadata information that can be passed in script header. > > Given that so far (until compatibility is supported), Javascript client only supports String key/values, a very simple solution to this problem would be to define a new metadata parameter, e.g. data-type, which can optionally define the type of key, value, parameters and returned object. E.g. in the javascript client case, I could just say: data-type=utf8 in the header of the script, and that would provide enough hints for the server to do its job by interpreting byte arrays dealt with in exec command as UTF-8 strings. > > This method is much more user friendly than having user plug a marshaller since it only requires a small change in the header of the script, as opposed to having to change server side configuration. I'm working on a prototype for this with hopes to include in 8.2. > > Cheers, > -- > Galder Zamarreño > Infinispan, Red Hat > >> On 29 Feb 2016, at 14:35, Vittorio Rigamonti <vrigamon(a)redhat.com&gt; wrote: >> >> Hi All, Hi Galder >> >> JBasicMarshaller.h is not an intent to go further along the way to implement a c++ JBossMarshaller, it has the only goal to provide a working 'exec' operation. >> The c++ exec currently works only with integer and "small" string data types, user can easily extends the marshaller to other basic types. >> >> My current model of the exec use case is this one (maybe it's too simplistic so correct me if I'm wrong): a "user defined consumer" consumes data produced by a "user defined producer", so maybe it could worth to evaluate a solution where the framework provides a common standard for communication (stringified json? or JSObject for in memory 100% Java) and let the user handle it's own data. >> This is a proposal approach specific to the exec scope, I can't say if it can be extended as a general approach where marshalling is involved. >> >> Cheers, >> Vittorio >> >> >> >> >> ----- Original Message ----- >> From: "Galder Zamarreño" <galder(a)redhat.com&gt; >> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; >> Sent: Monday, February 29, 2016 11:28:55 AM >> Subject: [infinispan-dev] HotRod exec operation tight coupling with JBoss Marshaller >> >> Hi all, >> >> While implement `exec` operation for the JS client, I've encountered an issue with how the exec parameters and return types are marshalled. >> >> The essence of the problem is that the server marshalls these objects instead of having the client drive how these are marshalled. As a result of this, for a JS or C++ client to be able to use `exec` with default configuration, they need to understand JBoss Marshaller format, which is not good. >> >> I'm not sure this would have been unavoidable due to the characteristics of `exec` but I wanted to see if we can find a good way to solve or get around this issue. Long term, we need better encoding handling both for incoming and returning types, but the question is whether we can find a way to better solve this until then. Here are some options: >> >> - For the C++ client, Vittorio has part implemented the JBoss Marshaller format [1], but I'm kinda reluctant to go down this path since that creates a lot of work for us as the number of types that can be discovered in a JBoss Marshaller format byte array are quite considerable [2]. We're bound to miss one of those and since clients could execute any script, the chances are high IMO... >> >> - An alternative would be for the JS/C++ clients to only support exec when the marshaller is one that enables compatibility mode. The idea here is that for compatibility mode to work, all clients involved are going to be set up with a marshaller that can work for all of them. Working on such marshaller is time better spent than on implementing the JBoss Marshaller format. We had a separate discussion on this topic in another dev thread... >> >> Any other ideas someone might have? >> >> Cheers, >> >> [1] https://github.com/infinispan/cpp-client/blob/master/include/infinispan/h... >> [2] https://github.com/jboss-remoting/jboss-marshalling/blob/master/river/src... >> -- >> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev