Andrew Scully | 19 Feb 11:10 2014
Picon

[jgroups-users] enable_bundling warning?

Hi,

When starting a Jgroups stack like this...

<UDP singleton_name="udp" enable_bundling="false" ...

...I get a warning like this...

JGRP000014: TP.enable_bundling has been deprecated: will be ignored as bundling is on by default.

I want to turn bundling off on this stack, hence why we're setting it to "false", so the warning doesn't make sense.

Is there now a new way to disable bundling?

I'm running against 3.4.2.Final, we didn't get this against 3.2.7.Final.

My guess is it has something to do with this ticket:


Cheers, Andy.
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Aleksandr Korostov | 13 Feb 21:06 2014
Picon

[jgroups-users] A node does not detect that it was excluded from the cluster

Hi,

We have a cluster of several dozen of nodes running with JGroups 2.12.1 (I know that it is a very old version). We use UDP, our current configuration is the following:

UDP(mcast_addr=${multicastAddress};ip_ttl=${timeToLive};mcast_port=${port}):
PING(timeout=2000;num_initial_members=4):
MERGE2(max_interval=30000;min_interval=10000):
FD(timeout=5000;max_tries=5):
VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(gc_lag=50;retransmit_timeout=600,1200,2400,4800):
UNICAST(timeout=600,1200,2400,4800):
pbcast.STABLE(desired_avg_gossip=20000):
FRAG:
pbcast.GMS(join_timeout=3000;merge_timeout=10000;print_local_addr=true)

We faced a problem when testing the ability to restore the cluster communication after a major network failure.

So we were running 14 nodes on several separate machines and were disrupting and restoring the network between the machines. When the cluster was parted we saw that the part with the active coordinator was excluding unreachable nodes one by one. For example if we part cluster like this

{1(coord), 2, 3, 4, 5, 6, 7 }              |          {8, 9}       |      {10, 11, 12, 13, 14}
 
The FD on the node 7 detects the failure of the node 8 and notifies the coordinator about it, node 8 is excluded and node 7 starts pinging node 9 and detects its failure after some time. So the number of the cluster members in the first partition gradually drops to 7.

The second partition {8, 9} works quite differently. In the absence of the coordinator these nodes "think" they run in the cluster of 14 nodes for quite a long time, and then the size of the cluster drops to 2. I think I understand why this is happening: node 9 pings node 10 and notifies the unreachable coordinator of its failure, then node 9 starts pinging node 11 (even without the coordinator excluding node 10), then it starts pinging node 12, after some time node 9 starts pinging node 1 which is its coordinator, and only when the node 9 understands that its coordinator is down this partition forms a cluster of 2 nodes. I know that the FD is not optimal and I'm going to switch to FD_ALL, however please read further.

Now consider what happens if we restore the network before node 9 detects the failure of the coordinator. For example at that point node 9 was pinging node 13. When we restore the network node 13 responds to the ARE_YOU_ALIVE message. What we see is that sometimes nodes 8 and 9 are stuck and never join the cluster back. So we have a situation when the new restored cluster has 12 nodes and nodes 8 and 9 "think" they are part of the cluster of 14 nodes while they are not. I'm not sure this is 100% reproducible.

So my main question: what is the mechanism for the node to "understand" that its not a member of the cluster anymore in the following cases:
   a. coordinator stays the same, but the coordinator excluded the node but the node did not receive that message due to the network failure and still "thinks" it is a member of the cluster
   b. coordinator changed. So the node "thinks" it is a part of the cluster with coordinator A, while the active cluster has different coordinator.


--
All the best,
Aleksandr Korostov
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
arnaud.pillac | 6 Feb 11:39 2014
Picon
Picon

[jgroups-users] Cluster not reconnect node

We actually encounter an error in production environnement. We have two nodes
(oppodindex1&2) in our JGroups cluster. Sometimes in load usage, cluster
member doesn't see each other and we have the following error in our logs:

