Details
-
Type:
Improvement Request
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 5.0.0
-
Fix Version/s: 5.0.1
-
Component/s: Transporter, WS API
-
Security Level: Public
-
- Environment:
- -
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Minor [ 4 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Summary | The listening IP of the NIO transporter and WS-API are not configurable and default to the configured container host | The listening IP of the NIO transporter, the JMX acces and WS-API are not configurable and default to the configured container host |
| Description |
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. |
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 JMX access, it is a bit different because RMI is taking care of setting this up and it seems it listens to 0.0.0.0 by default. |
| Summary | The listening IP of the NIO transporter, the JMX acces and WS-API are not configurable and default to the configured container host | The listening IP of the NIO transporter and WS-API are not configurable and default to the configured container host |
| Description |
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 JMX access, it is a bit different because RMI is taking care of setting this up and it seems it listens to 0.0.0.0 by default. |
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 JMX access, it is a bit different because it is the RMI Registry that actually listens and it is not configurable to listen to specific interfaces: it will always listen to everything. |
| Summary | The listening IP of the NIO transporter and WS-API are not configurable and default to the configured container host | The listening IP of the NIO transporter, the WS-API and the embedded regisrty are not configurable and default to the configured container host |
| Description |
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 JMX access, it is a bit different because it is the RMI Registry that actually listens and it is not configurable to listen to specific interfaces: it will always listen to everything. |
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 and the embedded registry. Note that altought the embedded registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the JMX access, it is a bit different because it is the RMI Registry that actually listens 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: - petals.transport.tcp.listen - petals.embedded-registry-overlay.listen - petals.ws-api.http.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
| Summary | The listening IP of the NIO transporter, the WS-API and the embedded regisrty are not configurable and default to the configured container host | The listening IP of the NIO transporter and the WS-API are not configurable and default to the configured container host |
| Description |
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 and the embedded registry. Note that altought the embedded registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the JMX access, it is a bit different because it is the RMI Registry that actually listens 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: - petals.transport.tcp.listen - petals.embedded-registry-overlay.listen - petals.ws-api.http.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
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 and the embedded registry. Concerning the Admin JMX service and the Embedded Registry, 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: - petals.transport.tcp.listen - petals.ws-api.http.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
| Summary | The listening IP of the NIO transporter and the WS-API are not configurable and default to the configured container host | The listening IP of the NIO transporter, the WS-API and the Embedded Registry are not configurable and default to the configured container host |
| Description |
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 and the embedded registry. Concerning the Admin JMX service and the Embedded Registry, 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: - petals.transport.tcp.listen - petals.ws-api.http.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
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 and the embedded registry. Note that although the Embedded Registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the Admin JMX service (of petals as well as of the registry), 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: - petals.transport.tcp.listen - petals.ws-api.http.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
| Description |
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 and the embedded registry. Note that although the Embedded Registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the Admin JMX service (of petals as well as of the registry), 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: - petals.transport.tcp.listen - petals.ws-api.http.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
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 and the embedded registry. Note that although the Embedded Registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the Admin JMX service (of petals as well as of the registry), 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: - petals.transport.tcp.listen - petals.ws-api.http.listen - petals.embedded-registry-overlay.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
| Description |
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 and the embedded registry. Note that although the Embedded Registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the Admin JMX service (of petals as well as of the registry), 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: - petals.transport.tcp.listen - petals.ws-api.http.listen - petals.embedded-registry-overlay.listen To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
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 and the embedded registry. Note that although the Embedded Registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the Admin JMX service (of petals as well as of the registry), 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: - petals.transport.tcp.receivers.listening.interface - petals.ws-api.http.listening.interface - petals.embedded-registry-overlay.listening.interface To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
| Summary | The listening IP of the NIO transporter, the WS-API and the Embedded Registry are not configurable and default to the configured container host | The listening IP of the NIO transporter and the WS-API are not configurable and default to the configured container host |
| Description |
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 and the embedded registry. Note that although the Embedded Registry is normally meant to be used only by the current container, there could be situations where it can't be running on localhost. Concerning the Admin JMX service (of petals as well as of the registry), 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: - petals.transport.tcp.receivers.listening.interface - petals.ws-api.http.listening.interface - petals.embedded-registry-overlay.listening.interface To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
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: - petals.transport.tcp.receivers.listening.interface - petals.ws-api.http.listening.interface To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 5.0.1 [ 10579 ] | |
| Resolution | Fixed [ 1 ] |
| Description |
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: - petals.transport.tcp.receivers.listening.interface - petals.ws-api.http.listening.interface To specify the address to listen to (localhost, 0.0.0.0, 192.160.1.1, etc). It will default to localhost (or should it default to the host of the current container as declared in the topology?) |
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! |
| Transition | Status Change Time | Execution Times | Last Executer | Last Execution Date | |||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
|||||||||
|
|
|
|
|
To be consistent with existing properties, can you use the following property names:
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.
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.