[
https://jira.jboss.org/jira/browse/JGRP-860?page=com.atlassian.jira.plugi...
]
Bela Ban commented on JGRP-860:
-------------------------------
[Notes from Sacha]
I still see too many people having trouble properly setting their
JGroups-based clusters. Most of the time it is by lack of knowledge or by
a constraint network infrastructure, but it is a fact. Consequently, I
would imagine a network tool that could be setup on all machines to
auto-discover some of those issues.
For example (might not be the best idea, but still):
- start a central GUI application on a node (or command line, whatever)
- start JGroups with a special flag on all remote nodes => agent mode!
- all those distributed agents will register with the central GUI
application and share their IP address, etc.
- the central application will then try to make them communicate using
the best protocol, etc. trying different options, possibly benchmarking
those.
- in case the nodes have several IPs, the tool would try those different
IPs to find the proper one
- would try to see if multicast is possible between those nodes or not
- if only a GOSSIP or TCP setup is possible
- would then write the resulting XML for the proposed Stack
Makes sense?
Another option would be to do the same thing and have the possibility to
run a bench and "dynamically" change some parameters of the stack and see
the changes => size of the messages, TTL, etc. so that developers could
dynamically adjust their stack based on their environment.
GUI to test whether cluster nodes find each other ok
----------------------------------------------------
Key: JGRP-860
URL:
https://jira.jboss.org/jira/browse/JGRP-860
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.8
- New DiscoveryServer (GUI) which listens on a TCP socket at a given port
- Then the nodes are started and connect to the DiscoveryServer via TCP
- Connected nodes are shown in a listbox in the DiscoveryServer's GUI
- The TCP connection between a node and the DS is the *control channel*, and is
independent of JGroups (doesn't use a JGroups config)
- The control channel is used to (a) register nodes and (b) send new JGroups
configurations from the DS to the nodes
- The GUI has 4 tabs: UDP, TCP dynamic (TCP:MPING config), TCP static (TCP:TCPPING) and
External discovery (TCP:TCPGOSSIP).
- Each tab has configuration specific options, e.g. for UDP we have
- multicast address
- multicast port
- TTL
- checkbox: use flush or not
- checkbox: use state transfer or not
- etc etc etc
There are 2 actions buttons: "Discover" and "Save config". The latter
saves the current configuration to a file (XML format). The "Discovery" button
sends the current config to all nodes, via the control channel. Each node then creates a
channel with the received config and connects to the cluster. The DiscoveryServer GUI
(which also joins the same cluster) shows all nodes in a second listbox. When the number
of nodes in the first and second listbox is the same, then this shows that the config
works. In that case, the user can press "Save config" and use the generated
config with all cluster nodes.
- In case UDP doesn't work or a user wants a TCP based config from the onset, the
user simply clicks on the TCP tab, fills in the required information and clicks on
"Discover".
- The initial config for each tab is provided by the corresponding default shipped with
JGroups, e.g. UDP uses udp.xml
In a second stage, we could also not just verify that the cluster can be established, but
also run some perf tests over it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira