[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Bruno Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Bruno Silva commented on WFLY-6731:
-----------------------------------
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
<distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 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:56)
> 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.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Bruno Silva (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Bruno Silva edited comment on WFLY-6731 at 8/1/16 7:53 AM:
-----------------------------------------------------------
{noformat}
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
<distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
{noformat}
was (Author: bcampolina):
<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
<transport lock-timeout="60000"/>
<replicated-cache name="default" mode="SYNC">
<transaction mode="BATCH"/>
</replicated-cache>
</cache-container>
<cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
<distributed-cache name="concurrent" mode="SYNC" l1-lifespan="0" owners="2">
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
<transport lock-timeout="60000"/>
<distributed-cache name="dist" mode="ASYNC" l1-lifespan="0" owners="2">
<locking isolation="REPEATABLE_READ"/>
<transaction mode="BATCH"/>
<file-store/>
</distributed-cache>
</cache-container>
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
<transport lock-timeout="60000"/>
<local-cache name="local-query">
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</local-cache>
<invalidation-cache name="entity" mode="SYNC">
<transaction mode="NON_XA"/>
<eviction strategy="LRU" max-entries="10000"/>
<expiration max-idle="100000"/>
</invalidation-cache>
<replicated-cache name="timestamps" mode="ASYNC"/>
</cache-container>
</subsystem>
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 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:56)
> 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.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6731 at 8/1/16 6:20 AM:
------------------------------------------------------------
[~bcampolina] Can you attach the infinispan configuration being used for your web sessions? The assumption being made by the code is that, since your cache is transactional, a plain HashMap can be used to stored sessions (as opposed to a ConcurrentHashMap), since session attribute iteration is always performed under lock.
was (Author: pferraro):
[~bcampolina] Can you attach the infinispan configuration being used for your web sessions? The assumption being made by the code is that your cache is transactional, thus a plain HashMap is used to stored sessions (as opposed to a ConcurrentHashMap), since session attribute iteration is always performed under lock.
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 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:56)
> 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.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6731:
------------------------------------
[~bcampolina] Can you attach the infinispan configuration being used for your web sessions? The assumption being made by the code is that your cache is transactional, thus a plain HashMap is used to stored sessions (as opposed to a ConcurrentHashMap), since session attribute iteration is always performed under lock.
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 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:56)
> 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.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1680:
----------------------------------------------
This is caused by WFCORE-1627. The cursor value is now used to extract the piece of line to complete. Some completers (such as EchoDMR one) provides 0 for the cursor value although buffer.length should be passed. I suspect that some other completers are affected. I will have to check the various calls to completers.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (DROOLS-1150) Problems found by FindBugs in drools-core
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1150?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1150:
-------------------------------------
Infinite recursions and other minor issues fixed by this commit https://github.com/droolsjbpm/drools/commit/a493b58a889cb71258d664dac0112...
I'm leaving this ticket open since there are other FindBugs reports that deserves to be investigated.
> Problems found by FindBugs in drools-core
> -----------------------------------------
>
> Key: DROOLS-1150
> URL: https://issues.jboss.org/browse/DROOLS-1150
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
> Attachments: findBugsDroolsCore.ods, FindBugsResult_4_29_16-drools-core.html
>
>
> I ran FindBugs analysis on drools-core module on master. There is 880 warnings in the report. So a pretty decent number. I picked some for start. See attachments. Also we should focus on concurrency warnings. You can find them in the report under "Multithreaded correctness Warnings" section.
> For better description of the warnings, you can install FindBugs-IDEA plugin and run the analysis in IDE. Each warning has some short description, sometimes with a link pointing to an article or more detailed info about the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1130:
-------------------------------------
Reproduced with the following test case
{code}
@Test(timeout=10000)
public void testCascadingTimedRule() throws Exception {
String drl =
"package org.simple \n" +
"import " + AtomicInteger.class.getCanonicalName() + "\n" +
"rule R1 \n" +
" timer (int:30s) " +
"when \n" +
" $i : AtomicInteger(get() == 1)" +
"then \n" +
" modify($i) { set(2) }; \n" +
"end \n" +
"rule R2 \n" +
"when \n" +
" $i : AtomicInteger(get() == 2)" +
"then \n" +
" modify($i) { set(3) }; \n" +
"end \n";
KieSessionConfiguration conf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
conf.setOption( ClockTypeOption.get( "pseudo" ) );
conf.setOption( TimedRuleExectionOption.YES );
KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
.build()
.newKieSession( conf, null );
PseudoClockScheduler timeService = ( PseudoClockScheduler ) ksession.<SessionClock>getSessionClock();
timeService.advanceTime( new Date().getTime(), TimeUnit.MILLISECONDS );
AtomicInteger i = new AtomicInteger( 1 );
ksession.insert( i );
ksession.fireAllRules();
timeService.advanceTime( 35, TimeUnit.SECONDS );
assertEquals(3, i.get());
}
{code}
> Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1130
> URL: https://issues.jboss.org/browse/DROOLS-1130
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: timer-rule-bug.zip
>
>
> I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of:
> http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht...
> _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_
> Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase.
> *DRL:*
> {code}
> import java.util.logging.Logger
> import bug.timedrules.Table
> rule "table with 1 player"
> timer( int: 3s)
> no-loop true
> when
> $table : Table( getCounter() == 1)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 1");
> modify($table){
> setCounter(2)
> }
> end
> rule "Table upgrade to 2 player"
> no-loop true
> when
> $table : Table( getCounter() == 2)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 2");
> modify($table){
> setCounter(3)
> }
> end
> {code}
> *java code:*
> {code}
> @Test
> public void executeNewRuleAfterTimedRuleExecution() throws Exception {
> KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();
> ksconf.setOption(TimedRuleExectionOption.YES);
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL);
> if (kbuilder.hasErrors()) {
> throw new IllegalStateException(kbuilder.getErrors().toString());
> }
> kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null);
> Table table = new Table(1234, 1);
> statefulKnowledgeSession.insert(table);
> statefulKnowledgeSession.fireAllRules();
> Thread.sleep(TimeUnit.SECONDS.toMillis(5));
> statefulKnowledgeSession.dispose();
> Assert.assertThat(table.getCounter(), CoreMatchers.is(3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6808.
------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
Fixed by WFLY-6878.
> DistributableSession validate method throw misleading exception message
> -----------------------------------------------------------------------
>
> Key: WFLY-6808
> URL: https://issues.jboss.org/browse/WFLY-6808
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final, 11.0.0.Alpha1
>
>
> In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
> {code}
> public class DistributableSession implements io.undertow.server.session.Session {
> private static void validate(Session<LocalSessionContext> session) {
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
> }
> }
> }
> {code}
> The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
> I would recommend we do instead:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
> }
> {code}
> or even better:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
> }
> {code}
> but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-4186) Improve Infinispan module compatibility with older releases
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4186?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-4186.
------------------------------
Resolution: Out of Date
> Improve Infinispan module compatibility with older releases
> -----------------------------------------------------------
>
> Key: WFLY-4186
> URL: https://issues.jboss.org/browse/WFLY-4186
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
> I suggest we either:
> 1. Export org.infinispan.commons from the org.infinispan module
> 2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months