November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated WFLY-9587: ---------------------------------- Summary: Investigate and introduce capabilities for the transactional subsytems transations/xts/rts (was: Investigate and add capability for the transactional subsytems transations/xts/rts) > Investigate and introduce capabilities for the transactional subsytems transations/xts/rts > ------------------------------------------------------------------------------------------ > > Key: WFLY-9587 > URL: https://issues.jboss.org/browse/WFLY-9587 > Project: WildFly > Issue Type: Feature Request > Components: Transactions, XTS > Affects Versions: 11.0.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. > https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9587) Investigate and add capability for the transactional subsytems transations/xts/rts

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created WFLY-9587: ------------------------------------- Summary: Investigate and add capability for the transactional subsytems transations/xts/rts Key: WFLY-9587 URL: https://issues.jboss.org/browse/WFLY-9587 Project: WildFly Issue Type: Feature Request Components: Transactions, XTS Affects Versions: 11.0.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9586) Persistent EJB timers should resume only once if missed multiple times

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-9586: -------------------------------------- Summary: Persistent EJB timers should resume only once if missed multiple times Key: WFLY-9586 URL: https://issues.jboss.org/browse/WFLY-9586 Project: WildFly Issue Type: Enhancement Components: EJB Reporter: Wolf-Dieter Fink Timers which are persistent need to resume if the timeout is missed, i.e. if the server was down. The EJB specification say by §13.2: "In the event of a container crash or container shutdown, the timeout callback method for a persistent timer that has not been cancelled will be invoked on a new JVM when the container is restarted or on another JVM instance across which the container is distributed. This rule applies to both programmatically or automatically created persistent timers." The understanding is not clear and can be - resume ALL missed timeouts - resume but fire the timer only once As Wildfly prevent from having the same timeout running concurrent a server start will have the effect that multiple timeouts are fired (assume you have a timer scheduled for every second and the server is down for minutes) but only the first (or a couple) will efectively executed all other will 'only' burden the server and log warn/error messages. The effect for the server start is a slower startup, long list of log messages and no real benefit! If the spec is really unclear here a configuration flag should be added to control that behaviour (like done for ejb invocation in-vm calls - byReference/byValue) The current behaviour should be the default but a boolean attribute should allow to fire the timer only once and set the next timeout according to the schedule (recurring or calendar) in the future. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name

by Shing Lam (JIRA)

Shing Lam created WFLY-9585: ------------------------------- Summary: Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name Key: WFLY-9585 URL: https://issues.jboss.org/browse/WFLY-9585 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga) Reporter: Shing Lam We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected. We have in the ejb-jar.xml {code:xml} <enterprise-beans> <session> <ejb-name>BackgroundRecoverySessionEJB</ejb-name> <resource-ref> <res-ref-name>jdbc/RMDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> <persistence-context-ref> <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name> </persistence-context-ref> </session> {code} and in jboss-ejb3.xml {code:xml} <jboss:enterprise-beans> <jboss:ejb> <ejb-name>BackgroundRecoverySessionEJB</ejb-name> <resource-ref> <res-ref-name>jdbc/RMDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name> </resource-ref> </jboss:ejb> {code} the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4. But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;" If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB. Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3439?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3439: ------------------------------------- Description: DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input. As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. was: DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. One thing to be careful about when looking at this is the possibility that the operation (or a step in it if it's composite) has not been provided by the slave HC, but rather is the original request input. As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. > Reevaluate MultiphaseOverallContext.transformServerOperation > ------------------------------------------------------------ > > Key: WFCORE-3439 > URL: https://issues.jboss.org/browse/WFCORE-3439 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. > Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. > One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input. > As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3439: ---------------------------------------- Summary: Reevaluate MultiphaseOverallContext.transformServerOperation Key: WFCORE-3439 URL: https://issues.jboss.org/browse/WFCORE-3439 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. One thing to be careful about when looking at this is the possibility that the operation (or a step in it if it's composite) has not been provided by the slave HC, but rather is the original request input. As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-188) [QE] - JMAN4-201 - Enable metric based alerts for EAP

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-188?page=com.atlassian.jira.pl... ] Guilherme Baufaker Rêgo resolved HAWKULARQE-188. ------------------------------------------------ Release Notes Text: JMAN4-241 was verified. Remaining requirements were moved to JMAN4-241 Resolution: Done > [QE] - JMAN4-201 - Enable metric based alerts for EAP > ----------------------------------------------------- > > Key: HAWKULARQE-188 > URL: https://issues.jboss.org/browse/HAWKULARQE-188 > Project: Hawkular QE > Issue Type: Task > Reporter: Hayk Hovsepyan > Assignee: Guilherme Baufaker Rêgo > Priority: Critical > Labels: 4.6 > > See [JMAN4-201|https://issues.jboss.org/browse/JMAN4-201] -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-183) Java 7+ level hack on the LogManager does not work

by James Perkins (JIRA)

James Perkins created LOGMGR-183: ------------------------------------ Summary: Java 7+ level hack on the LogManager does not work Key: LOGMGR-183 URL: https://issues.jboss.org/browse/LOGMGR-183 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins Assignee: James Perkins The {{org.jboss.logmanager.LogManager}} uses {{getConstructor()}} method for the {{java.util.logging.Level$KnownLevel}} hack. This should be using {{getDeclaredConstructor()}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1361) Documentation for flush strategies needs clarification

by Stephen Fikes (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1361?page=com.atlassian.jira.plugin... ] Stephen Fikes updated JBJCA-1361: --------------------------------- Description: http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html... It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense. The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections - specifically to those that are associated with a specific authentication credential whereas the {{All*}} variants include all subsets associated with the datasource (regardless of credentials). was: http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html... It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense. The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections that are associated with a specific authentication credential whereas the {{All*}} variants are not so limited. > Documentation for flush strategies needs clarification > ------------------------------------------------------ > > Key: JBJCA-1361 > URL: https://issues.jboss.org/browse/JBJCA-1361 > Project: IronJacamar > Issue Type: Bug > Components: Documentation > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: Stephen Fikes > > http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html... > It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense. > The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections - specifically to those that are associated with a specific authentication credential whereas the {{All*}} variants include all subsets associated with the datasource (regardless of credentials). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1361) Documentation for flush strategies needs clarification

by Stephen Fikes (JIRA)

Stephen Fikes created JBJCA-1361: ------------------------------------ Summary: Documentation for flush strategies needs clarification Key: JBJCA-1361 URL: https://issues.jboss.org/browse/JBJCA-1361 Project: IronJacamar Issue Type: Bug Components: Documentation Affects Versions: 1.2.7.Final, WildFly/IronJacamar 1.3.4.Final Reporter: Stephen Fikes http://www.ironjacamar.org/doc/userguide/1.2/en-US/html_single/index.html... It wasn't immediately clear to me how {{EntirePool}} and {{IdleConnections}} flush strategies work since both use the word "all" in their explanation/definition. Comparing {{AllConnections}} and {{AllIdleConnections}} it is clear that "all" with regard to {{EntirePool}} and {{IdleConnections}} is limited in some sense. The subtlety lies in the fact that a single datasource can have multiple (internal) sets of connections grouped/segregated by authentication credentials. Consequently, "all" in the context of {{EntirePool}} or {{IdleConnections}} is limited to a subset of the connections that are associated with a specific authentication credential whereas the {{All*}} variants are not so limited. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2017