June 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-35) JSR107 compliant API

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-35?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on ISPN-35: --------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1186860|https://bugzilla.redhat.com/show_bug.cgi?id=1186860] from VERIFIED to CLOSED > JSR107 compliant API > -------------------- > > Key: ISPN-35 > URL: https://issues.jboss.org/browse/ISPN-35 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Manik Surtani > Assignee: Mircea Markus > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4172) Update to JCache 1.0 final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4172?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4172: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1186860|https://bugzilla.redhat.com/show_bug.cgi?id=1186860] from VERIFIED to CLOSED > Update to JCache 1.0 final > -------------------------- > > Key: ISPN-4172 > URL: https://issues.jboss.org/browse/ISPN-4172 > Project: Infinispan > Issue Type: Component Upgrade > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha3, 7.0.0.Final > > > JCache 1.0 has been released to Maven Central now. Update. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5448) NPE when configuring both SSL and authentication in the same fluid configuration API for HotRod

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5448?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5448: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1219448|https://bugzilla.redhat.com/show_bug.cgi?id=1219448] from VERIFIED to CLOSED > NPE when configuring both SSL and authentication in the same fluid configuration API for HotRod > ----------------------------------------------------------------------------------------------- > > Key: ISPN-5448 > URL: https://issues.jboss.org/browse/ISPN-5448 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Remote Protocols > Affects Versions: 7.2.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.2.Final, 8.0.0.Final > > > ConfigurationBuilder config = new ConfigurationBuilder(); > config > .security() > .authentication() > .ssl() > .enable(); > breaks with a NullPointerException -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5268) Backup segments may not be removed after failed state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5268?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5268: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1199210|https://bugzilla.redhat.com/show_bug.cgi?id=1199210] from VERIFIED to CLOSED > Backup segments may not be removed after failed state transfer > --------------------------------------------------------------- > > Key: ISPN-5268 > URL: https://issues.jboss.org/browse/ISPN-5268 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Tristan Tarrant > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Dist cache can lost data if the primary and all backups are lost at the same time. To detect such data loss, they are monitoring the tatal sum of entries from all nodes using JMX. If the sum reduces by a considerable ammount, data loss (by lost a segment) is concluded. But they found a case that the sum increases, not decreases, after failed state transfer. This is probably caused by an extra backup segment that hasn't been cleaned up when the last state transfer failed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-3944) DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3944?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3944: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1074517|https://bugzilla.redhat.com/show_bug.cgi?id=1074517] from VERIFIED to CLOSED > DistSyncL1RepeatableReadFuncTest.testNoEntryInL1GetWithConcurrentReplace random failures > ---------------------------------------------------------------------------------------- > > Key: ISPN-3944 > URL: https://issues.jboss.org/browse/ISPN-3944 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: 630, testsuite_stability > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > Attachments: dsl1rrft.log.gz > > > Random failure in DistSyncL1RepeatableReadFuncTest>DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace: > {noformat} > 00:23:34,658 ERROR (testng-DistSyncL1RepeatableReadFuncTest:) [UnitTestTestNGListener] Test testNoEntryInL1GetWithConcurrentReplace(org.infinispan.distribution.DistSyncL1RepeatableReadFuncTest) failed. > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [NodeA-57647]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNoEntryInL1GetWithConcurrentReplace(DistSyncL1FuncTest.java:193) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5420) Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5420?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5420: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1208429|https://bugzilla.redhat.com/show_bug.cgi?id=1208429] from VERIFIED to CLOSED > Thread pools are depleted by ClusterTopologyManagerImpl.waitForView() and causing deadlock > ------------------------------------------------------------------------------------------ > > Key: ISPN-5420 > URL: https://issues.jboss.org/browse/ISPN-5420 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 8.0.0.Alpha1 > > > The join process was designed in the idea that a node would start its caches in sequential order, so {{ClusterTopologyManager.waitForView()}} would block at most once for each joining node. However, WildFly actually starts {{2 * Runtime.availableProcessors()}} caches in parallel, and this can be a problem when the machine has a lot of cores and multiple nodes. > {{ClustertopologyManager.handleClusterView()}} only updates the {{viewId}} after it updated the cache topologies of each cache AND after it confirmed the availability of all the nodes with a {{POLICY_GET_STATUS}} RPC. This RPC can block, and it's very easy for the remote-executor thread pool on the coordinator to become overloades with threads like this: > {noformat} > "remote-thread-172" daemon prio=10 tid=0x00007f0cc48c0000 nid=0x28ca4 in Object.wait() [0x00007f0c5f25b000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > at org.infinispan.topology.ClusterTopologyManagerImpl.waitForView(ClusterTopologyManagerImpl.java:357) > - locked <0x00000000ff3bd900> (a java.lang.Object) > at org.infinispan.topology.ClusterTopologyManagerImpl.handleJoin(ClusterTopologyManagerImpl.java:123) > at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:162) > at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:144) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:276) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5433) JSR-107 Support for standard annotations in client-server mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5433?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5433: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1218088|https://bugzilla.redhat.com/show_bug.cgi?id=1218088] from VERIFIED to CLOSED > JSR-107 Support for standard annotations in client-server mode > -------------------------------------------------------------- > > Key: ISPN-5433 > URL: https://issues.jboss.org/browse/ISPN-5433 > Project: Infinispan > Issue Type: Feature Request > Components: JCache > Reporter: Matej Čimbora > Assignee: Tristan Tarrant > > Currently all the annotation-related logic resides in embedded module. Add support for HotRod implementation as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5542) Shorten interceptor stack for local caches

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5542?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-5542: ------------------------------------- If the test is comparing an unbounded concurrent hash map to a bounded cache then we are really comparing apples and oranges. Even the tests by Ben (who wrote caffeine) are only comparing to the old ConcurrentLinkedHashMap (note this isn't ConcurrentHashMap). > Shorten interceptor stack for local caches > ------------------------------------------ > > Key: ISPN-5542 > URL: https://issues.jboss.org/browse/ISPN-5542 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 8.0.0.Beta1 > > > Accessing local caches is much slower than plain concurrent hash maps, likely due high interceptor stack. One optimization is to have options to remove some interceptors when these are not used. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5542) Shorten interceptor stack for local caches

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5542?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5542: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/3557 (was: https://issues.jboss.org/browse/ISPN-5542) > Shorten interceptor stack for local caches > ------------------------------------------ > > Key: ISPN-5542 > URL: https://issues.jboss.org/browse/ISPN-5542 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 8.0.0.Beta1 > > > Accessing local caches is much slower than plain concurrent hash maps, likely due high interceptor stack. One optimization is to have options to remove some interceptors when these are not used. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5542) Shorten interceptor stack for local caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5542?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-5542: ------------------------------------ I'm not sure most of the overhead is likely not because of the interceptor stack: https://github.com/infinispan/infinispan/pull/3282#issuecomment-102150962 > Shorten interceptor stack for local caches > ------------------------------------------ > > Key: ISPN-5542 > URL: https://issues.jboss.org/browse/ISPN-5542 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 8.0.0.Beta1 > > > Accessing local caches is much slower than plain concurrent hash maps, likely due high interceptor stack. One optimization is to have options to remove some interceptors when these are not used. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2015