[JBoss JIRA] (WFLY-6929) It is not possible to set jboss.modules.system.pkgs per server in domain mode
by Bogdan Ilchyshyn (JIRA)
Bogdan Ilchyshyn created WFLY-6929:
--------------------------------------
Summary: It is not possible to set jboss.modules.system.pkgs per server in domain mode
Key: WFLY-6929
URL: https://issues.jboss.org/browse/WFLY-6929
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: Bogdan Ilchyshyn
Assignee: Jason Greene
Priority: Minor
It is not possible to set {{jboss.modules.system.pkgs}} property per server / server group in domain configuration. Even when the following configuration is added to {{host.xml}}:
{code:xml}
<server name="server-one" group="main-server-group">
<jvm name="default">
<jvm-options>
<option value="-Djboss.modules.system.pkgs=my.package"/>
...
{code}
It is overridden by configuration in {{domain.conf}}:
{noformat}
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
{noformat}
This is an issue for configuring third-party java agents per-server. A problem described in WFLY-895 adds to this. One should either add a whole bunch of things to _all_ jvms in domain in order to make agent work, or remove config from {{domain.conf}} to avoid overrides.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ELY-618) Dead code in DEREncoder
by Ondrej Lukas (JIRA)
Ondrej Lukas created ELY-618:
--------------------------------
Summary: Dead code in DEREncoder
Key: ELY-618
URL: https://issues.jboss.org/browse/ELY-618
Project: WildFly Elytron
Issue Type: Bug
Affects Versions: 1.1.0.Beta7
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
There is an unintentional dead code in writeTag method of org.wildfly.security.asn1.DEREncoder. Variable {{tagNumber}} can be assigned to 31 as its maximal value from {{int tagNumber = tag & TAG_NUMBER_MASK;}} (because {{TAG_NUMBER_MASK = 0x1f}}) on line 576 [1] which means that condition {{if (tagNumber < 128)}} on line 582 is always true. It causes that else branch is never executed.
[1] https://github.com/wildfly-security/wildfly-elytron/blob/4453ea40a7a617b6...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[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:
------------------------------------
This looks more like a bug in JSF. http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html#g... is required to throw an ISE if the session is not valid, yet the com.sun.faces.application.WebappLifecycleListener.requestDestroyed(...) event does not handle this.
> 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
(v6.4.11#64026)
9 years, 8 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:
------------------------------------
Am I to assume that your web application uses the default web cache (i.e. dist)? or have you overridden this via jboss-web.xml?
> 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, 8 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/8/16 3:57 PM:
------------------------------------------------------------
[~bcampolina] Am I to assume that your web application uses the default web cache (i.e. dist)? or have you overridden this via jboss-web.xml?
was (Author: pferraro):
Am I to assume that your web application uses the default web cache (i.e. dist)? or have you overridden this via jboss-web.xml?
> 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, 8 months
[JBoss JIRA] (WFLY-6926) TimeoutException: Replication timeout when handling request with DIST cache
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6926?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6926:
------------------------------------
[~mvinkler] Can you try to reproduce this issue against the latest from the Infinispan 8.2.x branch?
> TimeoutException: Replication timeout when handling request with DIST cache
> ---------------------------------------------------------------------------
>
> Key: WFLY-6926
> URL: https://issues.jboss.org/browse/WFLY-6926
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.CR1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Seen in http-session scenarios with *DIST* cache only. REPL cache scenarios seem not to be affected.
> TimeoutExceptions occur right away after sending first request and definitely result in client getting 500:
> {code}
> [JBossINF] [0m[31m04:31:39,033 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.staggeredProcessNext(CommandAwareRpcDispatcher.java:375)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$processCallsStaggered$3(CommandAwareRpcDispatcher.java:357)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Client:
> {code}
> 2016/08/08 04:31:39:068 EDT [WARN ][Runner - 4] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: Internal Server Error>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: Internal Server Error
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:163)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> I was able to reproduce it even with a very small load of 30 sessions.
> Server link (run with 30 sessions):
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> Client link (run with 30 sessions):
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> This issue occurs under different conditions than JBEAP-3779 (which is similar), that's why I opened new issue.
> Number of occurrences of TimeoutExceptions is very high. The server logs are full of them.
> This issue makes clustering with *DIST* cache unusable, thus giving blocker priority.
> Also, there is a issue with shutting down the servers in the end of the test, I don't know if it can be related, but I am hitting it constantly in the http-session DIST scenarios.
> The server shutdown usually gets stuck on this command:
> {code}
> [JBossINF] [0m[0m04:38:51,694 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web
> {code}
> *EDIT:*
> Also ejb-remote tests with *DIST* cache are affected (even if only 20 sessions are created).
> Server log for ejb-remote run:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> Client log for ejb-remote run:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> *EDIT #2:*
> Can be very easily reproduced locally. Just start a cluster of at least 3 servers with clusterbench deployed. Then do few requests to various nodes until you get 500 as a response. Also notice, when shutting down a node, which logged TimeoutException before, the node won't stop and get stuck during the shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6928) Upgrade Infinispan to 8.2.4.Final
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6928:
----------------------------------
Summary: Upgrade Infinispan to 8.2.4.Final
Key: WFLY-6928
URL: https://issues.jboss.org/browse/WFLY-6928
Project: WildFly
Issue Type: Component Upgrade
Components: Clustering
Affects Versions: 10.1.0.CR1
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Priority: Blocker
Fix For: 10.1.0.Final
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6926) TimeoutException: Replication timeout when handling request with DIST cache
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6926?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6926:
------------------------------------
This is likely due to ISPN-6745 - for which a fix is already committed in the 8.2.x branch.
> TimeoutException: Replication timeout when handling request with DIST cache
> ---------------------------------------------------------------------------
>
> Key: WFLY-6926
> URL: https://issues.jboss.org/browse/WFLY-6926
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.CR1
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
> Priority: Blocker
>
> Seen in http-session scenarios with *DIST* cache only. REPL cache scenarios seem not to be affected.
> TimeoutExceptions occur right away after sending first request and definitely result in client getting 500:
> {code}
> [JBossINF] [0m[31m04:31:39,033 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Replication timeout for perf19
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:801)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:642)
> [JBossINF] at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> [JBossINF] at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> [JBossINF] at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> [JBossINF] at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.staggeredProcessNext(CommandAwareRpcDispatcher.java:375)
> [JBossINF] at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.lambda$processCallsStaggered$3(CommandAwareRpcDispatcher.java:357)
> [JBossINF] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [JBossINF] at java.lang.Thread.run(Thread.java:745)
> {code}
> Client:
> {code}
> 2016/08/08 04:31:39:068 EDT [WARN ][Runner - 4] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error sampling data: Internal Server Error>
> org.jboss.smartfrog.loaddriver.RequestProcessingException: Invalid response code: 500 Content: Internal Server Error
> at org.jboss.smartfrog.loaddriver.http.HttpRequestProcessorFactoryImpl$HttpRequestProcessor.processRequest(HttpRequestProcessorFactoryImpl.java:163)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> I was able to reproduce it even with a very small load of 30 sessions.
> Server link (run with 30 sessions):
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> Client link (run with 30 sessions):
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> This issue occurs under different conditions than JBEAP-3779 (which is similar), that's why I opened new issue.
> Number of occurrences of TimeoutExceptions is very high. The server logs are full of them.
> This issue makes clustering with *DIST* cache unusable, thus giving blocker priority.
> Also, there is a issue with shutting down the servers in the end of the test, I don't know if it can be related, but I am hitting it constantly in the http-session DIST scenarios.
> The server shutdown usually gets stuck on this command:
> {code}
> [JBossINF] [0m[0m04:38:51,694 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web
> {code}
> *EDIT:*
> Also ejb-remote tests with *DIST* cache are affected (even if only 20 sessions are created).
> Server log for ejb-remote run:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> Client log for ejb-remote run:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/mvinkler_eap-7x-failo...
> *EDIT #2:*
> Can be very easily reproduced locally. Just start a cluster of at least 3 servers with clusterbench deployed. Then do few requests to various nodes until you get 500 as a response. Also notice, when shutting down a node, which logged TimeoutException before, the node won't stop and get stuck during the shutdown.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFCORE-1700) Add ManagementXml_5
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1700:
----------------------------------------
Summary: Add ManagementXml_5
Key: WFCORE-1700
URL: https://issues.jboss.org/browse/WFCORE-1700
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Alpha5
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months