2:19 p.m.
I'm trying to understand the issues in remoting subsystem vs the management usage a
bit better before I dig into this. We have 3 ways remoting is set up:
1) Standalone server
a) Endpoint is set up when installing the subsystem
b) Management is set up and creates a new stream server and channel open listener for
("management") with the endpoint from a) injected
2) Host controller
a) Endpoint is set up by the bootstrap
b) Bootstrap sets up the management stream server and channel open listeners for (using
endpoint from a) injected
-"management" - i.e. traffic on the management address
-"server" - i.e. traffic from a server
-"domain" - if it is the master, to listen to traffic from slaves
c) If it is a slave it connects to the master on the "domain" channel
3) Domain mode server
a) Endpoint is set up when installing the subsystem
b) No management stream server is created
c) A channel is opened to the HC using the endpoint from a) on the "server"
channel.
So, I think the issue is that the core depends on stuff set up by a subsystem? A problem
in 3 is that if there is no remoting subsystem no endpoint is created, so communication
with HC will not start and we will not get the subsystem config from the HC.
Something doesn't feel quite right but I'm not sure what, so I'm throwing out
some ideas.
The remoting subsystem is quite basic at the moment and the code to set up new connectors
is commented out.
So maybe we should stick with what we have for HC:
<management>
<security-realms>
SNIP
</security-realms>
<management-interfaces>
<native-interface interface="management" port="9999"
/>
<http-interface interface="management" port="9990"/>
</management-interfaces>
</management>
But for the standalone server case do something like
<management>
<management-interfaces>
<native-channel name="server" />
<http-interface interface="management" port="9990">
</management-interfaces>
</management>
<subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
<connector socket-binding="remote-management">
<security-stuff><security-stuff/>
<channel name="server" type="management"/>
</connector>
<connector socket-binding="user">
<security-stuff><security-stuff/>
<channel name="jndi" type="jndi"/>
<channel name="jndi" type="ejb"/>
</connector>
</subsystem>
Or maybe everything all goes over one socket so
<subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
<connector socket-binding="remote-management">
<security-stuff><security-stuff/>
<channel name="server" type="management"/>
<channel name="jndi" type="jndi"/>
<channel name="jndi" type="ejb"/>
</connector>
</subsystem>
I'm not clear on the security side of this but we now have the http side of it
securing itself in one way and the native channel in another, so maybe this is better
<management>
<management-interfaces>
<native-channel name="server" />
<http-interface interface="management" port="9990">
<security-realms>
SNIP
</security-realms>
</http-interface>
</management-interfaces>
</management>
Or the alternative for the domain mode server is to use two endpoints, one for management
installed by the core, and one for other stuff installed by the remoting subsystem.
3:41 p.m.
Real quick reply:
1) IMO only having a single remoting socket for both management and
other uses is A Real Good Thing™. But if there are situations that
prevent that, I don't think it's terrible.
2) We need to continue to support AS 7.0-style configs. That to me means
for cases where that style config is used, we create a separate endpoint.
3) For a domain mode server, we can't force people to add a remoting
subsystem in their domain.xml profile. We talked about having the
HostController generate one, but that will result in the server having a
profile that does not match what was configured in domain.xml --
suddenly a bonus subsystem appears. That is no good.
4) For a domain mode server if the HostController is going to configure
the server to set up a native management interface that points to the
remoting subsystem in the profile, it needs to be told how to do so. One
solution, is, in domain.xml:
<server-group name="main-server-group" profile="default">
<native-management remoting-connector="management"/>
</server-group>
In summary, I think reusing the remoting subsystem endpoint is great and
we should have our standard configs set up that way but there are cases
where things aren't going to be configured that way.
On 9/22/11 2:19 PM, Kabir Khan wrote:
I'm trying to understand the issues in remoting subsystem vs the
management usage a bit better before I dig into this. We have 3 ways remoting is set up:
1) Standalone server
a) Endpoint is set up when installing the subsystem
b) Management is set up and creates a new stream server and channel open listener for
("management") with the endpoint from a) injected
2) Host controller
a) Endpoint is set up by the bootstrap
b) Bootstrap sets up the management stream server and channel open listeners for (using
endpoint from a) injected
-"management" - i.e. traffic on the management address
-"server" - i.e. traffic from a server
-"domain" - if it is the master, to listen to traffic from slaves
c) If it is a slave it connects to the master on the "domain" channel
3) Domain mode server
a) Endpoint is set up when installing the subsystem
b) No management stream server is created
c) A channel is opened to the HC using the endpoint from a) on the "server"
channel.
So, I think the issue is that the core depends on stuff set up by a subsystem? A problem
in 3 is that if there is no remoting subsystem no endpoint is created, so communication
with HC will not start and we will not get the subsystem config from the HC.
Something doesn't feel quite right but I'm not sure what, so I'm throwing out
some ideas.
The remoting subsystem is quite basic at the moment and the code to set up new connectors
is commented out.
So maybe we should stick with what we have for HC:
<management>
<security-realms>
SNIP
</security-realms>
<management-interfaces>
<native-interface interface="management" port="9999"
/>
<http-interface interface="management"
port="9990"/>
</management-interfaces>
</management>
But for the standalone server case do something like
<management>
<management-interfaces>
<native-channel name="server" />
<http-interface interface="management" port="9990">
</management-interfaces>
</management>
<subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
<connector socket-binding="remote-management">
<security-stuff><security-stuff/>
<channel name="server" type="management"/>
</connector>
<connector socket-binding="user">
<security-stuff><security-stuff/>
<channel name="jndi" type="jndi"/>
<channel name="jndi" type="ejb"/>
</connector>
</subsystem>
Or maybe everything all goes over one socket so
<subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
<connector socket-binding="remote-management">
<security-stuff><security-stuff/>
<channel name="server" type="management"/>
<channel name="jndi" type="jndi"/>
<channel name="jndi" type="ejb"/>
</connector>
</subsystem>
I'm not clear on the security side of this but we now have the http side of it
securing itself in one way and the native channel in another, so maybe this is better
<management>
<management-interfaces>
<native-channel name="server" />
<http-interface interface="management" port="9990">
<security-realms>
SNIP
</security-realms>
</http-interface>
</management-interfaces>
</management>
Or the alternative for the domain mode server is to use two endpoints, one for management
installed by the core, and one for other stuff installed by the remoting subsystem.
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
4854
days inactive
4854
days old
1 comments
2 participants
participants (2)
-
Brian Stansberry -
Kabir Khan