8:07 p.m.
I think 2 is the only realistic option since it supports distant remote clients. It's
also similar to what we had before. Async topology changes shouldn't be an issue IMO.
The server endpoint always has the option to redirect to the right location. As long as we
have the requirement that the server endpoints be a jgroups cluster, then we can reuse the
jgroups view IDs which have already formed a consensus.
Another interesting aspect is stateless load balancing policy and stateful session
affinity. Since time is short my thoughts are start basic: round robin + sticky failover.
Sent from my iPad
On Oct 18, 2011, at 9:31 AM, Jaikiran Pai <jpai(a)redhat.com> wrote:
From someone who has very limited knowledge of clustering internals -
the only "advantage" (for us) in going with #1 would be the ability to
setup easy connectivity? From what I understand, #2 would allow more
flexibility to the users (and a bit of complexity for us in managing the
connections and authentication) on setting up the cluster for the
invocations. Am I right?
-Jaikiran
On Tuesday 11 October 2011 09:29 PM, David M. Lloyd wrote:
> There are at least two basic paths we can follow for clustered
> invocation based on the current architecture. The right choice is going
> to depend primarily upon the expected use cases, which I am not in a
> position to properly judge.
>
> Option 1: Clustered Invocation Transport
> ----------------------------------------
>
> In this option, we introduce a new "LAN" transport type for invocation
> on the cluster. The transport would use direct TCP connections or UDP
> messages (or both, depending on request size) to convey the invocation.
> The characteristics of this option are as follows:
>
> - Security: reliance on physical network security only (no TLS or
> authentication)
> - Latency is very low, even to new nodes
> - Topology changes can be conveyed as separate asynchronous messages
> - Invocations from external networks would happen through a proxy node,
> with Remoting being bridged to the LAN, to perform security functions
>
> Option 2: Load-balanced Remoting Connections
> --------------------------------------------
>
> In this option, we rely on the client to establish one or more Remoting
> connection(s) to one or more of the nodes of the cluster. Logic in the
> client will be used to determine what connection(s) to use for what
> clusters. We have the option of automatically connecting as topology
> changes or requiring the user to set up the connections in advance.
> Note that automatic connection cannot work in the case of
> user-interactive authentication. Characteristics:
>
> - Security: full authentication and TLS supported
> - Latency is low once the connection is established, however there is
> some overhead involved in authentication and security negotiation
> - Topology changes should be asynchronous notifications
> - Each connection has to be separately authenticated
> - Automatically establishing connections is not presently supported, so
> we'd need a bit of infrastructure for that. Deal with user-interactive
> authentication. Deal with connection lifecycle management. Deal with
> configuration. This will be a point of fragility
>
> Summary
> -------
>
> For both options, we have to determine an appropriate load-balancing
> strategy. The choice of direction will affect how our clustering and
> transaction interceptors function. We also have to suss out the logic
> around dealing with conflicting or wrongly-ordered topology updates;
> hopefully our existing policies will continue to apply.
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev