[JBoss JIRA] (JGRP-2082) Coordinator failover is taking longer because VERIFY_SUSPECT runs twice
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-2082?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-2082:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1348404|https://bugzilla.redhat.com/show_bug.cgi?id=1348404] from POST to MODIFIED
> Coordinator failover is taking longer because VERIFY_SUSPECT runs twice
> -----------------------------------------------------------------------
>
> Key: JGRP-2082
> URL: https://issues.jboss.org/browse/JGRP-2082
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.3
> Reporter: Osamu Nagano
> Assignee: Bela Ban
> Fix For: 3.6.10, 4.0
>
>
> There are 4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each. To test the coordinator failover behaviour, nodes on m03 are all killed at the same time. These are suspected and verified in sequence at the first time (line 9 to 18, only m03_n007 is verified as dead and others are just queued), while these are verified as a whole at the second time (line 19 to 34). Since the coordinator is in the queued at the first time, view change is not triggered and causing a delay.
> - m03_n001 is the original coordinator.
> - m05_n001 is the next coordinator and the owner of the following log messages.
> {code}
> 8 12:04:10,997 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK acceptor,m05_n001/clustered) m05_n001/clustered: accepted connection from /172.20.66.36:29702
> 9 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n001/clustered]
> 10 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n002/clustered]
> 11 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n003/clustered]
> 12 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n004/clustered]
> 13 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n005/clustered]
> 14 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n006/clustered]
> 15 12:04:10,999 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n007/clustered]
> 16 12:04:10,999 DEBUG [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: suspecting [m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n006/clustered, m03_n007/clustered]
> 17 12:04:11,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n007/clustered is dead
> 18 12:04:12,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n007/clustered is dead (passing up SUSPECT event)
> 19 12:04:16,000 TRACE [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: received SUSPECT message from m06_n007/clustered: suspects=[m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n002/clustered, m03_n001/clustered, m03_n007/clustered, m03_n006/clustered]
> 20 12:04:16,000 DEBUG [org.jgroups.protocols.FD_SOCK] (INT-28,shared=udp) m05_n001/clustered: suspecting [m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n005/clustered, m03_n006/clustered, m03_n007/clustered]
> 21 12:04:16,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n003/clustered is dead
> 22 12:04:16,000 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n004/clustered is dead
> 23 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n005/clustered is dead
> 24 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n002/clustered is dead
> 25 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n001/clustered is dead
> 26 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n007/clustered is dead
> 27 12:04:16,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (INT-28,shared=udp) verifying that m03_n006/clustered is dead
> 28 12:04:17,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n003/clustered is dead (passing up SUSPECT event)
> 29 12:04:17,001 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n004/clustered is dead (passing up SUSPECT event)
> 30 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n007/clustered is dead (passing up SUSPECT event)
> 31 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n001/clustered is dead (passing up SUSPECT event)
> 32 12:04:17,002 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n002/clustered is dead (passing up SUSPECT event)
> 33 12:04:17,003 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n005/clustered is dead (passing up SUSPECT event)
> 34 12:04:17,003 TRACE [org.jgroups.protocols.VERIFY_SUSPECT] (VERIFY_SUSPECT.TimerThread,m05_n001/clustered) m03_n006/clustered is dead (passing up SUSPECT event)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-606) Wrap the match elements with an outer match element.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-606:
------------------------------------
Summary: Wrap the match elements with an outer match element.
Key: ELY-606
URL: https://issues.jboss.org/browse/ELY-606
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 1.1.0.Beta7
For each match type we support at most one definition of each - by adding a wrapper element we can use xsd:all to more accurately reflect this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6885:
-----------------------------------
Component/s: EJB
Transactions
> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6885
> URL: https://issues.jboss.org/browse/WFLY-6885
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 10.0.0.Final
> Reporter: Marcel Kolsteren
> Assignee: Jason Greene
> Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6885:
--------------------------------------
Assignee: Tom Jenkinson (was: Jason Greene)
> Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6885
> URL: https://issues.jboss.org/browse/WFLY-6885
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 10.0.0.Final
> Reporter: Marcel Kolsteren
> Assignee: Tom Jenkinson
> Attachments: tx-timeout.zip
>
>
> The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method.
> I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test).
> I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here
> [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...]
> This happens (I verified by stepping through the code with the debugger):
> * The catch block of invokeInOurTx is entered.
> * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception.
> * The finally block of invokeInOurTx is entered.
> * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause.
> The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6889) ArrayIndexOutOfBoundsException happens when Accept header is just a slash
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6889?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6889:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
(was: 10.1.0.CR1)
> ArrayIndexOutOfBoundsException happens when Accept header is just a slash
> -------------------------------------------------------------------------
>
> Key: WFLY-6889
> URL: https://issues.jboss.org/browse/WFLY-6889
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 10.0.0.Final
> Reporter: Dmitrii Tikhomirov
> Assignee: Dmitrii Tikhomirov
> Fix For: 11.0.0.Alpha1
>
>
> Some clients send Accept header with just '/'. It causes ArrayIndexOutOfBoundsException as follows.
> {code}
> 2016-07-26 14:22:57,119 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-15) Error Rendering View[/index.xhtml]: java.lang.ArrayIndexOutOfBoundsException: 0
> at com.sun.faces.renderkit.RenderKitUtils.buildTypeArrayFromString(RenderKitUtils.java:913)
> at com.sun.faces.renderkit.RenderKitUtils.determineContentType(RenderKitUtils.java:563)
> at com.sun.faces.renderkit.RenderKitImpl.createResponseWriter(RenderKitImpl.java:260)
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1193)
> 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 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.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.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> 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:802)
> 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)
> {code}
> This is fixed in the upstream as JAVASERVERFACES-4077 but not backported yet.
> https://java.net/jira/browse/JAVASERVERFACES-4077
> https://github.com/javaserverfaces/mojarra/commit/14514cfe589cacad683f86a...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (JBJCA-1327) Wrong condition when parsing ironjacamar.rollback_on_fatal_error property
by Martin Simka (JIRA)
Martin Simka created JBJCA-1327:
-----------------------------------
Summary: Wrong condition when parsing ironjacamar.rollback_on_fatal_error property
Key: JBJCA-1327
URL: https://issues.jboss.org/browse/JBJCA-1327
Project: IronJacamar
Issue Type: Bug
Affects Versions: WildFly/IronJacamar 1.3.4.Final
Reporter: Martin Simka
Assignee: Stefano Maestri
There is wrong condition in https://github.com/ironjacamar/ironjacamar/blob/1.3/core/src/main/java/or...
{code:java}
value = SecurityActions.getSystemProperty("ironjacamar.rollback_on_fatal_error");
if (value != null && !value.trim().equals(""))
{
if ("true".equalsIgnoreCase(value) || "false".equalsIgnoreCase(value))
{
doSetRollbackOnly = Boolean.parseBoolean(value);
}
else
{
StringTokenizer st = new StringTokenizer(value, ",");
while (doDelistResource && st.hasMoreTokens()) // <-- should be while (doSetRollbackOnly ...
{
if (getPool().getName().equals(st.nextToken()))
doSetRollbackOnly = false;
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-6856) Jboss CLI reporting wrong readings of datasource
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6856?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen closed WFLY-6856.
---------------------------------
Resolution: Won't Fix
Upgrade to 10.0, and open forum a user thread if you can questions
> Jboss CLI reporting wrong readings of datasource
> ------------------------------------------------
>
> Key: WFLY-6856
> URL: https://issues.jboss.org/browse/WFLY-6856
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 8.2.0.Final
> Reporter: ritesh ranjan
> Assignee: Jesper Pedersen
> Labels: wildfly
>
> Jboss's CLI is reporting wrong values of datasource parameters.(active count,idlecount etc..)
> As per the reading , idle connections on the database side have been closed but actually the connections are indeed active.
> Probably, jboss isn't checking on the oracle side.
> PS : found in wildfly 8 and our db is Oracle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months