[JBoss JIRA] (ELY-779) Iteration count transformation: BCrypt
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-779?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-779:
---------------------------------
One thing we need to talk about - again - is that BCrypt uses a "cost" parameter which is the log2 of the actual iteration count. I think that we probably would want to at least consider using a real iteration count algorithm parameter to represent the actual count, even though the values have an unusual domain of validity (‹2⁴, ..., 2³¹›, which can be verified by the simple expression {{Integer.bitCount(n) == 1}}).
One challenge of the cost parameter in the implementation is that to raise the cost to the next valid value, you have to add 2ⁿ - 2ⁿ⁻¹ iterations which is hard to fit in with the scheme. We'd probably have to convert to iterations/rounds internally anyway so we can calculate the difference and apply the additional rounds.
> Iteration count transformation: BCrypt
> --------------------------------------
>
> Key: ELY-779
> URL: https://issues.jboss.org/browse/ELY-779
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: David Lloyd
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-321) Add getCredentialNames() method to RealmIdentity
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-321?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-321.
-----------------------------
Resolution: Out of Date
> Add getCredentialNames() method to RealmIdentity
> ------------------------------------------------
>
> Key: ELY-321
> URL: https://issues.jboss.org/browse/ELY-321
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
>
> Add a {{getCredentialNames()}} method to {{RealmIdentity}}. The description would be something like this:
> bq. Get the names of the available credentials in this identity. The {@link #getCredentialSupport(String)} method should be used to determine the exact level of support for each credential. The realm may have access to credentials which are not named in this set.
> The method should return the set or an empty set (never {{null}}). Initial PR could just update realms to return the empty set, or just implement for the easy realms, with followup JIRAs/PRs for the remainder.
> This probably should not be a default operation, since it is something that realms generally should explicitly support.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-473) True credential forwarding support
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-473?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-473.
-----------------------------
Assignee: David Lloyd
Resolution: Done
> True credential forwarding support
> ----------------------------------
>
> Key: ELY-473
> URL: https://issues.jboss.org/browse/ELY-473
> Project: WildFly Elytron
> Issue Type: Enhancement
> Reporter: David Lloyd
> Assignee: David Lloyd
> Priority: Minor
> Fix For: 1.1.0.Beta16
>
>
> Now we are ready for true support for forwarding credentials.
> The credentials should be associated with the SecurityIdentity itself. A permission check is required to acquire them (maybe even both a code permission check *and* a user authorization check).
> We could support holding one credential per type+algorithm combination, or simply a list of credentials which can be queried.
> Authentication client API should be enhanced to search a security domain's current identity for a forwarding credential to use.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2135) OOM with Jgroups 3.6.11.
by Zoltan Farkas (JIRA)
Zoltan Farkas created JGRP-2135:
-----------------------------------
Summary: OOM with Jgroups 3.6.11.
Key: JGRP-2135
URL: https://issues.jboss.org/browse/JGRP-2135
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.11
Reporter: Zoltan Farkas
Assignee: Bela Ban
We are running our JVMs with : -XX:OnOutOfMemoryError="kill -9 %p"
we have been experiencing OOMs fairly often, and the OOMs happen at:
{code}
Object / Stack Frame |Name | Shallow Heap | Retained Heap |Context Class Loader |Is Daemon
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
java.lang.Thread @ 0x81bdf838 |Connection.Receiver [144.77.77.53:50363 - 144.77.77.53:50363],sis-cluster.service,prodpmwsv5-6461| 120 | 456 |sun.misc.Launcher$AppClassLoader @ 0x800175a8|false
|- at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:48) | | | | |
|- at org.jgroups.blocks.cs.TcpConnection$Receiver.run()V (TcpConnection.java:310)| | | | |
|- at java.lang.Thread.run()V (Thread.java:745) | | | | |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{code}
the Code where it happens is in TcpConnection.java:
{code}
while(canRun()) {
try {
int len=in.readInt();
if(buffer == null || buffer.length < len)
buffer=new byte[len];
in.readFully(buffer, 0, len);
updateLastAccessed();
server.receive(peer_addr, buffer, 0, len);
}
catch(OutOfMemoryError mem_ex) {
t=mem_ex;
break; // continue;
}
catch(IOException io_ex) {
t=io_ex;
break;
}
catch(Throwable e) {
}
}
{code}
when allocating: buffer=new byte[len];
it looks to me that some invalid large value is received and the process OOMs when allocating a huge byte array
Running JVMs without kill on OOM would make this issue "dissapear" in the sense that it is swallowed by:
{code}
catch(OutOfMemoryError mem_ex) {
t=mem_ex;
break; // continue;
}
{code}
Handling OutOfMemoryError is a strange implementation choice...
instead a size limit should be employed to protect from receiving invalid sizes...
My heap limit is 1GB and my heap dumps are 50Mb so the attempted allocation size is huge...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2033) CLI provides confusing error if an attribute does not exist
by Stuart Douglas (JIRA)
Stuart Douglas created WFCORE-2033:
--------------------------------------
Summary: CLI provides confusing error if an attribute does not exist
Key: WFCORE-2033
URL: https://issues.jboss.org/browse/WFCORE-2033
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Stuart Douglas
If a CLI operation contains an attribute that does not exist the resulting error message is not very informative:
[standalone@localhost:9990 /] :reload(adminonly=true)
Failed to handle ':reload(adminonly=true)': java.lang.IllegalArgumentException
The error message should inform the user that the attribute they specified was incorrect.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7651) Session invalidation not reflected when coming from another concurrent request
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7651?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-7651:
-----------------------------------------------
Description:
When a request is being processed, and another concurrent request invalidates the session, invalidation is not reflected in the first request, i.e.: calling HttpServletRequest#isRequestedSessionIdValid() returns true. But trying to get any request attribute shows that the request is effectively destroyed.
Related to WFLY-7568 and probably also to WFLY-6744
was:When a request is being processed, and another concurrent request invalidates the session, invalidation is not reflected in the first request, i.e.: calling HttpServletRequest#isRequestedSessionIdValid() returns true. But trying to get any request attribute shows that the request is effectively destroyed.
> Session invalidation not reflected when coming from another concurrent request
> ------------------------------------------------------------------------------
>
> Key: WFLY-7651
> URL: https://issues.jboss.org/browse/WFLY-7651
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
> Attachments: session-invalidation-1.0-SNAPSHOT.war, session-invalidation-src.zip
>
>
> When a request is being processed, and another concurrent request invalidates the session, invalidation is not reflected in the first request, i.e.: calling HttpServletRequest#isRequestedSessionIdValid() returns true. But trying to get any request attribute shows that the request is effectively destroyed.
> Related to WFLY-7568 and probably also to WFLY-6744
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7651) Session invalidation not reflected when coming from another concurrent request
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-7651:
--------------------------------------------------
Summary: Session invalidation not reflected when coming from another concurrent request
Key: WFLY-7651
URL: https://issues.jboss.org/browse/WFLY-7651
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Guillermo González de Agüero
Assignee: Stuart Douglas
Attachments: session-invalidation-1.0-SNAPSHOT.war, session-invalidation-src.zip
When a request is being processed, and another concurrent request invalidates the session, invalidation is not reflected in the first request, i.e.: calling HttpServletRequest#isRequestedSessionIdValid() returns true. But trying to get any request attribute shows that the request is effectively destroyed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7568) Sporadic UT000010: Session is invalid
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7568?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero closed WFLY-7568.
----------------------------------------------
Resolution: Rejected
Thinking about it a little more, it doesn't seem like a bug. Probably Mojarra should throw a ViewExpiredException, but that's not Undertow's domain. I'll investigate the HttpServletRequest#isRequestedSessionIdValid() behavior though.
> Sporadic UT000010: Session is invalid
> -------------------------------------
>
> Key: WFLY-7568
> URL: https://issues.jboss.org/browse/WFLY-7568
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Environment: WildFly 10.1 (patched from 10.0) in domain mode. One single node behing a ModCluster balancer running on another server group of the same WildFly domain.
> SO: RedHat Linux
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> I'm occasionally getting stacktraces of invalid sessions on our JSF application.
> Some details:
> - The whole page is role protected (url-pattern: /*)
> - Login and logout are programmatically done on a Servlet, using HttpServletRequest#login and HttpServletRequest#logout methods (form login).
> - Application is not marked <distributable />, and there's only one node.
> I have two stacktraces. The first one is from the user request:
> {quote}
> java.lang.IllegalStateException: UT000010: Session is invalid qx9ZygAt_gKYG__SAFEOI1ojrUXvN5lZ2wXl0c9O
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:471)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
> at com.sun.faces.context.SessionMap.put(SessionMap.java:127)
> at com.sun.faces.context.SessionMap.put(SessionMap.java:61)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.getResponseEncoding(FaceletViewHandlingStrategy.java:1310)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1198)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:405)
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:134)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at org.omnifaces.filter.FacesExceptionFilter.doFilter(FacesExceptionFilter.java:93)
> at org.omnifaces.filter.HttpFilter.doFilter(HttpFilter.java:108)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at xx.xxxxxxx.xxxxxxx.xxxxxxx.xxxxx.ServletFilter.doFilter(PermisosFilter.java:56)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:201)
> at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:178)
> 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.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:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
> at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
> 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 io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 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:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> It seems to pass the security checks (so I should assume the session is still valid?), but then it fails on the JSF part.
> After that, the error page is shown, but if fails again since it uses a view scoped bean:
> {quote}
> java.lang.IllegalStateException: UT000010: Session is invalid qx9ZygAt_gKYG__SAFEOI1ojrUXvN5lZ2wXl0c9O
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:471)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122)
> at com.sun.faces.context.SessionMap.get(SessionMap.java:118)
> at com.sun.faces.application.view.ViewScopeContextManager.getContextMap(ViewScopeContextManager.java:244)
> at com.sun.faces.application.view.ViewScopeContextManager.getContextMap(ViewScopeContextManager.java:228)
> at com.sun.faces.application.view.ViewScopeContextManager.getBean(ViewScopeContextManager.java:201)
> at com.sun.faces.application.view.ViewScopeContext.get(ViewScopeContext.java:108)
> at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:70)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> at xx.xxxxxxx.xxxxxxx.xxxxxxx.xxxxxxxxxxxxx.ViewScopedCDIBean$Proxy$_$$_WeldClientProxy.isActivado(Unknown Source)
> at xx.xxxxxxx.xxxxxxx.xxxxxxx.xxxxxxxxxxxxx.JSFPhaseCycleListener.afterPhase(SistemaToDo.java:37)
> at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107)
> at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:658)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:81)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:62)
> at io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:209)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:480)
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:413)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:319)
> 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 io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> 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:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {quote}
> This traces appear every two days or so. I don't have much insight on the user steps involved, but I can set an HttpSessionListener to check if sessions are really invalid.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months