[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=12535502#action_12535502 ] 

Bela Ban commented on JGRP-1202:
--------------------------------

I guess injecting a SocketFactory instance into a stack is the way to go. However, we have to think about the following case. Say we have a shared transport ("udp") that's used by standard-session-cache and sfsb-cache.
All sockets created in sfsb-cache would be created by a SocketFactory instantiated with the name "sfsb-cache".
All sockets created in standard-session-cache would be created by a SocketFactory instantiated with the name "standard-session-cache".

So, for example, we could have the following config:
standard-session-cache:
FD_SOCK.bind_port: 7300

sfsb-cache:
FD_SOCK.bind_port: 7400

However, since we have a shared transport, what would the naming scheme be for it ? It's used by both standard-session-cache and sfsb-cache, so we cannot give it the name of either one, or should we ? Or should we just call it "udp" ?

One solution would be give the SocketFactory in a shared transport the name of its singleton_name attr, e.g. in the above example "udp".

When setting the SocketFactory, e.g. in JChannel.setSocketFactory(), we'd create an event SET_SOCKET_FACTORY (with an instance of a SocketFactory) and send it down the stack. 

When we have a singleton (shared) transport, the TP$ProtocolAdapter would catch the event and install the socket factory, then discard the event (not send it down to the transport). The transport's SocketFactory would have to be set separately.

When there's no singleton transport, the SET_SOCKET_FACTORY event would be caught by the transport (TP) and the factory would be installed.

A getSocketFactory() method (inherited from Protocol) would return the socket factory of TP$ProtocolAdapter if a singleton transport is used and the call originated from above TP, or the one from TP if the call originated in TP. If no singleton transport is used, the socket factory of TP would always be returned.

> 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. 

-- 
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