SocketFactory: creation of sockets needs to have the singleton_name in shared transports ---------------------------------------------------------------------------------------- Key: JGRP-1202 URL: https://jira.jboss.org/browse/JGRP-1202 Project: JGroups Issue Type: Feature Request Reporter: Brian Stansberry Assignee: Bela Ban Fix For: 2.10 The createXXX() methods of SocketFactory need an additional parameter (possibly the singleton_name) when creating sockets in shared transport environments, e.g. FD_SOCK (A) and FD_SOCK (B) on the same shared transport will need to create server sockets on *different* ports, so we need to know whether we're creating a ServerSocket for A or B. [Email Brian] Should the createXXX methods return wrapper objects that contain the socket plus information about the socket (the addresses, ports)? This would allow JGroups to know how the socket is actually configured, so it can report the correct information via its own JMX interface, Probe, etc. > We have to agree on the service names. In JGroups, I'll have 1 file > (possibly Global.java, or mybe an XML file) which lists all service > names used. Brian will then need to use the same names in domain.xml, > and possibly add a description to each service, e.g.: > > jgroups.udp.mcast_port 7500 The multicast receiver socket of JGroups > jgroups.fd_sock.server_port 8950 The server socket of FD_SOCK (used for > failure detection) > These need to be qualified with the stack name, otherwise you can't run e.g. both stack name="udp-async" and stack name="udp-sync" in the same server. That could be empty or a default value if no stack name is known. Hmm, but that doesn't quite work for protocols that are shared across stacks, i.e. transports or hopefully FD_SOCK. Perhaps use: 1) singleton_name if configured 2) else stack name if configured 3) else empty or some default value This puts a burden on the SocketFactory impl to understand what's being requested and how that maps onto what's specified in its configuration (e.g. domain.xml). But that's the job of the SocketFactory impl.

SocketFactory: creation of sockets needs to have the singleton_name in shared transports ---------------------------------------------------------------------------------------- Key: JGRP-1202 URL: https://jira.jboss.org/browse/JGRP-1202 Project: JGroups Issue Type: Feature Request Reporter: Brian Stansberry Assignee: Bela Ban Fix For: 2.10 The createXXX() methods of SocketFactory need an additional parameter (possibly the singleton_name) when creating sockets in shared transport environments, e.g. FD_SOCK (A) and FD_SOCK (B) on the same shared transport will need to create server sockets on *different* ports, so we need to know whether we're creating a ServerSocket for A or B. [Email Brian] Should the createXXX methods return wrapper objects that contain the socket plus information about the socket (the addresses, ports)? This would allow JGroups to know how the socket is actually configured, so it can report the correct information via its own JMX interface, Probe, etc. > We have to agree on the service names. In JGroups, I'll have 1 file > (possibly Global.java, or mybe an XML file) which lists all service > names used. Brian will then need to use the same names in domain.xml, > and possibly add a description to each service, e.g.: > > jgroups.udp.mcast_port 7500 The multicast receiver socket of JGroups > jgroups.fd_sock.server_port 8950 The server socket of FD_SOCK (used for > failure detection) > These need to be qualified with the stack name, otherwise you can't run e.g. both stack name="udp-async" and stack name="udp-sync" in the same server. That could be empty or a default value if no stack name is known. Hmm, but that doesn't quite work for protocols that are shared across stacks, i.e. transports or hopefully FD_SOCK. Perhaps use: 1) singleton_name if configured 2) else stack name if configured 3) else empty or some default value This puts a burden on the SocketFactory impl to understand what's being requested and how that maps onto what's specified in its configuration (e.g. domain.xml). But that's the job of the SocketFactory impl.