What I'm currently thinking is, that all backchannel logout requests can
be sent asynchronously, but the caller will wait for them until all the
responses are received.
Like if there are 4 clientSessions here:
, the "backchannelLogoutClientSession" will be triggered in 4 separate
threads, but then will wait until all of them are finished (Thread.join
or Future.get or something like that). In that case, Keycloak will be
still aware of all the logout requests success and failures. Currently
Keycloak is aware, but sending logout requests is sequential (request2
send after response1 is received) and that's far from optimal solution IMO.
Btv. I've just checked that when some logout request fails, we just log
. I guess we should also report it to LOGOUT Event to see which requests
were successful and which failed. That's another issue though, but is
On 11/02/16 20:41, Marko Strukelj wrote:
There is one neat side-effect of current implementation in that it
immediately apparent when backchannel events don't work due to
misconfiguration or firewall issues.
If the proposed optimisation is implemented I think we should add some
logging on the server that will make it very obvious when backchannel
On Thu, Feb 11, 2016 at 5:57 PM, Marek Posolda <mposolda(a)redhat.com> wrote:
> Few things, which we can possibly do:
> - Currently when application initiates logout through
> servletRequest.logout , it sends request to Keycloak logout endpoint.
> This endpoint then sends backchannel request to all logged clients with
> registered admin URL. I think we can improve here and not send request
> to the original application, which initiated logout.
> For example: When product-portal application initiates logout through
> servletRequest.logout, the adapter itself should be already able to do
> all logout actions on it's side (invalidate httpSession etc) and there
> is no need to send another request from keycloak to product-portal to
> logout same httpSession.
> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
> could be send in parallel. Currently they are send sequentially, which
> is not very optimal.
> keycloak-dev mailing list