[
https://issues.jboss.org/browse/JGRP-1832?page=com.atlassian.jira.plugin....
]
Shay Matasaro commented on JGRP-1832:
-------------------------------------
The current test focuses mainly on identifying mcast issues which is a great diagnostics
start , and we use the largestate test to identify issues such as dropped packets etc..
But the largestate test uses a much bigger stack, is more complex to configure and run,
and it uses unicast.
1)
It would be great if the mcast sender had a feature , that will fire a stream of
sequentially numbered datagrams(for example 1,2,3,...100) to the mcast address , and the
receiver will identify and log any gaps in sequence.
This will also allow us to run multiple receivers, one on each node, with one sender and
complete testing of multiple nodes in one shot , rather then running the test multiple
times on "node couples"
2)
Can the test detect inefficient mtu fragmentation and defragmantation along a route?
3)
In order to track packet loss issues , we sometimes use jgroups at debug or trace log
level.
But, enabling jgroups debug/trace logging in a production environment , is tricky and can
slow down the server, especially if debug level is enabled on multiple servers.
It would be great if we can run a receiver instance(lets call it listener) that will
listen to the mcast cluster traffic and log relevant data(but obviously will not
interfere)
This allows us to trace mcast in a separate process or even a different machine without
any impact to the prod server.
The important aspect here is the ability to correlate the receiver log lines to the log
lines on servers for which we did enable jgroups debug.
4)
The information that the listener is recording could be further improved , and provide
great help , I have quiet a few suggestions on that front but i don’t want to make this
comment too long
one example would be that the listener log can be further precessed by an analysis tool to
detect split-brain , or cluster collisions.
let me know what you think?
more suggestions to come ;)
Update McastSenderTest/McastReceiverTest to bind the multicast
sockets the same as JGroups
------------------------------------------------------------------------------------------
Key: JGRP-1832
URL:
https://issues.jboss.org/browse/JGRP-1832
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.4.3
Reporter: Dennis Reed
Assignee: Dennis Reed
Priority: Optional
Fix For: 3.4.5, 3.5
JGroups binds multicast sockets using specific MulticastSocket constructors depending on
the operating system (to avoid crosstalk issues).
McastSenderTest and McastReceiverTest always bind the socket using the basic
MulticastSocket(port) constructor.
In order to more closely test the way JGroups will be sending and receiving the packets,
these tests will be updated to bind the sockets the same way.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)