one-port support for HornetQ
One of the main features planned for WildFly is to use a single port for all remoting access (including JMS).
WildFly 8 will only have a single HTTP port opened and remoting clients will switch to their respective protocols by initiating a HTTP Upgrade request.
This impacts HornetQ since it must be able to fit into this design to have its connectors and acceptors ready to work with a single port.
HornetQ connectors (that are used by clients to connect to the brokers) must be able to initiate the HTTP Upgrade request and switch to its core protocol after the Upgrade succeeds.
Similarly, HornetQ acceptors must be ready to handle the HTTP Upgrade and upgrade the connection to serve the core protocol.
In WildFly, the Undertow Web container is in charge of the HTTP upgrade and protocols must be registered to a ChannelUpgradeHandler and provide an implementation of XNIO's ChannelListener<StreamConnection> that corresponds to the switched connection after the upgrade succeeds.
Note that this only concerns HornetQ CORE protocol (used for JMS) and not its STOMP and AMQP implementations where the protocols (and their client implementations) do not support connections initiated by a HTTP Upgrade.
Acceptors
HornetQ is using Netty 3.x at the moment and this version does not accept socket handover. This will not fit with WildFly design where Undertow+XNIO owns the server socket.
There are 2 possibilites to provide one-port acceptor for HornetQ:
1. Upgrade to Netty 4.x (that support socket handover), patch XNIO to be able to access the ServerSocket and implement a ChannelListener<StreamConnection> that will access this raw server socket and pass it somehow to Netty in the existing NettyAcceptor. This also implies to run performance tests with Netty 4.x to avoid any regression.
2. Create a XNIO-based Acceptor that can be plugged into HornetQ. This requires no upgrade to Netty (since it will not be used at all) or patch to XNIO. I am not sure how much work this new acceptor represents... and we will have to run performance tests with it too.
In both case, WildFly's messaging subsystem will be configured to register HornetQ core's ChannelListener<StreamConnection> to its Undertow server.
For HornetQ standalone, we could also provide one-port support by embedding an Undertow Web server with a ChannelUpgradeHandler and registering its CORE protocol. This would ensure that the HornetQ clients would always use the same connector regardless of connecting to WildFly or standalone HornetQ.
=> This would add a dependency to undertow-core + XNIO in hornetq-server module.
Connectors
Connectors will now connect to the broker by initiating a HTTP request with a Upgrade header.
That implies that HornetQ client jar must be able to make this HTTP request and perform the Upgrade handshake.
Unfortunately, java.net.HttpURLConnection can not be used since it does not allow to use the Upgrade header by default.
One option would be to use Undertow client code (adding a dependency to undertow-core + xnio) that would perform the HTTP Upgrade and give access to the StreamConnection.
HornetQ is also using Netty 3.x for its remoting client side. We have the same options to provide one-port connector for HornetQ
1. Upgrade to Netty 4.x, apply the same patch to XNIO to access the raw socket and pass it to the existing Netty Connector
2. Create a XNIO-based Connector. Again, I am not sure how much work this new connector represents...
To sum up, there are 2 alternatives:
1. Upgrade to Netty 4.x, patch XNIO and keep the existing Netty-based connector/acceptor
2. Provde XNIO-based connector/acceptor. I don't know much about XNIO and have no idea the amount of work it represents to provide a new transport (will the same feature set than the Netty ones).
Any thoughts on this?
