July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12329) ManagedScheduledExecutorService should be only available after server is ready

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12329?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12329: ----------------------------------------- WFCORE-4291 is about allowing 'graceful startup' to be turned off in some way. This is related in the sense that this is a 'graceful startup' issue. Doing WFCORE-4291 means examining code that is using 'suspend' as a way to control startup behavior and to see if that is appropriate. > ManagedScheduledExecutorService should be only available after server is ready > ------------------------------------------------------------------------------ > > Key: WFLY-12329 > URL: https://issues.jboss.org/browse/WFLY-12329 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 17.0.1.Final > Reporter: nimo stephan > Assignee: Eduardo Martins > Priority: Major > > I use a *ManagedScheduledExecutorService* to execute tasks periodically: > {code:java} > @Startup > @Singleton > public class TaskScheduler { > @Resource > ManagedScheduledExecutorService executorService; > @PostConstruct > public void init() { > executorService.scheduleAtFixedRate(this::task, 0, 5, TimeUnit.SECONDS); > } > public void task() { > System.out.println("long running task:" + LocalTime.now()); > } > } > {code} > Wildfly throws a few exceptions as long as server is not fully initiated and in "suspend"-mode: > {code:java} > 12:44:12,715 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.IllegalStateException: WFLYEE0111: Cannot run scheduled task my.Task$$Lambda$1041/0x000000080240a040@5ee966ec as container is suspended > at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:164) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) > {code} > I use _ManagedScheduledExecutorService_ instead of _ScheduledExecutorService_ in JEE because, *ManagedScheduledExecutorService* should be managed by JEE. Hence, the server should also manage and guarantee not to fire the executorService until the server is ready (and EJBs are available). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4560) HTTP management interface fails to start if backed by a "https" socket-binding

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4560?page=com.atlassian.jira.plugi... ] Jeff Mesnil commented on WFCORE-4560: ------------------------------------- [~ropalka] It seems to be a valid MSC bug. Should we open a MSC issue to track and fix it? > HTTP management interface fails to start if backed by a "https" socket-binding > ------------------------------------------------------------------------------ > > Key: WFCORE-4560 > URL: https://issues.jboss.org/browse/WFCORE-4560 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 9.0.2.Final, 10.0.0.Beta1 > Reporter: Jaikiran Pai > Assignee: Jeff Mesnil > Priority: Major > Fix For: 10.0.0.Beta2 > > > A user has reported that WildFly 17.0.0.Final fails to start when ManagementRealm is backed by a socket-binding which uses HTTPS. More details about this issue are here https://developer.jboss.org/thread/280311. > There's actually more than one issue in that thread: > 1. The failure to start > 2. The absence of any error message indicating what failed. > This JIRA is mainly to track the failure to start and a separate JIRA can/will probably be opened for dealing with the absence of the error message (since I am guessing that it's going to be a more generic issue/change). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12140) Set bridgeName while creating JMSBridge on server

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12140?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12140: ----------------------------------- Labels: downstream_dependency (was: ) > Set bridgeName while creating JMSBridge on server > ------------------------------------------------- > > Key: WFLY-12140 > URL: https://issues.jboss.org/browse/WFLY-12140 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 17.0.0.Beta1 > Reporter: Shailendra Singh > Assignee: Emmanuel Hugonnet > Priority: Minor > Labels: downstream_dependency > Fix For: 17.0.0.Final > > > Set bridgeName while creating JMSBridge on server > When JMS bridge get reconnected after network issue the logs contains the default bridgeName i.e "N/A" > {code:java} > 14:07:56,933 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-109) AMQ342010: Failed to connect JMS Bridge N/A: javax.jms.JMSException: Failed to create session factory > at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:846) > at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:282) > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.createConnection(JMSBridgeImpl.java:1120) > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1286) > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1392) > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2800(JMSBridgeImpl.java:77) > at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1902) > 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) > Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ219007: Cannot connect to server(s). Tried with all available servers.] > at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:795) > at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:844) > ... 9 more > {code} > And reconenct message. > {code:java} > 14:07:57,834 INFO [org.apache.activemq.artemis.jms.bridge] (Thread-109) AMQ341001: JMS Bridge N/A succeeded in reconnecting to servers > {code} > bridgeName will be helpful to find the bridge having the issue in multi JMS Bridge scenario. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12161) The expression for the value of share-prepared-statements does not work in XA datasource .

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12161?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12161: ----------------------------------- Labels: downstream_dependency (was: ) > The expression for the value of share-prepared-statements does not work in XA datasource . > ------------------------------------------------------------------------------------------ > > Key: WFLY-12161 > URL: https://issues.jboss.org/browse/WFLY-12161 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 17.0.0.Beta1 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Major > Labels: downstream_dependency > Fix For: 17.0.0.Final > > > - Although , the "expressions-allowed" is true for "share-prepared-statements" , the expression for it does not work . > -------------------------------------------- > [standalone@localhost:9990 /] /subsystem=datasources/xa-data-source=ExampleXADS:read-resource-description() > "share-prepared-statements" => { > "type" => BOOLEAN, > "description" => "Whether to share prepared statements, i.e. whether asking for same statement twice without closing uses the same underlying prepared statement", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > --------------------------------------------- > - It shows below error if we set expression for share-prepared-statements . > --------------------------------------------- > 18:32:07,698 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 41) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "datasources"), > ("xa-data-source" => "ExampleXADS") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:69) > at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:324) > at org.jboss.as.connector.subsystems.datasources.DataSourceModelNodeUtil.xaFrom(DataSourceModelNodeUtil.java:292) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.secondRuntimeStep(AbstractDataSourceAdd.java:298) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd$1.execute(AbstractDataSourceAdd.java:134) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > --------------------------------------------- > - However , it works in a non-xa datasource . -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12333) Skip redundant put operations when distributable web sessions use local, non-persistent cache configuration

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12333?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12333: -------------------------------- Description: When a distributable web session is closed, we perform a cache put to ensure state is persisted/replicated. However, when the cache configuration is both local and non-persistent, this cache operation is redundant. (was: When a distributable SFSB is released, we perform a cache put to ensure state is persisted/replicated. However, when the cache configuration is both local and non-persistent, this cache operation is redundant.) > Skip redundant put operations when distributable web sessions use local, non-persistent cache configuration > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-12333 > URL: https://issues.jboss.org/browse/WFLY-12333 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 17.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > When a distributable web session is closed, we perform a cache put to ensure state is persisted/replicated. However, when the cache configuration is both local and non-persistent, this cache operation is redundant. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12333) Skip redundant put operations when distributable web sessions use local, non-persistent cache configuration

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12333?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12333: -------------------------------- Component/s: Web (Undertow) (was: EJB) > Skip redundant put operations when distributable web sessions use local, non-persistent cache configuration > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-12333 > URL: https://issues.jboss.org/browse/WFLY-12333 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 17.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > When a distributable SFSB is released, we perform a cache put to ensure state is persisted/replicated. However, when the cache configuration is both local and non-persistent, this cache operation is redundant. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12333) Skip redundant put operations when distributable web sessions use local, non-persistent cache configuration

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12333: ----------------------------------- Summary: Skip redundant put operations when distributable web sessions use local, non-persistent cache configuration Key: WFLY-12333 URL: https://issues.jboss.org/browse/WFLY-12333 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 17.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro When a distributable SFSB is released, we perform a cache put to ensure state is persisted/replicated. However, when the cache configuration is both local and non-persistent, this cache operation is redundant. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4396) WildFly Core pom should use https URLs in repository and pluginRepository elements

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFCORE-4396?page=com.atlassian.jira.plugi... ] Martin Stefanko updated WFCORE-4396: ------------------------------------ Labels: downstream_dependency (was: ) > WildFly Core pom should use https URLs in repository and pluginRepository elements > ---------------------------------------------------------------------------------- > > Key: WFCORE-4396 > URL: https://issues.jboss.org/browse/WFCORE-4396 > Project: WildFly Core > Issue Type: Bug > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: downstream_dependency > Fix For: 9.0.0.Beta3, 9.0.0.Final > > > Help avoid man-in-the-middle attack problems during builds by using http. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12174) Configure internal broker not to check for configuration changes

