November 2016 - infinispan-issues

[JBoss JIRA] (ISPN-7172) Total order caches can hang during join

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7172?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7172: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Total order caches can hang during join > --------------------------------------- > > Key: ISPN-7172 > URL: https://issues.jboss.org/browse/ISPN-7172 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.0.0.Beta1 > > > When two nodes join a cache in quick sequence, it's possible for a {{CacheTopologyControlCommand}} to arrive between {{LocalTopologyManagerImpl}} adding the {{LocalCacheStatus}} to the {{runningCaches}} map, but before it calling {{cacheStatus.getTopologyUpdatesExecutor().executeAsync(() -> joinFuture)}} to block topology updates. > This exposes a bug in the way {{LimitedExecutor}} wraps a {{WithinThreadExecutor}}, which causes {{SyncPrepareUseSynchronizationTotalOrderTest}} (and possibly other total order tests) to hang: > {noformat} > "testng-SyncPrepareUseSynchronizationTotalOrderTest" #15 prio=5 os_prio=0 tid=0x00007fc674b74000 nid=0x2f3f waiting on condition [0x00007fc626682000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000000829d03a0> (a java.util.concurrent.CompletableFuture$Signaller) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.CompletableFuture$Signaller.block(CompletableFuture.java:1687) > at java.util.concurrent.ForkJoinPool.managedBlock(ForkJoinPool.java:3320) > at java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1767) > at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1907) > at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82) > at org.infinispan.executors.LimitedExecutor.execute(LimitedExecutor.java:70) > at org.infinispan.executors.LimitedExecutor.executeAsync(LimitedExecutor.java:96) > at org.infinispan.topology.LocalTopologyManagerImpl.join(LocalTopologyManagerImpl.java:141) > at org.infinispan.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:121) > at sun.reflect.GeneratedMethodAccessor146.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:867) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:633) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:622) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:547) > - locked <0x00000000829d0520> (a org.infinispan.factories.ComponentRegistry) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:231) > at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:808) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:639) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:590) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:454) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:422) > at org.infinispan.test.MultipleCacheManagersTest.getCaches(MultipleCacheManagersTest.java:248) > at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:257) > at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:266) > at org.infinispan.tx.totalorder.simple.BaseSimpleTotalOrderTest.createCacheManagers(BaseSimpleTotalOrderTest.java:326) > at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:109) > at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:119) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6906) Reduce dependency on JBoss Marshalling

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6906?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6906: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4620, https://github.com/infinispan/infinispan/pull/4648, https://github.com/infinispan/infinispan/pull/4627 (was: https://github.com/infinispan/infinispan/pull/4530, https://github.com/infinispan/infinispan/pull/4620, https://github.com/infinispan/infinispan/pull/4626, https://github.com/infinispan/infinispan/pull/4627) > Reduce dependency on JBoss Marshalling > -------------------------------------- > > Key: ISPN-6906 > URL: https://issues.jboss.org/browse/ISPN-6906 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.0.0.Final > > > Since its inception Infinispan has been using JBoss Marshalling to deal with all the marshalling needs. With some tweaking (e.g. hooking a custom ObjectTable instance), the JBoss Marshalling based Infinispan externalizer layer is able to produce tiny binary payloads but it has some problems partly due to JBoss Marshalling itself and partly due to our own implementation details: > JBoss Marshalling's objective has always been to try to produce a binary format that passes Java specification, but this is not a requirement for Infinispan. In fact, to reduce the payload size, Infinispan hooks at the ObjectTable level to produce minimal payload sizes. > On top of the mismatch problems mentioned above, JBoss Marshalling’s programming model is based around creating a marshaller, writing to it, and then finishing using it by discarding its context (same applies to unmarshalling). The problem here is two-fold: > * Both marshaller and unmarshaller are quite heavy objects, keeping context information such as references to instances appearing multiple times...etc, so constantly creating them is costly. So, to avoid wasting resources, we ended up adding thread locals that keep a number of marshaller/unmarshaller instances per thread (see ISPN-1815). These thread locals can potentially affect memory space (see user dev post). > * The second problem is the need to support reentrant marshalling calls when storing data in binary format. The need for reentrancy appears in situations like this: Imagine you have to marshall a PutKV command, so you start a marshaller and write some stuff. Then, you have store the key and value, but these are binary so they have to be transformed into binary format, so again a marshaller needs to be created and key/value information written, finish with the marshaller and then write the bytes in the command itself. So, there needs to be a way to start two marshallers without having finished the first one. This is the reason why the changes added in ISPN-1815 resulted in the thread local keeping a number of marshaller/unmarshaller instances rather than a single one. > Finally, for inter-node cluster communication and storing data in persistence layer, Infinispan is using JBoss Marshalling for both marshalling the types it knows about, e.g. internal data types, and types it does not know about, e.g. key and value types. This means that even if the marshaller is configurable, it’s not easy to switch to a different marshaller (see here for an example where we try to use a different marshaller). This problem is not present in Hot Rod Java clients since there JBoss Marshalling is purely used to marshall keys and values, so it’s very easy to test out a different marshaller. > With all this in mind, the following change recommendations can be made: > * For those types that we know about, marshall those manually in the most compact way possible. JBoss Marshalling codebase does a lot of these for encoding basic types (e.g. Strings, numbers)...etc, so we should be able to reuse them. > * Only rely on 3rd party marshalling libraries for types we don’t know about, e.g. key and value types (If these key/value types happen to be primitives, or primitive derivations (e.g. arrays), we should be able to optimise those too. So, you only rely on 3rd party marshalling libraries for custom unknown types.). The benefit here is the we decouple Infinispan from using JBoss Marshalling all over the place, making it easier to try different marshalling mechanisms. > * With JBoss Marshalling only used for unknown custom types, if the JBoss Marshalling marshaller implementation wants to use thread locals, that's fine, but then we effectively get rid of them except for custom types when JBoss Marshalling marshaller is used, plus we can switch/try different 3rd party marshallers which might be better suited. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7214) Scope server restarts to server group

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7214?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-7214: -------------------------------------- Status: Open (was: New) > Scope server restarts to server group > ------------------------------------- > > Key: ISPN-7214 > URL: https://issues.jboss.org/browse/ISPN-7214 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.Alpha4, 8.1.6.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Beta1 > > > We are restarting all server groups when we need to restart servers (due to a configuration change). We should scope server restarts only to an affected server group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7214) Scope server restarts to server group

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7214?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-7214: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/144 > Scope server restarts to server group > ------------------------------------- > > Key: ISPN-7214 > URL: https://issues.jboss.org/browse/ISPN-7214 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.Alpha4, 8.1.6.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Beta1 > > > We are restarting all server groups when we need to restart servers (due to a configuration change). We should scope server restarts only to an affected server group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7214) Scope server restarts to server group

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-7214: ----------------------------------------- Summary: Scope server restarts to server group Key: ISPN-7214 URL: https://issues.jboss.org/browse/ISPN-7214 Project: Infinispan Issue Type: Bug Components: Console Affects Versions: 8.1.6.Final, 9.0.0.Alpha4 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 9.0.0.Beta1 We are restarting all server groups when we need to restart servers (due to a configuration change). We should scope server restarts only to an affected server group. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7206) Administration console - task history only shows last 10 tasks

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7206?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-7206: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/143 > Administration console - task history only shows last 10 tasks > -------------------------------------------------------------- > > Key: ISPN-7206 > URL: https://issues.jboss.org/browse/ISPN-7206 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.Alpha4 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > > Click on cache container -> Tasks execution -> Task history > This only shows last 10 tasks, there should probably be an option to display more (like in the events page), or the user should be able to go to the next page to see older tasks. > If this is an intention, there should be an indication that only last 10 tasks are displayed and that the rest can be found in events tab. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7206) Administration console - task history only shows last 10 tasks

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7206?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-7206: -------------------------------------- Status: Open (was: New) > Administration console - task history only shows last 10 tasks > -------------------------------------------------------------- > > Key: ISPN-7206 > URL: https://issues.jboss.org/browse/ISPN-7206 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.Alpha4 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > > Click on cache container -> Tasks execution -> Task history > This only shows last 10 tasks, there should probably be an option to display more (like in the events page), or the user should be able to go to the next page to see older tasks. > If this is an intention, there should be an indication that only last 10 tasks are displayed and that the rest can be found in events tab. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7185) Confirmation dialog is not displayed when changing configuration

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7185?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic resolved ISPN-7185. --------------------------------------- Resolution: Cannot Reproduce Bug > Confirmation dialog is not displayed when changing configuration > ---------------------------------------------------------------- > > Key: ISPN-7185 > URL: https://issues.jboss.org/browse/ISPN-7185 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.Alpha4 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Attachments: Screen Shot 2016-11-10 at 7.41.57 AM.png > > > When changing configuration there should be confirmation pop-up dialog. > (Confirmation: Update configuration template distributedCache? "Cancel" "Confirm") > Steps to reproduce: > click on cache container -> Configuration -> Transport -> change lock timeout -> click save -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6742) Console shows cache available and disabled at the same time

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6742?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-6742: -------------------------------------- Status: Pull Request Sent (was: Reopened) > Console shows cache available and disabled at the same time > ----------------------------------------------------------- > > Key: ISPN-6742 > URL: https://issues.jboss.org/browse/ISPN-6742 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.2.2.Final > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 9.0.0.Alpha3 > > Attachments: attachment.png > > > Page: go to cache detail and click "Actions" -> "Disable". > After confirmation, the cache status is still "Available", but new red box appears with text "Disabled", see the attachment. This doesn't seem to me very intuitive, if the cache is disabled, it should be IMO unavailable and this should be also reflected in the caches list. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6776) Administration console - push state transfer and cancel state transfer buttons don't work properly

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6776?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-6776: -------------------------------------- Status: Open (was: New) > Administration console - push state transfer and cancel state transfer buttons don't work properly > -------------------------------------------------------------------------------------------------- > > Key: ISPN-6776 > URL: https://issues.jboss.org/browse/ISPN-6776 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Attachments: domain.xml, host.xml > > > Click on cache container -> Actions -> Manage backup sites -> Push state (on BRN site which is configured) > result: nothing happens, server log: > [Server:server-one] 15:15:03,752 ERROR [org.jgroups.protocols.relay.RELAY2] (ServerService Thread Pool -- 36) master:server-one: no route to BRN: dropping message > expected result: Success! The operation has been successfully executed. > Please note that if we take the site offline and then online again in the "Manage backup sites" dialog, push state button works correctly. > Cancel state button is behaving the same, except taking site offline and then online again doesn't help. > I'm attaching server configuration -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2016