[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2080 at 9/21/16 10:45 AM:
----------------------------------------------------------
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each
* 32 bytes for {{Inet6Address}}
This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses...
That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}.
The downside is that we have to create a new instance of {{Inet4Address}} or {{Inet6Address}} every time we need to send a unicast message, by extracting the address and port from the UUID.
was (Author: belaban):
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each
* 32 bytes for {{Inet6Address}}
This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses...
That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2080:
--------------------------------
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each
* 32 bytes for {{Inet6Address}}
This means a total of 88 bytes for an IPv4 address and 96 bytes for an IPv6 address! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use 40 bytes for an IPv4 address and 48 bytes for an IPv6 address. That's much less memory used than {{IpAddressUUID}}.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2080 at 9/21/16 10:42 AM:
----------------------------------------------------------
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each
* 32 bytes for {{Inet6Address}}
This means a total of *88 bytes for an IPv4 address* and *96 bytes for an IPv6 address*! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses...
That would use *40 bytes for an IPv4 address* and *48 bytes for an IPv6 address*. That's much less memory used than {{IpAddressUUID}}.
was (Author: belaban):
I'm starting to have second thoughts on {{IpAddressUUID}}... :-(
Looking at the size of an instance (using JOL), we have
* 32 bytes for {{IpAddressUUID}}
* 24 bytes for {{Inet4Address}}
* 32 bytes for {{InetAddressHolder}} and {{InetAddressHolder6}} each
* 32 bytes for {{Inet6Address}}
This means a total of 88 bytes for an IPv4 address and 96 bytes for an IPv6 address! This is *per instance*! Note that if we used symbolic hostnames, then all Inet4Addresses and Inet6Addresses pointing to the same host would be canonicalized to point to the same address instance, but that's not the case when using dotted-decimal addresses.
I'm starting to think whether it would make more sense to use Neal's original proposal and simply increase the size of a {{UUID}} by 6 bytes (4 address and 4 port) for IPv4 and 20 bytes (16 address and 4 port) for IPv6 addresses... That would use 40 bytes for an IPv4 address and 48 bytes for an IPv6 address. That's much less memory used than {{IpAddressUUID}}.
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1301) Add remote API call to deploy kie artifact from a specific maven repo.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1301?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1301:
-------------------------------------
In practice it is required to:
# have an API to dynamically add and remove a maven repository and list all available repositories
# have a public method to deploy an artifact into a specific repository
> Add remote API call to deploy kie artifact from a specific maven repo.
> ----------------------------------------------------------------------
>
> Key: DROOLS-1301
> URL: https://issues.jboss.org/browse/DROOLS-1301
> Project: Drools
> Issue Type: Feature Request
> Reporter: Hiram Chirino
> Assignee: Mario Fusco
>
> We want to build a camel OSE example which needs to deploy kie artifacts to a BRMS server. We want to avoid having to require a user from having to setup and deploy this artifacts to mvn repo.
> We could have our example pod host a mvn repo with the kie artifacts deployed to it. It would be nice to have the API call the requests the sever to the deploy the artifact GAV to also pass along the the mvn repo URL to the pod hosting the kie artifacts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1301) Add remote API call to deploy kie artifact from a specific maven repo.
by Hiram Chirino (JIRA)
Hiram Chirino created DROOLS-1301:
-------------------------------------
Summary: Add remote API call to deploy kie artifact from a specific maven repo.
Key: DROOLS-1301
URL: https://issues.jboss.org/browse/DROOLS-1301
Project: Drools
Issue Type: Feature Request
Reporter: Hiram Chirino
Assignee: Edson Tirelli
We want to build a camel OSE example which needs to deploy kie artifacts to a BRMS server. We want to avoid having to require a user from having to setup and deploy this artifacts to mvn repo.
We could have our example pod host a mvn repo with the kie artifacts deployed to it. It would be nice to have the API call the requests the sever to the deploy the artifact GAV to also pass along the the mvn repo URL to the pod hosting the kie artifacts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months