by Martin Stefanko (Jira)

[ https://issues.jboss.org/browse/WFLY-12174?page=com.atlassian.jira.plugin... ] Martin Stefanko updated WFLY-12174: ----------------------------------- Labels: downstream_dependency (was: ) > Configure internal broker not to check for configuration changes > ---------------------------------------------------------------- > > Key: WFLY-12174 > URL: https://issues.jboss.org/browse/WFLY-12174 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Affects Versions: 17.0.0.Beta1 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: downstream_dependency > Fix For: 17.0.0.Final > > > Currently the internal broker will scan periodically the logging.properties file to detect changes while the logging configuraiton is managed by WildFly. > Setting the configurationFileRefreshPeriod to -1 to avoid reloading of > logging.properties -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4585) Not working configured SSL using legacy security-realm in ManagementRealm on host.xml

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4585?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-4585: ------------------------------------- Security: (was: Security Issue) > Not working configured SSL using legacy security-realm in ManagementRealm on host.xml > --------------------------------------------------------------------------------------- > > Key: WFCORE-4585 > URL: https://issues.jboss.org/browse/WFCORE-4585 > Project: WildFly Core > Issue Type: Bug > Components: Security > Environment: tried in Linux version RHEL 7.2 > Reporter: Tarak A > Assignee: Darran Lofthouse > Priority: Major > > Hi Team, > We need your suggestion to fix SSL configuration issue in legacy security-realm in ManagementRealm on host.xml, and it is causing not to start master node with legacy SSL settings in Wildfly 17.0.1 Final version. Below are the example setting we used to configure,same settings working in Wildfly 15.0.1. > SSL > <security-realm name="ManagementRealm"> > <server-identities> > <ssl> > <keystore path="server.jks" relative-to="jboss.server.config.dir" keystore-password="keystore_password" alias="server" key-password="key_password" /> > </ssl> > </server-identities> > <authentication> > <truststore path="server.jks" relative-to="jboss.server.config.dir" keystore-password="truststore_password" /> > <local default-user="$local"/> > <properties path="application-users.properties" relative-to="jboss.server.config.dir"/> > </authentication> > </security-realm> -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 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 2019