[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 7/27/16 7:41 AM:
---------------------------------------------------------
Hmm... we could also start from the end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}.
The reason we abandoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}).
Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness.
The advantages of this over encoding the IP address in a UUID are:
* To extract an {{IpAddress}} from a UUID when sending a message, we'd need to create a new {{IpAddress}} instance for every message (high allocation rate). When adding some randomness to {{IpAddress}}, we can directly use those
* Encoding an IPv4 address in a UUID takes 6 bytes (4 for the address and 2 for the port), so we have 10 bytes left for randomness in the UUID. For IPv6, the required size is 18 bytes, so we'd need to make the UUID larger to have enough randomness. With the extension scheme, {{IpAddress}} would always contain the same amount of randomness.
was (Author: belaban):
Hmm... we could also start from the end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}.
The reason we abaondoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}).
Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness.
> 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)
8 years, 5 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:
--------------------------------
Hmm... we could also start from the end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}.
The reason we abaondoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}).
Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness.
> 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)
8 years, 5 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2062.
----------------------------
Resolution: Done
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2062:
---------------------------
Fix Version/s: 3.6.11
Backported to the 3.6 branch as well. Will break binary compatibilty if someone uses 3.6.10 and 3.6.11 in the same cluster and uses {{Util.objectToByteBuffer()}} methods.
However, the recommendation is to let users do their own serialization anyway, so this is fine IMO.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1673) Testsuite: tests for CLI controller aliases
by Martin Schvarcbacher (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1673?page=com.atlassian.jira.plugi... ]
Martin Schvarcbacher updated WFCORE-1673:
-----------------------------------------
Description:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
+*TEST PLAN*+
# set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
# connect to controller alias with all options (protocol, hostname, port) specified
# protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
# <default-protocol use-legacy-override=true> && no protocol specified && port=9999 →use remoting://
# <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
# no protocol specified in <default-controller> → use <default-protocol>
was:
Added integration tests for server aliases defined in jboss-cli.xml
Usage in bin/jboss-cli.xml:
{code:xml}
<controllers>
<controller name="ServerOne">
<protocol>http-remoting</protocol>
<host>localhost</host>
<port>9990</port>
</controller>
</controllers>
{code}
{code:bash}
./bin/jboss-cli.sh --controller=ServerOne --connect
{code}
> Testsuite: tests for CLI controller aliases
> -------------------------------------------
>
> Key: WFCORE-1673
> URL: https://issues.jboss.org/browse/WFCORE-1673
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Test Suite
> Reporter: Martin Schvarcbacher
> Assignee: Martin Schvarcbacher
> Priority: Minor
>
> Added integration tests for server aliases defined in jboss-cli.xml
> Usage in bin/jboss-cli.xml:
> {code:xml}
> <controllers>
> <controller name="ServerOne">
> <protocol>http-remoting</protocol>
> <host>localhost</host>
> <port>9990</port>
> </controller>
> </controllers>
> {code}
> {code:bash}
> ./bin/jboss-cli.sh --controller=ServerOne --connect
> {code}
> +*TEST PLAN*+
> # set invalid default controller configuration to ensure all settings are being loaded only from controller aliases
> # connect to controller alias with all options (protocol, hostname, port) specified
> # protocol specified in <default-controller> overrides <default-protocol> when calling --connect without --controller
> # <default-protocol use-legacy-override=true> && no protocol specified && port=9999 →use remoting://
> # <default-protocol use-legacy-override=false> && no protocol specified && port=9999 → use protocol from <default-protocol>
> # no protocol specified in <default-controller> → use <default-protocol>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2062:
--------------------------------
OK, so I added a check if the String contains only ASCII chars (< 128) and use TYPE_STRING if that's the case. If not, I use TYPE_UTF_STRING (newly added) and use write/readUTF() instead.
> TYPE_STRING does not handle unicode
> -----------------------------------
>
> Key: JGRP-2062
> URL: https://issues.jboss.org/browse/JGRP-2062
> Project: JGroups
> Issue Type: Bug
> Reporter: Cody Ebberson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character.
> For example, see objectToByteBuffer lines 561-567:
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util....
> {code:java}
> case TYPE_STRING:
> String str=(String)obj;
> int len=str.length();
> ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING);
> for(int i=0; i < len; i++)
> retval.put((byte)str.charAt(i));
> return retval.array();
> {code}
> This code will incorrectly encode any String with non ASCII encoding.
> There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6881) User with password which contains chinese chars isn't able to log in to AD (on Windows).
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-6881:
----------------------------------
Summary: User with password which contains chinese chars isn't able to log in to AD (on Windows).
Key: WFLY-6881
URL: https://issues.jboss.org/browse/WFLY-6881
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
Priority: Minor
We have a problem log in to AD on Windows. When user has password with chinese chars he cannot log in.
My observations:
I found out this: If I create AD entries from linux and update testsuite for using this entries (not creating own) then it is ok.
I wasn't able to find out where is the exact problem. In my opinion there is some problem with creating AD user password on windows.
Workaround:
Creating AD data in other way.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-1671) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1671?page=com.atlassian.jira.plugi... ]
Lin Gao updated WFCORE-1671:
----------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1704
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security
> ----------------------------------------------------------------------------------------
>
> Key: WFCORE-1671
> URL: https://issues.jboss.org/browse/WFCORE-1671
> Project: WildFly Core
> Issue Type: Bug
> Components: Security, Server
> Reporter: Derek Horton
> Assignee: Lin Gao
>
> security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following:
> <security-realm name="ManagementRealm">
> <authentication>
> <jaas name="jmx-console"/>
> </authentication>
> <authorization map-groups-to-roles="false">
> <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
> </authorization>
> </security-realm>
> <security-domain name="jmx-console" cache-type="default">
> <authentication>
> <login-module code="RealmUsersRoles" flag="required">
> <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/>
> </login-module>
> </authentication>
> </security-domain>
> The following error is logged during the authentication attempt:
> 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367)
> at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347)
> at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174)
> at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162)
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months