[JBoss JIRA] (WFCORE-5015) Create 'core-specific' variants of Galleon feature groups and packages that are 'overridden' in full WildFly
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-5015?page=com.atlassian.jira.plug... ]
Brian Stansberry updated WFCORE-5015:
-------------------------------------
Fix Version/s: 13.0.0.Beta2
> Create 'core-specific' variants of Galleon feature groups and packages that are 'overridden' in full WildFly
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5015
> URL: https://issues.redhat.com/browse/WFCORE-5015
> Project: WildFly Core
> Issue Type: Task
> Components: Build System
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 13.0.0.Beta2
>
>
> See [https://lists.jboss.org/pipermail/wildfly-dev/2020-June/007342.html... background.
> For the wildfly-core galleon pack feature groups and packages that are 'overridden' in full WildFly, create a differently named variant in the galleon-common module that can be referenced in full WF. This eliminates the 'overriding/subclassing' and in a GAL-319 type future setup will allow the 'core' source item to be directly incorporated in the target FP in full without conflicting with an item with the same name in that target FP.
>
> Feature groups:
>
> domain-host-excludes
> domain-interfaces
> domain-profile
> host-master
> host-slave
> host
> standalone-profile
>
> Packages:
> bin.common
> bin.vaulttools
> docs.licenses.merge
> misc.common
> misc.domain
> misc.standalone
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5036) Improve support for conditionally-defined capabilities
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-5036?page=com.atlassian.jira.plug... ]
Richard Achmatowicz updated WFCORE-5036:
----------------------------------------
Description:
Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request.
Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally registered, we can use OperationContext.hasOptionalCapability() to check if it is actually registered. So consuming is easy but setting up is hard.
Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration.
Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK.
This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier.
FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate.
was:
Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request.
Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally defined, we can use OperationContext.hasOptionalCapability() to check if it is defined. So consuming is easy but setting up is hard.
Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration.
Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK.
This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier.
FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate.
> Improve support for conditionally-defined capabilities
> ------------------------------------------------------
>
> Key: WFCORE-5036
> URL: https://issues.redhat.com/browse/WFCORE-5036
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Richard Achmatowicz
> Assignee: Jeff Mesnil
> Priority: Major
>
> Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request.
> Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally registered, we can use OperationContext.hasOptionalCapability() to check if it is actually registered. So consuming is easy but setting up is hard.
> Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration.
> Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK.
> This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier.
> FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate.
>
>
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5036) Improve support for conditionally-defined capabilities
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFCORE-5036:
-------------------------------------------
Summary: Improve support for conditionally-defined capabilities
Key: WFCORE-5036
URL: https://issues.redhat.com/browse/WFCORE-5036
Project: WildFly Core
Issue Type: Feature Request
Components: Management
Reporter: Richard Achmatowicz
Assignee: Jeff Mesnil
Not sure if this is a (useability) bug or a feature request, so I have marked it as a feature request.
Implementing capabilities which represent a resource associated with an attribute which may or may not need to be defined is problematic, as once the capability is defined in the resource, we need to do custom registration and custom de-registration based on whether the condition holds or not. Custom registration needs to happen in the add handler for the resource as well as write handler for the attribute. Custom de-registration needs to happen in the remove handler and is complicated by the fact that de-registration of resources happens before de-registration of capabilities (should be the other way around?). Once this capability is conditionally defined, we can use OperationContext.hasOptionalCapability() to check if it is defined. So consuming is easy but setting up is hard.
Here is an example. EJB3SubsystemRootResourceDefinition has an attribute called default-slsb-instance-pool which gives the name of a defined strict-max-pool instance to be used as a default value for SLSBs. This attribute has no default and may be defined or not. When it is defined, it is used to generate a service name and that service name is added as a dependency for SLSBs which have no custom pool specified in their configuration.
Defining and registering the capability based on whether the attribute is defined or not leads to the problems described above, AFAIK.
This is not an uncommon use case; it would be nice if defining capabilities for such optional attributes were easier.
FYI: The clustering subsystem runs into this issue quite often and has worked around the problem by associating predicates with capabilities which can be used at registration time to see if a capability should be defined by evaluating the predicate.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13646) [GSS](7.3.z) Exception while exporting metrics during WildFly initialization
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-13646:
-----------------------------------
Summary: [GSS](7.3.z) Exception while exporting metrics during WildFly initialization
Key: WFLY-13646
URL: https://issues.redhat.com/browse/WFLY-13646
Project: WildFly
Issue Type: Bug
Components: MP Metrics
Affects Versions: 18.0.1.Final, 19.0.0.Beta2
Reporter: Brad Maxwell
Assignee: Brian Stansberry
When the open tracing system is enabled and some metrics are exposed, if when the WildFly is in the startup process, the Prometheus server calls the /metrics endpoint, WildFly prints a stacktrace for each metrics that is has detected (i.e. more than thousands) with the following message:
*WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available
*
In some cases the error persists, even after the server startup is done and we need to restart the WildFly; but we couldn't find the exact scenario for that.
Here is an example for wildfly_jpa_second_level_cache_size_in_memory metric:
{code}
2020-03-02 09:38:06,739 WARN [management I/O-2] [metrics] Unable to export metric wildfly_jpa_second_level_cache_size_in_memory: java.lang.IllegalStateException: WFLYMETRICS0003: Unable to read attribute second-level-cache-size-in-memory on [
("deployment" => "application.ear"),
("subdeployment" => "application-persistence.jar"),
("subsystem" => "jpa"),
("hibernate-persistence-unit" => "application.ear/application-persistence.jar#app"),
("entity-cache" => "com.app.persistence.entity.Country")
]: "WFLYCTL0379: System boot is in process; execution of remote management operations is not currently available".
at org.wildfly.extension.microprofile.metrics.MetricCollector.readAttributeValue(MetricCollector.java:303)
at org.wildfly.extension.microprofile.metrics.MetricCollector.access$200(MetricCollector.java:70)
at org.wildfly.extension.microprofile.metrics.MetricCollector$2.getValue(MetricCollector.java:174)
at org.wildfly.extension.microprofile.metrics.MetricCollector$2.getValue(MetricCollector.java:171)
at io.smallrye.metrics.exporters.OpenMetricsExporter.createSimpleValueLine(OpenMetricsExporter.java:445)
at io.smallrye.metrics.exporters.OpenMetricsExporter.exposeEntries(OpenMetricsExporter.java:178)
at io.smallrye.metrics.exporters.OpenMetricsExporter.getEntriesForScope(OpenMetricsExporter.java:150)
at io.smallrye.metrics.exporters.OpenMetricsExporter.exportAllScopes(OpenMetricsExporter.java:101)
at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:116)
at io.smallrye.metrics.MetricsRequestHandler.handleRequest(MetricsRequestHandler.java:73)
at org.wildfly.extension.microprofile.metrics.MetricsContextService$1.handleRequest(MetricsContextService.java:81)
at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:666)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:59)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2315) ASYM_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/JGRP-2315?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated JGRP-2315:
-------------------------------
Summary: ASYM_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures (was: ASYNC_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures)
> ASYM_ENCRYPT: Race condition in cipher queue usage can cause message decryption failures
> ----------------------------------------------------------------------------------------
>
> Key: JGRP-2315
> URL: https://issues.redhat.com/browse/JGRP-2315
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 4.0.16
>
>
> If a message is received that needs to be decrypted, or if a message need to be encrypted, a cipher is taken from the queue. However, if a new coordinator concurrently sends a new secret key, it will clear and recreate the cipher queues. If the previous operation then puts its cipher back on the queue, the queue will now contain a cipher with the old secret key. This will result in random message decryption failures when a message encryption/decryption pulls the outdated cipher from the queue.
> While this is mitigated somewhat by the caching of old cipher versions, newly joined members do not have the ability to read messages encrypted by outdated ciphers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13645) Provide a set of EAP XP QuickStarts that can run on OpenShift
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13645?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13645:
-----------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly-proposals/pull/321)
> Provide a set of EAP XP QuickStarts that can run on OpenShift
> --------------------------------------------------------------
>
> Key: WFLY-13645
> URL: https://issues.redhat.com/browse/WFLY-13645
> Project: WildFly
> Issue Type: Feature Request
> Components: Quickstarts
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Major
>
> The Quickstarts distributed in JBoss EAP XP should be made compatible with JBoss EAP XP Openshift images and templates.
> Please note that JBoss EAP XP Quickstarts, to be considered Openshift compatible, goes beyond “it is deployed to Openshift without errors”, and “all functionality works when running on Openshift”, the documentation of such Quickstarts also need to include the *supported* Openshift usage instructions (specific asciidoc sections which QE tests), similar to the ones included with JBoss EAP CD Quickstarts.
> Also similar to JBoss EAP CD releases, a live branch of JBoss EAP XP Quickstarts for Openshift should be prepared at the JBoss Developer source repository, which the JBoss EAP XP OpenShift Templates should point to, so users may easily discovery and create new projects with JBoss EAP XP Quickstarts.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13438) Database Timers: instances sporadically fail to start in a cluster
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13438?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13438:
-----------------------------------
[~marcos-scholtz] I tried to reproduce it with WildFly 20.0.0.Final, but couldn't reproduce it. I restarted the 3-server server group (with full-ha profile) many times without seeing the "reinstate timer" errors.
Did you configure the timer data store with proper transaction isolation level (READ_COMMITTED or SERIALIZABLE)?
https://docs.wildfly.org/20/Developer_Guide.html#EJB3_Clustered_Database_...
> Database Timers: instances sporadically fail to start in a cluster
> ------------------------------------------------------------------
>
> Key: WFLY-13438
> URL: https://issues.redhat.com/browse/WFLY-13438
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.1.0.Final
> Reporter: Marcos Scholtz
> Assignee: Cheng Fang
> Priority: Major
>
> We use a postgresql database for persistent timers, to control the execution of scheduled tasks in a cluster. It mainly works, but when operating in a cluster and when a server-group is restarted, sometimes individual instances in the cluster fail to start because of an error when reinstating persistent timers.
> Configuration of the Datasource:
> {code}
> <xa-datasource jndi-name="java:/datasources/MonitoringDS" pool-name="MonitoringDS" enabled="true">
> <xa-datasource-property name="ServerName">
> appserver.local
> </xa-datasource-property>
> <xa-datasource-property name="PortNumber">
> 5432
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> monitoringdb
> </xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgresql</driver>
> <security>
> <user-name>xxx</user-name>
> <password>xxx</password>
> </security>
> </xa-datasource>
> {code}
> Configuration of the timer service:
> {code}
> <timer-service thread-pool-name="default" default-data-store="batch-clustered-store">
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> <database-data-store name="batch-clustered-store" datasource-jndi-name="java:/datasources/MonitoringDS" database="'postgresql'" partition="${batch.partition}" refresh-interval="60000" allow-execution="true"/>
> </data-stores>
> </timer-service>
> {code}
> Note we use a system-property on the server-group to determine the partition name.
> Also, we made NO changes to the SQL statements in "timer-sql.properties".
> The timer is generated by a `@Schedule` annotation in an EJB like this:
> {code}
> @Schedule(
> dayOfMonth = "${manual.scheduler.dayofmonth:*}",
> dayOfWeek = "${manual.scheduler.dayofweek:*}",
> hour = "${manual.scheduler.hour:2/6}",
> minute = "${manual.scheduler.minute:2}"
> )
> @TransactionAttribute(TransactionAttributeType.NEVER)
> void doPostboxImport() {
> log.info("Starting Postbox Import");
> BatchRuntime.getJobOperator().start("PostboxImportBatchlet", null);
> }
> {code}
> The error we sporadically get when starting more than one instance at the same time (when all instances try to reinstate timers) is like this:
> {code}
> 14:48:28,117 WARN [com.arjuna.ats.arjuna] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} ARJUNA012078: Abort called illegaly on atomic action 0:ffff7f000001:-27f2652e:5eb2b20f:f
> 14:48:28,118 WARN [org.jboss.as.ejb3.timer] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} WFLYEJB0161: Failed to reinstate timer 'postbox-integration-service.postbox-integration-service.PostboxImport' (id=unavailable) from its persistent state: javax.transaction.NotSupportedException: WFTXN0001: A transaction is already in progress
> at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:60)
> at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:54)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:984)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:712)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 14:48:28,153 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} MSC000001: Failed to start service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: java.lang.RuntimeException: java.lang.NullPointerException
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:626)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:537)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.loadAutoTimer(TimerServiceImpl.java:388)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:774)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:336)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
> ... 16 more
> {code}
> The error seems similar to the one described in WFLY-13386, but the stack trace and the steps to reproduce it seem different to me, so I'm not sure if it's the same problem. The problem also existed in Wildfly 14 , we just updated to 19.1 (also hoping that his error would be corrected).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server
by Dmitrii Pogorelov (Jira)
[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ]
Dmitrii Pogorelov updated WFLY-13144:
-------------------------------------
Description:
The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
{code}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
was:
The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
{code:noformat}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
> Resource Adapter can't be deleted after restarting server
> ---------------------------------------------------------
>
> Key: WFLY-13144
> URL: https://issues.redhat.com/browse/WFLY-13144
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final
> Reporter: Dmitrii Pogorelov
> Assignee: Ivo Studensky
> Priority: Critical
> Attachments: jca-demo-1.0.rar, jcademo-source-code.rar
>
>
> The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
> "rolled-back" => true
> }
> {code}
> After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13144) Resource Adapter can't be deleted after restarting server
by Dmitrii Pogorelov (Jira)
[ https://issues.redhat.com/browse/WFLY-13144?page=com.atlassian.jira.plugi... ]
Dmitrii Pogorelov updated WFLY-13144:
-------------------------------------
Steps to Reproduce:
All steps were performed on WildFly 11.0.0.Final but the bug can be also reproduced on WildFly 14.0.1.Final and WildFly 17.0.1.Final (haven't checked newest versions of WildFly yet).
1. I developed a very simple connector which was actually taken from [https://github.com/fmarchioni/mastertheboss/tree/master/jca-demo] (I attached source code of the jca in scope of the issue), compiled it and got the jca-demo-1.0.rar archive.
2. put the jca-demo-1.0.rar archive to deployments folder.
3. start the server.
4. after deploying the jca-demo-1.0.rar run the following cli commands:
{code}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:add(archive=jca-demo-1.0.rar, transaction-support=NoTransaction)
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1/connection-definitions=jcaDemo_VDB_ID_1:add(jndi-name=java:/jcaDemo_VDB_ID_1, enabled=true, class-name=com.sample.adapter.HelloWorldManagedConnectionFactory, min-pool-size=0, max-pool-size=20){allow-resource-service-restart=true}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:activate
{code}
in server.log you can see the following (the log was taken from WildFly 11.0.0.Final):
{code}
2020-02-20 12:03:33,103 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,115 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-5) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:03:33,121 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,123 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-6) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
5. if you try to run the cli command before restarting the server:
{code}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
in the server.log you will see the following:
{code}
2020-02-20 12:03:51,146 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
6. if you removed the resource adapter during the 5. step and before restarting the server, please, repeat the 4. step to create the resource adapter again.
7. restart the server.
8. try to run the cli command:
{code}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
the server will generate the following lines in the server.log:
{code}
2020-02-20 12:05:43,653 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0070: Deployment restart detected for deployment jca-demo-1.0.rar, performing full redeploy instead. 2020-02-20 12:05:43,693 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment jca-demo-1.0.rar (runtime-name: jca-demo-1.0.rar) in 35ms 2020-02-20 12:05:43,698 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "jca-demo-1.0.rar" (runtime-name: "jca-demo-1.0.rar") 2020-02-20 12:05:44,130 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,139 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,154 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:05:44,161 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,171 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
at the same time the "remove" cli command will return the following response:
{code}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
was:
All steps were performed on WildFly 11.0.0.Final but the bug can be also reproduced on WildFly 14.0.1.Final and WildFly 17.0.1.Final (haven't checked newest versions of WildFly yet).
1. I developed a very simple connector which was actually taken from https://github.com/fmarchioni/mastertheboss/tree/master/jca-demo (I attached source code of the jca in scope of the issue), compiled it and got the jca-demo-1.0.rar archive.
2. put the jca-demo-1.0.rar archive to deployments folder.
3. start the server.
4. after deploying the jca-demo-1.0.rar run the following cli commands:
{code:noformat}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:add(archive=jca-demo-1.0.rar, transaction-support=NoTransaction)
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1/connection-definitions=jcaDemo_VDB_ID_1:add(jndi-name=java:/jcaDemo_VDB_ID_1, enabled=true, class-name=com.sample.adapter.HelloWorldManagedConnectionFactory, min-pool-size=0, max-pool-size=20){allow-resource-service-restart=true}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:activate
{code}
in server.log you can see the following (the log was taken from WildFly 11.0.0.Final):
{code:noformat}
2020-02-20 12:03:33,103 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,115 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-5) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:03:33,121 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-5) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/temp840fa23b95ebcc91/content-85ce6bdbfce5b3b5/contents/ 2020-02-20 12:03:33,123 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-6) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
5. if you try to run the cli command before restarting the server:
{code:noformat}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
in the server.log you will see the following:
{code:noformat}
2020-02-20 12:03:51,146 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0011: Unbound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
6. if you removed the resource adapter during the 5. step and before restarting the server, please, repeat the 4. step to create the resource adapter again.
7. restart the server.
8. try to run the cli command:
{code:noformat}
/subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{code}
the server will generate the following lines in the server.log:
{code:noformat}
2020-02-20 12:05:43,653 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0070: Deployment restart detected for deployment jca-demo-1.0.rar, performing full redeploy instead. 2020-02-20 12:05:43,693 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0028: Stopped deployment jca-demo-1.0.rar (runtime-name: jca-demo-1.0.rar) in 35ms 2020-02-20 12:05:43,698 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "jca-demo-1.0.rar" (runtime-name: "jca-demo-1.0.rar") 2020-02-20 12:05:44,130 INFO [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,139 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020001: Required license terms for file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,154 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0007: Registered connection factory java:/jcaDemo_VDB_ID_1 2020-02-20 12:05:44,161 INFO [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-3) IJ020002: Deployed: file:/C:/DataVirtuality/wildfly-11.0.0.Final/standalone/tmp/vfs/temp/tempa8f374a95f0436c6/content-72dc113b1d3ebdfb/contents/ 2020-02-20 12:05:44,171 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-3) WFLYJCA0002: Bound JCA ConnectionFactory [java:/jcaDemo_VDB_ID_1]
{code}
at the same time the "remove" cli command will return the following response:
{code:noformat}
[standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
"rolled-back" => true
}
{code}
> Resource Adapter can't be deleted after restarting server
> ---------------------------------------------------------
>
> Key: WFLY-13144
> URL: https://issues.redhat.com/browse/WFLY-13144
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 14.0.1.Final, 11.0.0.Final, 17.0.1.Final
> Reporter: Dmitrii Pogorelov
> Assignee: Ivo Studensky
> Priority: Critical
> Attachments: jca-demo-1.0.rar, jcademo-source-code.rar
>
>
> The issue is related to the WFLY-6774 issue. I'm working with Teiid and should create/delete resource adapters many times, especially resource adapters based on the same archive. The WFLY-6774 fix works well before the restarting server allowing me to create/delete resource adapters without restarting the server. Once I restart the server and try to remove a resource adapter based on an archive I'll get the following error:
> {code}
> [standalone@localhost:9990 /] /subsystem=resource-adapters/resource-adapter=jcaDemo_VDB_ID_1:remove{allow-resource-service-restart=true}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.resourceadapters.ra.jcaDemo_VDB_ID_1 was depended upon by service jboss.deployment.unit.\"jca-demo-1.0.rar\".INSTALL",
> "rolled-back" => true
> }
> {code}
> After showing the error server will rollback the "remove" command deploying the jca-demo-1.0.rar archive again and re-creating the jcaDemo_VDB_ID_1 resource adapter. As a result I can't remove the resource adapter via cli commands, it can be removed only manually (removing the resource adapter in standalone.xml). The bug can be reproduced (at least versions which I checked) on WildFly 11.0.0.Final, WildFly 14.0.1.Final and WildFly 17.0.1.Final.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months