[JBoss JIRA] (WFLY-6744) Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6744?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6744:
------------------------------------
I opened UNDERTOW-913 yesterday (see linked) to ensure correct behavior for HttpServletRequest.getSession(...).
> Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6744
> URL: https://issues.jboss.org/browse/WFLY-6744
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.CR1
> Environment: Create a cluster with two nodes using standalone-ha.xml (default configuration), create an application with <distributable/> in the web.xml and it must have around 300 requests per seconds and I'm using SSO.
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> I reproduced the bug on Wildfly master (https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/artifact/...) . The problem is intermittent, sometimes it works but others not.
> {noformat}
> 2016-06-17 11:37:32,366 ERROR [io.undertow.servlet.request] (default task-3) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: javax.faces.FacesException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:122)
> at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:346)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:257)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> Caused by: java.lang.IllegalStateException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:56)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttributeNames(DistributableSession.java:134)
> at io.undertow.servlet.spec.HttpSessionImpl.getFilteredAttributeNames(HttpSessionImpl.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:135)
> at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:405)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:116)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6744) Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-6744?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-6744:
----------------------------------------------------
[~pferraro] Yes, but UNDERTOW-909 made HttpServletRequest.getSession(false) return an invalid session instead of null. There's still the possibility of a race condition, but seing the code, I don't think it was the cause of this issue. UNDERTOW-909 should fix this issue.
> Problem logout in cluster, not destroyed session (javax.faces.FacesException: UT000010: Session not found)
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6744
> URL: https://issues.jboss.org/browse/WFLY-6744
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.CR1
> Environment: Create a cluster with two nodes using standalone-ha.xml (default configuration), create an application with <distributable/> in the web.xml and it must have around 300 requests per seconds and I'm using SSO.
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> I reproduced the bug on Wildfly master (https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/artifact/...) . The problem is intermittent, sometimes it works but others not.
> {noformat}
> 2016-06-17 11:37:32,366 ERROR [io.undertow.servlet.request] (default task-3) UT015005: Error invoking method requestDestroyed on listener class com.sun.faces.config.ConfigureListener: javax.faces.FacesException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:122)
> at com.sun.faces.config.ConfigureListener.requestDestroyed(ConfigureListener.java:346)
> at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:257)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:328)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> 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)
> Caused by: java.lang.IllegalStateException: UT000010: Session not found 216sQVCJxKl2ALOykRmdC25xox30nESzAxB-znFS
> at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:56)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttributeNames(DistributableSession.java:134)
> at io.undertow.servlet.spec.HttpSessionImpl.getFilteredAttributeNames(HttpSessionImpl.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.getAttributeNames(HttpSessionImpl.java:135)
> at com.sun.faces.application.WebappLifecycleListener.syncSessionScopedBeans(WebappLifecycleListener.java:405)
> at com.sun.faces.application.WebappLifecycleListener.requestDestroyed(WebappLifecycleListener.java:116)
> ... 11 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7658) Undertow allows invalid URL patterns for Servlets
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7658?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-7658:
----------------------------------------------------
What about logging a warning when non portable URL patterns are used? Or providing an option to enable/disable a "strict" mode?
> Undertow allows invalid URL patterns for Servlets
> -------------------------------------------------
>
> Key: WFLY-7658
> URL: https://issues.jboss.org/browse/WFLY-7658
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Point 12.1 says:
> {quote}
> The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted:
> {quote}
> Given this, the string used to compare match will always start with "/".
> Point 12.2 of the Servlet 3.1 spec states the following conditions for the URL patterns of a Servlet:
> {quote}
> * A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
> * A string beginning with a ‘*.’ prefix is used as an extension mapping.
> * The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<context-root>/. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
> * A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
> * *All other strings are used for exact matches only.*
> {quote}
> If only exact matches are allowed, then an url pattern like "users" is unmatchable and thus invalid.
> However, Undertow is treating the url the same way as if it was prefixed with "/". While the spec doesn't mandate to cancel deployment in case of invalid url pattern (at least I haven't found it), at least a warning to the user saying the deployment has unmatchable url patterns would be appreciated.
> A Servlet with this path fails to deploy on Tomcat and Glassfish/Payara. Curiously, it works on Jetty.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK
by Josef Cacek (JIRA)
Josef Cacek created WFCORE-2046:
-----------------------------------
Summary: KeyManager synchronization issue when using IBM JDK
Key: WFCORE-2046
URL: https://issues.jboss.org/browse/WFCORE-2046
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Security
Reporter: Josef Cacek
Assignee: Brian Stansberry
Priority: Blocker
We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords.
As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines.
Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}).
The workflow:
# user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}}
# the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}}
# the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore.
*Possible workaround*
We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7682) PropertiesSecurityRealm error handling
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7682?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7682:
-----------------------------
Summary: PropertiesSecurityRealm error handling (was: PropertiesSecurityRealm does not catch DecodeException)
> PropertiesSecurityRealm error handling
> --------------------------------------
>
> Key: WFLY-7682
> URL: https://issues.jboss.org/browse/WFLY-7682
> Project: WildFly
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception is not enclosed into Realm exception when problem with properties file occure:
> {code:java}
> org.wildfly.security.util.DecodeException: ELY03007: Invalid hex character
> org.wildfly.security.util.NumericIterator$5.calc(NumericIterator.java:1074)
> org.wildfly.security.util.NumericIterator$5.hasNext(NumericIterator.java:1090)
> org.wildfly.security.util.ByteIterator.drainTo(ByteIterator.java:1153)
> org.wildfly.security.util.ByteIterator.drain(ByteIterator.java:1165)
> org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$1.verifyEvidence(LegacyPropertiesSecurityRealm.java:171)
> org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1680)
> org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:655)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-795) PropertiesSecurityRealm does not catch DecodeException
by Jan Kalina (JIRA)
Jan Kalina created ELY-795:
------------------------------
Summary: PropertiesSecurityRealm does not catch DecodeException
Key: ELY-795
URL: https://issues.jboss.org/browse/ELY-795
Project: WildFly Elytron
Issue Type: Bug
Reporter: Jan Kalina
Assignee: Jan Kalina
Following exception is not enclosed into Realm exception when problem with properties file occure:
{code:java}
org.wildfly.security.util.DecodeException: ELY03007: Invalid hex character
org.wildfly.security.util.NumericIterator$5.calc(NumericIterator.java:1074)
org.wildfly.security.util.NumericIterator$5.hasNext(NumericIterator.java:1090)
org.wildfly.security.util.ByteIterator.drainTo(ByteIterator.java:1153)
org.wildfly.security.util.ByteIterator.drain(ByteIterator.java:1165)
org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$1.verifyEvidence(LegacyPropertiesSecurityRealm.java:171)
org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1680)
org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:655)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7682) PropertiesSecurityRealm does not catch DecodeException
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7682?page=com.atlassian.jira.plugin.... ]
Jan Kalina moved ELY-795 to WFLY-7682:
--------------------------------------
Project: WildFly (was: WildFly Elytron)
Key: WFLY-7682 (was: ELY-795)
> PropertiesSecurityRealm does not catch DecodeException
> ------------------------------------------------------
>
> Key: WFLY-7682
> URL: https://issues.jboss.org/browse/WFLY-7682
> Project: WildFly
> Issue Type: Bug
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception is not enclosed into Realm exception when problem with properties file occure:
> {code:java}
> org.wildfly.security.util.DecodeException: ELY03007: Invalid hex character
> org.wildfly.security.util.NumericIterator$5.calc(NumericIterator.java:1074)
> org.wildfly.security.util.NumericIterator$5.hasNext(NumericIterator.java:1090)
> org.wildfly.security.util.ByteIterator.drainTo(ByteIterator.java:1153)
> org.wildfly.security.util.ByteIterator.drain(ByteIterator.java:1165)
> org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$1.verifyEvidence(LegacyPropertiesSecurityRealm.java:171)
> org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1680)
> org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:655)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (DROOLS-1364) InMemorySessionFactory has apparent memory leak
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1364?page=com.atlassian.jira.plugi... ]
Maciej Swiderski closed DROOLS-1364.
------------------------------------
Resolution: Won't Fix
> InMemorySessionFactory has apparent memory leak
> -----------------------------------------------
>
> Key: DROOLS-1364
> URL: https://issues.jboss.org/browse/DROOLS-1364
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final
> Reporter: Eli Israel
> Assignee: Maciej Swiderski
>
> I'm running drools with a runtime manager creating using PerRequest strategy and SessionCache turned on. (I process a LOT of requests but I want each one to be isolated)
> The SessionCache properly gets rid of sessions that have hung around too long, which is great.
> But the InMemorySessionFactory keeps a copy of every session it ever created, which -- it seems to me -- impedes garbage collection of unneeded, old sessions.
> It's possible I'm just reading this wrong, but examinations of running code using VisualVM show a LOT of RightTuple objects hanging around, attached to sessions and their GC root appears to be the InMemorySessionFactory.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months