node1:
22:04:19,971 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
22:04:19,975 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = MergeView::[oppodindex2-65413|3] (2) [oppodindex2-65413,
oppodindex1-12124], 2 subgroups: [oppodindex2-65413|2] (1)
[oppodindex2-65413], [oppodindex1-12124|1] (1) [oppodindex1-12124]
22:04:21,975 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
UNBLOCK
22:04:21,975 | WARN  | ppodindex1-12124 | GMS                              |
253 - org.jgroups - 3.4.0.Final | oppodindex1-12124: failed to collect all
ACKs (expected=2) for view [oppodindex2-65413|3] after 2000ms, missing 2
ACKs from oppodindex2-65413, oppodindex1-12124
22:07:02,325 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
22:07:02,627 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = [oppodindex1-12124|4] (1) [oppodindex1-12124]
22:07:02,627 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
UNBLOCK
22:07:58,088 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
22:07:58,089 | WARN  | ppodindex1-12124 | NAKACK2                          |
253 - org.jgroups - 3.4.0.Final | JGRP000011: oppodindex1-12124: dropped
message batch from non-member oppodindex2-65413 (view=[oppodindex1-12124|4]
(1) [oppodindex1-12124])
22:07:58,091 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = MergeView::[oppodindex2-65413|5] (2) [oppodindex2-65413,
oppodindex1-12124], 2 subgroups: [oppodindex2-65413|3] (1)
[oppodindex2-65413], [oppodindex1-12124|4] (1) [oppodindex1-12124]
22:08:02,039 | INFO  | ppodindex1-12124 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
UNBLOCK

Node 2:
22:07:03,992 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
22:07:04,296 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = [oppodindex2-65413|2] (1) [oppodindex2-65413]
22:07:04,297 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
UNBLOCK
22:07:35,154 | WARN  | ppodindex2-65413 | NAKACK2                          |
253 - org.jgroups - 3.4.0.Final | JGRP000011: oppodindex2-65413: dropped
message batch from non-member oppodindex1-12124 (view=[oppodindex2-65413|2]
(1) [oppodindex2-65413])
22:07:51,055 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
22:07:51,060 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = MergeView::[oppodindex2-65413|3] (2) [oppodindex2-65413,
oppodindex1-12124], 2 subgroups: [oppodindex2-65413|2] (1)
[oppodindex2-65413], [oppodindex1-12124|1] (1) [oppodindex1-12124]
22:07:53,059 | WARN  | ppodindex2-65413 | Merger                           |
253 - org.jgroups - 3.4.0.Final | oppodindex2-65413: failed to collect all
ACKs (2) for merge view MergeView::[oppodindex2-65413|3] (2)
[oppodindex2-65413, oppodindex1-12124], 2 subgroups: [oppodindex2-65413|2]
(1) [oppodindex2-65413], [oppodindex1-12124|1] (1) [oppodindex1-12124] after
2000 ms, missing ACKs from oppodindex1-12124
22:07:53,061 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
UNBLOCK
22:11:29,176 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
22:11:29,178 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = MergeView::[oppodindex2-65413|5] (2) [oppodindex2-65413,
oppodindex1-12124], 2 subgroups: [oppodindex2-65413|3] (1)
[oppodindex2-65413], [oppodindex1-12124|4] (1) [oppodindex1-12124]
22:11:31,177 | WARN  | ppodindex2-65413 | Merger                           |
253 - org.jgroups - 3.4.0.Final | oppodindex2-65413: failed to collect all
ACKs (2) for merge view MergeView::[oppodindex2-65413|5] (2)
[oppodindex2-65413, oppodindex1-12124], 2 subgroups: [oppodindex2-65413|3]
(1) [oppodindex2-65413], [oppodindex1-12124|4] (1) [oppodindex1-12124] after
2000 ms, missing ACKs from oppodindex2-65413
22:11:31,178 | WARN  | ppodindex2-65413 | GMS                              |
253 - org.jgroups - 3.4.0.Final | oppodindex2-65413: failed to collect all
ACKs (expected=2) for view [oppodindex2-65413|5] after 2000ms, missing 1
ACKs from oppodindex1-12124
22:11:31,178 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
UNBLOCK
23:08:13,884 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster does
BLOCK
23:08:14,186 | INFO  | ppodindex2-65413 | IndexReceiver                    |
275 - fr.bull.telco.orange.pod.index-manager - 0.1.4.SNAPSHOT | Cluster new
VIEW = [oppodindex2-65413|6] (1) [oppodindex2-65413]

