[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka commented on WFLY-14284:
-----------------------------------------
I see. As I can see I think the documentation needs a bit more care related this. I would think that the all places which talks about `http-remoting` should be changed but I'm not sure. If you can create an issue and assign it to me it would be nice.
Regarding the remote outbound connection. What I know the outbound connection needs to be configured with some security configuration. You will need at least the `security-realm`. The protocol is not needed when you are fine with the default one (which will be the `remote+http`). I'm not sure about username.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14123) Add OSGI Headers for jboss-client.jar
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-14123?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-14123:
------------------------------------
Summary: Add OSGI Headers for jboss-client.jar (was: Add OSGI Headers for jboss-ciient.jar)
> Add OSGI Headers for jboss-client.jar
> -------------------------------------
>
> Key: WFLY-14123
> URL: https://issues.redhat.com/browse/WFLY-14123
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Darran Lofthouse
> Assignee: Moulali Shikalwadi
> Priority: Major
> Fix For: 23.0.0.Beta1
>
>
> Headers such as the following should be added:
> {code:java}
> Bundle-ManifestVersion: 2
> Bundle-SymbolicName: org.jboss.client
> Bundle-Version: 1.0
> Bundle-Name: Test
> ExtensionFragment-Host: org.openjdk.jmc.rjmxExport-
> Package: *
> Automatic-Module-Name: org.jboss.client {code}
> The reason for this change is so the jar can be copied to a Java Mission Control folder
> {{/path/to/jmc/dropins/ and these updates will correct the class loading enabling the remoting-jmx connection to be established.}}
>
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
[~ochaloup] I'd like to fix de documentation but in fact I don't know how is the right way to configure Wildfly without messages about deprecations.
At this time I just had changed the protocol and use the already documented workaround for authentication. On our instances we are still getting this messages.
The Developer Guide has only one referece to remote+http protocol and the remaining use always http-remoting. Have I provide a pull request change all of them without discern the context or you want to say only about the chapter that refer to remote outbound connection?
What would be the right way to use remote outbound without username, security-realm and protocol attributes?
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka edited comment on WFLY-14284 at 1/27/21 6:02 AM:
------------------------------------------------------------------
[~adrianots] True. My summary is that your issue routed us to two issues. The first is the trouble in http client (ie. WEJBHTTP-53) the second is the incorrect and insufficient documentation. Do you think you can create a new separate issue for the documentation (https://issues.redhat.com/browse/WFLY, component `Documentation`)?
For sure it will be more than welcome if you provide a PR to WFLY github repository that would fix the troubles you know about - the WFLY documentation is under https://github.com/wildfly/wildfly/tree/master/docs/src/main/asciidoc.
was (Author: ochaloup):
[~adrianots] True. My summary is that your issue routed us to two issues. The first is the trouble in http client (ie. WEJBHTTP-53) the second is the incorrect and insufficient documentation. Do you think you can create a new separate issue for the documentation?
For sure it will be more than welcome if you provide a PR to WFLY github repository that would fix the troubles you know about - the WFLY documentation is under https://github.com/wildfly/wildfly/tree/master/docs/src/main/asciidoc.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka edited comment on WFLY-14284 at 1/27/21 6:02 AM:
------------------------------------------------------------------
[~adrianots] True. My summary is that your issue routed us to two issues. The first is the trouble in http client (ie. WEJBHTTP-53) the second is the incorrect and insufficient documentation. Do you think you can create a new separate issue for the documentation?
For sure it will be more than welcome if you provide a PR to WFLY github repository that would fix the troubles you know about - the WFLY documentation is under https://github.com/wildfly/wildfly/tree/master/docs/src/main/asciidoc.
was (Author: ochaloup):
[~adrianots] I truly agree with you. My summary is that your issue routed us to two issues. The first is the trouble in http client (ie. WEJBHTTP-53) the second is the incorrect and insufficient documentation. Do you think you can create a new separate issue for the documentation?
For sure it will be more than welcome if you provide a PR to WFLY github repository that would fix the troubles you know about - the WFLY documentation is under https://github.com/wildfly/wildfly/tree/master/docs/src/main/asciidoc.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka commented on WFLY-14284:
-----------------------------------------
[~adrianots] I truly agree with you. My summary is that your issue routed us to two issues. The first is the trouble in http client (ie. WEJBHTTP-53) the second is the incorrect and insufficient documentation. Do you think you can create a new separate issue for the documentation?
For sure it will be more than welcome if you provide a PR to WFLY github repository that would fix the troubles you know about - the WFLY documentation is under https://github.com/wildfly/wildfly/tree/master/docs/src/main/asciidoc.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (ELY-2074) SSO from FORM authentication required a distributed session
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-2074?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELY-2074:
---------------------------------------
After some further discussions with [~pferraro] we have identified that it is not the case that the session needs to be distributable, the clustering testsuite actually contains tests that verify the SSO session is correctly replicated.
Paul has identified that when the session is not distributable the InMemorySessionManager is in use:
[https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...]
As I shut down the node the authentication was against this session manager notifies all session listeners that the session is being destroyed, this has the side effect of invalidating the SSO session.
If instead of shutting down the node I instead kill the node then failover is successful and the SSO session has not been invalidated so the user is not prompted to authenticate again.
> SSO from FORM authentication required a distributed session
> -----------------------------------------------------------
>
> Key: ELY-2074
> URL: https://issues.redhat.com/browse/ELY-2074
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Affects Versions: 1.14.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.14.2.CR1
>
>
> Presently SSO only works on failover if also have a distributed HTTP session.
> The SSO support is supposed to be operating independently of the session otherwise we should have just used the session to replicate the identity. I suspect that when we attempt to restore the identity we check if we have a session scope but as it does not exist we skip attempting the restoration, we should be open to restoration being possible without a session.
> Overall however it feels like this approach will require some clean up which may be needed for ELY-1626 - instead of the current approach which intercepts session access and converts to SSO we may be better making SSO a real scope or something similar so mechanisms can interact directly with it. The approach today where we wrap the scope access and intercept the calls means mechanisms can easily make invalid assumptions about scope availability such as in this case.
> The following TRACE logging shows a successful failover where a web application is marked as being distributed:
> {code:java}
> 2021-01-26 11:01:34,120 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
> 2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
> 2021-01-26 11:01:34,121 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2021-01-26 11:01:34,158 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@4b6842ff] for mechanism [FORM]
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate session 3t7EGcnmInMeUYH3-thjyQpTyOanRdoX3Dm-BcS6. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
> 2021-01-26 11:01:34,160 TRACE [org.wildfly.security] (default task-1) Principal assigning: [alice], pre-realm rewritten: [alice], realm name: [example-realm], post-realm rewritten: [alice], realm rewritten: [alice]
> 2021-01-26 11:01:34,165 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing principal alice.
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following attributes: [groups] => [user, Users]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorizing against the following runtime attributes: [Source-Address] => [127.0.0.1]
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Permission mapping: identity [alice] with roles [Users, user] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Authorization succeed
> 2021-01-26 11:01:34,166 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = alice authorizedIdentity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
> 2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: succeed
> 2021-01-26 11:01:34,167 TRACE [org.wildfly.security] (default task-1) Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=alice, securityDomain=org.wildfly.security.auth.server.SecurityDomain@61f54c5f, authorizationIdentity=EMPTY, realmInfo=RealmInfo{name='example-realm', securityRealm=org.wildfly.security.auth.realm.FileSystemSecurityRealm@78079856}, creationTime=2021-01-26T11:01:34.165503Z}
> 2021-01-26 11:01:34,168 TRACE [org.wildfly.security] (default task-1) Role mapping: principal [alice] -> decoded roles [Users, user] -> domain decoded roles [] -> realm mapped roles [Users, user] -> domain mapped roles [Users, user] {code}
>
> Where the web application is not distributed the following is logged instead:
> {code:java}
> 2021-01-26 11:26:14,189 INFO [org.infinispan.CLUSTER] (thread-10,ejb,nodea) ISPN100001: Node nodeb left the cluster
> 2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) Created ServletSecurityContextImpl enableJapi=true, integratedJaspi=true, applicationContext=default-host /simple-webapp
> 2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) No AuthConfigProvider for layer=HttpServlet, appContext=default-host /simple-webapp
> 2021-01-26 11:26:59,400 TRACE [org.wildfly.security.http.servlet] (default task-1) JASPIC Unavailable, using HTTP authentication.
> 2021-01-26 11:26:59,402 TRACE [org.wildfly.security] (default task-1) No CachedIdentity to restore.
> 2021-01-26 11:26:59,402 TRACE [org.wildfly.security] (default task-1) Created HttpServerAuthenticationMechanism [org.wildfly.security.auth.server.SecurityIdentityServerMechanismFactory$1@71dc2149] for mechanism [FORM]
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling SocketAddressCallback
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling MechanismInformationCallback type='HTTP' name='FORM' host-name='localhost' protocol='http'
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security.http.form] (default task-1) Trying to re-authenticate. There is no session attached to the following request. Request URI: [http://localhost:8080/simple-webapp/secured], Context path: [/simple-webapp]
> 2021-01-26 11:26:59,404 TRACE [org.wildfly.security] (default task-1) Handling CachedIdentityAuthorizeCallback: principal = null authorizedIdentity = null {code}
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14357) Sporadic ArrayIndexOutOfBoundsException on first few calls
by Peter Bilstein (Jira)
[ https://issues.redhat.com/browse/WFLY-14357?page=com.atlassian.jira.plugi... ]
Peter Bilstein commented on WFLY-14357:
---------------------------------------
Hi [~ron_sigal],
thanks alot for the quick fix! Really, that was fast!
Unfortunately it is not possible for me to test. We are using keycloak docker distribution in our tests and due to the fact that this only happens in our CI runs where we have already applied a workaround for the problem, I'm not able to verify.
Changing the List to CopyOnWriteArrayList sounds like a (the ;) ) valid solution to me.
Regards
Peter
> Sporadic ArrayIndexOutOfBoundsException on first few calls
> ----------------------------------------------------------
>
> Key: WFLY-14357
> URL: https://issues.redhat.com/browse/WFLY-14357
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 21.0.0.Final
> Reporter: Peter Bilstein
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: resteasy-jaxrs-3.13.2.Final.jar
>
>
> From time to time we get a sporadic failure when trying to login to keycloak 12.0.1 (on wildfly 21?!) via Oauth during test runs. This seems to happen on concurrent calls to the auth service:
>
> {noformat}
> [0m[0m09:40:59,607 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> [0m[31m09:41:03,906 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-3) Uncaught server error: java.lang.ArrayIndexOutOfBoundsException: Index 34 out of bounds for length 33
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.statistics.StatisticsControllerImpl.register(StatisticsControllerImpl.java:25)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.LocatorRegistry.processMethod(LocatorRegistry.java:66)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.LocatorRegistry.register(LocatorRegistry.java:49)
> at org.jboss.resteasy.resteasy-jaxrs(a)3.13.2.Final//org.jboss.resteasy.core.LocatorRegistry.<init>(LocatorRegistry.java:41)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:129)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:104)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:245)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:61)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at org.keycloak.keycloak-wildfly-extensions@12.0.1//org.keycloak.provider.wildfly.WildFlyRequestFilter.lambda$doFilter$0(WildFlyRequestFilter.java:41)
> at org.keycloak.keycloak-services@12.0.1//org.keycloak.services.filters.AbstractRequestFilter.filter(AbstractRequestFilter.java:43)
> at org.keycloak.keycloak-wildfly-extensions@12.0.1//org.keycloak.provider.wildfly.WildFlyRequestFilter.doFilter(WildFlyRequestFilter.java:39)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.2.2.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.core@2.2.2.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at org.jboss.xnio@3.8.2.Final//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.base/java.lang.Thread.run(Thread.java:834)
> [0m[31m09:41:03,906 ERROR [org.keycloak.services.error.KeycloakErrorHandler] (default task-1) Uncaught server error: java.lang.ArrayIndexOutOfBoundsException: Index 34 out of bounds for length 33
> at java.base/java.util.ArrayList.add(ArrayList.java:487)
> at java.base/java.util.ArrayList.add(ArrayList.java:499)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.statistics.StatisticsControllerImpl.register(StatisticsControllerImpl.java:25)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.LocatorRegistry.processMethod(LocatorRegistry.java:66)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.LocatorRegistry.register(LocatorRegistry.java:49)
> at org.jboss.resteasy.resteasy-jaxrs(a)3.13.2.Final//org.jboss.resteasy.core.LocatorRegistry.<init>(LocatorRegistry.java:41)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:129)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:104)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:245)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:61)
> at org.jboss.resteasy.resteasy-jaxrs@3.13.2.Final//org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at org.keycloak.keycloak-wildfly-extensions@12.0.1//org.keycloak.provider.wildfly.WildFlyRequestFilter.lambda$doFilter$0(WildFlyRequestFilter.java:41)
> at org.keycloak.keycloak-services@12.0.1//org.keycloak.services.filters.AbstractRequestFilter.filter(AbstractRequestFilter.java:43)
> at org.keycloak.keycloak-wildfly-extensions@12.0.1//org.keycloak.provider.wildfly.WildFlyRequestFilter.doFilter(WildFlyRequestFilter.java:39)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.2.2.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
> at io.undertow.core@2.2.2.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at org.wildfly.extension.undertow@21.0.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1530)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.2.2.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.2.2.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
> at io.undertow.core@2.2.2.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at org.jboss.xnio@3.8.2.Final//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> To me it looks like a concurrent access to StatisticsControllerImpl, which is not threadsafe itself. (see Stacktrace, where two threads access the StatisticsControllerImpl)
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months