[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Cheng Fang edited comment on WFLY-12031 at 4/30/19 12:54 PM:
-------------------------------------------------------------
When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used. So when removing it, we should also use the file name part of the path {{filePath}}.
I think changing the remove line to the following should work (around line 272):
{code:java}
openFilePaths.remove(filePath.getFileName().toString());
{code}
/cc [~flavia.rainone]
was (Author: cfang):
When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used. So when removing it, we should also use the file name part of the path {{filePath}}.
I think changing the remove line to the following should work:
{code:java}
openFilePaths.remove(filePath.getFileName().toString());
{code}
/cc [~flavia.rainone]
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Window 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Cheng Fang commented on WFLY-12031:
-----------------------------------
When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used. So when removing it, we should also use the file name part of the path {{filePath}}.
I think changing the remove line to the following should work:
{code:java}
openFilePaths.remove(filePath.getFileName().toString());
{code}
/cc [~flavia.rainone]
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Window 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes commented on JBJCA-1389:
--------------------------------------
The root cause seems to be that, unlike other code paths, there is no {{checkStatus()}} call prior to the execution of {{mc.getRealConnection()}} in {{getWrappedObject()}}.
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1389:
---------------------------------
Description:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
The NPE obscures the usage issue.
was:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
> The NPE obscures the usage issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1389:
---------------------------------
Description:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
The NPE obscures the usage issue.
was:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
The NPE obscures the usage issue.
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
> The NPE obscures the usage issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ]
Stephen Fikes updated JBJCA-1389:
---------------------------------
Description:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
was:
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException }} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
> NullPointerException raised when calling isWrapperFor(...) on a closed connection
> ---------------------------------------------------------------------------------
>
> Key: JBJCA-1389
> URL: https://issues.jboss.org/browse/JBJCA-1389
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.4.9
> Reporter: Stephen Fikes
> Priority: Major
>
> When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..."
> {code}
> ... java.lang.NullPointerException
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
> at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
> at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection
by Stephen Fikes (Jira)
Stephen Fikes created JBJCA-1389:
------------------------------------
Summary: NullPointerException raised when calling isWrapperFor(...) on a closed connection
Key: JBJCA-1389
URL: https://issues.jboss.org/browse/JBJCA-1389
Project: IronJacamar
Issue Type: Bug
Components: JDBC
Affects Versions: 1.4.9
Reporter: Stephen Fikes
When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException }} is raised. The exception should be "Connection is not associated with a managed connection: ..."
{code}
... java.lang.NullPointerException
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914)
at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64)
at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
I have created a proposed fix for the NullPointerException above. The draft is in the following branches:
https://github.com/tadamski/jboss-classfilewriter/tree/WFLY-11566
https://github.com/tadamski/core/tree/WFLY-11566
I'm still having some errors:
{code}
CDIValidationCoreTest.testInputsInvalid
CDIValidationCoreTest.testInputsInvalidNoExecutableValidation
CDIValidationCoreTest.testInputsInvalidNoParameters
{code}
The thing is that I see the same errors on current head without the fix applied.
[~mkopecky][~ron_sigal] Could you please double check that?
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years