March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9977) Redundant CONSOLE log handler adding in CLI scripts for messaging-clustering* QS

by Nikoleta Žiaková (JIRA)

Nikoleta Žiaková created WFLY-9977: -------------------------------------- Summary: Redundant CONSOLE log handler adding in CLI scripts for messaging-clustering* QS Key: WFLY-9977 URL: https://issues.jboss.org/browse/WFLY-9977 Project: WildFly Issue Type: Bug Components: Quickstarts Affects Versions: 12.0.0.Final Reporter: Nikoleta Žiaková Assignee: Tomaz Cerar CLI scripts in messaging-clustering and messaging-clustering-singleton QS contain redundant step for adding CONSOLE log handler. They fails with: {code} Failure: WFLYCTL0212: Duplicate resource {code} The reason is that CONSOLE log handler is enabled by default. Readme files mention adding the handler, too: https://github.com/wildfly/quickstart/tree/master/messaging-clustering https://github.com/wildfly/quickstart/tree/master/messaging-clustering-si... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code

by Sander Stoel (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugi... ] Sander Stoel commented on WFCORE-3527: -------------------------------------- This change along with WFLY-9663 has effectively killed https://github.com/jbosgi/jbosgi/ which was still being actively maintained and used, I also do not see a way to get this to work anymore. > Remove OSGi obsolete code > ------------------------- > > Key: WFCORE-3527 > URL: https://issues.jboss.org/browse/WFCORE-3527 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 4.0.0.Alpha5 > Reporter: Richard Opalka > Assignee: Richard Opalka > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ] Amos Feng edited comment on WFLY-9955 at 3/8/18 3:31 AM: --------------------------------------------------------- https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... {code} TxControl.setDefaultTimeout(resolvedValue.asInt()); ContextTransactionManager.setGlobalDefaultTransactionTimeout(resolvedValue.asInt()); {code} if the value == 0; TxControl.setDefaultTimeout(0); // the transaction will be never time out. So it is OK to set zero here ContextTransactionManager.setGlobalDefaultTransactionTimeout(0); // this is wrong, so it has to be converted to the maximum timeout which might be Integer.MAX_VALUE [~dmlloyd], I do not understand the necessary to introduce a maximum timeout attribute. I suppose to change the above codes to {code} int timeoutValue = resolvedValue.asInt(); TxControl.setDefaultTimeout(timeoutValue); if (timeoutValue == 0) { timeoutValue = Integer.MAX_VALUE; } ContextTransactionManager.setGlobalDefaultTransactionTimeout(timeoutValue); {code} was (Author: zhfeng): https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... {code} TxControl.setDefaultTimeout(resolvedValue.asInt()); ContextTransactionManager.setGlobalDefaultTransactionTimeout(resolvedValue.asInt()); {code} if the value == 0; TxControl.setDefaultTimeout(0); // the transaction will be never time out. So it is OK to set zero here ContextTransactionManager.setGlobalDefaultTransactionTimeout(0); // this is wrong, so it has to be converted to the maximum timeout which might be Integer.MAX_VALUE [~dmlloyd], I do not understand the necessary to introduce a maximum timeout attribute. I suppose to change the above codes to {code} int timeoutValue = resolvedValue.asInt(); TxControl.setDefaultTimeout(timeoutValue); if (timeoutValue > 0) { timeoutValue = Integer.MAX_VALUE; } ContextTransactionManager.setGlobalDefaultTransactionTimeout(timeoutValue); {code} > Compatibility problem: allow a timeout value of "0" to be set > ------------------------------------------------------------- > > Key: WFLY-9955 > URL: https://issues.jboss.org/browse/WFLY-9955 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value. > The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ] Amos Feng commented on WFLY-9955: --------------------------------- https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... {code} TxControl.setDefaultTimeout(resolvedValue.asInt()); ContextTransactionManager.setGlobalDefaultTransactionTimeout(resolvedValue.asInt()); {code} if the value == 0; TxControl.setDefaultTimeout(0); // the transaction will be never time out. So it is OK to set zero here ContextTransactionManager.setGlobalDefaultTransactionTimeout(0); // this is wrong, so it has to be converted to the maximum timeout which might be Integer.MAX_VALUE [~dmlloyd], I do not understand the necessary to introduce a maximum timeout attribute. I suppose to change the above codes to {code} int timeoutValue = resolvedValue.asInt(); TxControl.setDefaultTimeout(timeoutValue); if (timeoutValue > 0) { timeoutValue = Integer.MAX_VALUE; } ContextTransactionManager.setGlobalDefaultTransactionTimeout(timeoutValue); {code} > Compatibility problem: allow a timeout value of "0" to be set > ------------------------------------------------------------- > > Key: WFLY-9955 > URL: https://issues.jboss.org/browse/WFLY-9955 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value. > The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7691) Custom pool not working when applied to Message-Driven Bean

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-7691?page=com.atlassian.jira.plugin.... ] Yeray Borges resolved WFLY-7691. -------------------------------- Resolution: Cannot Reproduce {{maxSessions}} is not a valid activation configuration properties defined by Wildfly, you must use {{maxSession}} instead. If you don't define it, the default value is 15, that's the reason you are getting only 15 messages at the same time. > Custom pool not working when applied to Message-Driven Bean > ----------------------------------------------------------- > > Key: WFLY-7691 > URL: https://issues.jboss.org/browse/WFLY-7691 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Evandro Pomatti > Assignee: Yeray Borges > Labels: mdb, pool > > I tried to configure a custom thread pool por an MDB in order to increase performance, but it seems that the association is being ignored by WildFly. > When I associate my custom pool with increased size to 50 to my MDB, only 15 messages keep getting dequeue at a time. > I also don't know why 15, since the default MDB pool "mdb-strict-max-pool" max size is configured to be 20. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7691) Custom pool not working when applied to Message-Driven Bean

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-7691?page=com.atlassian.jira.plugin.... ] Yeray Borges reassigned WFLY-7691: ---------------------------------- Assignee: Yeray Borges > Custom pool not working when applied to Message-Driven Bean > ----------------------------------------------------------- > > Key: WFLY-7691 > URL: https://issues.jboss.org/browse/WFLY-7691 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Evandro Pomatti > Assignee: Yeray Borges > Labels: mdb, pool > > I tried to configure a custom thread pool por an MDB in order to increase performance, but it seems that the association is being ignored by WildFly. > When I associate my custom pool with increased size to 50 to my MDB, only 15 messages keep getting dequeue at a time. > I also don't know why 15, since the default MDB pool "mdb-strict-max-pool" max size is configured to be 20. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9967) LayeredDistributionTestCase fails without clean install

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9967?page=com.atlassian.jira.plugin.... ] Chao Wang reassigned WFLY-9967: ------------------------------- Assignee: Chao Wang > LayeredDistributionTestCase fails without clean install > ------------------------------------------------------- > > Key: WFLY-9967 > URL: https://issues.jboss.org/browse/WFLY-9967 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Jan Kalina > Assignee: Chao Wang > > LayeredDistributionTestCase fails when started twice without {{mvn clean}} - removing old working directory is done using operation supporting only blank directories: > {code} > Running org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase > Tests run: 4, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.1 sec <<< FAILURE! - in org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase > before(org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase) Time elapsed: 0.058 sec <<< ERROR! > java.nio.file.DirectoryNotEmptyException: target/jbossas-layered/modules/system/layers/test > at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242) > at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108) > at java.nio.file.Files.deleteIfExists(Files.java:1165) > at org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase.buildLayer(LayeredDistributionTestCase.java:162) > at org.jboss.as.test.manualmode.layered.LayeredDistributionTestCase.before(LayeredDistributionTestCase.java:99) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9976) EJB Client Interceptor not invoked for Local Interface

