[jboss-jira] [JBoss JIRA] (JGRP-1832) Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups

[Shay Matasaro (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971259#comment-12971259 ] 

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)