[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5357:
----------------------------------------
Another idea: use ping to provide some hints back to the client? E.g. if the server is configured with compatibility, the client could adjust hashing, see ISPN-5477
> Hot Rod protocol 3.0
> --------------------
>
> Key: ISPN-5357
> URL: https://issues.jboss.org/browse/ISPN-5357
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
>
> A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html]
> In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns.
> An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5477) Compatibility with L1 can lead to wrong return type
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-5477:
--------------------------------------
Summary: Compatibility with L1 can lead to wrong return type
Key: ISPN-5477
URL: https://issues.jboss.org/browse/ISPN-5477
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols
Affects Versions: 7.2.1.Final
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 7.2.2.Final
Currently, when using compatibility mode with distributed caches, it is possible for users to store keys using embedded API which hash differently to when the same key is access via remote API. This is due to the differences in source data. For embedded, the source object is the POJO, whereas for remote, the source object is the byte[] format of the pojo.
When using such keys, remote APIs might go to a node which is not owner, leading to a remote get. When two gets are executed, the first of which results in L1 entry being added to the container, the second get result in exceptions such as this on the client:
{code}
java.lang.ClassCastException: [B cannot be cast to xxx....
{code}
This is due to over eager unboxing by the BaseTypeConverterInterceptor. I discovered this while investigating ISPN-5449.
It would be ideal to not have scenarios where there are diverging keys but for that, clients would need to know when compatibility is enabled, which currently is not known by the clients. Maybe this could be negotiated with the ping command?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-4919) Configuration templates
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-4919:
---------------------------------------
[~pferraro] that is indeed a limitation and I'd rather have an "inherited" flag for attributes.
Please comment on the pull request.
I also had to drop the <caches> element since there would be no 1:1 match between declaration and model.
> Configuration templates
> -----------------------
>
> Key: ISPN-4919
> URL: https://issues.jboss.org/browse/ISPN-4919
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
> <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5476) Cross-site tests should run in parallel
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5476:
----------------------------------
Summary: Cross-site tests should run in parallel
Key: ISPN-5476
URL: https://issues.jboss.org/browse/ISPN-5476
Project: Infinispan
Issue Type: Task
Components: Core, Cross-Site Replication, Test Suite - Core
Affects Versions: 7.2.1.Final
Reporter: Dan Berindei
Fix For: 8.0.0.Final
Currently the cross-site tests have to run in a single thread, and that means they're much slower than the regular core tests.
It also means they need to run with a separate Maven profile, and that (combined with their duration) makes it very unlikely for devs to run the xsite tests on their machines.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5293) Create generic execution framework from EntryIterator
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5293?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-5293:
-----------------------------------------
ISPN-5219 has two 'extra' needs when it comes for iterating:
* Possibility to configure the batch size
* Possibility to pass in the segments of interest
* (Potentially) Pass in the server(s) of interest (shortcut for the above)
Do you plan to cover these?
> Create generic execution framework from EntryIterator
> -----------------------------------------------------
>
> Key: ISPN-5293
> URL: https://issues.jboss.org/browse/ISPN-5293
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce
> Reporter: William Burns
> Assignee: William Burns
>
> This framework could be used to power a segment aware map/reduce framework and other events that require execution across the cluster.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5472) Surefire crashes during LevelDB test suite
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5472?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5472:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3474
> Surefire crashes during LevelDB test suite
> ------------------------------------------
>
> Key: ISPN-5472
> URL: https://issues.jboss.org/browse/ISPN-5472
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 8.0.0.Alpha1
>
>
> Sometimes the surefire plugin has problems with the master-fork communication during the LevelDB test suite and stops the entire reactor:
> {noformat}
> [11:17:10]W: [Step 2/4] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project infinispan-cachestore-leveldb: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: java.lang.RuntimeException: 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null: NoSuchElementException -> [Help 1]
> [11:17:10] : [Step 2/4] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project infinispan-cachestore-leveldb: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: java.lang.RuntimeException: 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> [11:17:10] : [Step 2/4] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> [11:17:10] : [Step 2/4] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> [11:17:10] : [Step 2/4] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> [11:17:10] : [Step 2/4] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> [11:17:10] : [Step 2/4] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> [11:17:10] : [Step 2/4] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [11:17:10] : [Step 2/4] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [11:17:10] : [Step 2/4] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [11:17:10] : [Step 2/4] at java.lang.reflect.Method.invoke(Method.java:483)
> [11:17:10] : [Step 2/4] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [11:17:10] : [Step 2/4] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [11:17:10] : [Step 2/4] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [11:17:10] : [Step 2/4] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [11:17:10] : [Step 2/4] Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: java.lang.RuntimeException: 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> [11:17:10] : [Step 2/4] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [11:17:10] : [Step 2/4] ... 19 more
> [11:17:10] : [Step 2/4] Caused by: java.lang.RuntimeException: java.lang.RuntimeException: 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.close(ThreadedStreamConsumer.java:123)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:463)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:352)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:158)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:967)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:831)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> [11:17:10] : [Step 2/4] ... 20 more
> [11:17:10] : [Step 2/4] Caused by: java.lang.RuntimeException: 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:209)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:110)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> [11:17:10] : [Step 2/4] at java.lang.Thread.run(Thread.java:745)
> [11:17:10] : [Step 2/4] Caused by: java.util.NoSuchElementException
> [11:17:10] : [Step 2/4] at java.util.StringTokenizer.nextToken(StringTokenizer.java:349)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.deserializeStackStraceWriter(ForkClient.java:217)
> [11:17:10] : [Step 2/4] at org.apache.maven.plugin.surefire.booterclient.output.ForkClient.createReportEntry(ForkClient.java:202)
> [11:17:10] : [Step 2/4] ... 3 more
> {noformat}
> http://ci.infinispan.org/viewLog.html?buildId=26311&buildTypeId=bt9&tab=b...
> I have created a bug in Surefire: https://issues.apache.org/jira/browse/SUREFIRE-1157
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5474) Transactions created when applying state should never be replicated
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5474?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5474:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3473
> Transactions created when applying state should never be replicated
> -------------------------------------------------------------------
>
> Key: ISPN-5474
> URL: https://issues.jboss.org/browse/ISPN-5474
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 7.2.2.Final, 8.0.0.Alpha1
>
>
> {{BaseRpcInterceptor.shouldInvokeRemoteTxCommand}} forces the replication of transactional commands if the topology id changed since the start of the transaction. However, this can also apply for transaction used internally to apply state during state transfer.
> For a state transfer tx, the collection of affected keys is empty, but {{ReplicationLogic.getOwners(Collection)}} returns {{null}} instead of {{Collections.emptySet()}}, and the prepare/commit command ends up being replicated to all the other nodes.
> The extra RPC sometimes causes failures in {{ReplCommandRetryTest}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5475) Narayana should be configured to use a volatile store by default
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5475?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5475:
-------------------------------
Status: Open (was: New)
> Narayana should be configured to use a volatile store by default
> ----------------------------------------------------------------
>
> Key: ISPN-5475
> URL: https://issues.jboss.org/browse/ISPN-5475
> Project: Infinispan
> Issue Type: Task
> Components: Test Suite - Core
> Affects Versions: 7.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Alpha1
>
>
> The {{jbossts-properties.xml}} configuration file in the core module configures a file store by default, and tests have to call {{TestCacheManagerFactory.markAsTransactional()}} (or one of the methods that calls it) to configure a volatile store instead.
> Furthermore, the {{jbossts-properties.xml}} file is explicitly filtered out of the core tests jar, so other modules can't use it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5475) Narayana should be configured to use a volatile store by default
by Dan Berindei (JIRA)
Dan Berindei created ISPN-5475:
----------------------------------
Summary: Narayana should be configured to use a volatile store by default
Key: ISPN-5475
URL: https://issues.jboss.org/browse/ISPN-5475
Project: Infinispan
Issue Type: Task
Components: Test Suite - Core
Affects Versions: 7.2.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 8.0.0.Alpha1
The {{jbossts-properties.xml}} configuration file in the core module configures a file store by default, and tests have to call {{TestCacheManagerFactory.markAsTransactional()}} (or one of the methods that calls it) to configure a volatile store instead.
Furthermore, the {{jbossts-properties.xml}} file is explicitly filtered out of the core tests jar, so other modules can't use it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months
[JBoss JIRA] (ISPN-5449) java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5449?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-5449:
-------------------------------------
I believe I figured out the root cause of this. It looks like if you are using L1 and you have 2 concurrent gets for the same key and the second one is a getCacheEntry it will throw this exception. This is because the synchronizer between gets only currently returns the value and not the entry. I need to tweak the synchronizer to return the entry instead so either method can work.
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-5449
> URL: https://issues.jboss.org/browse/ISPN-5449
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.2.1.Final
> Reporter: Enrico Olivelli
> Assignee: Galder Zamarreño
> Fix For: 7.2.2.Final
>
>
> Hi,
> I'm going to upgrade to Infinspan 7.2.1final but I got into a showstopper. This error occours very frequently and the cluster becomes not usable.
> In dev enviroment I'm using only Java HotRod clients and 3 Java HotRod Servers. When I put a "byte[]" in a cache then the following error occurs.
> Using only one Hotrod server the error does not occur.
> {code}
> ERROR interceptors.InvocationContextInterceptor: ISPN000136: Execution error
> java.lang.ClassCastException: [B cannot be cast to org.infinispan.container.entries.CacheEntry
> at org.infinispan.interceptors.compat.BaseTypeConverterInterceptor.visitGetCacheEntryCommand(BaseTypeConverterInterceptor.java:118)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitGetCacheEntryCommand(AbstractVisitor.java:91)
> at org.infinispan.commands.read.GetCacheEntryCommand.acceptVisitor(GetCacheEntryCommand.java:39)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.getCacheEntry(CacheImpl.java:437)
> at org.infinispan.cache.impl.DecoratedCache.getCacheEntry(DecoratedCache.java:547)
> at org.infinispan.server.hotrod.CacheDecodeContext.get(CacheDecodeContext.scala:180)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$hotrod$HotRodDecoder$$decodeKey(HotRodDecoder.scala:103)
> at org.infinispan.server.hotrod.HotRodDecoder$$anonfun$decode$1.apply$mcV$sp(HotRodDecoder.scala:48)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:206)
> at org.infinispan.server.hotrod.HotRodDecoder$$anon$1.run(HotRodDecoder.scala:205)
> at org.infinispan.security.Security.doAs(Security.java:143)
> at org.infinispan.server.hotrod.HotRodDecoder.wrapSecurity(HotRodDecoder.scala:205)
> at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.scala:45)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:370)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:168)
> at org.infinispan.server.hotrod.HotRodDecoder.org$infinispan$server$core$transport$StatsChannelHandler$$super$channelRead(HotRodDecoder.scala:31)
> at org.infinispan.server.core.transport.StatsChannelHandler$class.channelRead(StatsChannelHandler.scala:32)
> at org.infinispan.server.hotrod.HotRodDecoder.channelRead(HotRodDecoder.scala:31)
> ....
> {code}
> Cache Server configuration:
> {code}
> Configuration wildcard = new ConfigurationBuilder()
> .locking().lockAcquisitionTimeout(lockAcquisitionTimeout)
> .concurrencyLevel(10000)
> .isolationLevel(IsolationLevel.READ_COMMITTED)
> .useLockStriping(true)
> .clustering()
> .cacheMode(CacheMode.DIST_SYNC)
> .l1().lifespan(l1ttl).enable()
> .hash().numOwners(numOwners)
> .capacityFactor(capacityFactor)
> .partitionHandling().enabled(false)
> .stateTransfer().awaitInitialTransfer(false)
> .timeout(initialTransferTimeout).fetchInMemoryState(false)
> .storeAsBinary().enabled(true)
> .storeKeysAsBinary(false).storeValuesAsBinary(false)
> .jmxStatistics().enable()
> .unsafe().unreliableReturnValues(true) // put e remove non ritornano il valore precedente, tanto a noi non interessa
> .compatibility().enable()
> .build();
> {code}
> Hotrod Endpoint:
> {code}
> HotRodServerConfigurationBuilder configBuilder = new HotRodServerConfigurationBuilder()
> .host(address)
> .port(port);
> hotrodserver.start(configBuilder
> .build(),
> manager);
> {code}
> Client side config:
> {code}
> org.infinispan.client.hotrod.configuration.ConfigurationBuilder clientBuilder = new org.infinispan.client.hotrod.configuration.ConfigurationBuilder().forceReturnValues(false);
> clientBuilder.nearCache().mode(NearCacheMode.LAZY).maxEntries(10000);
> //(for each server....)
> clientBuilder.addServer().host(serveraddress).port(serverport);
> {code}
> {code}
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(clientBuilder.build());
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 7 months