Hi Senthalan,
What I understood by reading your description on the behavior of the
*context.currentSubject *method is that it always returns the subject of
the *last-completed-subject-identifier-step* rather than the subject of the
current subject identifier step. If my understanding is correct,
Hi Damith,
According to this architecture, the passive node will only fetch event
states and filter events only once it is active. This model might exhaust
the queue 2 very soon depending on the rate of events. What if we could add
another async task to check the state and filter events even if
Hi Johann,
On Wed, Jun 27, 2018 at 8:52 AM Johann Nallathamby wrote:
> Hi IAM Team,
>
> I think the following limitation in the WSO2 IS is causing some major
> usability issues.
>
> We have following views mainly where we display claims for a user:
> 1. Admin user profile view in management
@Anoukh,
We can configure a LB in front to handle failover. Actually that is the
correct solution rather than publishing to both. But I think we need to
figure out how to handle incoming databridge traffic as it cannot be load
balanced. Yes we can utilize client side load balancing and directly
Hi Damith,
Just a few clarifications on the new architecture.
I'm assuming that "queue1" and "queue2" are actually per Source? Which
means if we have 3 sources, we'll have 3 queues in active node and 3 queues
in passive node? Does that mean there will be 3 threads working in async?
Also, the main
Hi all,
We are in the process of refactor/improve the existing HA architecture due
to various concerns found.
Below is the high level design came up with. We will provide more in-depth
details as the implementation carries on.
As per above at a given point of time there will only be a one
