[jboss-jira] [JBoss JIRA] Commented: (JGRP-1202) SocketFactory: creation of sockets needs to have the singleton_name in shared transports
[
https://jira.jboss.org/browse/JGRP-1202?page=com.atlassian.jira.plugin.sy...
]
Bela Ban commented on JGRP-1202:
--------------------------------
I don't like the current solution. I think I'll scrap it and instead propose the
following:
- When creating a JChannel, set the socket factory. The factory impl would probably
include the stack name, since it is known by the channel creator
- The socket factory would reside in the transport (non singleton) or in the transport and
each of the TP$ProtocolAdapters
- Protocol would provide a getSocketFactory() method, which bubbles down the stack and
fetches the first socket factory found
- This is similar to what we do with ThreadFactory (nice !)
- Caveat: the channel creator has to install the socket factory, but that shouldn't be
a big deal
- Every socket is still created with a service name (no change to the SocketFactory API
!), and the socket factory impl keeps the name of the stack. Example: the stack name is
"udp-sync" and the service_name is "jgroups.fd_sock"; we'll look
up the port in an XML (of management console) and create a socket with the correct port
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: Bela Ban
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira