July 2016 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (DROOLS-1241) Incremental compilation doesn't recognize an event if the event declaration is in an unchanged drl

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1241: ----------------------------------- Summary: Incremental compilation doesn't recognize an event if the event declaration is in an unchanged drl Key: DROOLS-1241 URL: https://issues.jboss.org/browse/DROOLS-1241 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco If incremental compilation adds a brand new drl that tries to use a type as an event and that type has been indeed declared as an event but in a different unchanged drl, the builder is no longer able to recognize the type as an event thus causing a compilation error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-5117) Switch to version 5 of the management schema

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5117?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-5117: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9079 (was: https://github.com/wildfly/wildfly/pull/8583) > Switch to version 5 of the management schema > -------------------------------------------- > > Key: WFLY-5117 > URL: https://issues.jboss.org/browse/WFLY-5117 > Project: WildFly > Issue Type: Task > Components: Domain Management, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5136) Switch http-management-interface configurations to use http-upgrade enabled.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5136?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-5136: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9079 (was: https://github.com/wildfly/wildfly/pull/8832) > Switch http-management-interface configurations to use http-upgrade enabled. > ---------------------------------------------------------------------------- > > Key: WFLY-5136 > URL: https://issues.jboss.org/browse/WFLY-5136 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6890) Add Weld SPI dependency to the transactions module

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/WFLY-6890?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on WFLY-6890: --------------------------------------- Fix pull request on Narayana WildFly clone: https://github.com/jbosstm/jboss-as/pull/47 > Add Weld SPI dependency to the transactions module > -------------------------------------------------- > > Key: WFLY-6890 > URL: https://issues.jboss.org/browse/WFLY-6890 > Project: WildFly > Issue Type: Task > Components: Transactions > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 10.1.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6890) Add Weld SPI dependency to the transactions module

by Gytis Trikleris (JIRA)

Gytis Trikleris created WFLY-6890: ------------------------------------- Summary: Add Weld SPI dependency to the transactions module Key: WFLY-6890 URL: https://issues.jboss.org/browse/WFLY-6890 Project: WildFly Issue Type: Task Components: Transactions Reporter: Gytis Trikleris Assignee: Gytis Trikleris Fix For: 10.1.0.CR1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016