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
Anuj Shah | 20 Oct 21:41 2014
Picon

[jgroups-users] ExecutionService at least once behaviour

I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!

This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc

                // The person currently servicing our request has gone down
                // without completing so we have to keep our request alive by
                // sending ours back to the coordinator

The problem is that there is no guarantee that the request was not completed.

For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout. 

I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)

Perhaps there could be control over the behaviour:
* At least once - assumes task failed and resubmits
* At most once - assumes task completed and cleans up - may not actually be complete
* Exactly once - not sure if this is possible
------------------------------------------------------------------------------
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
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users
Bela Ban | 15 Oct 15:36 2014
Picon

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


On 07/10/14 17:52, Bobby Bissett wrote:
> Hi all,
>
> 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:
>
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
>
> What we're seeing is that, after "some time," a member in a 3-node group
> seems to pause on one node for about 20 seconds. During that time there
> is no jgroups logging (Level.FINER) of heartbeat messages or logging
> from our own threads.

This points to a GC pause, as you suspected. JGroups will suspect and 
exclude the paused node from the cluster by FD, only to be re-merged 
back later by MERGE3.

> The node leaves the view and eventually rejoins
> it, but the long time pause causes other parts of our app to fail (the
> app mostly creates a jdbc connection every 10 seconds to ping a database
> and then cleans up the connection). This wasn't an issue on OpenJDK 6.

You can mitigate this on the JGroups side and up the timeout*max_tries 
to be greater than your longest GC pause. Currently the product is 9s in 
your config below.
This will reduce the number of false suspicions, but not completely 
eliminate them. E.g. if you up the combined timeout to 30s, but have a 
50s GC pause (I've seen those before, on large heaps with falsely 
configured GC options), then all bets are off again.

However, this will not help your DB connection code, as it'll hang as 
well. Also, if you invoke blocking RPCs into the paused node, the RPC 
will hang for the duration of the pause, or throw a TimeoutException if 
the max time of the call is less then the GC pause.

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.

> Before I go diving into GC tuning, has anyone else seen this before? I
> have logs available if that helps any. At the time of the pause, there
> are 2 lines out of order in the log, one appearing 20 seconds later than
> it was supposed to.
>
> Thanks,
> Bobby
>
>         JChannel channel = new JChannel(false);
>          ProtocolStack stack = new ProtocolStack();
>          channel.setProtocolStack(stack);
>
>          stack.addProtocol(new TCP()
>              .setValue("oob_thread_pool_keep_alive_time", 5000)
>              .setValue("timer_keep_alive_time", 3000)
>              .setValue("bind_addr", InetAddress.getByName(<address>)
>              .setValue("bind_port", bindingPort)
>              .setValue("thread_pool_min_threads", 1)
>              .setValue("thread_pool_keep_alive_time", 5000)
>              .setValue("send_buf_size", 640000)
>              .setValue("oob_thread_pool_queue_max_size", 100)
>              .setValue("oob_thread_pool_max_threads", 8)
>              .setValue("thread_pool_queue_enabled", false)
>              .setValue("sock_conn_timeout", 300)
>              .setValue("oob_thread_pool_min_threads", 1)
>              .setValue("loopback", false)
>              .setValue("oob_thread_pool_queue_enabled", false)
>              .setValue("max_bundle_timeout", 30)
>              .setValue("thread_pool_queue_max_size", 100)
>              .setValue("recv_buf_size", 5000000))
>              .addProtocol(new TCPPING()
>                  .setValue("initial_hosts", <3 addresses here>)
>                  .setValue("num_initial_members", 3)) // default: 10
>              .addProtocol(new MERGE2()
>                  .setValue("min_interval", 10000)
>                  .setValue("max_interval", 30000))
>              .addProtocol(new FD_SOCK())
>              .addProtocol(new FD()
>                  .setValue("max_tries", getJGRoupsMaxTries()) <-- 3
>                  .setValue("timeout", getJGroupsTimeout())) <-- 3000
>              .addProtocol(new VERIFY_SUSPECT()
>                  .setValue("timeout", 1500))
>              .addProtocol(new BARRIER())
>              .addProtocol(new NAKACK2()
>                  .setValue("use_mcast_xmit", false))
>              .addProtocol(new UNICAST3()
>                  .setValue("conn_close_timeout", 5000L))
>              .addProtocol(new STABLE()
>                  .setValue("desired_avg_gossip", 50000)
>                  .setValue("max_bytes", 4000000)
>                  .setValue("stability_delay", 1000))
>              .addProtocol(createAuthProtocol())
>              .addProtocol(new GMS()
>                  .setValue("join_timeout", 3000)
>                  .setValue("print_local_addr", false))
>              .addProtocol(new MFC()
>                  .setValue("max_credits", 2000000)
>                  .setValue("min_credits", 800000))
>              .addProtocol(new FRAG2());
>          stack.init();

--

-- 
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
Bela Ban | 6 Oct 08:39 2014
Picon

[jgroups-users] Docker and JGroups

FYI,

[1] http://belaban.blogspot.ch/2014/10/jgroups-and-docker.html

--

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

------------------------------------------------------------------------------
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
Dave Rathnow | 3 Oct 20:20 2014
Picon

[jgroups-users] How to stop JGRP000010 warnings

We recently installed a third party product in our network that uses a version of JBoss that includes JGroups.  I do development using JBoss and, since they installed the product, have been finding these messages in my log file:

 

WARN  [org.jgroups.protocols.UDP] () JGRP000010: packet from 192.168.170.57:45688 has different version (2.11.0) than ours (3.2.12); packet is discarded (received 7 identical messages from 192.168.170.57:45688 in the last 61,400 ms)

 

I have two questions:

 

1.      What is causing this?

2.      Is there any way to stop it?

 

Thanks,
Dave

 

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
javagroups-users mailing list
javagroups-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javagroups-users

Gmane