Leonel Luciano Lourenço | 24 Nov 13:23 2014
Picon

[jgroups-users] JGroups TCP Over WAN

Hi !

I need to send/receive messages over WAN, for example, with two hosts.
Host A and Host B.

The Host A have a dynamic IP. Today, the IP is 200.100.100.80, for example. But, if the Host A restart your internet signal, he has a new IP: 180.28.48.50, for example.

The Host B send/receive message to Host A, but Host B is using NAT.
At home, i have dynamic IP and at college, they are using NAT.

How can i configure tcp.xml to work with this ?
Someone could help me ?

Thanks a lot and i´m sorry about my english.

Kind Regards,
Leonel
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Bobby Bissett | 20 Nov 22:14 2014
Picon

Re: [jgroups-users] known issue with pauses on jdk1.7?

On Tue, Oct 7, 2014 at 11:52 AM, Bobby Bissett <bbissett <at> gmail.com> wrote:

I suspect this might be a garbage collection issue with the jdk, but wanted to ask if other people have run into it just in case. My protocol stack is below, and the jvm is from Oracle:


Bela responded:
"[...] So the fix is really to tune your GC options, cause that's the root 
cause. Modern JVMs allow you to define max pause times, and that should 
really do the job. "

I honestly can't figure out how to respond on the forum (yes, am logged in and there's no reply/respond link), and I don't get responses emailed to me when I'm the one that submitted the original question. Dunno why.

Wanted to write thanks to Bela. That was all good info, and I'll look into the GC settings that were in use when the issue happened.

Cheers,
Bobby


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Ben Johnson | 18 Nov 12:38 2014
Picon

Re: [jgroups-users] GMS event type 1 (MSG) not being passed down the stack with 3.5.0.Final and later?

Hi Bela

Thanks for that, adding mcast_group_addr to the UDP protocol solved the issue for both the test and my AUTH
protocol.  I did need to add -Djava.net.preferIPv4Stack=true in my environment to avoid the exception:

java.lang.Exception: found IPv4 multicast address /232.5.5.5 in an IPv6 stack

Also, attempting to instantiate JChannel using the ProtocolStack constructor in the test did not work for me:

channel = new JChannel(stack);

instead, I had to use:

channel = new JChannel(false);
channel.setName(name);
channel.setProtocolStack(stack);
stack.init();

Using 'new JChannel(stack)' threw the following exception (looking at the code, something to do with the
channel is not set (null) for a variable named 'prot'; using the code for 3.6.1.Final):

java.lang.NullPointerException
	at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
	at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
	at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
	at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1042)
	at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:245)
	at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:408)
	at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:610)
	at org.jgroups.protocols.BARRIER.up(BARRIER.java:165)
	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155)
	at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:200)
	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
	at org.jgroups.protocols.MERGE3.up(MERGE3.java:288)
	at org.jgroups.protocols.Discovery.up(Discovery.java:349)
	at org.jgroups.protocols.TP.up(TP.java:1419)
	at org.jgroups.protocols.TP.init(TP.java:1196)
	at org.jgroups.protocols.UDP.init(UDP.java:254)
	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:861)
	at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:833)
	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:861)
	at org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:833)
	at org.jgroups.JChannel.<init>(JChannel.java:190)
	at org.jgroups.JChannel.<init>(JChannel.java:172)
	at com.whatever.ViewChangedTest$Node.<init>(ViewChangedTest.java:67)
	at com.whatever.ViewChangedTest.testViewChanged(ViewChangedTest.java:29)

Also, I can only get this to work using IPv4, not IPv6 (two tests + log output attached).  Using IPv6, the test
fails with:

org.jgroups.TimeoutException: Timeout 10000 kicked in, views are:
A: [A|0] (1) [A]
B: [B|0] (1) [B]

	at org.jgroups.util.Util.waitUntilAllChannelsHaveSameSize(Util.java:293)
	at com.whatever.ViewChangedTestIPv6.testViewChanged(ViewChangedTestIPv6.java:29)
Attachment (ViewChangedTestIPv4.java): text/x-java, 3955 bytes
Attachment (ViewChangedTestIPv6.java): text/x-java, 3704 bytes
Console output from ViewChangedTestIPv6.testViewChanged():

