[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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 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)
9 years, 9 months