[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:
------------------------------------
Ok, so you are only testing read access, and no eviction... the link I posted isn't relevant in this case.
The results were a bit lower and more tightly grouped on my machine (i7-4900MQ, OpenJDK 1.8.0_45 with {{-server -XX:+AggressiveOpts -XX:+UseCompressedOops}}):
{noformat}
Benchmark Mode Cnt Score Error Units
MapBenchmark.testCache thrpt 200 11450421.970 ± 64022.513 ops/s
MapBenchmark.testChm thrpt 200 121654143.099 ± 349886.912 ops/s
MapBenchmark.testDataContainer thrpt 200 96444066.368 ± 1088248.658 ops/s
{noformat}
Still, it's weird how huge the difference between the CHM and DataContainer results are, considering that all {{DataContainer.get(k)}} does extra is {{if(e != null && e.canExpire())}} and that {{canExpire()}} can be replaced by the JIT with {{false}}. I really expected {{DC.get()}} to be inlined and for DC to perform exactly the same as CHM, but I guess there's still a type guard in there.
> 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, 8 months
[JBoss JIRA] (ISPN-5324) Create extended RemoteCacheManager for testing purposes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5324?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5324:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1205828|https://bugzilla.redhat.com/show_bug.cgi?id=1205828] from VERIFIED to CLOSED
> Create extended RemoteCacheManager for testing purposes
> -------------------------------------------------------
>
> Key: ISPN-5324
> URL: https://issues.jboss.org/browse/ISPN-5324
> Project: Infinispan
> Issue Type: Feature Request
> Components: Test Suite - Core
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 7.2.0.Beta2
>
>
> The extended RemoteCacheManager should expose details such as the following:
> * transportFactory
> The implementation should be internal and NOT part of public API.
> This way we can get rid of reflection in tests for HotRod client and these tests can be reused for C++ and C# HotRod clients. Any tests that use reflection are currently unusable for those implementations.
> The ultimate goal is to extend the test suite for C++ and C# clients.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4546:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1163727|https://bugzilla.redhat.com/show_bug.cgi?id=1163727] from VERIFIED to CLOSED
> Possible stale lock when the primary owner leaves during rebalance
> ------------------------------------------------------------------
>
> Key: ISPN-4546
> URL: https://issues.jboss.org/browse/ISPN-4546
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.0.Alpha5, 7.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 7.2.0.Final
>
>
> Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null
> B sends prepareCommand(tx1, put(k, v)) to C, D
> D adds backup locks and replies
> C acquires lock, ready to send reply to B
> A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E]
> A, C and E install topology T+1, B and D do not
> E requests and receives tx data from C, including tx1
> C leaves
> B sees a SuspectException, sends rollbackCommand(tx1) to C, D
> D removes tx1
> C has left, but is ignored
> B reports to the user that the tx has been rolled back
> B and D install topology T+1 (optional)
> A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E]
> A, B, D, E all install topology T+2
> E requests and receives state from D, but it does not remove tx1
> A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null
> E now has a stale backup lock on k
> It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E.
> A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months
[JBoss JIRA] (ISPN-5304) WildFly module "/org/infinispan/client/hotrod/jdg-6.4" is different if installed with library or HR-client
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5304?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5304:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1205568|https://bugzilla.redhat.com/show_bug.cgi?id=1205568] from VERIFIED to CLOSED
> WildFly module "/org/infinispan/client/hotrod/jdg-6.4" is different if installed with library or HR-client
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5304
> URL: https://issues.jboss.org/browse/ISPN-5304
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 7.2.0.Alpha1, 7.1.1.Final
> Environment: Infinispan as WildFly module
> Reporter: Wolf-Dieter Fink
> Assignee: Adrian Nistor
> Fix For: 7.2.0.Beta2, 7.2.0.Final, 7.2.1.Final
>
>
> If Infinispan is used inside WildFly applications there are two WF modules for Infinispan.
> One for Library mode
> One for HotRod remote client mode
> Both modules contain
> modules/org/infinispan/client/hotrod/jdg-6.4/infinispan-client-hotrod-6.2.0.Final-redhat-4.jar
> modules/org/infinispan/client/hotrod/jdg-6.4/module.xml
> BUT
> the module.xml is different:
> < <module name="org.infinispan" slot="jdg-6.4"/>
> ---
> > <module name="org.infinispan.commons" slot="jdg-6.4"/>
> > <module name="org.infinispan.protostream" slot="jdg-6.4"/>
> > <module name="org.infinispan.query.dsl" slot="jdg-6.4"/>
> > <module name="org.infinispan.query.remote.client" slot="jdg-6.4"/>
> This mean it is not possible to use both modules if there are applications with library mode and others with HR remote client mode.
> Also it is odd because it depends on the installation order what dependencies are installed.
> It should be possible to install both modules and use it at the same time from different applicaitons.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 8 months