June 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6800) Remove MultipleRpcCommand

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6800?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6800: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > Remove MultipleRpcCommand > ------------------------- > > Key: ISPN-6800 > URL: https://issues.jboss.org/browse/ISPN-6800 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Alpha3, 9.0.0.Final > > > Having {{MultipleRpcCommand}} makes some things more complex than they should be, e.g. {{CacheRpcCommandExternalizer}} needs a thread-local because of it. > It was only used by the replication queue, which has been already removed in ISPN-6417. So it's safe to remove it completely and simplify {{CacheRpcCommandExternalizer}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6703) ClearCommand hanging in the test suite

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6703?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-6703: --------------------------------------- Assignee: Gustavo Fernandes (was: Dan Berindei) > ClearCommand hanging in the test suite > -------------------------------------- > > Key: ISPN-6703 > URL: https://issues.jboss.org/browse/ISPN-6703 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Alpha2, 8.2.2.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > {noformat} > "testng-ClusteredCacheWithInfinispanDirectoryTest" #15 prio=5 os_prio=0 tid=0x00007fe220532000 nid=0x19a waiting on condition [0x00007fe1cc7dd000] > java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000007b8698d48> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) > at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:96) > at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:97) > at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:366) > at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:281) > at org.infinispan.statetransfer.StateTransferInterceptor.visitClearCommand(StateTransferInterceptor.java:132) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:58) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:58) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99) > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113) > at org.infinispan.commands.AbstractVisitor.visitClearCommand(AbstractVisitor.java:58) > at org.infinispan.commands.write.ClearCommand.acceptVisitor(ClearCommand.java:44) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335) > at org.infinispan.cache.impl.CacheImpl.clear(CacheImpl.java:588) > at org.infinispan.cache.impl.CacheImpl.clear(CacheImpl.java:579) > at org.infinispan.test.TestingUtil.killCaches(TestingUtil.java:769) > at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:607) > at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:101) > at sun.reflect.GeneratedMethodAccessor214.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564) > at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:786) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6813) Add SNI support for REST

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6813?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-6813: -------------------------------------- Fix Version/s: (was: 9.0.0.Final) (was: 9.0.0.Alpha2) > Add SNI support for REST > ------------------------ > > Key: ISPN-6813 > URL: https://issues.jboss.org/browse/ISPN-6813 > Project: Infinispan > Issue Type: Sub-task > Components: Security, Server > Reporter: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6813) Add SNI support for REST

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-6813?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned ISPN-6813: ----------------------------------------- Assignee: Sebastian Łaskawiec > Add SNI support for REST > ------------------------ > > Key: ISPN-6813 > URL: https://issues.jboss.org/browse/ISPN-6813 > Project: Infinispan > Issue Type: Sub-task > Components: Security, Server > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6813) Add SNI support for REST

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-6813: ----------------------------------------- Summary: Add SNI support for REST Key: ISPN-6813 URL: https://issues.jboss.org/browse/ISPN-6813 Project: Infinispan Issue Type: Sub-task Reporter: Sebastian Łaskawiec -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5721) Add SNI support to the endpoints

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-5721?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reopened ISPN-5721: --------------------------------------- > Add SNI support to the endpoints > -------------------------------- > > Key: ISPN-5721 > URL: https://issues.jboss.org/browse/ISPN-5721 > Project: Infinispan > Issue Type: Feature Request > Components: Security, Server > Affects Versions: 8.0.0.Final > Reporter: Tristan Tarrant > Assignee: Sebastian Łaskawiec > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > Openshift Router uses DNS names to perform routing. It is perfectly legal to have this kind of configuration: > {code} > client 1 --> example.com:11222 -----+> Hotrod server > / > client 2 --> example2.com:11222 / > {code} > In that case the TLS configuration might be problematic (since very often certificates are issued for a domain name). However it is possible to use [SNI TLS Extension|https://tools.ietf.org/html/rfc6066#page-6]. > The SNI needs to be added to: > * Client's configuration (it needs to modify it's own {{SSLContext}} and add {{SSLParams}} > * Hotrod server to support SNI (with Netty) > * XML Configuration for Hotrod -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6812) JavaDoc still has references to NotifyingFuture

