[JBoss JIRA] (ISPN-5477) Compatibility with L1 can lead to wrong return type
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5477?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5477:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3476
> 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)
10 years, 10 months
[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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 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)
10 years, 10 months