After these errors, the service is unavailable because the JGroup cluster is
down, no communication between nodes (node 2 says: no physical address for
node1). We don't understand why the cluster create new view with subgroups
and not just only the two nodes? We use the JGroups 3.4.0 version.

We have the following configuration:
<config
	xmlns="urn:org:jgroups"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:org:jgroups
http://www.jgroups.org/schema/JGroups-3.3.xsd">
	<UDP
		bind_addr="podclusterip"
		bind_port="8900"
		mcast_addr="224.9.9.9"
		mcast_port="8901" />
	<PING num_initial_members="2" />
	<MERGE2 />
	<FD_SOCK />
	<FD_ALL />
	<VERIFY_SUSPECT />
	<pbcast.NAKACK2 />
	<UNICAST3 />
	<pbcast.STABLE />
	<pbcast.GMS join_timeout="300000" />
	<UFC />
	<MFC />
	<FRAG2 />
	<RSVP />
	<pbcast.STATE_SOCK
		bind_addr="podclusterip"
		bind_port="8902" />
	<pbcast.FLUSH timeout="300000" />
</config>

Could you please send us a feeback, maybe we need to adjust timeout when
servers are in load, or upgrade JGroups to the latest release.

Arnaud Pillac

--
View this message in context: http://jgroups.1086181.n5.nabble.com/Cluster-not-reconnect-node-tp10059.html
Sent from the JGroups - General mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
Marilen Corciovei | 5 Feb 11:47 2014
Picon

[jgroups-users] JGroups communication stops working after a few minutes

Hello everybody,

I am using jgroups as a base for ehcache replication and in certain 
conditions I am facing a very strange condition.

JGroups is configured for udp, for a 2 nodes cluster. JGroups starts, 
connects, works for 3-4 minutes then stops working without any error. I 
have several clusters and this problem might be related to the 
virtualization platform for the clusters (kvm not ok, virtualbox ok) 
however what I cannot understand is why it works perfectly ok at the 
beginning.

I have spent the last days turning on TRACE for jgroups and I can see 
that at some point some sockets are closed:

2014-02-04 21:48:38,907 TRACE 
[INT-1,EH_CACHE,linux1-26104-org.jgroups.protocols.UNICAST3] 
linux1-26104: removed receive connection for linux2-63479
2014-02-04 21:48:38,907 TRACE 
[INT-1,EH_CACHE,linux1-26104-org.jgroups.protocols.UNICAST3] 
linux1-26104: removed receive connection for linux2-63479
2014-02-04 21:48:39,009 DEBUG 
[Timer-5,EH_CACHE,linux1-26104-org.jgroups.protocols.UNICAST3] 
linux1-26104: removing expired connection for linux1-26104 (60035 ms 
old) from send_table
2014-02-04 21:48:39,009 DEBUG 
[Timer-5,EH_CACHE,linux1-26104-org.jgroups.protocols.UNICAST3] 
linux1-26104: removing expired connection for linux1-26104 (60035 ms 
old) from send_table

and after this point nothing works anymore. However some time later the 
FD_ALL detects a problem, checks for the dead peer and the dead peer 
says it's ok yet messages are no longer received, maybe a listening 
thread is dead?. It works with TCP and I have tried dozens of UDP 
configurations with no luck.

Any ideeas are appreciated, regards,
Len
www.len.ro

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
Chris Lecompte | 5 Feb 07:43 2014
Picon

[jgroups-users] Long Delay in Receiving Messages