by Alan Field (JIRA)

Alan Field created ISPN-6812: -------------------------------- Summary: JavaDoc still has references to NotifyingFuture Key: ISPN-6812 URL: https://issues.jboss.org/browse/ISPN-6812 Project: Infinispan Issue Type: Bug Affects Versions: 9.0.0.Alpha2 Reporter: Alan Field The following classes still refer to {{NotifyingFuture}} in the JavaDoc, even though the code has been changed to use {{CompletableFuture}} : {{AsyncCache.java}} (5 matches) {{DistributedExecutionCompletionService.java}} (5 matches) {{Cache.java}} (6 matches) It also looks like the {{FutureAssertion.java}} class is no longer needed? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6350) Data race in the ShardIndexManager under topology changes

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6350?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6350: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4433 > Data race in the ShardIndexManager under topology changes > --------------------------------------------------------- > > Key: ISPN-6350 > URL: https://issues.jboss.org/browse/ISPN-6350 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.2.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Labels: affinity > > The following example data race can cause unrecoverable errors during indexing: > \[node1\] cache.put(key) // key maps to segment 48, owned by node1 > \[node1\] starts shard 48 > \[node1\] acquires lock on shard 48 > \[node1\] starts writing to the index > \[node1\] notification of topology changed, lock released on shard 48 > \[node1\] lock reacquired (still writing to the index) > \[node1\] commit on shard 48 > \[node1\] shard still locked > \[node2\] cache.put(key) // Node2 now owns segment 48 > \[node2\] starts shard 48 > \[node2\] tries to acquire the lock on shard 48 > \[node2\] fail (lock still owned by node1) > The current mechanism employed by the {{ShardIndexManager}} during topology changes involves using a listener and closing the IndexWriter on all nodes upon ownership changes, so that the lock is released and can be reacquired by the new owner (1 segment maps to 1 shard). > Since writing to a shard can take some time, the listener can be triggered in the middle of an index operation and the closing of the index writer will have a very short duration because it is sudden reacquired, and not released anymore. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6777) Improve Cache Stores configuration screen

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6777?page=com.atlassian.jira.plugin.... ] Work on ISPN-6777 started by Ryan Emerson. ------------------------------------------ > Improve Cache Stores configuration screen > ----------------------------------------- > > Key: ISPN-6777 > URL: https://issues.jboss.org/browse/ISPN-6777 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Reporter: Pedro Zapata > Assignee: Ryan Emerson > Fix For: 9.0.0.Beta2 > > > Infinispan administrators should be able to select and configure any cache store easily, without having to enter class names and other free-form properties. > Only one tab ‘Cache store’ will be displayed in the cache configuration options > The user will have the option to select a type of store from the list (Single File, LevelDB, …) + the option ‘NONE’ > When the option is changed, all the generic + specific properties will be shown below. > Properties should be presented as combos, if they are enumerable. For example, class (if there’s a way of filtering all implementing classes in classpath). > Sensible defaults should be set. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6777) Improve Cache Stores configuration screen

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6777?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6777: ------------------------------- Status: Open (was: New) > Improve Cache Stores configuration screen > ----------------------------------------- > > Key: ISPN-6777 > URL: https://issues.jboss.org/browse/ISPN-6777 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Reporter: Pedro Zapata > Assignee: Ryan Emerson > Fix For: 9.0.0.Beta2 > > > Infinispan administrators should be able to select and configure any cache store easily, without having to enter class names and other free-form properties. > Only one tab ‘Cache store’ will be displayed in the cache configuration options > The user will have the option to select a type of store from the list (Single File, LevelDB, …) + the option ‘NONE’ > When the option is changed, all the generic + specific properties will be shown below. > Properties should be presented as combos, if they are enumerable. For example, class (if there’s a way of filtering all implementing classes in classpath). > Sensible defaults should be set. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2016