[keycloak-dev] Support concurrent startup by more cluster nodes

[Stian Thorgersen]

900 seconds is probably ok, but what happens if the node holding the lock
dies?

On 7 March 2016 at 11:03, Marek Posolda <mposolda at redhat.com> wrote:

> Send PR with added support for $subject .
> https://github.com/keycloak/keycloak/pull/2332 .
>
> Few details:
> - Added DBLockProvider, which handles acquire and release of DB lock.
> When lock is acquired, the cluster node2 needs to wait until node1
> release the lock
>
> - The lock is acquired at startup for the migrating model (both model
> specific and generic migration), importing realms and adding initial
> admin user. So this can be done always just by one node at a time.
>
> - The lock is implemented at DB level, so it works even if infinispan
> cluster is not correctly configured. For the JPA, I've added
> implementation, which is reusing liquibase DB locking with the bugfix,
> which prevented builtin liquibase lock to work correctly. I've added
> implementation for Mongo too.
>
> - Added DBLockTest, which simulates 20 threads racing for acquire lock
> concurrently. It's passing with all databases.
>
> - Default timeout for acquire lock is 900 seconds and the time for lock
> recheck is 2 seconds. So if node2 is not able to acquire lock within 900
> seconds, it fails to start. There is possibility to change in
> keycloak-server.json. Is 900 seconds too much? I was thinking about the
> case when there is some large realm file importing at startup.
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160307/c83f0ec5/attachment.html