March 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4723) ClusterListenerReplTest testPrimaryOwnerGoesDownAfterBackupRaisesEvent random failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4723?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4723: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1195704|https://bugzilla.redhat.com/show_bug.cgi?id=1195704] from ON_QA to VERIFIED > ClusterListenerReplTest testPrimaryOwnerGoesDownAfterBackupRaisesEvent random failures > -------------------------------------------------------------------------------------- > > Key: ISPN-4723 > URL: https://issues.jboss.org/browse/ISPN-4723 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 7.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Priority: Blocker > Fix For: 7.0.0.Beta2 > > > This test seems to fail spuriously > http://ci.infinispan.org/viewLog.html?buildId=11756&buildTypeId=bt9 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5234) Implement single cluster view page (P1)

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-5234?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-5234: ------------------------------------ Sliders are working, values are passing to controller. I am working on filtering and computation of cache array that should be really shown in dependence on set values on sliders. > Implement single cluster view page (P1) > --------------------------------------- > > Key: ISPN-5234 > URL: https://issues.jboss.org/browse/ISPN-5234 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 8.0.0.Final > > > In our admin console current single cluster view page does not contain the following functionality that should be implemented: > * -Zoom in/out- > * Node availability/detail > * Filter by metrics (node view) > * Filter by metrics (cache view) > * Search node (search as you type) > * Search cache (search as you type) > * -Cluster switcher- > * Cluster status view -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5238) Maintain session in ispn-mgmt-console (ctrl+R)

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-5238?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-5238: ------------------------------------ [~vblagojevic] we will need to do something with this soon. It will speed up development tremendously. The thing is that node is running nodemon that is watches for changes in files in an application. When file is changed (eg. cluster.html) it reloads page, source code and immediately shows changes in your browser. Now, however, after a change, we are losing all our scope and we are not logged in application anymore. Page refreshes and there are only AngularJS brackects with empty properties shown on page. Also, some users might want to hit ctrl+R from time to time. We need to come up with some solution soon, implement it and integrate it asap, so we can build more code more easily. > Maintain session in ispn-mgmt-console (ctrl+R) > ---------------------------------------------- > > Key: ISPN-5238 > URL: https://issues.jboss.org/browse/ISPN-5238 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Tomas Sykora > Assignee: Vladimir Blagojevic > Fix For: 8.0.0.Final > > > When you reload a page in Infinispan Management Console data is lost and you need to re-login. We need to make sure that the session is maintained properly and operations like ctrl+R, F5 etc. does not affect behaviour negatively. > It will also help with development and testing when you need to reload a page to see some changes from time to time. > I did a small research around this topic and made some experiments but I was not able to achieve what I wanted. Maybe we can come up with even different approach. > Anyway I suppose we can stick to the idea that ctrl+R should just reload the page and data successfully. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5028) BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned random failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5028?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5028: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1193558|https://bugzilla.redhat.com/show_bug.cgi?id=1193558] from ON_QA to VERIFIED > BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned random failures > -------------------------------------------------------------------------- > > Key: ISPN-5028 > URL: https://issues.jboss.org/browse/ISPN-5028 > Project: Infinispan > Issue Type: Bug > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.1.0.Beta1 > > > {noformat} > 01:40:35,536 ERROR (testng-LocalEntryRetrieverEvictionTest:) [UnitTestTestNGListener] Test testExpiredEntryNotReturned(org.infinispan.iteration.LocalEntryRetrieverEvictionTest) failed. > java.lang.AssertionError: expected:<{0=0 stay in cache, 1=1 stay in cache, 2=2 stay in cache, 3=3 stay in cache, 4=4 stay in cache}> but was:<{0=0 stay in cache, 1=1 stay in cache, 2=2 stay in cache, expired=this shouldn't be returned, 3=3 stay in cache, 4=4 stay in cache}> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.iteration.BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned(BaseEntryRetrieverEvictionTest.java:56) > {noformat} > The problem is that the test measures the time expired since _before_ inserting the value, it should measure the time since _after_ inserting the value (actually {{Thread.sleep()}} would suffice). Computing the time since before the insert is only useful when check that the entry didn't expire too soon. > I have seen a failure in {{LocalEntryRetrieverEvictionTest}} on my machine, but only failures in {{ReplicatedEntryRetrieverEvictionTest}} and {{DistributedEntryRetrieverEvictionTest}} in CI: > http://ci.infinispan.org/viewLog.html?buildId=14438&tab=buildResultsDiv&b... > http://ci.infinispan.org/viewLog.html?buildId=14568&tab=buildResultsDiv&b... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4955) JCache implementation over HotRod

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4955?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4955: ---------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3264 > JCache implementation over HotRod > --------------------------------- > > Key: ISPN-4955 > URL: https://issues.jboss.org/browse/ISPN-4955 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Reporter: Tristan Tarrant > Assignee: Ion Savin > Fix For: 7.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5278) Require Maven 3.1.1 or newer

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5278?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5278: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3286 > Require Maven 3.1.1 or newer > ---------------------------- > > Key: ISPN-5278 > URL: https://issues.jboss.org/browse/ISPN-5278 > Project: Infinispan > Issue Type: Feature Request > Components: Build process > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > Assignee: Ion Savin > > wildfly-maven-plugin 1.1.0.Alpha1 breaks on 3.0.5, enforce 3.1.1 or newer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5278) Require Maven 3.1.1 or newer

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-5278?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-5278: ---------------------------- Status: Open (was: New) > Require Maven 3.1.1 or newer > ---------------------------- > > Key: ISPN-5278 > URL: https://issues.jboss.org/browse/ISPN-5278 > Project: Infinispan > Issue Type: Feature Request > Components: Build process > Affects Versions: 7.2.0.Alpha1 > Reporter: Ion Savin > Assignee: Ion Savin > > wildfly-maven-plugin 1.1.0.Alpha1 breaks on 3.0.5, enforce 3.1.1 or newer. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5274) Inconsistent data after transaction rollback (with success on originator)

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5274?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5274: ------------------------------------ Agree, it is probably better to fail the transaction in this situation. The transaction still won't be atomic, as some of the nodes will have already committed it, but it would be better than the current outcome. I believe it will be enough to fail the transaction if one of the commit command's targets is missing from the view and the local partition is unavailable. To minimize the chances of a partial commit, we should perform the check before sending the commit command, but we also need to run it after - in case the cluster split right then. The "after" check could create some false positives because it won't have access to the actual responses to the commit command, so the partition could become degraded right after the commit succeeded. This will leave the cache inconsistent, but I think it is an acceptable risk for now. > Inconsistent data after transaction rollback (with success on originator) > ------------------------------------------------------------------------- > > Key: ISPN-5274 > URL: https://issues.jboss.org/browse/ISPN-5274 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Matej Čimbora > Assignee: Dan Berindei > > Scenario > Nodes edg-perf[10-13], partition handling on > 1.Transaction is started on edg-perf10 > {code} > 10:24:48,228 TRACE [org.infinispan.transaction.xa.TransactionXaAdapter] (DefaultStressor-6) start called on tx GlobalTransaction:<edg-perf10-20667>:38910:local > {code} > 2. Value of key_000000000000065B is updated within the transaction > {code} > 10:24:48,405 TRACE [org.radargun.service.InfinispanOperations$Cache] (DefaultStressor-6) PUT cache=testCache key=key_000000000000065B value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ] > {code} > 3. Transaction is successfully prepared on edg-perf11 & edg-perf12 > {code} > 10:24:48,559 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-6) Responses: [sender=edg-perf11-61837, received=true, suspected=false] > [sender=edg-perf12-7305, received=true, suspected=false] > {code} > 4. Transaction commit is issued > {code} > 10:24:48,562 TRACE [org.infinispan.transaction.TransactionCoordinator] (DefaultStressor-6) Committing transaction GlobalTransaction:<edg-perf10-20667>:38910:local > {code} > 5. Other participating nodes (edg-perf11 & edg-perf12) are suspected... > {code} > 10:24:52,705 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf11-61837 left during remote call, ignoring > 10:24:52,716 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (DefaultStressor-6) Target node edg-perf12-7305 left during remote call, ignoring > {code} > ... as they received a new view (without edg-perf10) meanwhile. > {code} > 10:24:48,547 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,edg-perf12-7305) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf12-7305|20] (3) [edg-perf12-7305, edg-perf11-61837, edg-perf13-25187], 2 subgroups: [edg-perf13-25187|8] (1) [edg-perf13-25187], [edg-perf13-25187|19] (1) [edg-perf13-25187] > {code} > Still, the transaction is commited on edg-perf10 & updated entry is stored locally > {code} > 10:24:52,894 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Trying to commit. Key=key_000000000000065B. Operation Flag=null, L1 invalidation=false > 10:24:52,896 TRACE [org.infinispan.statetransfer.CommitManager] (DefaultStressor-6) Committing key=key_000000000000065B. It is a L1 invalidation or a normal put and no tracking is enabled! > 10:24:52,908 TRACE [org.infinispan.container.DefaultDataContainer] (DefaultStressor-6) Creating new ICE for writing. Existing=ImmortalCacheEntry{key=key_000000000000065B, value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}, metadata=EmbeddedMetadata{version=null}, new value=[6 #15: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, 3147, ] > {code} > 6. Other nodes rollback the transaction > {code} > 10:24:50,376 DEBUG [org.infinispan.transaction.TransactionTable] (transport-thread-10) Rolling back transaction GlobalTransaction:<edg-perf10-20667>:38910:remote because originator edg-perf10-20667 left the cluster > {code} > 7. edg-perf10 receives a new view, containing nodes edg-perf[10,11,13]. Incoming state transfer overwrites the updated value > {code} > 10:25:09,614 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf10-20667) ISPN000093: Received new, MERGED cluster view: MergeView::[edg-perf10-20667|22] (3) [edg-perf10-20667, edg-perf11-61837, edg-perf13-25187], 4 subgroups: [edg-perf10-20667|15] (2) [edg-perf10-20667, edg-perf11-61837], [edg-perf10-20667|19] (3) [edg-perf10-20667, edg-perf12-7305, edg-perf11-61837], [edg-perf10-20667|18] (1) [edg-perf10-20667], [edg-perf10-20667|21] (2) [edg-perf10-20667, edg-perf13-25187] > {code} > 8. get operation returns outdated value > {code} > 10:26:21,020 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (DefaultStressor-6) Response(s) to ClusteredGetCommand{key=key_000000000000065B, flags=null} is {edg-perf12-7305=SuccessfulResponse{responseValue=ImmortalCacheValue {value=[6 #14: 296, 501, 1109, 1119, 1459, 1544, 1999, 2083, 2130, 2257, 2298, 2784, 2941, 3009, ]}} } > {code} > From client perspective, this behavior is not transparent. Provided the transaction ended up successfully, presence of the updated entry can be assumed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5231) CacheNotifierImpl should wire the listener and converter with dependecies from ComponentRegistry

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5231?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5231: -------------------------------- Status: Open (was: New) > CacheNotifierImpl should wire the listener and converter with dependecies from ComponentRegistry > ------------------------------------------------------------------------------------------------ > > Key: ISPN-5231 > URL: https://issues.jboss.org/browse/ISPN-5231 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > > The wiring is already done for distributed iterators, so the same mechanism should be reused with filters that are used for events. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-5231) CacheNotifierImpl should wire the listener and converter with dependecies from ComponentRegistry

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5231?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-5231: ----------------------------------- Assignee: Adrian Nistor > CacheNotifierImpl should wire the listener and converter with dependecies from ComponentRegistry > ------------------------------------------------------------------------------------------------ > > Key: ISPN-5231 > URL: https://issues.jboss.org/browse/ISPN-5231 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.2.0.Final > > > The wiring is already done for distributed iterators, so the same mechanism should be reused with filters that are used for events. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2015