I was discussing with a customer few days ago regarding how to deploy OpenAM optimally on Amazon Web Services. One topic which we discussed in-depth was how does OpenAM session work and why do OpenAM nodes need to be aware of one another.
ForgeRock documentation has a lot of information regarding how the Core Token Service (CTS) works and how performance is optimised when Reduced Crosstalk is enabled.
However, the documentation did not mention much about any activity besides sessions validation via cross-talk.
Our discussion that day was : "What is the other usage(s) of crosstalk? Can we remove crosstalk totally as we scale up/down frequently in AWS environment? If not, what happens when an OpenAM node is removed from site? Will crosstalk becomes the performance bottleneck in "non-locatable" OpenAM situation? "
Luckily, as what Peter has mentioned in his blog, Cluster State Service is here to help.
As we already know, under normal circumstances OpenAM uses crosstalk when requests gets misrouted, and this is something that does not change once session failover is enabled. Although the sessions are stored in OpenDJ, OpenAM will remain to send crosstalk requests to the other instances (in essence, this behavior is what the reduced crosstalk mode attempts to change).
In case of session failover it doesn’t really help if AM waits on crosstalk response from a node which may be actually unavailable. In order to prevent this scenario, there is a component that gets automatically enabled once session failover has been enabled: the ClusterStateService (or CSS as I’d like to call it). The ClusterStateService essentially tries to monitor the servers within the current site (and since 12 it also monitors remote site URLs), so that if there is a need to do a crosstalk, OpenAM first checks with ClusterStateService whether the given node is available, before sending any kind of crosstalk request.
PS: Peter has started using diagrams in his blog! Keep it up! :)