First let me say that I’m using a rather old version of JGroups (2.11.1), I’ll be upgrading but can’t
in this particular instance.  I’m using the following protocols, UDP, PING, MERGE2, FD_ALL,
VERIFY_SUSPECT, NAKACK and GMS.  I am seeing an issue for a 24 node cluster where messages are experiencing
serious delays but only to/from certain nodes.  For instance I have a ping operation established to test
communication in the cluster.  The protocol using UDP sends a message from a single node to the group using
channel.send(null, message) and then expects a reply message from each node (including itself).  When
experiencing the problem, a node in question does not appear to receive any messages via multicast.  For
instance, if I run the ping operation on a node that is not experiencing the problem I receive a 23 of 24
replies.  If I run the same operation on the node experiencing the issue then I receive 0 of 24 replies
implying that the node could not send/receive any of the messages within the 10 second timeout that the
operation will wait.  After some time ~30 minutes the messages are received and then from that point on the
issue no longer exists (until it crops up again).  Other nodes on the same host do not necessarily exhibit
the problem.  Is there any particular diagnostic information that I could inspect from the Probe command
or otherwise that might indicate if this is a network related issue?  It seems to be but the delay seems
rather huge in this case.  

Chris
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
Bela Ban | 24 Jan 14:36 2014
Picon

[jgroups-users] JGroups status presentation

FYI,
[1] http://belaban.blogspot.ch/2014/01/jgroups-status-and-outlook.html

--

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
sirlordt | 14 Jan 21:20 2014
Picon

[jgroups-users] Hide warning messages from SO incorrect setting

Hi how hide this messages? any config?

WARNING: JGRP000015: the send buffer of socket DatagramSocket was set to
640KB, but the OS only allocated 131,07KB. This might lead to performance
problems. Please set your max send buffer in the OS correctly (e.g.
net.core.wmem_max on Linux)
ene 14, 2014 3:28:50 PM org.jgroups.logging.JDKLogImpl warn
WARNING: JGRP000015: the receive buffer of socket DatagramSocket was set to
5MB, but the OS only allocated 131,07KB. This might lead to performance
problems. Please set your max receive buffer in the OS correctly (e.g.
net.core.rmem_max on Linux)
ene 14, 2014 3:28:50 PM org.jgroups.logging.JDKLogImpl warn
WARNING: JGRP000015: the send buffer of socket MulticastSocket was set to
640KB, but the OS only allocated 131,07KB. This might lead to performance
problems. Please set your max send buffer in the OS correctly (e.g.
net.core.wmem_max on Linux)
ene 14, 2014 3:28:50 PM org.jgroups.logging.JDKLogImpl warn
WARNING: JGRP000015: the receive buffer of socket MulticastSocket was set to
5MB, but the OS only allocated 131,07KB. This might lead to performance
problems. Please set your max receive buffer in the OS correctly (e.g.
net.core.rmem_max on Linux)

--
View this message in context: http://jgroups.1086181.n5.nabble.com/Hide-warning-messages-from-SO-incorrect-setting-tp10038.html
Sent from the JGroups - General mailing list archive at Nabble.com.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
Kresimir Simatovic | 13 Jan 17:09 2014
Picon

[jgroups-users] Garbage collection and suspect event

Hello!

I've observed following:

1) Node in cluster has long garbage collection pause (45 sec)
2) It was suspected by neighbor node 
3) Node was excluded by coordinator some 10 sec after GC started 
4) When GC finished node sent heartbeat:  ignoring the SUSPECT message and
sending back a HEARTBEAT_ACK

As a result, node has obsolete view which was installed before it was
suspected. It could send messages to other nodes (and receive responses
back) but it was invisible to other members. Coordinator on it and other
nodes was same. After disconnect/connect everything worked fined.

Is there way node could detect such situation and recover from it ?

Protocol stack is distro tcp.xml.

Thanks!

--
View this message in context: http://jgroups.1086181.n5.nabble.com/Garbage-collection-and-suspect-event-tp10037.html
Sent from the JGroups - General mailing list archive at Nabble.com.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
Rajni Sharma | 10 Jan 08:59 2014
Picon