by Bartosz Baranowski (JIRA)

Bartosz Baranowski created WFLY-9976: ---------------------------------------- Summary: EJB Client Interceptor not invoked for Local Interface Key: WFLY-9976 URL: https://issues.jboss.org/browse/WFLY-9976 Project: WildFly Issue Type: Enhancement Components: EJB Affects Versions: 12.0.0.Final Reporter: Bartosz Baranowski Assignee: Flavia Rainone -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/WFLY-9955?page=com.atlassian.jira.plugin.... ] Amos Feng commented on WFLY-9955: --------------------------------- sure, I will have a look > Compatibility problem: allow a timeout value of "0" to be set > ------------------------------------------------------------- > > Key: WFLY-9955 > URL: https://issues.jboss.org/browse/WFLY-9955 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: David Lloyd > Assignee: Amos Feng > > Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value. > The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9975) infinispan cache-container[jndi-name] fails validation in WildFly 12

by Pratik Parikh (JIRA)

Pratik Parikh created WFLY-9975: ----------------------------------- Summary: infinispan cache-container[jndi-name] fails validation in WildFly 12 Key: WFLY-9975 URL: https://issues.jboss.org/browse/WFLY-9975 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 12.0.0.Final Environment: ALL Reporter: Pratik Parikh Assignee: Jason Greene Priority: Blocker Widfly 12 fails to recognize jndi-name attribute and emits exception the following: OPVDX001: Validation error in standalone.xml ----------------------------------- | | 336: | 337: | 338: | ^^^^ 'jndi-name' isn't an allowed attribute for the 'cache-container' | element | | Attributes allowed here are: | aliases jndi-name name | default-cache module statistics-enabled | | 339: | 340: | 341: | | 'jndi-name' is allowed on elements: | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > context-services > context-service | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > managed-thread-factories > managed-thread-factory | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > managed-executor-services > managed-executor-service | - server > profile > {urn:jboss:domain:ee:4.0}subsystem > concurrent > managed-scheduled-executor-services > managed-scheduled-executor-service | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container > local-cache | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container > replicated-cache | - server > profile > {urn:jboss:domain:infinispan:5.0}subsystem > cache-container > invalidation-cache | - server > profile > {urn:jboss:domain:mail:3.0}subsystem > mail-session | - server > profile > {urn:jboss:domain:transactions:4.0}subsystem > commit-markable-resources > commit-markable-resource | | | The primary underlying error message was: | > ParseError at [row,col]:[338,4] | > Message: WFLYCTL0197: Unexpected attribute 'jndi-name' encountered | |------------------------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 March 2018