21:56:48.103 [main] ERROR org.jgroups.protocols.UDP - failed setting ip_ttl
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_71]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_71]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_71]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_71]
	at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.protocols.UDP.createSockets(UDP.java:368) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.protocols.UDP.start(UDP.java:270) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel.startStack(JChannel.java:887) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel._preConnect(JChannel.java:549) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel.connect(JChannel.java:284) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel.connect(JChannel.java:275) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at com.whatever.ViewChangedTestIPv6$Node.<init>(ViewChangedTestIPv6.java:70) [test-classes/:?]
	at com.whatever.ViewChangedTestIPv6.testViewChanged(ViewChangedTestIPv6.java:26) [test-classes/:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_71]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_71]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_71]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_71]
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) [testng.jar:6.0-201103151423]
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:673) [testng.jar:6.0-201103151423]
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) [testng.jar:6.0-201103151423]
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) [testng.jar:6.0-201103151423]
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) [testng.jar:6.0-201103151423]
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) [testng.jar:6.0-201103151423]
	at org.testng.TestRunner.runWorkers(TestRunner.java:1147) [testng.jar:?]
	at org.testng.TestRunner.privateRun(TestRunner.java:749) [testng.jar:?]
	at org.testng.TestRunner.run(TestRunner.java:600) [testng.jar:?]
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) [testng.jar:?]
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312) [testng.jar:?]
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274) [testng.jar:?]
	at org.testng.SuiteRunner.run(SuiteRunner.java:223) [testng.jar:?]
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) [testng.jar:?]
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) [testng.jar:?]
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039) [testng.jar:?]
	at org.testng.TestNG.runSuitesLocally(TestNG.java:964) [testng.jar:?]
	at org.testng.TestNG.run(TestNG.java:900) [testng.jar:?]
	at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:110) [testng.jar:6.0-201103151423]
	at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:205) [testng.jar:6.0-201103151423]
	at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174) [testng.jar:6.0-201103151423]
	at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125) [testng-plugin.jar:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_71]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_71]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_71]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_71]
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) [idea_rt.jar:?]
Caused by: java.io.IOException: Method not implemented!
	at
java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:237) ~[?:1.7.0_71]
	... 45 more

-------------------------------------------------------------------
GMS: address=A, cluster=whatever, physical address=192.168.0.20:64179
-------------------------------------------------------------------
A joined whatever; view=[A|0] (1) [A]
21:56:52.538 [main] ERROR org.jgroups.protocols.UDP - failed setting ip_ttl
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_71]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_71]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_71]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_71]
	at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.protocols.UDP.createSockets(UDP.java:368) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.protocols.UDP.start(UDP.java:270) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel.startStack(JChannel.java:887) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel._preConnect(JChannel.java:549) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel.connect(JChannel.java:284) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at org.jgroups.JChannel.connect(JChannel.java:275) [jgroups-3.6.1.Final.jar:3.6.1.Final]
	at com.whatever.ViewChangedTestIPv6$Node.<init>(ViewChangedTestIPv6.java:70) [test-classes/:?]
	at com.whatever.ViewChangedTestIPv6.testViewChanged(ViewChangedTestIPv6.java:27) [test-classes/:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_71]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_71]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_71]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_71]
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) [testng.jar:6.0-201103151423]
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:673) [testng.jar:6.0-201103151423]
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) [testng.jar:6.0-201103151423]
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) [testng.jar:6.0-201103151423]
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) [testng.jar:6.0-201103151423]
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) [testng.jar:6.0-201103151423]
	at org.testng.TestRunner.runWorkers(TestRunner.java:1147) [testng.jar:?]
	at org.testng.TestRunner.privateRun(TestRunner.java:749) [testng.jar:?]
	at org.testng.TestRunner.run(TestRunner.java:600) [testng.jar:?]
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) [testng.jar:?]
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:312) [testng.jar:?]
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:274) [testng.jar:?]
	at org.testng.SuiteRunner.run(SuiteRunner.java:223) [testng.jar:?]
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) [testng.jar:?]
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) [testng.jar:?]
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1039) [testng.jar:?]
	at org.testng.TestNG.runSuitesLocally(TestNG.java:964) [testng.jar:?]
	at org.testng.TestNG.run(TestNG.java:900) [testng.jar:?]
	at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:110) [testng.jar:6.0-201103151423]
	at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:205) [testng.jar:6.0-201103151423]
	at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:174) [testng.jar:6.0-201103151423]
	at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:125) [testng-plugin.jar:?]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.7.0_71]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[?:1.7.0_71]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.7.0_71]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_71]
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) [idea_rt.jar:?]
Caused by: java.io.IOException: Method not implemented!
	at
