[JBoss JIRA] (ISPN-6307) Add datatype metadata script parameter for dealing with UTF-8 Strings
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6307?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-6307:
---------------------------------------
I'd probably use mime conventions for the value of datatype.
datatype="text/plain; charset=utf-8"
Although it makes it more difficult to parse, it is much more flexible
> Add datatype metadata script parameter for dealing with UTF-8 Strings
> ---------------------------------------------------------------------
>
> Key: ISPN-6307
> URL: https://issues.jboss.org/browse/ISPN-6307
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 8.2.0.Final
>
>
> Hot Rod's 'execute' operation is tightly coupled with JBoss Marshalling making it difficult to run an execute operation from Javascript, who currently supports plain, UTF-8 String keys and values.
> The essence of the problem is that the server marshalls parameters and return values 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.
> IOW, if a JS client sends a UTF-8 string as parameter, server tries to unmarshall it using the JBoss Marshaller and it fails. This happens because exec assumes the client is a Java client. The same happens with the return value.
> On top of that, the script run from Javascript would be expect cached values to be Strings.
> In order to accommodate the JS client's needs to support plain UTF-8 Strings, and also help C/C++ client, it was decided to add a new metadata parameter to the script called `datatype` which for JS scripts, it would take as value `utf8`.
> When `datatype=utf8`, the following will happen:
> 1. Parameters to the script will be assumed to be UTF-8 Strings.
> 2. Cached values would be assumed to be Strings.
> 3. The return type of the script will be transformed into byte[] encoded as UTF-8 String.
> When `datatype=utf8` is defined, no attempt to interoperate with data stored using a Java Hot Rod client or a REST client. To get such interoperability, compatibility mode would need to be enabled and both Java HR client and JS/C++ client would need to share the same marshaller. This is not yet in place but will come.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6307) Add datatype metadata script parameter for dealing with UTF-8 Strings
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6307?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6307:
-----------------------------------
Description:
Hot Rod's 'execute' operation is tightly coupled with JBoss Marshalling making it difficult to run an execute operation from Javascript, who currently supports plain, UTF-8 String keys and values.
The essence of the problem is that the server marshalls parameters and return values 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.
IOW, if a JS client sends a UTF-8 string as parameter, server tries to unmarshall it using the JBoss Marshaller and it fails. This happens because exec assumes the client is a Java client. The same happens with the return value.
On top of that, the script run from Javascript would be expect cached values to be Strings.
In order to accommodate the JS client's needs to support plain UTF-8 Strings, and also help C/C++ client, it was decided to add a new metadata parameter to the script called `datatype` which for JS scripts, it would take as value `utf8`.
When `datatype=utf8`, the following will happen:
1. Parameters to the script will be assumed to be UTF-8 Strings.
2. Cached values would be assumed to be Strings.
3. The return type of the script will be transformed into byte[] encoded as UTF-8 String.
When `datatype=utf8` is defined, no attempt to interoperate with data stored using a Java Hot Rod client or a REST client. To get such interoperability, compatibility mode would need to be enabled and both Java HR client and JS/C++ client would need to share the same marshaller. This is not yet in place but will come.
was:
Hot Rod's 'execute' operation is tightly coupled with JBoss Marshalling making it difficult to run an execute operation from Javascript, who currently supports plain, UTF-8 String keys and values.
The essence of the problem is that the server marshalls parameters and return values 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.
IOW, if a JS client sends a UTF-8 string as parameter, server tries to unmarshall it using the JBoss Marshaller and it fails. This happens because exec assumes the client is a Java client.
The same happens with the return value.
On top of that, the a script run from Javascript would be expect cached values to be Strings.
In order to accommodate the JS client's needs to support plain UTF-8 Strings, and also help C/C++ client, it was decided to add a new metadata parameter to the script called `datatype` which for JS scripts, it would take as value `utf8`.
When `datatype=utf8`, the following will happen:
1. Parameters to the script will be assumed to be UTF-8 Strings.
2. Cached values would be assumed to be Strings and a facade Cache implementation will internally make the conversion.
3. The return type of the script will be transformed into byte[] encoded as UTF-8 String.
When `datatype=utf8` is defined, no attempt to interoperate with data stored using a Java Hot Rod client or a REST client. To get such interoperability, compatibility mode would need to be enabled and both Java HR client and JS/C++ client would need to share the same marshaller. This is not yet in place but will come.
> Add datatype metadata script parameter for dealing with UTF-8 Strings
> ---------------------------------------------------------------------
>
> Key: ISPN-6307
> URL: https://issues.jboss.org/browse/ISPN-6307
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 8.2.0.Final
>
>
> Hot Rod's 'execute' operation is tightly coupled with JBoss Marshalling making it difficult to run an execute operation from Javascript, who currently supports plain, UTF-8 String keys and values.
> The essence of the problem is that the server marshalls parameters and return values 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.
> IOW, if a JS client sends a UTF-8 string as parameter, server tries to unmarshall it using the JBoss Marshaller and it fails. This happens because exec assumes the client is a Java client. The same happens with the return value.
> On top of that, the script run from Javascript would be expect cached values to be Strings.
> In order to accommodate the JS client's needs to support plain UTF-8 Strings, and also help C/C++ client, it was decided to add a new metadata parameter to the script called `datatype` which for JS scripts, it would take as value `utf8`.
> When `datatype=utf8`, the following will happen:
> 1. Parameters to the script will be assumed to be UTF-8 Strings.
> 2. Cached values would be assumed to be Strings.
> 3. The return type of the script will be transformed into byte[] encoded as UTF-8 String.
> When `datatype=utf8` is defined, no attempt to interoperate with data stored using a Java Hot Rod client or a REST client. To get such interoperability, compatibility mode would need to be enabled and both Java HR client and JS/C++ client would need to share the same marshaller. This is not yet in place but will come.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6038) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6038?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6038:
----------------------------------
Priority: Minor (was: Blocker)
> ClientAsymmetricClusterTest.testAsymmetricCluster random failures
> -----------------------------------------------------------------
>
> Key: ISPN-6038
> URL: https://issues.jboss.org/browse/ISPN-6038
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Test Suite - Server
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 8.2.0.Final
>
>
> {{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
> {noformat}
> 10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
> 10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
> java.lang.NullPointerException
> at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6310) Endpoints registered via CLI have wrong JMX name
by Martin Gencur (JIRA)
Martin Gencur created ISPN-6310:
-----------------------------------
Summary: Endpoints registered via CLI have wrong JMX name
Key: ISPN-6310
URL: https://issues.jboss.org/browse/ISPN-6310
Project: Infinispan
Issue Type: Bug
Components: CLI, Server
Affects Versions: 8.2.0.CR1
Reporter: Martin Gencur
When I register second Memcached (called "memcached2") endpoint via CLI, the resulting JMX name is
{code}
jboss.datagrid-infinispan2:type=Server,name=Memcached,component=Transport
{code}
This is wrong because when the endpoint is configured in domain.xml, the resulting address is different:
{code}
jboss.datagrid-infinispan:type=Server,name=Memcached-memcached2,component=Transport
{code}
I suppose the latter name is correct because all the other Infinispan MBeans can be found under that domain (jboss.datagrid-infinispan). OTOH, when CLI is used and the second endpoint added, the new doman jboss.datagrid-infinispan2 has only a single MBean under itself, and that is the new endpoint.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6309) Preload does not work with invalidation cache [file-store]
by Goran Jaric (JIRA)
[ https://issues.jboss.org/browse/ISPN-6309?page=com.atlassian.jira.plugin.... ]
Goran Jaric updated ISPN-6309:
------------------------------
Steps to Reproduce:
If there is some data in file-store and preload is used on invalidation cache, exception is thrown:
...
Caused by: java.lang.NullPointerException: null
at org.infinispan.remoting.rpc.RpcManagerImpl.setTopologyId(RpcManagerImpl.java:300) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:136) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:203) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.invalidateAcrossCluster(InvalidationInterceptor.java:249) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.visitCommitCommand(InvalidationInterceptor.java:138) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
...
full stacktrace available in attachment.
There is also configuration of infinispan and jgroup tcp attached as well.
This is very similar to [https://issues.jboss.org/browse/ISPN-2723#comment-12749872], since this part is true
??Looks to me the NPE comes from stateTransferManager.getCacheTopology() returning null. That could potentially happen if preloading started before StateConsumerImpl.onTopologyUpdate() has executed.??
was:
If there is some data in file-store and preload is used on invalidation cache, exception is thrown:
{quote}...
Caused by: java.lang.NullPointerException: null
at org.infinispan.remoting.rpc.RpcManagerImpl.setTopologyId(RpcManagerImpl.java:300) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:136) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:203) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.invalidateAcrossCluster(InvalidationInterceptor.java:249) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.visitCommitCommand(InvalidationInterceptor.java:138) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
...{quote}
full stacktrace available in attachment.
There is also configuration of infinispan and jgroup tcp attached as well.
This is very similar to [https://issues.jboss.org/browse/ISPN-2723#comment-12749872], since this part is true
??Looks to me the NPE comes from stateTransferManager.getCacheTopology() returning null. That could potentially happen if preloading started before StateConsumerImpl.onTopologyUpdate() has executed.??
> Preload does not work with invalidation cache [file-store]
> ----------------------------------------------------------
>
> Key: ISPN-6309
> URL: https://issues.jboss.org/browse/ISPN-6309
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.1.0.Final
> Reporter: Goran Jaric
> Priority: Critical
> Attachments: CacheException.log, infinispan.xml, jgroups-tcp.xml
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6309) Preload does not work with invalidation cache [file-store]
by Goran Jaric (JIRA)
[ https://issues.jboss.org/browse/ISPN-6309?page=com.atlassian.jira.plugin.... ]
Goran Jaric updated ISPN-6309:
------------------------------
Steps to Reproduce:
If there is some data in file-store and preload is used on invalidation cache, exception is thrown:
{code:java}
...
Caused by: java.lang.NullPointerException: null
at org.infinispan.remoting.rpc.RpcManagerImpl.setTopologyId(RpcManagerImpl.java:300) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:136) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:203) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.invalidateAcrossCluster(InvalidationInterceptor.java:249) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.visitCommitCommand(InvalidationInterceptor.java:138) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
...
{code}
full stacktrace available in attachment.
There is also configuration of infinispan and jgroup tcp attached as well.
This is very similar to [https://issues.jboss.org/browse/ISPN-2723#comment-12749872], since this part is true
??Looks to me the NPE comes from stateTransferManager.getCacheTopology() returning null. That could potentially happen if preloading started before StateConsumerImpl.onTopologyUpdate() has executed.??
was:
If there is some data in file-store and preload is used on invalidation cache, exception is thrown:
...
Caused by: java.lang.NullPointerException: null
at org.infinispan.remoting.rpc.RpcManagerImpl.setTopologyId(RpcManagerImpl.java:300) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotelyAsync(RpcManagerImpl.java:136) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:203) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.invalidateAcrossCluster(InvalidationInterceptor.java:249) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
at org.infinispan.interceptors.InvalidationInterceptor.visitCommitCommand(InvalidationInterceptor.java:138) ~[infinispan-core-8.1.0.Final.jar:8.1.0.Final]
...
full stacktrace available in attachment.
There is also configuration of infinispan and jgroup tcp attached as well.
This is very similar to [https://issues.jboss.org/browse/ISPN-2723#comment-12749872], since this part is true
??Looks to me the NPE comes from stateTransferManager.getCacheTopology() returning null. That could potentially happen if preloading started before StateConsumerImpl.onTopologyUpdate() has executed.??
> Preload does not work with invalidation cache [file-store]
> ----------------------------------------------------------
>
> Key: ISPN-6309
> URL: https://issues.jboss.org/browse/ISPN-6309
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.1.0.Final
> Reporter: Goran Jaric
> Priority: Critical
> Attachments: CacheException.log, infinispan.xml, jgroups-tcp.xml
>
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month