[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6771:
------------------------------------
Status: Open (was: New)
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-6771:
---------------------------------------
Assignee: Gustavo Fernandes
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
> Assignee: Gustavo Fernandes
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6771:
------------------------------------
Component/s: Remote Protocols
(was: hot)
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Jean-Francois LARTAUD (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Jean-Francois LARTAUD updated ISPN-6771:
----------------------------------------
Description:
After debugging :
In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
* For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
** The new servers list is returned only if servers have been added.
** As this list is not empty, the balancy strategy for the first cache is updated.
* For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
** The associated balancing strategies are not updated.
{code}
public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
synchronized (lock) {
Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
if (!servers.isEmpty()) {
FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
balancer.setServers(servers);
}
}
}
{code}
was:
After debugging :
In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
* For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
** The new servers list is returned only if servers have been added.
** As this list is not empty, the balancy strategy for the first cache is updated.
* For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
** The associated balancing strategies are not updated.
{code}
public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
synchronized (lock) {
Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
//
if (!servers.isEmpty()) {
FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
balancer.setServers(servers);
}
}
}
{code}
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: hot
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Jean-Francois LARTAUD (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Jean-Francois LARTAUD updated ISPN-6771:
----------------------------------------
Steps to Reproduce:
Configuration :
* Server side :
** 3 distributed-cache into a cache container
** 3 nodes (nodeA, nodeB, nodeC).
* Client side :
** 1 remote cache manager with TcpTransportFactory and RoundRobinBalancingStrategy.
** 2 infinispan-server nodes (nodeA, nodeB) configured into the server list
Everything is running except nodeC
1. I start a new infinispan-server (nodeC)
2. Only the RoundRobingBalancingStrategy associated with the 1st cache declared is updated with the new infinispan-server nodeC
3. I stop the nodeB
4. Only the RoundRobinBalancingStrategy associated with the first cache declared is updated
5. The RoundRobinStrategies associated with the 2nd and 3rd are not updated. When quering on these cache, the nodeB is "excluded" and it remains only one node (nodeA).
6. I stop nodeA
7. When quering the 1st cache, the nodeC is requested. When querying the 2nd and the 3rd caches, I got "org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport"
was:
Configuration :
* Server side :
** 3 distributed-cache into a cache container
** 3 nodes (nodeA, nodeB, nodeC).
* Client side :
** 1 remote cache manager with TcpTransportFactory and RoundRobinBalancingStrategy.
** 2 infinispan-server nodes (nodeA, nodeB) configured into the server list
Everything is running except nodeC
1. I start a new infinispan-server (nodeC)
2. Only the RoundRobingBalancingStrategy associated with the 1st cache declared is updated with the new infinispan-server
3. I stop the nodeB
4. Only the RoundRobinBalancingStrategy associated with the first cache declared is updated
5. The RoundRobinStrategy assciated with the 2nd and 3rd are not updated. When quering on these cache, the nodeB is "excluded" and it remains only one node (nodeA).
6. I stop nodeA
7. When quering the 1st cache, the nodeC is requested. When querying the 2nd and the 3rd caches, I got "org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport"
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: hot
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> //
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Jean-Francois LARTAUD (JIRA)
[ https://issues.jboss.org/browse/ISPN-6771?page=com.atlassian.jira.plugin.... ]
Jean-Francois LARTAUD updated ISPN-6771:
----------------------------------------
Steps to Reproduce:
Configuration :
* Server side :
** 3 distributed-cache into a cache container
** 3 nodes (nodeA, nodeB, nodeC).
* Client side :
** 1 remote cache manager with TcpTransportFactory and RoundRobinBalancingStrategy.
** 2 infinispan-server nodes (nodeA, nodeB) configured into the server list
Everything is running except nodeC
1. I start a new infinispan-server (nodeC)
2. Only the RoundRobingBalancingStrategy associated with the 1st cache declared is updated with the new infinispan-server
3. I stop the nodeB
4. Only the RoundRobinBalancingStrategy associated with the first cache declared is updated
5. The RoundRobinStrategy assciated with the 2nd and 3rd are not updated. When quering on these cache, the nodeB is "excluded" and it remains only one node (nodeA).
6. I stop nodeA
7. When quering the 1st cache, the nodeC is requested. When querying the 2nd and the 3rd caches, I got "org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport"
was:
Configuration :
* Server side :
** 3 distributed-cache into a cache container
* Client side :
** 1 remote cache manager with TcpTransportFactory and RoundRobinBalancingStrategy.
** 2 infinispan-server nodes (nodeA, nodeB) configured into the server list
Everything is running.
1. I start a new infinispan-server (nodeC)
2. Only the RoundRobingBalancingStrategy associated with the 1st cache declared is updated with the new infinispan-server
3. I stop the nodeB
4. Only the RoundRobinBalancingStrategy associated with the first cache declared is updated
5. The RoundRobinStrategy assciated with the 2nd and 3rd are not updated. When quering on these cache, the nodeB is "excluded" and it remains only one node (nodeA).
6. I stop nodeA
7. When quering the 1st cache, the nodeC is requested. When querying the 2nd and the 3rd caches, I got "org.infinispan.client.hotrod.exceptions.TransportException:: Could not fetch transport"
> HotRod Client - TcpTransportFactory - update topology issue with multiple caches
> --------------------------------------------------------------------------------
>
> Key: ISPN-6771
> URL: https://issues.jboss.org/browse/ISPN-6771
> Project: Infinispan
> Issue Type: Bug
> Components: hot
> Affects Versions: 9.0.0.Alpha2, 8.2.2.Final
> Environment: Infinispan server 8.2.2.Final
> Hot rod client (Java) : 8.2.2.Final
> Reporter: Jean-Francois LARTAUD
>
> After debugging :
> In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
> * For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
> ** The new servers list is returned only if servers have been added.
> ** As this list is not empty, the balancy strategy for the first cache is updated.
> * For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
> ** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
> ** The associated balancing strategies are not updated.
> {code}
> public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
> synchronized (lock) {
> Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
> //
> if (!servers.isEmpty()) {
> FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
> balancer.setServers(servers);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6771) HotRod Client - TcpTransportFactory - update topology issue with multiple caches
by Jean-Francois LARTAUD (JIRA)
Jean-Francois LARTAUD created ISPN-6771:
-------------------------------------------
Summary: HotRod Client - TcpTransportFactory - update topology issue with multiple caches
Key: ISPN-6771
URL: https://issues.jboss.org/browse/ISPN-6771
Project: Infinispan
Issue Type: Bug
Components: hot
Affects Versions: 8.2.2.Final, 9.0.0.Alpha2
Environment: Infinispan server 8.2.2.Final
Hot rod client (Java) : 8.2.2.Final
Reporter: Jean-Francois LARTAUD
After debugging :
In TcpTransportFactory, the topologyInfo is global (whatever the number of caches), the balancing strategies are defined by cache.
* For the 1st cache, the servers list is updated (org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory#updateServers(java.util.Collection<java.net.SocketAddress>, byte[], boolean), the topologyInfo is updated.
** The new servers list is returned only if servers have been added.
** As this list is not empty, the balancy strategy for the first cache is updated.
* For the other caches, the server list is updated by calling the same "updateServers" method, the "updateTopologyInfo" method is called
** But as the topologyInfo has been already updated for the 1st cache, it returns "Collections.emptyList();"
** The associated balancing strategies are not updated.
{code}
public void updateServers(Collection<SocketAddress> newServers, byte[] cacheName, boolean quiet) {
synchronized (lock) {
Collection<SocketAddress> servers = updateTopologyInfo(newServers, quiet);
//
if (!servers.isEmpty()) {
FailoverRequestBalancingStrategy balancer = getOrCreateIfAbsentBalancer(cacheName);
balancer.setServers(servers);
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6422) ServerEventLoggerTest.testClusteredServerEventLogging fails randomly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6422?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6422:
----------------------------------
Status: Open (was: New)
> ServerEventLoggerTest.testClusteredServerEventLogging fails randomly
> --------------------------------------------------------------------
>
> Key: ISPN-6422
> URL: https://issues.jboss.org/browse/ISPN-6422
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Adrian Nistor
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
> Fix For: 9.0.0.Alpha3
>
>
> http://ci.infinispan.org/viewLog.html?buildId=37676&tab=buildResultsDiv&b...
> {code}
> java.lang.NullPointerException: null
> at java.util.ComparableTimSort.binarySort(ComparableTimSort.java:258)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:185)
> at java.util.Arrays.sort(Arrays.java:1312)
> at java.util.Arrays.sort(Arrays.java:1506)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:141)
> at org.infinispan.server.eventlogger.ServerEventLogger.getEvents(ServerEventLogger.java:131)
> at org.infinispan.server.eventlogger.ServerEventLoggerTest$2.call(ServerEventLoggerTest.java:86)
> at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1348)
> at org.infinispan.server.eventlogger.ServerEventLoggerTest.testClusteredServerEventLogging(ServerEventLoggerTest.java:66)
> ------- Stdout: -------
> Configuring TestNG with: TestNG652Configurator
> Transport protocol stack used = tcp
> ------- Stderr: -------
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|0] (1) [ServerEventLoggerTest-NodeA-31008]
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeA-31008, physical addresses are [127.0.0.1:7900]
> Mar 20, 2016 2:14:51 AM org.infinispan.factories.GlobalComponentRegistry start
> INFO: ISPN000128: Infinispan version: Infinispan 'Chakra' 9.0.0-SNAPSHOT
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeB-14491, physical addresses are [127.0.0.1:7901]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeC-47842, physical addresses are [127.0.0.1:7902]
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #1
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #2
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #3
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #4
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #5
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #6
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #7
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #8
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #9
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #10
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #11
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #12
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|4] (1) [ServerEventLoggerTest-NodeA-31008]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6422) ServerEventLoggerTest.testClusteredServerEventLogging fails randomly
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6422?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6422:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4404
> ServerEventLoggerTest.testClusteredServerEventLogging fails randomly
> --------------------------------------------------------------------
>
> Key: ISPN-6422
> URL: https://issues.jboss.org/browse/ISPN-6422
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Adrian Nistor
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
> Fix For: 9.0.0.Alpha3
>
>
> http://ci.infinispan.org/viewLog.html?buildId=37676&tab=buildResultsDiv&b...
> {code}
> java.lang.NullPointerException: null
> at java.util.ComparableTimSort.binarySort(ComparableTimSort.java:258)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:185)
> at java.util.Arrays.sort(Arrays.java:1312)
> at java.util.Arrays.sort(Arrays.java:1506)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:141)
> at org.infinispan.server.eventlogger.ServerEventLogger.getEvents(ServerEventLogger.java:131)
> at org.infinispan.server.eventlogger.ServerEventLoggerTest$2.call(ServerEventLoggerTest.java:86)
> at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1348)
> at org.infinispan.server.eventlogger.ServerEventLoggerTest.testClusteredServerEventLogging(ServerEventLoggerTest.java:66)
> ------- Stdout: -------
> Configuring TestNG with: TestNG652Configurator
> Transport protocol stack used = tcp
> ------- Stderr: -------
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|0] (1) [ServerEventLoggerTest-NodeA-31008]
> Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeA-31008, physical addresses are [127.0.0.1:7900]
> Mar 20, 2016 2:14:51 AM org.infinispan.factories.GlobalComponentRegistry start
> INFO: ISPN000128: Infinispan version: Infinispan 'Chakra' 9.0.0-SNAPSHOT
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeB-14491, physical addresses are [127.0.0.1:7901]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start
> INFO: ISPN000078: Starting JGroups channel ISPN
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842]
> Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded
> INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeC-47842, physical addresses are [127.0.0.1:7902]
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #1
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #2
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #3
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #4
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #5
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #6
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #7
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #8
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #9
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #10
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> INFO: message #11
> Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog
> WARN: message #12
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted
> INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|4] (1) [ServerEventLoggerTest-NodeA-31008]
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000080: Disconnecting JGroups channel ISPN
> Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop
> INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months