[JBoss JIRA] (ISPN-3866) Parser60.parseStore() ignores store configurations if they are not a SingleFileStore or a ClusterLoader
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3866?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3866:
-------------------------------
Fix Version/s: 7.0.0.Alpha2
(was: 7.0.0.Alpha1)
> Parser60.parseStore() ignores store configurations if they are not a SingleFileStore or a ClusterLoader
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3866
> URL: https://issues.jboss.org/browse/ISPN-3866
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 6.0.1.Final
> Reporter: Guillermo GARCIA OCHOA
> Assignee: Tristan Tarrant
> Priority: Critical
> Fix For: 7.0.0.Alpha2
>
>
> The {{Parser60.parseStore()}} methods ignores all store definition that is not a {{SingleFileStore}} or a {{ClusterLoader}}
> {code:java}
> private void parseStore(final XMLExtendedStreamReader reader, final ConfigurationBuilderHolder holder) throws XMLStreamException {
> ConfigurationBuilder builder = holder.getCurrentConfigurationBuilder();
> CacheLoader store = null;
> Boolean fetchPersistentState = null;
> Boolean ignoreModifications = null;
> Boolean purgeOnStartup = null;
> Boolean preload = null;
> Boolean shared = null;
> // Here it reads the attributes that the AbstractStoreConfiguration defines
> for (int i = 0; i < reader.getAttributeCount(); i++) {
> ParseUtils.requireNoNamespaceAttribute(reader, i);
> String value = replaceProperties(reader.getAttributeValue(i));
> Attribute attribute = Attribute.forName(reader.getAttributeLocalName(i));
> ...
> }
> // Then it will use the read attributes (and parse the childrens tags)
> // if and only if the configure store is a SingleFileStore or ClusterLoader
> if (store != null) {
> if (store instanceof SingleFileStore) {
> ...
> parseStoreChildren(reader, sfs);
> } else if (store instanceof ClusterLoader) {
> ...
> parseLoaderChildren(reader, cscb);
> }
> }
> }
> {code}
> This means that there is no way to set a configuration to my custom cache store with the default parser {{Parser60}}.
> If there is another way to what I'm asking for, please let me know because in the documentation only refers to the {{SingleFileStore}} implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (ISPN-3984) CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3984?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3984:
-------------------------------
Fix Version/s: 7.0.0.Alpha2
(was: 7.0.0.Alpha1)
> CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys random failures
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3984
> URL: https://issues.jboss.org/browse/ISPN-3984
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Vladimir Blagojevic
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha2
>
> Attachments: cmdtnmrt.log.gz
>
>
> The random failures in CompatModeDistributedTwoNodesMapReduceTest.testInvokeMapReduceOnAllKeys seem to be caused by state transfer being disabled in the test's caches.
> {noformat}
> 12:11:51,674 ERROR (testng-CompatModeDistributedTwoNodesMapReduceTest:) [UnitTestTestNGListener] Test testInvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.CompatModeDistributedTwoNodesMapReduceTest) failed.
> java.lang.AssertionError: key 'well' does not have count 1 but 2
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:224)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.verifyResults(BaseWordCountMapReduceTest.java:334)
> at org.infinispan.distexec.mapreduce.BaseWordCountMapReduceTest.testInvokeMapReduceOnAllKeys(BaseWordCountMapReduceTest.java:162)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (ISPN-3983) Remove some performance bottlenecks from ProtoStream
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3983?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3983:
-------------------------------
Fix Version/s: 7.0.0.Alpha2
(was: 7.0.0.Alpha1)
> Remove some performance bottlenecks from ProtoStream
> ----------------------------------------------------
>
> Key: ISPN-3983
> URL: https://issues.jboss.org/browse/ISPN-3983
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Querying
> Affects Versions: 6.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Labels: 6.3remotequeries, 630
> Fix For: 7.0.0.Final, 7.0.0.Alpha2
>
>
> Profiling has shown that there are many HashMaps created in MessageContext to help field lookup by name.
> Normally this is a static piece of information that should be computed only once when a marshaller is registered and then it should become immutable and be reused.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (ISPN-3941) Add pre-release stable version check for maven dependencies
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3941?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3941:
-------------------------------
Fix Version/s: 7.0.0.Alpha2
(was: 7.0.0.Alpha1)
> Add pre-release stable version check for maven dependencies
> -----------------------------------------------------------
>
> Key: ISPN-3941
> URL: https://issues.jboss.org/browse/ISPN-3941
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build process
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.0.0.Alpha2
>
>
> We need to enhance our maven build to perform the following dependecy checks before doing a release:
> 1. no SNAPSHOT dependencies are used
> 2. all dependencies are Final if the current build is a Final
> Rule #2 might not be implementable for some external dependencies (some organizations use weird version schemes), so we might want to do this check only for org.jboss, org.infinispan artifact groups.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3942:
-------------------------------
Fix Version/s: 7.0.0.Alpha2
(was: 7.0.0.Alpha1)
> HotRod client keep trying recover a connection to a cluster member after shutdown
> ---------------------------------------------------------------------------------
>
> Key: ISPN-3942
> URL: https://issues.jboss.org/browse/ISPN-3942
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 6.0.1.Final, 7.0.0.Alpha1
> Environment: Infinispan server with HotRod client in server-client mode and replicated caches.
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: clustered, hotrod, hotrod-java-client
> Fix For: 7.0.0.Final, 7.0.0.Alpha2
>
> Attachments: hotrod-client.log
>
>
> If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed.
> There is only a replicated cache configured.
> From the server-logfile the new cluster view is established
> 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered]
> There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server.
> This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months