Petals ESB Container

The listening IP of the NIO transporter and the WS-API are not configurable and default to the configured container host

Details

  • Type: Improvement Request Improvement Request
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 5.0.0
  • Fix Version/s: 5.0.1
  • Component/s: Transporter, WS API
  • Security Level: Public
  • Description:
    Hide

    The NIO transporter listens to the same host as the one configured in the topology.

    It can be problematic if we want to listen to all ips of the machine (0.0.0.0).
    The bottom of the issue is that we should differentiate between the listening ip and the host/ip used by other container to contact another one.

    This also the case for the WS-API extension.

    Concerning the Admin JMX service, it is a bit different because it is the RMI Registry that actually listens for both of them and it is not configurable to listen to specific interfaces: it will always listen to everything.

    We should introduce thus new configurations in server.properties to specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc):

    • petals.transport.tcp.receivers.listening.interface
    • petals.ws-api.http.listening.interface

    It will default to the host of the current container as declared in the topology!

    Show
    The NIO transporter listens to the same host as the one configured in the topology. It can be problematic if we want to listen to all ips of the machine (0.0.0.0). The bottom of the issue is that we should differentiate between the listening ip and the host/ip used by other container to contact another one. This also the case for the WS-API extension. Concerning the Admin JMX service, it is a bit different because it is the RMI Registry that actually listens for both of them and it is not configurable to listen to specific interfaces: it will always listen to everything. We should introduce thus new configurations in server.properties to specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc):
    • petals.transport.tcp.receivers.listening.interface
    • petals.ws-api.http.listening.interface
    It will default to the host of the current container as declared in the topology!
  • Environment:
    -

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Christophe DENEUX added a comment - Tue, 1 Dec 2015 - 15:02:01 +0100 - edited

To be consistent with existing properties, can you use the following property names:

  • petals.transport.tcp.receivers.listening.interface.
  • petals.ws-api.http.listening.interface.


IMO, it has no sense to introduce such a parameter for the embedded registry because the embedded registry is only available for standalone container. So, I think that we can use the interface 'localhost' as hard-coded value.

Show
Christophe DENEUX added a comment - Tue, 1 Dec 2015 - 15:02:01 +0100 - edited To be consistent with existing properties, can you use the following property names:
  • petals.transport.tcp.receivers.listening.interface.
  • petals.ws-api.http.listening.interface.

IMO, it has no sense to introduce such a parameter for the embedded registry because the embedded registry is only available for standalone container. So, I think that we can use the interface 'localhost' as hard-coded value.
Hide
Permalink
Victor NOËL added a comment - Tue, 1 Dec 2015 - 15:07:26 +0100

Yes but who knows if there is some restrictions that makes it running on 127.0.0.1 a problem? It was more for consistency, and anyway, we need to do it for the registry overlay (PETALSREGOVER-8), so adding the configuration for the embedded one is cheap… I will think)

Show
Victor NOËL added a comment - Tue, 1 Dec 2015 - 15:07:26 +0100 Yes but who knows if there is some restrictions that makes it running on 127.0.0.1 a problem? It was more for consistency, and anyway, we need to do it for the registry overlay (PETALSREGOVER-8), so adding the configuration for the embedded one is cheap… I will think)
Hide
Permalink
Christophe DENEUX added a comment - Tue, 1 Dec 2015 - 15:08:11 +0100

You can find here (http://vafer.org/blog/20061010091658/) some inputs to introduce such a parameter for the JMX API.

Show
Christophe DENEUX added a comment - Tue, 1 Dec 2015 - 15:08:11 +0100 You can find here (http://vafer.org/blog/20061010091658/) some inputs to introduce such a parameter for the JMX API.
Hide
Permalink
Victor NOËL added a comment - Tue, 1 Dec 2015 - 15:20:09 +0100

Ok, removed the embedded registry, it makes no real sense.

Show
Victor NOËL added a comment - Tue, 1 Dec 2015 - 15:20:09 +0100 Ok, removed the embedded registry, it makes no real sense.
Hide
Permalink
Victor NOËL added a comment - Tue, 1 Dec 2015 - 16:30:45 +0100

Committed and documentation updated too

Show
Victor NOËL added a comment - Tue, 1 Dec 2015 - 16:30:45 +0100 Committed and documentation updated too
Hide
Permalink
Christophe DENEUX added a comment - Tue, 1 Mar 2016 - 10:33:19 +0100

To be more user-friendly, the default value of the NIO transporter has been moved to "0.0.0.0" (all network interface). In this way, we can install easily a distributed topology without having to update 'server.properties'.

Show
Christophe DENEUX added a comment - Tue, 1 Mar 2016 - 10:33:19 +0100 To be more user-friendly, the default value of the NIO transporter has been moved to "0.0.0.0" (all network interface). In this way, we can install easily a distributed topology without having to update 'server.properties'.

People

Dates

  • Created:
    Tue, 1 Dec 2015 - 10:51:57 +0100
    Updated:
    Tue, 1 Mar 2016 - 10:33:19 +0100
    Resolved:
    Tue, 1 Dec 2015 - 16:30:45 +0100
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.