[JBoss JIRA] (ISPN-5008) 7.0.x missing cachestore-remote and extended-statistics modules
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5008?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5008:
----------------------------------
Fix Version/s: 7.0.3.Final
> 7.0.x missing cachestore-remote and extended-statistics modules
> ---------------------------------------------------------------
>
> Key: ISPN-5008
> URL: https://issues.jboss.org/browse/ISPN-5008
> Project: Infinispan
> Issue Type: Bug
…
[View More]> Components: Build process
> Affects Versions: 7.0.2.Final
> Reporter: Ion Savin
> Assignee: Ion Savin
> Fix For: 7.1.0.Alpha1, 7.0.3.Final
>
>
> The distribution/package.xml script contains declaration for adding the two modules but they are not present in the package (7.0.0->7.0.2).
> {noformat}
> <module dir="${output.dir}" target="modules/infinispan-extended-statistics" module="extended-statistics" artifact="infinispan-extended-statistics" />
> <module dir="${output.dir}" target="modules/persistence/remote" module="persistence/remote" artifact="infinispan-cachestore-remote" />
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-5007) Enhance the distribution script to detect missing artifacts
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5007?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5007:
----------------------------------
Fix Version/s: 7.0.3.Final
> Enhance the distribution script to detect missing artifacts
> -----------------------------------------------------------
>
> Key: ISPN-5007
> URL: https://issues.jboss.org/browse/ISPN-5007
> Project: Infinispan
> Issue Type: Feature …
[View More]Request
> Components: Build process
> Affects Versions: 7.0.2.Final
> Reporter: Ion Savin
> Assignee: Ion Savin
> Fix For: 7.1.0.Alpha1, 7.0.3.Final
>
>
> The build should fail if the maven artifacts to be copied into the distribution jar are not found.
> To reproduce the issue apply this patch (the build will succeed but the distribution .zip will not contain the uberjars):
> {noformat}
> diff --git a/all/pom.xml b/all/pom.xml
> index cecd6c6..779ed97 100644
> --- a/all/pom.xml
> +++ b/all/pom.xml
> @@ -25,7 +25,7 @@
> <executions>
> <execution>
> <id>mrproper</id>
> - <phase>prepare-package</phase>
> + <phase>initialize</phase>
> <goals>
> <goal>clean</goal>
> </goals>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-4975) Cross site state transfer - status of push gets stuck at "SENDING" after being cancelled
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4975?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4975:
----------------------------------
Fix Version/s: 7.0.3.Final
> Cross site state transfer - status of push gets stuck at "SENDING" after being cancelled
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-4975
> URL: https://issues.jboss.org/browse/ISPN-4975
> …
[View More]Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Alpha1, 7.0.3.Final
>
>
> After invoking: site --cancelpush backupSite on the producer site, status of the push operation seems to get stuck at "SENDING" value (tested by site --pushstatus), even if state transfer is not currently in progress.
> Invoking site --cancelreceive mainSite on the consumer site works correctly. New invocation of site --push backupsite leads to "X-Site state transfer to '%s' already started!" being displayed. The issue seems to be caused by XSiteStateTransferManagerImpl.siteCollector not being cleared.
> Used configuration:
> distributed caches, site A: 2 nodes, site B: 3 nodes, B is a backup for A.
> Scenario
> - Start A,B
> - Take B offline using takeSiteOffline
> - Load data into A
> - Push state into B
> - CancelPushState B
> -- PushStateStatus remains stuck at SENDING & new push is not possible
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-5030) NPE during node rebalance after a leave
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5030?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5030:
----------------------------------
Fix Version/s: 7.0.3.Final
> NPE during node rebalance after a leave
> ---------------------------------------
>
> Key: ISPN-5030
> URL: https://issues.jboss.org/browse/ISPN-5030
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects …
[View More]Versions: 7.1.0.Alpha1
> Reporter: Sanne Grinovero
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 7.1.0.Beta1, 7.0.3.Final
>
>
> I'm seeing stacktraces dumped to standard out during the normal test run of the infinispan-core module:
> {noformat}
> 2014-11-28 21:39:52,652 WARN [CacheTopologyControlCommand] (remote-thread-DistributedEntryRetrieverTest-NodeA-p610-t6) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=org.infinispan.iteration.DistributedEntryRetrieverTest, type=LEAVE, sender=DistributedEntryRetrieverTest-NodeC-12939, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=2}
> java.lang.NullPointerException
> at org.infinispan.topology.ClusterCacheStatus.updateRebalanceMembers(ClusterCacheStatus.java:307)
> at org.infinispan.topology.ClusterCacheStatus.doLeave(ClusterCacheStatus.java:578)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleLeave(ClusterTopologyManagerImpl.java:148)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:164)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:278)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This is the unmodified testsuite, in current master {{33c5f85}}. It doesn't seem to cause actual test failures.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-4989) infinispan-transport thread name is undefined
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4989?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4989:
----------------------------------
Fix Version/s: 7.0.3.Final
> infinispan-transport thread name is undefined
> ---------------------------------------------
>
> Key: ISPN-4989
> URL: https://issues.jboss.org/browse/ISPN-4989
> Project: Infinispan
> Issue Type: Enhancement
> Components: …
[View More]Server
> Affects Versions: 7.0.1.Final
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Priority: Minor
> Fix For: 7.1.0.Alpha1, 7.1.0.Final, 7.0.3.Final
>
>
> In stack trace, all infinispan-transport threads appear as "undefined".
> {noformat}
> "undefined" prio=10 tid=0x00007f536528e800 nid=0x7da waiting on condition [0x00007f534835b000]
> {noformat}
> We can add the {{thread-name-pattern="%G %f-%t"}} on the infinispan-transport thread factory.
> {noformat}
> %t - emit the per-factory thread sequence number
> %g - emit the global thread sequence number
> %f - emit the factory sequence number
> %i - emit the thread ID
> %G - emit the thread group name
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4979:
----------------------------------
Fix Version/s: 7.0.3.Final
> CacheStatusResponse map uses too much memory
> --------------------------------------------
>
> Key: ISPN-4979
> URL: https://issues.jboss.org/browse/ISPN-4979
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State …
[View More]Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.1.0.Alpha1, 7.1.0.Final, 7.0.3.Final
>
>
> When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory.
> We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-4444) After state transfer, a node is able to read keys it no longer owns from its data container
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4444?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4444:
----------------------------------
Fix Version/s: 7.0.3.Final
> After state transfer, a node is able to read keys it no longer owns from its data container
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-4444
> URL: https://issues.jboss.org/browse/ISPN-4444
> …
[View More] Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Alpha1, 7.0.3.Final
>
>
> When state transfer ends and each node receives a CH_UPDATE command from the coordinator, it first installs the new topology and then it starts invalidating entries it no longer owns.
> However, there are two cases when the node can still read its stale values:
> 1. If L1 is enabled, it will look in the local DataContainer first, regardless of the key's location.
> 2. If L1 is disabled, but the key was removed on the new owners, the node will still look up the key in the local DataContainer after receiving a null response.
> The problem can be reproduced with {{TxReadAfterLosingOwnershipTest}} and its subclasses, by replacing the {{operation.update(cache(1));}} line with {{operation.update(cache(0));}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months