java.net.DualStackPlainDatagramSocketImpl.setTimeToLive(DualStackPlainDatagramSocketImpl.java:237) ~[?:1.7.0_71]
	... 45 more

-------------------------------------------------------------------
GMS: address=B, cluster=whatever, physical address=192.168.0.20:64180
-------------------------------------------------------------------
B joined whatever; view=[B|0] (1) [B]
org.jgroups.TimeoutException: Timeout 10000 kicked in, views are:
A: [A|0] (1) [A]
B: [B|0] (1) [B]

	at org.jgroups.util.Util.waitUntilAllChannelsHaveSameSize(Util.java:293)
	at com.whatever.ViewChangedTestIPv6.testViewChanged(ViewChangedTestIPv6.java:29)
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Ben Johnson | 13 Nov 11:57 2014
Picon

[jgroups-users] GMS event type 1 (MSG) not being passed down the stack with 3.5.0.Final and later?

Hi Bela

I recently updated a project I've been working on from JGroups 3.4.4.Final to JGroups 3.6.0.Final using
Windows 7 Pro 64bit and JDK 1.7.0_17.  It was working fine with 3.4.4.Final but not with 3.5.0.Final,
3.5.1.Final or 3.6.0.Final.  I'm actually working on an AUTH protocol, but I can reproduce what I think is a
similar behaviour with a simple ReceiverAdapter class too - rudimentary test code attached (in my AUTH
class, I'm not getting the GMS event type MSG = 1 - see attached logs).

The output when using 3.4.4.Final looks like this:

C:\dev\Java\jdk1.7.0_17\bin\java ...
Connected to the target VM, address: '127.0.0.1:56870', transport: 'socket'

-------------------------------------------------------------------
GMS: address=X-21427, cluster=whatever, physical address=192.168.0.20:49962
-------------------------------------------------------------------
X-21427 joined whatever; view=[X-21427|0] (1) [X-21427]

-------------------------------------------------------------------
GMS: address=X-63887, cluster=whatever, physical address=192.168.0.20:49963
-------------------------------------------------------------------
X-63887 joined whatever; view=[X-21427|1] (2) [X-21427, X-63887]
X-21427 stopped
X-63887 stopped
Disconnected from the target VM, address: '127.0.0.1:56870', transport: 'socket'

Process finished with exit code 0

*********
But when using 3.5.0.Final, notice the second node's view doesn't show the coordinator node:

C:\dev\Java\jdk1.7.0_17\bin\java ...
Connected to the target VM, address: '127.0.0.1:57976', transport: 'socket'

-------------------------------------------------------------------
GMS: address=X-57080, cluster=whatever, physical address=192.168.0.20:50297
-------------------------------------------------------------------
X-57080 joined whatever; view=[X-57080|0] (1) [X-57080]

-------------------------------------------------------------------
GMS: address=X-28200, cluster=whatever, physical address=192.168.0.20:50299
-------------------------------------------------------------------
X-28200 joined whatever; view=[X-28200|0] (1) [X-28200]
X-57080 stopped
X-28200 stopped

Process finished with exit code 0

*********

The stack is initialised programmatically:

                ProtocolStack stack = new ProtocolStack();
                stack.addProtocol(new UDP().setValue("bind_addr", InetAddress.getLocalHost())
                        .setValue("mcast_port", 7600))
                        .addProtocol(new PING())
                        .addProtocol(new MERGE3())
                        .addProtocol(new FD_SOCK())
                        .addProtocol(new FD_ALL().setValue("timeout", 12000).setValue("interval", 3000))
                        .addProtocol(new VERIFY_SUSPECT())
                        .addProtocol(new BARRIER())
                        .addProtocol(new NAKACK2())
                        .addProtocol(new UNICAST3())
                        .addProtocol(new STABLE())
                        .addProtocol(new GMS())
                        .addProtocol(new UFC())
                        .addProtocol(new MFC())
                        .addProtocol(new FRAG2());

                channel.setProtocolStack(stack);
                stack.init();
                channel.connect("whatever");

and the ReceiverAdaptor methods are overridden like this:

         <at> Override
        public void receive(Message msg) {
            System.out.println(msg);
        }

         <at> Override
        public void viewAccepted(View view) {
            System.out.println(view);
        }

Any ideas what might be causing this?

Thanks in advance,
Ben
Attachment (AUTH_BPKA_Events_3.4.4.Final): application/octet-stream, 4044 bytes
Attachment (AUTH_BPKA_Events_3.5.0.Final): application/octet-stream, 2739 bytes
Attachment (ViewChangedTest.java): text/x-java, 5069 bytes
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Bobby Bissett | 12 Nov 20:06 2014
Picon

[jgroups-users] two TCPPING questions

Hi all,

With jgroups 3.4.2.Final, we build our stack programmatically like so:

        JChannel channel = new JChannel(false);
        ProtocolStack stack = new ProtocolStack();
        channel.setProtocolStack(stack);
        stack.addProtocol(new TCP()
            [lots of values ommitted]
            .addProtocol(new TCPPING()
                .setValue("initial_hosts", <generate list> )
                .setValue("num_initial_members", 3)) // default: 10
            .addProtocol(new MERGE2()
            [etc]
        stack.init();

Since we're not changing the value of 'break_on_coord_rsp,' I think I don't need that 'num_initial_members' setting at all. Is that correct? (Everything seems to work fine whether I'm adding my 2nd or 5th member.)

Second question: The <generate list> data above comes from the user, and if it doesn't include all of the existing nodes, then the connections still work but the new node has no physical address for the ones that were missing. Is there a way I recover from that situation (assuming I can detect it), without closing the channel and trying again with the correct list of members?

I'm getting the requirement that the user should be able to start the app with only one current member in the startup configuration and that everything else "just works." I'm not sure how to do that except to have the new process ask that one member for a full list (possibly simple REST call) and use that to create the jgroups channel.

Thank you,
Bobby Bissett

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Christian Trimble | 11 Nov 07:28 2014

[jgroups-users] Dropwizard JGroups Integration Example

Hello,

  I put together a quick example of integrating JGroups with Dropwizard.  Thought I would share:


  It isn’t much, but it does show a way of getting the stack configuration into Dropwizard’s YAML configuration file. 

-Christian

-- 
Christian Trimble
Software Architect
c: 480.430.2854 | w: 602.340.9440
-- 
meltmedia
We are Interactive Superheroes

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Phil Zhang | 10 Nov 08:22 2014

[jgroups-users] post a new thread on the forum

Hey Experts, 

I am quite new to JGroup and was working on an incidence that the node of my cluster keep dropping regularly. When the merge protocol try merging the dropping node back to the cluster, sometime it get merged, sometime it does not. After restart the dropped node however, the view was merged together. 

At the time of occurrence, there is no performance issue on any nodes. There is no any noteworthy events that indicates the network is unstable. The load level was normal. I am in the need of some help to provide some hypothesis on what could be the cause if it. 

below is the configuration of the node: 
cluster.link.channel.properties.transport.0= 
TCP(bind_addr=localhost;bind_port=25000): 
TCPPING(initial_hosts={with nodes addressand portnumber}; 
port_range=1; 
timeout=10000; 
num_initial_members=4;return_entire_cache=true): 

MERGE3(min_interval=10000;max_interval=30000): 
FD_SOCK: 
FD(timeout=3000;max_tries=3): 
VERIFY_SUSPECT(timeout=1500): 
pbcast.NAKACK2(use_mcast_xmit=false;discard_delivered_msgs=true): 
UNICAST2: 
pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=4M): 
pbcast.GMS(join_timeout=3000;print_local_addr=true;view_bundling=true): 
UFC(max_credits=2M;min_threshold=0.4): 
FRAG2(frag_size=61440) 


Thank you very much for any insight.

 

------------------------------------------------------------------------------
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Jim Thomas | 4 Nov 03:23 2014

[jgroups-users] Central Lock with Data

I am using a central lock in my cluster which every member attempts to obtain, thus ensuring that a process is executing exactly once in the cluster at any given time (with small interruptions as it moves between members).  Before the lock is returned a block of data is sent to the cluster using a multicast message (currently by way of a distributed map).  Once the lock is obtained the current value is read from the distributed map.  What I'm finding is that this works fine when I'm running multiple instances on the loopback interface but does not work well in high-latency networks.  I have resorted to time-tagging the data so the new lock holder can wait for a new data value if the current one is too old.  This makes my small interruptions much larger.

It seems to me that I could make a new central lock protocol which allows bundling of data with the lock messages so the data is guaranteed to be up to date when the lock is obtained (or null if the lock is being issued due to a problem with the previous lock holder).  However JGroups has so many features (that I doubt I'll ever master) that I'm going to assume that there must be an easier way around this using some other protocol tricks.  But I'm not sure how I guarantee that I process a data message before the thread waiting on the lock unblocks.

Any ideas would be greatly appreciated.

JT


------------------------------------------------------------------------------
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
ibrahim EL-sanosi | 1 Nov 23:00 2014
Picon

[jgroups-users] run Draw Demo from the fource code, Eclipce or command line

Hi belaban,

I am new user to JGroups. I am trying to run Draw demo from Eclipse and command line using the source code (not jgroups.jar). but I am geting this bugs,

$ java org.jgroups.demos.Draw
java.lang.ExceptionInInitializerError
        at org.jgroups.conf.ConfiguratorFactory.getConfigStream(ConfiguratorFact
ory.java:151)
        at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorF
actory.java: 210)
        at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(Configurato
rFactory.java:93)
        at org.jgroups.JChannel.<init>(JChannel.java:139)
        at org.jgroups.demos.Draw.<init>(Draw.java:57)
        at org.jgroups.demos.Draw.main(Draw.java:161)
Caused by: java.util.MissingResourceException: Can't find bundle for base name j
g-messages, locale en_US
        at java.util.ResourceBundle.throwMissingResourceException(Unknown Source
)
        at java.util.ResourceBundle.getBundleImpl(Unknown Sou rce)
        at java.util.ResourceBundle.getBundle(Unknown Source)
        at org.jgroups.util.Util.<clinit>(Util.java:97)
 javagroups-users <at> lists.sourceforge.net


Note that I use JGroups version 3.6.0, windows 7, default protocol stack (i didn't t touch any things), and standalone.

Any help please?



Ibrahim EL-Sanosi
ibrahimsabat <at> yahoo.com
------------------------------------------------------------------------------
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Bela Ban | 28 Oct 09:56 2014
Picon

Re: [jgroups-users] Many threads are hanging while performing TP$TransferQueueBundler.send i.e., in TP.send()


On 25/10/14 13:54, Dinesh V wrote:
> Hi Bela,
>
> We are having an issue while performing JChannel.send operation as several
> threads are hanging and all these threads are getting blocked at
> TP$TransferQueueBundler.send() method.
>
> Can you please let us know if there is any specific configuration which we
> need to fine tune so that we could avoid this situation.
>
> Is there any specific timeout param which we could use to discard the
> message being sent though JChannel i.e., after a specific timeout period can
> it be discarded automatically and release the blocking thread.

No

> Can you suggest if we could avoid this issue by using TCP_NIO instead of
> TCP.
>
> Please find following JGroups version which we are using and the TCP
> configuration.
> We have 11 nodes in this cluster.
>
> Version:      3.3.5.Final

You can try:
- Increase the min_threads in both pools
- Disable the queue in the OOB thread pool
- Replace "run" with "discard" in both pools
- FD.timeout is 10 minutes ? This will cause hanging members to block 
the entire cluster for 10 mins, I'm sure this is not what you want !
- Use 3.6 or 3.5.1 and tcp.xml shipped with it, to see if that works; I 
don't support 3.3.x

> ===================================
> <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.0.xsd">
>      <TCP bind_port="8010"
>           port_range="0"
>           loopback="true"
>           recv_buf_size="20000000"
>           send_buf_size="640000"
>           discard_incompatible_packets="true"
>           max_bundle_size="64000"
>           max_bundle_timeout="30"
>           enable_bundling="true"
>           use_send_queues="true"
>           sock_conn_timeout="3000"
>           peer_addr_read_timeout="3000"
>
>           thread_pool.enabled="true"
>           thread_pool.min_threads="1"
>           thread_pool.max_threads="25"
>           thread_pool.keep_alive_time="5000"
>           thread_pool.queue_enabled="true"
>           thread_pool.queue_max_size="1000"
>           thread_pool.rejection_policy="Run"
>
>           oob_thread_pool.enabled="true"
>           oob_thread_pool.min_threads="1"
>           oob_thread_pool.max_threads="8"
>           oob_thread_pool.keep_alive_time="5000"
>           oob_thread_pool.queue_enabled="true"
>           oob_thread_pool.queue_max_size="1000"
>           oob_thread_pool.rejection_policy="Run"
>           timer.rejection_policy="Discard"
>           timer.max_threads="500"/>
>
>      <TCPPING timeout="200000"
>               initial_hosts=""
>               port_range="0"
>               num_initial_members="1"/>
>      <MERGE2  min_interval="10000"
>               max_interval="20000"/>
>      <FD_SOCK
>               get_cache_timeout="3000"
>               sock_conn_timeout="3000"
>               start_port="8015"
>
>      <FD timeout="60000" max_tries="10" />
>      <VERIFY_SUSPECT timeout="3000"  />
>      <BARRIER />
>      <pbcast.NAKACK
>                     use_mcast_xmit="false"
>                     retransmit_timeout="900,1800,3600,7200,14400"
>                     discard_delivered_msgs="true"/>
>      <UNICAST timeout="300,600,1200" />
>      <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                     max_bytes="400000"/>
>      <pbcast.GMS print_local_addr="true" join_timeout="60000"
>                  view_bundling="true"/>
>      <FRAG2 frag_size="60000" />
>      <pbcast.STATE_TRANSFER/>
> </config>
> ===================================
>
> Close to 200 threads were in stuck state, can we avoid a potential scenario
> where in, if there is any dead lock in TP.send() or if the target node
> is not
> responding or down when the current node in trying to send messages. Please
> note that, before sending we are making sure to identify if the target node
> address is part of channel view members list or not, if there is any
> additional
> time out param which can be set in JGroups TCP config file (as most of the
> operating systems does not allow to set a socket write timeout).
>
> Thread-55445 "[STUCK] ExecuteThread: '410' for queue:
> 'weblogic.kernel.Default (self-tuning)'" <alive, suspended, parked,
> priority=1, DAEMON> {
>      java.util.concurrent.locks.LockSupport.park(LockSupport.java:154)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1981)
>
> java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:288)
> org.jgroups.protocols.TP
> <http://org.jgroups.protocols.tp/>$TransferQueueBundler.send(TP.java:2237)
>      org.jgroups.protocols.*TP.send*(TP.java:1539)
>      org.jgroups.protocols.TP.down(TP.java:1231)
>      org.jgroups.protocols.Discovery.down(Discovery.java:543)
>      org.jgroups.protocols.TCPPING.down(TCPPING.java:108)
>      org.jgroups.protocols.MERGE2.down(MERGE2.java:151)
>      org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:291)
>      org.jgroups.protocols.FD.down(FD.java:278)
>      org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:75)
>      org.jgroups.protocols.BARRIER.down(BARRIER.java:87)
>      org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:487)
>      org.jgroups.protocols.UNICAST.down(UNICAST.java:461)
>      org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:338)
>      org.jgroups.protocols.pbcast.GMS.down(GMS.java:901)
>      org.jgroups.protocols.FRAG2.down(FRAG2.java:117)
>
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:182)
>      org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1021)
>      org.jgroups.JChannel.down(JChannel.java:766)
>      org.jgroups.*JChannel.send*(JChannel.java:424)
>
>
> Thread-55452 "[STUCK] ExecuteThread: '416' for queue:
> 'weblogic.kernel.Default (self-tuning)'" <alive, suspended, parked,
> priority=1, DAEMON> {
>      java.util.concurrent.locks.LockSupport.park(LockSupport.java:154)
>
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1981)
>
> java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:288)
> org.jgroups.protocols.TP
> <http://org.jgroups.protocols.tp/>$TransferQueueBundler.send(TP.java:2237)
>      org.jgroups.protocols.TP.send(TP.java:1539)
>      org.jgroups.protocols.TP.down(TP.java:1231)
>      org.jgroups.protocols.Discovery.down(Discovery.java:543)
>      org.jgroups.protocols.TCPPING.down(TCPPING.java:108)
>      org.jgroups.protocols.MERGE2.down(MERGE2.java:151)
>      org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:291)
>      org.jgroups.protocols.FD.down(FD.java:278)
>      org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:75)
>      org.jgroups.protocols.BARRIER.down(BARRIER.java:87)
>      org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:487)
>      org.jgroups.protocols.UNICAST.down(UNICAST.java:461)
>      org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:338)
>      org.jgroups.protocols.pbcast.GMS.down(GMS.java:901)
>      org.jgroups.protocols.FRAG2.down(FRAG2.java:117)
>
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:182)
>      org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1021)
>      org.jgroups.JChannel.down(JChannel.java:766)
>      org.jgroups.JChannel.send(JChannel.java:424)
>
> "[STUCK] ExecuteThread: '27' for queue: 'weblogic.kernel.Default
> (self-tuning)'" id=138 idx=0x24c tid=32436 prio=1 alive, parked,
> native_blocked, daemon
>      -- Parking to wait for:
> java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject <at> 0x5c8c40d0
>      at jrockit/vm/Locks.park0(J)V(Native Method)
>      at jrockit/vm/Locks.park(Locks.java:2230)[inlined]
>      at jrockit/proxy/sun/misc/Unsafe.park(Unsafe.java:616)[inlined]
>      at
> java/util/concurrent/locks/LockSupport.park(LockSupport.java:156)[inlined]
>      at
> java/util/concurrent/locks/AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)[optimized]
>      at
> java/util/concurrent/LinkedBlockingQueue.put(LinkedBlockingQueue.java:306)[optimized]
>      at
> org/jgroups/protocols/TP$TransferQueueBundler.send(TP.java:2239)[optimized]
>      at org/jgroups/protocols/TP.send(TP.java:1540)[optimized]
>      at org/jgroups/protocols/TP.down(TP.java:1281)[optimized]
>      at org/jgroups/protocols/Discovery.down(Discovery.java:597)[inlined]
>      at org/jgroups/protocols/TCPPING.down(TCPPING.java:108)[optimized]
>      at org/jgroups/protocols/MERGE2.down(MERGE2.java:182)[optimized]
>      at org/jgroups/protocols/FD_SOCK.down(FD_SOCK.java:348)[optimized]
>      at org/jgroups/protocols/FD.down(FD.java:307)[optimized]
>      at
> org/jgroups/protocols/VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:84)[optimized]
>      at org/jgroups/protocols/BARRIER.down(BARRIER.java:95)[optimized]
>      at org/jgroups/protocols/pbcast/NAKACK.down(NAKACK.java:569)[optimized]
>      at org/jgroups/protocols/UNICAST.down(UNICAST.java:521)[optimized]
>      at org/jgroups/protocols/pbcast/STABLE.down(STABLE.java:361)[optimized]
>      at org/jgroups/protocols/pbcast/GMS.down(GMS.java:958)[optimized]
>      at org/jgroups/protocols/FRAG2.down(FRAG2.java:143)[optimized]
>      at
> org/jgroups/protocols/pbcast/STATE_TRANSFER.down(STATE_TRANSFER.java:237)[optimized]
>      at
> org/jgroups/stack/ProtocolStack.down(ProtocolStack.java:1022)[optimized]
>      at org/jgroups/JChannel.down(JChannel.java:767)[inlined]
>      at org/jgroups/JChannel.send(JChannel.java:432)[inlined]
>
> Thanks,
> Dinesh

--

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

------------------------------------------------------------------------------
Bela Ban | 21 Oct 11:06 2014
Picon

[jgroups-users] JGroups 3.6.0.Final released

http://belaban.blogspot.ch/2014/10/jgroups-360final-released.html

--

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

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho

Gmane