[WFLY-19992] Enable configuration of selected XNIO/Remoting parametrs… #668
Conversation
… for remoting objects for inbound and outblound communication
|
|
||
| == Overview | ||
|
|
||
| During analysis of various support cases we found out that there is no possibility to configure XNIO/Remoting options for connections that use remoting protocol (f.e. EJB). It it worth emphasizing that this issue doesn't deal merely with the lack of options parsing that has to be implemented. There are many objects that are created by remoting f.e. Endpoints or Channels, and, what is important in the context of this issue, they can be used in both inbound and outbound scenario. So the goal of this issue is to design and document the elegant way of configuring remoting options. |
There was a problem hiding this comment.
We can configure certain XNIO/Remoting options, but we cannot generally configure all XNIO/Remoting options.
| == Requirements | ||
|
|
||
| * users would be able to configure selected options | ||
| * users would be able to rely on one configuration file "standalone*.xml" for in server deployments |
There was a problem hiding this comment.
This is not a requirement, it is part of a proposed solution. Users already use many different files to configure their application deployments.
|
|
||
| === Non-Requirements | ||
|
|
||
| * configuration of all available xnio/remoting options |
There was a problem hiding this comment.
If this is the case, which subset of XNIO/Remoting options are targeted for configuration?
|
|
||
| === User Stories | ||
|
|
||
| User deploys many number of applications on WildFly - the number of them exceeds the default maximum number of channels for remoting protocol. All those application utilize a remoting connection. Users are getting: "Too many channels open" exception. They would like to configure their server so that the application works correctly. |
There was a problem hiding this comment.
Any similar problems on a standalone client?
| I'm attaching relevant parts of my implementation plan that I wrote in WFCORE-6873: | ||
|
|
||
| === Current status | ||
| There are number of XNIO objects created in default WildFly configuration (Endpoints, connectors) which have to be configured on both client and server side to make the configuration work. During the connection establishment, client and server negotiate the parameters, so if f.e. MAX_INBOUND_CHANNELS is set to high value on the server but MAX_OUTBOUND_CHANNELS is not explicitly set then the default value would still be used. Although, completely logical, it may be confusing to users who change configuration that the parameters they have modified are not used. Even with the knowledge above, it is not always clear what objects have to be changed to make the configuration work. For example, there is an endpoint configuration in the remoting subystem (not present in default subsystem configuration) that is meant to configure subsystem endpoint (that is the endpoint that is used by the subsystems and not management). The subystem endpoint is then used to create the http-connector that is used, among others, for remoting+http protocol invocations. The problem is that the properties configured at subsystem endpoint are not propagated to the http-connector. As a result, setting MAX_INBOUND_CHANNELS on the subsystem endpoint would not result in changing the number of channels, even if client side is configured correctly. In order to make server side work, the properties have to be configured on http-connector directly. |
There was a problem hiding this comment.
The fact that configuration properties of the HTTP connector are not inherited from the Remoting subsystem Endpoint is a separate issue.
|
|
||
| === Considerations for the proposed solution | ||
|
|
||
| We would like to avoid having many configuration files and keep the server configuration in standalone-*.xml file. |
There was a problem hiding this comment.
We already have a lot of configuration files for configuring deployments (e.g. jboss-ejb-client.xml and others) and there is no intention of eliminating these.
|
|
||
| We would like to avoid having many configuration files and keep the server configuration in standalone-*.xml file. | ||
| Even with wildfly-config.xml, we can only configure one subsystem endpoint for outbound communication (via server-wide wildfly-config.xml) and another (via remoting subsystem) for inbound communication. | ||
| On the other hand, it would be preferable to support minimal configuration that is suitable for our customer use cases. Since the configuration with one subsystem endpoint and without direct possibility of outbound endpoint configuration seems to work well for vast majority of our customer it seems feasible to add minimal extension that solves the bugs described above. |
There was a problem hiding this comment.
Are there performance implications for this change? We are moving from two endpoints per server (used to create connections and channels and send traffic) down to one. On a server with a lot of inbound traffic from clients and a lot of outbound traffic from deployments, might this have a performance impact?
|
|
||
| === Possibilities of further extension | ||
|
|
||
| As noted above, this proposal is a minimal solution that solves the problem - it enables users to configure Endpoint properties in one place but does not allow for any more complex configuration. For example a more comphrehensive fix to this problem may allow to configure a number of endpoints so that different endpoints can be chosen for inbound or outbound scenarios or chosen by various deployments. The problem with those more complex designs is that we don't have any user feedback that they need such configuration abilities and we may risk implementing non-trivial configuration extensions that would not be used. Because of that, I'm proposing to start with this simple solution first. If after it's introduction we obtain a feedback that more complex configuration is needed, we would follow in next RFE. In such scenario, we would have more data what configurations are needed by and we would be able to design the extension based on this feedback. |
There was a problem hiding this comment.
If there are only one or two "problem properties" (e.g. MAX_OUTBOUND_CHANNELS, MAX_INBOUND_CHANNELS) why is this solution preferable to the system property solution?
| [[test_plan]] | ||
| == Test Plan | ||
|
|
||
| Suggested fix does not introduce any XML modification - it only wires remoting objects in a way so that the endpoint configured in remoting subsystem is "captured" also for outbound connection. Because of that, we may provide integration test that will emulate the behavior described in use case scenario and verify that the fix makes it work correctly. |
There was a problem hiding this comment.
I think you might also include extensive performance testing as you are moving from two Endpoints down to one.
|
|
||
| == Community Documentation | ||
|
|
||
| The community documentation would have to add information about sharing an endpoint for inbound and outbound communication. Explanation of configuration in real world scenario, such as mentioned use case, is also necessary. |
There was a problem hiding this comment.
This is going to be hard to explain to users - why they should use separate configuration files for their deployments - except in the case of Remoting and XNIO configuration.
… for remoting objects for inbound and outblound communication
https://issues.redhat.com/browse/WFLY-19992