[JBoss JIRA] (WFLY-3251) @WebContext overrides realm in web.xml
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3251?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-3251:
----------------------------------
Fix Version/s: 9.0.0.Alpha1
> @WebContext overrides realm in web.xml
> --------------------------------------
>
> Key: WFLY-3251
> URL: https://issues.jboss.org/browse/WFLY-3251
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Alessio Soldano
> Fix For: 9.0.0.Alpha1
>
>
> In WEB-INF/web.xml I'm having this declaration (to be used for REST and SOAP):
> {code}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Shop</realm-name>
> </login-config>
> {code}
> Furthermore, I'm having a SOAP-based web service:
> {code}
> @WebService(name = "KundeSOAP",
> targetNamespace = "urn:shop:soap:kunde",
> serviceName = "KundeSOAPService")
> @SOAPBinding
> @WebContext(authMethod = "BASIC",
> transportGuarantee = "CONFIDENTIAL",
> secureWSDLAccess = true)
> @Stateless
> @Interceptors(ConstraintViolationInterceptor.class)
> @RolesAllowed({ "...", "..." })
> @SecurityDomain("...")
> public class KundeSOAP {...}
> {code}
> But when the client invokes the server, then the realm name is "EJBWebServiceEndpointServlet Realm".
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3251) @WebContext overrides realm in web.xml
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-3251?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann updated WFLY-3251:
-------------------------------------
Affects Version/s: 8.1.0.CR2
(was: 8.0.0.Final)
> @WebContext overrides realm in web.xml
> --------------------------------------
>
> Key: WFLY-3251
> URL: https://issues.jboss.org/browse/WFLY-3251
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Alessio Soldano
>
> In WEB-INF/web.xml I'm having this declaration (to be used for REST and SOAP):
> {code}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Shop</realm-name>
> </login-config>
> {code}
> Furthermore, I'm having a SOAP-based web service:
> {code}
> @WebService(name = "KundeSOAP",
> targetNamespace = "urn:shop:soap:kunde",
> serviceName = "KundeSOAPService")
> @SOAPBinding
> @WebContext(authMethod = "BASIC",
> transportGuarantee = "CONFIDENTIAL",
> secureWSDLAccess = true)
> @Stateless
> @Interceptors(ConstraintViolationInterceptor.class)
> @RolesAllowed({ "...", "..." })
> @SecurityDomain("...")
> public class KundeSOAP {...}
> {code}
> But when the client invokes the server, then the realm name is "EJBWebServiceEndpointServlet Realm".
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3251) @WebContext overrides realm in web.xml
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-3251?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-3251:
------------------------------------------
CR4 can be obtained from GitHub although not officially released.
> @WebContext overrides realm in web.xml
> --------------------------------------
>
> Key: WFLY-3251
> URL: https://issues.jboss.org/browse/WFLY-3251
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Alessio Soldano
>
> In WEB-INF/web.xml I'm having this declaration (to be used for REST and SOAP):
> {code}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Shop</realm-name>
> </login-config>
> {code}
> Furthermore, I'm having a SOAP-based web service:
> {code}
> @WebService(name = "KundeSOAP",
> targetNamespace = "urn:shop:soap:kunde",
> serviceName = "KundeSOAPService")
> @SOAPBinding
> @WebContext(authMethod = "BASIC",
> transportGuarantee = "CONFIDENTIAL",
> secureWSDLAccess = true)
> @Stateless
> @Interceptors(ConstraintViolationInterceptor.class)
> @RolesAllowed({ "...", "..." })
> @SecurityDomain("...")
> public class KundeSOAP {...}
> {code}
> But when the client invokes the server, then the realm name is "EJBWebServiceEndpointServlet Realm".
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3251) @WebContext overrides realm in web.xml
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-3251?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-3251:
------------------------------------------
The issue still exists in WildFly 8.1.0.CR4
> @WebContext overrides realm in web.xml
> --------------------------------------
>
> Key: WFLY-3251
> URL: https://issues.jboss.org/browse/WFLY-3251
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.CR2
> Reporter: Juergen Zimmermann
> Assignee: Alessio Soldano
>
> In WEB-INF/web.xml I'm having this declaration (to be used for REST and SOAP):
> {code}
> <login-config>
> <auth-method>BASIC</auth-method>
> <realm-name>Shop</realm-name>
> </login-config>
> {code}
> Furthermore, I'm having a SOAP-based web service:
> {code}
> @WebService(name = "KundeSOAP",
> targetNamespace = "urn:shop:soap:kunde",
> serviceName = "KundeSOAPService")
> @SOAPBinding
> @WebContext(authMethod = "BASIC",
> transportGuarantee = "CONFIDENTIAL",
> secureWSDLAccess = true)
> @Stateless
> @Interceptors(ConstraintViolationInterceptor.class)
> @RolesAllowed({ "...", "..." })
> @SecurityDomain("...")
> public class KundeSOAP {...}
> {code}
> But when the client invokes the server, then the realm name is "EJBWebServiceEndpointServlet Realm".
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3017) OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3017?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3017:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1092206|https://bugzilla.redhat.com/show_bug.cgi?id=1092206] from ON_QA to VERIFIED
> OperationContextImpl.readResourceForUpdate assumes all resources represent persistent config
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-3017
> URL: https://issues.jboss.org/browse/WFLY-3017
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.1.0.CR1
>
>
> The readResourceForUpdate impl makes a few assumptions regarding the fact that a given Resource represents persistent config (i.e. Resource.isRuntime() == true):
> 1) It calls rejectUserDomainServerUpdates() which means an OSH running on a server could not call this.
> 2) It calls authorize(false, READ_WRITE_CONFIG) which means an OSH for an op available to the RBAC Operator role could not call this.
> Places this impacts include LogStoreProbeHandler and LogStoreTransactionDeleteHandler which should be calling readResourceForUpdate but aren't -- and can't because of this bug.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JBJCA-1179) Guard against Subject modification
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1179?page=com.atlassian.jira.plugin... ]
Ivo Studensky commented on JBJCA-1179:
--------------------------------------
[~simkam] If you @Ignore all the overloading test methods in {XA}DatasourceWithoutAllowMultipleUsersTestCase, then your entire testsuite will pass. At least it passed for me.
[~jesper.pedersen] I'd vote for re-opening this jira. I cannot attach my own build of ironjacamar-jdbc.jar for further testing if it is closed.
> Guard against Subject modification
> ----------------------------------
>
> Key: JBJCA-1179
> URL: https://issues.jboss.org/browse/JBJCA-1179
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Attachments: ironjacamar-jdbc.jar
>
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JBJCA-1179) Guard against Subject modification
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1179?page=com.atlassian.jira.plugin... ]
Ivo Studensky commented on JBJCA-1179:
--------------------------------------
[~simkam] It seems to be a bug of the test itself, more precisely its misconfiguration. You cannot call {{ds.getConnection()}} and {{ds.getConnection("dballo01", "dballo01");}} on the same datasource without enabled {{allow-multiple-users=true}}. That's the reason why 'allow-multiple-users' parameter exists. Otherwise, the connections are cached by Subject only and cannot distinguish between subject based and CRI based connection.
At my side only \{XA\}Datasource*Without*AllowMultipleUsersTestCase tests are failing due to 'Wrong credentials passed to getConnection!'.
> Guard against Subject modification
> ----------------------------------
>
> Key: JBJCA-1179
> URL: https://issues.jboss.org/browse/JBJCA-1179
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Attachments: ironjacamar-jdbc.jar
>
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1841) Discovery: reduce number of discovery requests to backend store
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1841:
---------------------------
Description:
The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
This is mainly done by
* Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
* Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
The _members file_ lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
The file could be located on a (shared) file system, S3, a DB table or a cloud store.
*This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
h5. The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
* Reducing the number of calls to the cloud store (latency!)
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
h5. References
See https://github.com/belaban/JGroups/blob/master/doc/design/CloudBasedDisco... for the design
was:
The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
This is mainly done by
* Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
* Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
The _members file_ lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
The file could be located on a (shared) file system, S3, a DB table or a cloud store.
*This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
h5. The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
* Reducing the number of calls to the cloud store (latency!)
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
> Discovery: reduce number of discovery requests to backend store
> ----------------------------------------------------------------
>
> Key: JGRP-1841
> URL: https://issues.jboss.org/browse/JGRP-1841
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
> This is mainly done by
> * Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
> * Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
> For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
> Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
> The _members file_ lists *all* members in a boostrap file in the following format:
> || Logical name || UUID || IP address:port || coord ||
> | A | 1 | 192.168.1.5:7800 | true |
> | B | 2 | 192.168.1.6:7800 | false |
> | C | 3 | 192.168.1.7:7800 | false |
> The file could be located on a (shared) file system, S3, a DB table or a cloud store.
> *This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
> On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
> Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
> When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
> Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
> Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
> h5. The goals of this protocol are:
> * Used when IP multicast is not available
> * Quick startup
> * Reducing the number of calls to the cloud store (latency!)
> ** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
> * Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> h5. Coordinator changes
> When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
> h5. New members (not listed) join
> This could be handled by either changing the bootstrap file manually or dynamically:
> * The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
> ** (This is done before sending a JOIN request to the coordinator)
> * Every member updates their local cache when receiving the INFO message
> * The coordinator, upon reception of an INFO message, updates the file
> ** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
> h5. References
> See https://github.com/belaban/JGroups/blob/master/doc/design/CloudBasedDisco... for the design
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl assumes RealmUser principal
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3124?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3124:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1082072|https://bugzilla.redhat.com/show_bug.cgi?id=1082072] from ON_QA to VERIFIED
> JXM PluggableMBeanServerImpl assumes RealmUser principal
> --------------------------------------------------------
>
> Key: WFLY-3124
> URL: https://issues.jboss.org/browse/WFLY-3124
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Fix For: 8.1.0.CR1
>
>
> JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception:
> {noformat}
> Caused by: java.util.NoSuchElementException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929)
> at java.util.HashMap$KeyIterator.next(HashMap.java:960)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871)
> at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month
[JBoss JIRA] (JGRP-1841) Discovery: reduce number of discovery requests to backend store
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1841:
---------------------------
Description:
The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
This is mainly done by
* Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
* Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
The _members file_ lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
The file could be located on a (shared) file system, S3, a DB table or a cloud store.
*This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
h5. The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
* Reducing the number of calls to the cloud store (latency!)
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
was:
A new protocol similar to {{FILE_PING}} (perhaps a subclass?) which lists *all* members in a boostrap file in the following format:
|| Logical name || UUID || IP address:port || coord ||
| A | 1 | 192.168.1.5:7800 | true |
| B | 2 | 192.168.1.6:7800 | false |
| C | 3 | 192.168.1.7:7800 | false |
The file could be located on a (shared) file system, S3, a DB table or a cloud store.
*This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{JDBC_PING}} etc.*
On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
The goals of this protocol are:
* Used when IP multicast is not available
* Quick startup
* Reducing the number of calls to the cloud store (latency!)
** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
* Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
h5. Coordinator changes
When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
h5. New members (not listed) join
This could be handled by either changing the bootstrap file manually or dynamically:
* The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
** (This is done before sending a JOIN request to the coordinator)
* Every member updates their local cache when receiving the INFO message
* The coordinator, upon reception of an INFO message, updates the file
** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
> Discovery: reduce number of discovery requests to backend store
> ----------------------------------------------------------------
>
> Key: JGRP-1841
> URL: https://issues.jboss.org/browse/JGRP-1841
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
> This is mainly done by
> * Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
> * Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
> For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
> Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
> The _members file_ lists *all* members in a boostrap file in the following format:
> || Logical name || UUID || IP address:port || coord ||
> | A | 1 | 192.168.1.5:7800 | true |
> | B | 2 | 192.168.1.6:7800 | false |
> | C | 3 | 192.168.1.7:7800 | false |
> The file could be located on a (shared) file system, S3, a DB table or a cloud store.
> *This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
> On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
> Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
> When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
> Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
> Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
> h5. The goals of this protocol are:
> * Used when IP multicast is not available
> * Quick startup
> * Reducing the number of calls to the cloud store (latency!)
> ** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
> * Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> h5. Coordinator changes
> When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
> h5. New members (not listed) join
> This could be handled by either changing the bootstrap file manually or dynamically:
> * The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
> ** (This is done before sending a JOIN request to the coordinator)
> * Every member updates their local cache when receiving the INFO message
> * The coordinator, upon reception of an INFO message, updates the file
> ** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 1 month