bergtwvd
commented
9 years ago LOGFILE FOR CONTAINER B:
WARN [main] portico.lrc: MOM support is currently unsupported in IEEE-1516e federations.
DEBUG [main] org.jgroups.conf.ClassConfigurator: Using jg-magic-map.xml as magic number file and jg-protocol-ids.xml for protocol IDs
DEBUG [main] org.jgroups.stack.Configurator: set property UDP.bind_addr to default value /10.10.0.2
DEBUG [main] org.jgroups.stack.Configurator: set property UDP.diagnostics_addr to default value /224.0.75.75
DEBUG [main] org.jgroups.protocols.FRAG2: received CONFIG event: {bind_addr=/10.10.0.2}
TRACE [main] org.jgroups.blocks.MessageDispatcher$ProtocolAdapter: setting local_addr (null) to e96f542b7216-17605
DEBUG [main] org.jgroups.protocols.FRAG2: received CONFIG event: {flush_supported=true}
TRACE [main] org.jgroups.protocols.pbcast.STABLE: stable task started
TRACE [main] org.jgroups.protocols.UNICAST2: e96f542b7216-17605: stable task started
DEBUG [main] org.jgroups.protocols.UDP: sockets will use interface 10.10.0.2
WARN [main] org.jgroups.protocols.UDP: [JGRP00014] the send buffer of socket DatagramSocket was set to 640KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
WARN [main] org.jgroups.protocols.UDP: [JGRP00014] the receive buffer of socket DatagramSocket was set to 8MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
WARN [main] org.jgroups.protocols.UDP: [JGRP00014] the send buffer of socket MulticastSocket was set to 640KB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
WARN [main] org.jgroups.protocols.UDP: [JGRP00014] the receive buffer of socket MulticastSocket was set to 8MB, but the OS only allocated 212.99KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
DEBUG [main] org.jgroups.protocols.UDP: socket information:
, mcast_addr=239.255.20.16:20913, bind_addr=/10.10.0.2, ttl=8
sock: bound to 10.10.0.2:56777, receive buffer size=212992, send buffer size=212992
mcast_sock: bound to 10.10.0.2:20913, send buffer size=212992, receive buffer size=212992
TRACE [main] org.jgroups.protocols.UDP: joined /224.0.75.75:7500 on ethwe
TRACE [main] org.jgroups.protocols.UDP: joined /224.0.75.75:7500 on eth0
TRACE [main] org.jgroups.protocols.UDP: joined /224.0.75.75:7500 on lo
TRACE [main] org.jgroups.protocols.UDP: sending msg to null, src=e96f542b7216-17605, headers are PING: [PING: type=GET_MBRS_REQ, cluster=ExampleFederation, arg=e96f542b7216-17605, view_id=, is_server=false, is_coord=false, logical_name=e96f542b7216-17605, physical_addrs=10.10.0.2:56777], UDP: [channel_name=ExampleFederation]
TRACE [main] org.jgroups.protocols.UDP: looping back message [dst:
TRACE [Incoming,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.pbcast.STABLE: e96f542b7216-17605: sending stability msg (in 294 ms) e96f542b7216-17605: [0]
TRACE [Incoming] org.jgroups.protocols.pbcast.STABLE: e96f542b7216-17605: sending stability msg e96f542b7216-17605: [0]
TRACE [Incoming] org.jgroups.protocols.UDP: sending msg to null, src=e96f542b7216-17605, headers are STABLE: [STABILITY]: digest is e96f542b7216-17605: [0 (5)], UDP: [channel_name=ExampleFederation]
TRACE [Incoming] org.jgroups.protocols.UDP: looping back message [dst:
TRACE [ViewHandler,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.pbcast.NAKACK2: e96f542b7216-17605 sending e96f542b7216-17605#7
TRACE [ViewHandler,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.UDP: sending msg to null, src=e96f542b7216-17605, headers are GMS: GmsHeader[VIEW]: view=[e96f542b7216-17605|1] [e96f542b7216-17605, a627c2c18b9a-60763], NAKACK2: [MSG, seqno=7], UDP: [channel_name=ExampleFederation]
TRACE [ViewHandler,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.UDP: looping back message [dst:
TRACE [Incoming,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.UDP: received [dst:
TRACE [ViewHandler,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.pbcast.NAKACK2: e96f542b7216-17605 sending e96f542b7216-17605#9
TRACE [ViewHandler,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.UDP: sending msg to null, src=e96f542b7216-17605, headers are GMS: GmsHeader[VIEW]: view=[e96f542b7216-17605|2] [e96f542b7216-17605], NAKACK2: [MSG, seqno=9], UDP: [channel_name=ExampleFederation]
TRACE [ViewHandler,ExampleFederation,e96f542b7216-17605] org.jgroups.protocols.UDP: looping back message [dst:
michaelrfraser
rade
hodiapa
I set up a test with the sample program installed in a Docker container (Dockerfile to be provided later).
Test environment:
Test:
A exits with a stacktrace. Logfile are attached.
Following test succeeds: On container A: java -cp $RTI_HOME/lib/portico.jar org.jgroups.tests.McastReceiverTest -mcast_addr 228.10.10.10 -port 20913
On container B: java -cp $RTI_HOME/lib/portico.jar org.jgroups.tests.McastSenderTest -mcast_addr 228.10.10.10 -port 20913
Route table on A: Destination Gateway Genmask Flags Metric Ref Use Iface default 10.1.0.1 0.0.0.0 UG 0 0 0 eth0 10.1.0.0 * 255.255.0.0 U 0 0 0 eth0 10.10.0.0 * 255.255.255.0 U 0 0 0 ethwe 224.0.0.0 * 240.0.0.0 U 0 0 0 ethwe
Route tabel on B: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.2.0.1 0.0.0.0 UG 0 0 0 eth0 10.2.0.0 * 255.255.0.0 U 0 0 0 eth0 10.10.0.0 * 255.255.255.0 U 0 0 0 ethwe 224.0.0.0 * 240.0.0.0 U 0 0 0 ethwe