[jboss-jira] [JBoss JIRA] Commented: (JGRP-1202) SocketFactory: creation of sockets needs to have the singleton_name in shared transports

[Bela Ban (JIRA)]

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

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