[JBoss JIRA] (ISPN-1242) Add dynamic grouping capabilities for unmodifiable key classes.
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1242?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-1242.
---------------------------------
Resolution: Won't Fix
> Add dynamic grouping capabilities for unmodifiable key classes.
> ---------------------------------------------------------------
>
> Key: ISPN-1242
> URL: https://issues.jboss.org/browse/ISPN-1242
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.0.0.CR7
> Reporter: Erik Salter
>
> The grouping API should be enhanced to add grouping capabilities to a a cache's put() or replace() methods.
> This encompasses the following scenario:
> Cache A uses a custom key class where the group is dynamically generated. Cache B's key is an unmodifiable String that needs to be grouped with the dynamic value of a key from Cache A. (Cache B's key can't be encapsulated in a custom key class since it needs to be queried from external entities that will not know the group context).
> And in pseudo-code:
> {code}
> Group class InternalResourceKey {
> String group;
> ...
> @Group
> String getGroup() {
> return group;
> }
> }
> InternalResourceKey key = new InternalResourceKey();
> {code}
> ...
> {code}
> resourceCache.lock( key );
> // Get the previous result.
> ResourceResult result = resourceCache.get( key );
> ResourceResult newResult = doWork( key, result );
> resourceCache.put( key, newResult );
> // I also want to group an external identifier that an external client knows about with the result so they will be on the same node
> employeeCache.put( "111-111-1111", newResult, key.getGroup() );
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-1147) Programmatically creating cache should be automatically reflected throughout the cluster
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-1147?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-1147.
---------------------------------
Resolution: Duplicate Issue
> Programmatically creating cache should be automatically reflected throughout the cluster
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-1147
> URL: https://issues.jboss.org/browse/ISPN-1147
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core, State Transfer
> Affects Versions: 4.2.1.FINAL
> Reporter: Randall Hauch
> Assignee: Tristan Tarrant
>
> Consider a symmetric cluster of two nodes (N1 and N2) each with a single cache (C1). Currently, a new cache (C2) must be programmatically created _on all all nodes in the cluster_ (if REPL, or all appropriate nodes if DIST) _before_ that new cache can even be _used_.
> Ideally, when a new cache (C2) is created on one node (N1), Infinispan should automatically propagate that creation to the appropriate nodes in the cluster so that the new cache can be used immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-6677) Deal with unavailable dependencies during startup
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6677?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6677:
----------------------------------
Comment: was deleted
(was: Yes, retries are the only option. But I think we should implement reties in Core (this way we could use the same approach for both embedded and client server). WDYT?
)
> Deal with unavailable dependencies during startup
> -------------------------------------------------
>
> Key: ISPN-6677
> URL: https://issues.jboss.org/browse/ISPN-6677
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Priority: Blocker
>
> In Kubernetes not all Pods start at the same time. It is perfectly possible to start first Infinispan and a bit later the database (in this configuration we are assuming that Infinispan has a dependency to DB). Note that this setup would fails.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-7993) Functional commands don't support Data convertions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7993?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7993:
----------------------------------
Fix Version/s: 9.2.0.Final
(was: 9.2)
> Functional commands don't support Data convertions
> --------------------------------------------------
>
> Key: ISPN-7993
> URL: https://issues.jboss.org/browse/ISPN-7993
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Fix For: 9.2.0.Final
>
>
> Functional commands don't support encoding
>
> For example, in this test
> {code}
> public class ClusteredCacheTest extends MultipleCacheManagersTest {
> public void testFunctionalMap() throws Exception {
> prepareTestData();
> FunctionalMapImpl functionalMap = FunctionalMapImpl.create(this.cache2.getAdvancedCache());
> FunctionalMap.ReadWriteMap<String, String> readWriteMap = ReadWriteMapImpl.create(functionalMap);
> readWriteMap.eval("k", view -> {
> view.set("v");
> return null;
> }).join();
> assertEquals("v", cache2.get("k"));
> }
> }
> {code}
> Returns this exception when the StorageType is OFF_HEAP
> {code}
> 17:27:22,296 ERROR (remote-thread-ClusteredCacheTest-NodeA-p2-t6) [InvocationContextInterceptor] ISPN000136: Error executing command ReadWriteKeyCommand, writing keys [k]
> java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes
> at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:38)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:134)
> at org.infinispan.statetransfer.CommitManager.commitEntry(CommitManager.java:141)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:101)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$ReplicationLogic.commitSingleEntry(ClusteringDependentLogic.java:435)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:183)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:604)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:825)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:581)17:27:22,310 ERROR (jgroups-4,ClusteredCacheTest-NodeB-5393) [InvocationContextInterceptor] ISPN000136: Error executing command ReadWriteKeyCommand, writing keys [k]
> org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredCacheTest-NodeA-49952, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:920)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$4(JGroupsTransport.java:689)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.requestDone(RspListFuture.java:53)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.accept(RspListFuture.java:48)
> java.util.concurrent.CompletionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredCacheTest-NodeA-49952, see cause for remote stack trace
> at java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375)
> at java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1934)
> at org.infinispan.query.blackbox.ClusteredCacheTest.testFunctionalMap(ClusteredCacheTest.java:886)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> 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.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:127)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ClusteredCacheTest-NodeA-49952, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:920)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$4(JGroupsTransport.java:689)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.requestDone(RspListFuture.java:53)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.accept(RspListFuture.java:48)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.accept(RspListFuture.java:19)
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.jgroups.blocks.GroupRequest.receiveResponse(GroupRequest.java:106)
> at org.infinispan.remoting.transport.jgroups.CustomRequestCorrelator.handleResponse(CustomRequestCorrelator.java:50)
> at org.jgroups.blocks.RequestCorrelator.dispatch(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:307)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:579)
> at org.jgroups.JChannel.up(JChannel.java:816)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:893)
> at org.jgroups.protocols.RSVP.up(RSVP.java:163)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:345)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:112)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:867)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1059)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:438)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:598)
> at org.jgroups.protocols.Discovery.up(Discovery.java:262)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1204)
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> 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)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.commons.marshall.WrappedBytes
> at org.infinispan.container.offheap.OffHeapDataContainer.put(OffHeapDataContainer.java:38)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:134)
> at org.infinispan.statetransfer.CommitManager.commitEntry(CommitManager.java:141)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:101)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$ReplicationLogic.commitSingleEntry(ClusteringDependentLogic.java:435)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:183)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:604)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:825)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:581)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.applyChanges(EntryWrappingInterceptor.java:637)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.lambda$setSkipRemoteGetsAndInvokeNextForDataCommand$8(EntryWrappingInterceptor.java:693)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:109)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:690)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitReadWriteKeyCommand(EntryWrappingInterceptor.java:497)
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:104)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:127)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:38)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitReadWriteKeyCommand(AbstractLockingInterceptor.java:200)
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:104)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:326)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:264)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadWriteKeyCommand(StateTransferInterceptor.java:174)
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:104)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:55)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:214)
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:104)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:97)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:60)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:55)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitReadWriteKeyCommand(DDAsyncInterceptor.java:214)
> at org.infinispan.commands.functional.ReadWriteKeyCommand.acceptVisitor(ReadWriteKeyCommand.java:104)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:51)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommandAsync(BaseRpcInvokingCommand.java:63)
> at org.infinispan.commands.remote.SingleRpcCommand.invokeAsync(SingleRpcCommand.java:57)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:101)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant updated ISPN-375:
---------------------------------
Labels: (was: hackathon)
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Priority: Blocker
> Fix For: 9.2.0.Final
>
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant updated ISPN-375:
---------------------------------
Fix Version/s: 9.2.0.Final
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: hackathon
> Fix For: 9.2.0.Final
>
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Tristan Tarrant updated ISPN-375:
---------------------------------
Sprint: (was: 9.1.0.Beta1)
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Priority: Blocker
> Labels: hackathon
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months