[JBoss JIRA] (ISPN-9683) Remote getBulk methods from RemoteCache
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9683?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9683:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 10.0.0.Alpha2
Resolution: Done
> Remote getBulk methods from RemoteCache
> ---------------------------------------
>
> Key: ISPN-9683
> URL: https://issues.jboss.org/browse/ISPN-9683
> Project: Infinispan
> Issue Type: Sub-task
> Components: Hot Rod
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Alpha2, 10.0.0.Final
>
>
> The getBulk methods have been deprecated for a while on the RemoteCache. We have appropriate streaming based methods for keySet, entrySet and retrieveEntries methods which are much better.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9785) RemoteCache entrySet and keySet must implement value equality
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9785?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9785:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> RemoteCache entrySet and keySet must implement value equality
> -------------------------------------------------------------
>
> Key: ISPN-9785
> URL: https://issues.jboss.org/browse/ISPN-9785
> Project: Infinispan
> Issue Type: Bug
> Components: Hot Rod
> Affects Versions: 9.1.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 10.0.0.Alpha2
>
>
> The Set interface contract explicitly states that the equals method must provide value equality. ISPN-7900 changed the keySet and added entrySet support. These methods must obey that contract. The values method is undefined and can stay how it is as the Collection interface doesn't state any specific guarantees.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9801:
-------------------------------
Status: Open (was: New)
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha2, 9.4.4.Final
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Dan Berindei (Jira)
Dan Berindei created ISPN-9801:
----------------------------------
Summary: ClusterTopologyManagerImpl hangs when restarting a node with FORK
Key: ISPN-9801
URL: https://issues.jboss.org/browse/ISPN-9801
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.3.Final, 10.0.0.Alpha1
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Alpha2, 9.4.4.Final
When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
{noformat}
14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
# not actually delivered :)
14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
{noformat}
So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-7035) Support Spring 5
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-7035?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7035:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Support Spring 5
> ----------------
>
> Key: ISPN-7035
> URL: https://issues.jboss.org/browse/ISPN-7035
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Sebastian Łaskawiec
> Assignee: Katia Aresti
> Priority: Critical
> Fix For: 10.0.0.Alpha2, 10.0.0.Final
>
>
> Currently everything is placed in {{org.infinispan.spring}} package. We should provide exactly the same split as we did in CDI ({{org.infinispan.spring}} into {{org.infinispan.spring.remote}} and {{org.infinispan.spring.embedded}})
> Move to Spring 5.1.x.RELEASE, Spring Session 2.x and Spring-Boot 2.x
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9800) Allow PersistenceManager availability check to be disabled
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9800?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-9800:
-------------------------------
Description: It should be possible to disable the persistence availability check by providing a availability-interval < 1. (was: It should be possible to disable the persistence availability check by providing a negative availability-interval.)
> Allow PersistenceManager availability check to be disabled
> ----------------------------------------------------------
>
> Key: ISPN-9800
> URL: https://issues.jboss.org/browse/ISPN-9800
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> It should be possible to disable the persistence availability check by providing a availability-interval < 1.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (ISPN-9800) Allow PersistenceManager availability check to be disabled
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-9800:
----------------------------------
Summary: Allow PersistenceManager availability check to be disabled
Key: ISPN-9800
URL: https://issues.jboss.org/browse/ISPN-9800
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 9.4.3.Final, 10.0.0.Alpha1
Reporter: Ryan Emerson
Assignee: Ryan Emerson
It should be possible to disable the persistence availability check by providing a negative availability-interval.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months