[jgroups-users] Return IPv6 in Java

Hi

I'm trying to print ipv6 address of my system using following java program
but it returns only ipv4 address.
When I do ipconfig it shows both ipv4 and ipv6 address.

    public static void main(String args[]) throws UnknownHostException {  

        System.out.println(System.getProperty("java.home"));  
        System.setProperty("java.net.preferIPv6Addresses", "true");  

System.out.println(System.getProperty("java.net.preferIPv6Addresses"));  
        InetAddress[] addr = InetAddress.getAllByName(hostname);  
        for (InetAddress address : addr) {  
            if (address instanceof Inet6Address) {  
                System.out.println("ipv6 address is " +
address.getHostAddress());  
            }  
            else  
                System.out.println("ipv4 address is " +
address.getHostAddress());  
        }  
    }  

Also on debugging i found though impl refers to Inet6Address but
findNative() method of ClassLoader.class calls init() method of
Inet4Address.class in place of calling init() method of Inet6Address.class
Anyone have any idea of why its doing this?

--
View this message in context: http://jgroups.1086181.n5.nabble.com/Return-IPv6-in-Java-tp10033.html
Sent from the JGroups - General mailing list archive at Nabble.com.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
Bela Ban | 4 Jan 14:12 2014
Picon

[jgroups-users] JGroups 3.4.2.Final released

FYI, the release notes are below.
Cheers,

         Release Notes - JGroups - Version 3.4.2

<h2>        Bug
</h2>
<ul>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1715'>JGRP-1715</a>] 
-         NullPointerException in MessageDispatcher.handleUpEvent
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1744'>JGRP-1744</a>] 
-         Race condition allows NullPointerException in Executing protocol
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1752'>JGRP-1752</a>] 
-         Concurrent message headers modification causes that message is 
never sent
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1753'>JGRP-1753</a>] 
-         BlockingInputStream: reading beyond the array&#39;s capacity
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1755'>JGRP-1755</a>] 
-         TP: dropping message to wrong destination in a shared transport
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1756'>JGRP-1756</a>] 
-         ConcurrentModificationException in Executing.handleView
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1757'>JGRP-1757</a>] 
-         Logging: exceptions are not logged correctly
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1758'>JGRP-1758</a>] 
-         UnknownFormatConversionException in UNICAST3 logging
</li>
</ul>

<h2>        Feature Request
</h2>
<ul>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1760'>JGRP-1760</a>] 
-         ENCRYPT: update symmetric key version and change symmetric key 
on view change
</li>
</ul>

<h2>        Task
</h2>
<ul>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1749'>JGRP-1749</a>] 
-         Remove override for jgroups.bind_addr, jgroups.udp.mcast_addr, 
jgroups.udp.mcast_port
</li>
<li>[<a href='https://issues.jboss.org/browse/JGRP-1762'>JGRP-1762</a>] 
-         Util.loadClass(): do we use the correct ClassLoader ?
</li>
</ul>

--

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
Bela Ban | 23 Dec 17:32 2013
Picon

[jgroups-users] Change in overriding of bind_addr etc via system props

FYI,

I've changed the way system properties override protocol properties [1]. 
The use case was a customer trying to create different clusters inside 
of the same JBoss EAP instance.

They assumed that using <UDP mcast_addr="${app1.mcast_addr:235.5.5.5}"/> 
for one app and {UDP mcast_addr="${app2.mcast_addr:236.5.5.5}"/> for the 
other and setting the relevant system properties app1.mcast_addr and 
app2.mcast_addr to *different* values would create 2 separate clusters...

Wrong ! JBoss EAP sets jgroups.udp.mcast_addr, which overwrites whatever 
was set in the XML config or via custom sysprops, so both clusters 
joined the same mcast_addr. Turns out they also used the same mcast_port 
(not set) and cluster name ("ISPN" set by Infinispan), so their nodes 
all joined the same cluster !

[1] https://issues.jboss.org/browse/JGRP-1749

--

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

Gmane