[JBoss JIRA] (ISPN-7420) Hot Rod enhancements for transcoding
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7420?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-7420:
---------------------------------------
Assignee: Gustavo Fernandes
> Hot Rod enhancements for transcoding
> ------------------------------------
>
> Key: ISPN-7420
> URL: https://issues.jboss.org/browse/ISPN-7420
> Project: Infinispan
> Issue Type: Sub-task
> Reporter: Galder Zamarreño
> Assignee: Gustavo Fernandes
>
> Several enhancements will need to be made to the Hot Rod protocol to work with transcoding:
> h3. Cache Writes (key + value)
> * Cache write operations that include values should have an optional parameter to be able to define the MIME type of the key and value that is being written. When the optional parameter is sent to the server, it will enable the server to implicitly discover what the types of the key+value are.
> * Once the first cache write has determined the key+value types, the clients do not need to send them again. If the client sends different types for the same cache, it should either result in the server ignoring it or an error (the former is preferable).
> * To avoid sending unnecessary data, advanced clients could cache the key+value type for a given cache after the first write request and then don't send it again.
> h3. Cache reads
> * Any operation that involves retrieving data should optionally take the type that the value should be transcoded to when returning it back to the client. This enables data to be read in different formats.
> * Within these operations, write operations that return previous values should be included.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-5083) Hot Rod decoder should use async Cache operations
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5083?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-5083:
---------------------------------------
Assignee: (was: Gustavo Fernandes)
> Hot Rod decoder should use async Cache operations
> -------------------------------------------------
>
> Key: ISPN-5083
> URL: https://issues.jboss.org/browse/ISPN-5083
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Fix For: 9.3.0.Final
>
>
> Hot Rod decoder is currently tying up Netty threads as a result of calling up to Infinispan sync operations. Instead, Hot Rod decoder should call up async operations, convert the Notifying Futures to Scala Futures, and write up the reply when it's received. This should increase performance specially under heavy load.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-6864) Add support for CORS headers to REST server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6864?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-6864.
---------------------------------
Resolution: Duplicate Issue
> Add support for CORS headers to REST server
> -------------------------------------------
>
> Key: ISPN-6864
> URL: https://issues.jboss.org/browse/ISPN-6864
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: James Falkner
> Priority: Minor
>
> Currently it is not possible to enable browser-based applications to call infinispan REST APIs due to the lack of [CORS|https://en.wikipedia.org/wiki/Cross-origin_resource_sharing] headers in the responses, and there is no way to alter the underlying web server to include these.
> This request asks that CORS headers be optionally returned in REST requests, and be configurable by admins. Specifically, the following headers:
> * Access-Control-Allow-Origin
> * Access-Control-Allow-Credentials
> * Access-Control-Expose-Headers
> * Access-Control-Max-Age
> * Access-Control-Allow-Methods
> * Access-Control-Allow-Headers
> This would enable browser-based apps to function when working across domains.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-9008) RpcManager.invokeCommandOnAll ignores cache member that are not in the cluster view
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9008?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9008:
-------------------------------
Status: Open (was: New)
> RpcManager.invokeCommandOnAll ignores cache member that are not in the cluster view
> -----------------------------------------------------------------------------------
>
> Key: ISPN-9008
> URL: https://issues.jboss.org/browse/ISPN-9008
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Alpha1
>
>
> {{RpcManager.invokeCommandOnAll}} broadcasts the command to all the members of the JGroups cluster view, and the {{ResponseCollector}} is not notified if any members of the cache are not in the cluster view.
> This is a problem in replicated caches with partition handling enabled, because it means a write can succeed in a minority partition in the time interval between {{JGroupsTransport}} seeing the minority cluster view and {{DistributionManagerImpl}} installing the {{DEGRADED_MODE}} cache topology.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8991) ClusteredLockSplitBrainTest.testLockUseAfterPartitionWithoutMajority fails
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8991?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8991:
------------------------------------
ISPN-9008 allows the lock to succeed in a minority partition after the cluster view is installed but before the cache enters degraded mode.
> ClusteredLockSplitBrainTest.testLockUseAfterPartitionWithoutMajority fails
> --------------------------------------------------------------------------
>
> Key: ISPN-8991
> URL: https://issues.jboss.org/browse/ISPN-8991
> Project: Infinispan
> Issue Type: Bug
> Components: Clustered Locks
> Reporter: Katia Aresti
> Assignee: Katia Aresti
>
> The test does a split of [3,3]. Partitions have no majority so lock acquisition should fail for the 6 nodes. But sometimes, lock acquisition does not fail, so the test fails randomly.
> {code}
> java.util.concurrent.ExecutionException: java.lang.AssertionError: Wrong exception thrown: expected:<org.infinispan.lock.exception.ClusteredLockException>, actual:<java.lang.AssertionError>
> Pile d'exécution
> java.lang.Error: java.util.concurrent.ExecutionException: java.lang.AssertionError: Wrong exception thrown: expected:<org.infinispan.lock.exception.ClusteredLockException>, actual:<java.lang.AssertionError>
> at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:47)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.lambda$testLockUseAfterPartitionWithoutMajority$3(ClusteredLockSplitBrainTest.java:94)
> at java.util.Arrays$ArrayList.forEach(Arrays.java:3880)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.testLockUseAfterPartitionWithoutMajority(ClusteredLockSplitBrainTest.java:92)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.util.concurrent.ExecutionException: java.lang.AssertionError: Wrong exception thrown: expected:<org.infinispan.lock.exception.ClusteredLockException>, actual:<java.lang.AssertionError>
> at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
> at org.infinispan.functional.FunctionalTestUtils.await(FunctionalTestUtils.java:45)
> ... 23 more
> Caused by: java.lang.AssertionError: Wrong exception thrown: expected:<org.infinispan.lock.exception.ClusteredLockException>, actual:<java.lang.AssertionError>
> at org.infinispan.test.Exceptions.assertException(Exceptions.java:22)
> at org.infinispan.test.Exceptions.assertException(Exceptions.java:63)
> at org.infinispan.lock.ClusteredLockSplitBrainTest.lambda$null$2(ClusteredLockSplitBrainTest.java:97)
> at java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:870)
> at java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:852)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.lock.impl.lock.ClusteredLockImpl$TryLockRequestHolder.handle(ClusteredLockImpl.java:179)
> at org.infinispan.lock.impl.lock.ClusteredLockImpl$RequestHolder.handleLockResult(ClusteredLockImpl.java:115)
> at org.infinispan.lock.impl.lock.ClusteredLockImpl.lambda$tryLock$2(ClusteredLockImpl.java:427)
> 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.infinispan.interceptors.impl.QueueAsyncInvocationStage.invokeQueuedHandlers(QueueAsyncInvocationStage.java:106)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:81)
> at org.infinispan.interceptors.impl.QueueAsyncInvocationStage.accept(QueueAsyncInvocationStage.java:30)
> 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.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:66)
> at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:56)
> at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35)
> at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:53)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1304)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1207)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:123)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.receive(JGroupsTransport.java:1342)
> at org.jgroups.JChannel.up(JChannel.java:819)
> 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:343)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:119)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:864)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1002)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:728)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:383)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:119)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> at org.jgroups.protocols.Discovery.up(Discovery.java:267)
> at org.jgroups.protocols.DISCARD.up(DISCARD.java:180)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1248)
> at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> ... 3 more
> Caused by: java.lang.AssertionError: should go to exceptionally ! r=true ex= null
> at org.infinispan.lock.ClusteredLockSplitBrainTest.lambda$null$1(ClusteredLockSplitBrainTest.java:95)
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> ... 46 more
> ... Removed 17 stack frames
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-9008) RpcManager.invokeCommandOnAll ignores cache member that are not in the cluster view
by Dan Berindei (JIRA)
Dan Berindei created ISPN-9008:
----------------------------------
Summary: RpcManager.invokeCommandOnAll ignores cache member that are not in the cluster view
Key: ISPN-9008
URL: https://issues.jboss.org/browse/ISPN-9008
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.2.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.3.0.Alpha1
{{RpcManager.invokeCommandOnAll}} broadcasts the command to all the members of the JGroups cluster view, and the {{ResponseCollector}} is not notified if any members of the cache are not in the cluster view.
This is a problem in replicated caches with partition handling enabled, because it means a write can succeed in a minority partition in the time interval between {{JGroupsTransport}} seeing the minority cluster view and {{DistributionManagerImpl}} installing the {{DEGRADED_MODE}} cache topology.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years