[JBoss JIRA] (ISPN-9402) Upgrade to JGroups 4.0.13.Final
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9402?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9402:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Upgrade to JGroups 4.0.13.Final
> -------------------------------
>
> Key: ISPN-9402
> URL: https://issues.jboss.org/browse/ISPN-9402
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: Core
> Affects Versions: 9.4.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.4.0.Final
>
>
> Interesting changes in JGroups 4.0.13.Final:
> {quote}
> - Changed the way a coord leaves gracefully (JGRP-2277): instead of creating the last view itself, the leaving coord asks the next-in-line to create and install it. This has the advantage that the new coord can retransmit the view (if lost) as it's stil alive and simplifies code, because the path for graceful leave and crash is now the same.
> - Reactive style of merging (JGRP-2281): when using MERGE3 and TCP, a merge could be only partial and multiple merge rounds would be needed, increasing the total time for a complete merge.
> This was changed by providing a new event which implements a reactive style of discovery by invoking a callback every time a discovery response is received.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-9459) Remove compat mode from the Memcached server
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9459?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9459:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.0.Final
Resolution: Done
> Remove compat mode from the Memcached server
> --------------------------------------------
>
> Key: ISPN-9459
> URL: https://issues.jboss.org/browse/ISPN-9459
> Project: Infinispan
> Issue Type: Sub-task
> Components: Memcached
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.4.0.Final
>
>
> The memcached server makes it hard to enable interoperability with other endpoints, as it stores keys as java.lang.String and treats byte[] as opaque values.
> It should respect the cache storage configuration and provide a way to specify what is the data type of the value that clients sends and receive, in order to convert it to/from the storage format.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8628 started by Adrian Nistor.
-------------------------------------------
> Simplify QueryEngine handling of Broadcast vs Fetch queries
> -----------------------------------------------------------
>
> Key: ISPN-8628
> URL: https://issues.jboss.org/browse/ISPN-8628
> Project: Infinispan
> Issue Type: Task
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 9.4.0.Final
>
>
> [~anistor] commented
> The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore.
> I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8628:
--------------------------------
Fix Version/s: 9.4.0.Final
> Simplify QueryEngine handling of Broadcast vs Fetch queries
> -----------------------------------------------------------
>
> Key: ISPN-8628
> URL: https://issues.jboss.org/browse/ISPN-8628
> Project: Infinispan
> Issue Type: Task
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 9.4.0.Final
>
>
> [~anistor] commented
> The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore.
> I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reassigned ISPN-8628:
-----------------------------------
Assignee: Adrian Nistor (was: Gustavo Fernandes)
> Simplify QueryEngine handling of Broadcast vs Fetch queries
> -----------------------------------------------------------
>
> Key: ISPN-8628
> URL: https://issues.jboss.org/browse/ISPN-8628
> Project: Infinispan
> Issue Type: Task
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 9.4.0.Final
>
>
> [~anistor] commented
> The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore.
> I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-9128) RehashWithSharedStoreTest.testRehashes random failures
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-9128?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-9128:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5989, https://github.com/infinispan/infinispan/pull/6231 (was: https://github.com/infinispan/infinispan/pull/5989)
> RehashWithSharedStoreTest.testRehashes random failures
> ------------------------------------------------------
>
> Key: ISPN-9128
> URL: https://issues.jboss.org/browse/ISPN-9128
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Labels: testsuite_stability
> Fix For: 9.4.0.Beta1
>
> Attachments: RehashWithSharedStoreTest_ISPN-7977_NPE_during_shutdown_20180507.log.gz
>
>
> {noformat}
> 16:00:32,748 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.RehashWithSharedStoreTest.testRehashes[SCATTERED_SYNC, tx=false, numOwners=1, l1=false]
> java.lang.AssertionError: Should be able to see key on new owner
> at org.infinispan.distribution.rehash.RehashWithSharedStoreTest.testRehashes(RehashWithSharedStoreTest.java:94) ~[test-classes/:?]
> {noformat}
> This first got my attention because I was working on ISPN-7977 and I noticed this NPE after the test failure:
> {noformat}
> 16:00:32,874 ERROR (jgroups-7,Test-NodeF-62673:[]) [ScatteredStateConsumerImpl] ISPN000471: Failed processing values received from remote node during rebalance.
> java.lang.NullPointerException: null
> at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.applyValues(ScatteredStateConsumerImpl.java:505) ~[classes/:?]
> at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.lambda$getValuesAndApply$8(ScatteredStateConsumerImpl.java:475) ~[classes/:?]
> at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760) [?:1.8.0_152]
> at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736) [?:1.8.0_152]
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) [?:1.8.0_152]
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) [?:1.8.0_152]
> at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67) [classes/:?]
> at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:57) [classes/:?]
> at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35) [classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (ISPN-9095) NPE during server shutdown when using scattered cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-9095?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-9095:
------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5989, https://github.com/infinispan/infinispan/pull/6231 (was: https://github.com/infinispan/infinispan/pull/5989)
> NPE during server shutdown when using scattered cache
> -----------------------------------------------------
>
> Key: ISPN-9095
> URL: https://issues.jboss.org/browse/ISPN-9095
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.1.Final
> Reporter: Paul Ferraro
> Assignee: Radim Vansa
> Fix For: 9.4.0.Beta1
>
>
> We hit NPE when running tests for RFE EAP7-867.
> EAP distribution was built from https://github.com/pferraro/wildfly/tree/scattered .
> Test description: Positive stress test (no failover), 4-node EAP cluster, clients: starting with 400 clients in the beginning, raising the number of clients to 6000 in the end of the test.
> During clean server shutdown in the end of the test, server logged NPE and got stuck:
> {code}
> [JBossINF] [0m[31m07:55:57,643 ERROR [org.infinispan.scattered.impl.ScatteredStateConsumerImpl] (thread-200,ejb,dev214) ISPN000471: Failed processing values received from remote node during rebalance.: java.lang.NullPointerException
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.applyValues(ScatteredStateConsumerImpl.java:505)
> [JBossINF] at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.lambda$getValuesAndApply$8(ScatteredStateConsumerImpl.java:475)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:66)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:56)
> [JBossINF] at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35)
> [JBossINF] at org.infinispan.remoting.transport.impl.RequestRepository.addResponse(RequestRepository.java:53)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processResponse(JGroupsTransport.java:1304)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.processMessage(JGroupsTransport.java:1207)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.access$200(JGroupsTransport.java:123)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport$ChannelCallbacks.receive(JGroupsTransport.java:1342)
> [JBossINF] at org.jgroups.JChannel.up(JChannel.java:819)
> [JBossINF] at org.jgroups.fork.ForkProtocolStack.up(ForkProtocolStack.java:134)
> [JBossINF] at org.jgroups.stack.Protocol.up(Protocol.java:340)
> [JBossINF] at org.jgroups.protocols.FORK.up(FORK.java:134)
> [JBossINF] at org.jgroups.protocols.FRAG3.up(FRAG3.java:166)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.FlowControl.up(FlowControl.java:343)
> [JBossINF] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:864)
> [JBossINF] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:240)
> [JBossINF] at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1002)
> [JBossINF] at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:728)
> [JBossINF] at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:383)
> [JBossINF] at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> [JBossINF] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:119)
> [JBossINF] at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:199)
> [JBossINF] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:252)
> [JBossINF] at org.jgroups.protocols.MERGE3.up(MERGE3.java:276)
> [JBossINF] at org.jgroups.protocols.Discovery.up(Discovery.java:267)
> [JBossINF] at org.jgroups.protocols.TP.passMessageUp(TP.java:1248)
> [JBossINF] at org.jgroups.util.SubmitToThreadPool$SingleMessageHandler.run(SubmitToThreadPool.java:87)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> Scattered cache was configured with bias-lifespan="0".
> Server configuration:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
> Server link:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/eap-7x-stress-ses...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months