[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1330:
-------------------------------------------
It seems that the ContenRepositoryCleaner might be executing after the shutdown, keeping the ExecutorService running.
We need to properly 'lock' the ContentRepository once its service is stopped.
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Attachments: server.log, server.log
>
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet updated WFCORE-1330:
--------------------------------------
Forum Reference: https://developer.jboss.org/message/970763, https://developer.jboss.org/thread/269789 (was: https://developer.jboss.org/message/956219#956219)
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Attachments: server.log, server.log
>
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1225) Add options to specify the salience range of rules in a Decision Table Sheet
by Osamu Kuniyasu (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1225?page=com.atlassian.jira.plugi... ]
Osamu Kuniyasu commented on DROOLS-1225:
----------------------------------------
Hi, Mario, Yes, correct.
> Add options to specify the salience range of rules in a Decision Table Sheet
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1225
> URL: https://issues.jboss.org/browse/DROOLS-1225
> Project: Drools
> Issue Type: Feature Request
> Components: decision tables
> Affects Versions: 6.4.0.Final
> Environment: any
> Reporter: Osamu Kuniyasu
> Assignee: Mario Fusco
> Fix For: 7.0.0.Final
>
>
> When we set Sequential=true in RuleSet properties.
> The salience of the generated rules are started from 65518 and down one by one.
> When we mix several Decision Table Sheets and DRL rules in a Ruleflow-Group (Agenda-Group), We could not make these rules' salience order, because each Decision Table Sheet has fixed to start from 65518.
> A (limited) workaround is to have separated Ruleflow-Groups,
> But this way does not solve the situation to back to the higher priority rules as it's previous Ruleflow-Group.
> To solve The request is that add two options into RuleSet properties. like,
> SequentialMaxPriority 10000
> SequentialMinPriority 1000
> By this optional properties, we can control the range of the salience of rules in the Decision Table Sheet. and it is possible safely to mix multiple Decision Table Sheets in a Ruleflow-Group.
> The SequentialMaxPriority is used to set the start value of the salience instead of 65518.
> The SequentialMinPriority is used to check if this minimum salience value is not violated in the Decision Table Compiler. (if it's violated, compilation error occurs.)
> Best Regards,
> Osamu Kuniyasu
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (DROOLS-1225) Add options to specify the salience range of rules in a Decision Table Sheet
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1225?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1225:
-------------------------------------
Hi [~kuniyasu], if I'm understanding correctly what you're asking here is adding those new SequentialMaxPriority and SequentialMinPriority optional fields in the "RuleSet" section of the XLS for each sheet and setting the salience of the generated rules accordingly. Can you confirm?
> Add options to specify the salience range of rules in a Decision Table Sheet
> ----------------------------------------------------------------------------
>
> Key: DROOLS-1225
> URL: https://issues.jboss.org/browse/DROOLS-1225
> Project: Drools
> Issue Type: Feature Request
> Components: decision tables
> Affects Versions: 6.4.0.Final
> Environment: any
> Reporter: Osamu Kuniyasu
> Assignee: Mario Fusco
> Fix For: 7.0.0.Final
>
>
> When we set Sequential=true in RuleSet properties.
> The salience of the generated rules are started from 65518 and down one by one.
> When we mix several Decision Table Sheets and DRL rules in a Ruleflow-Group (Agenda-Group), We could not make these rules' salience order, because each Decision Table Sheet has fixed to start from 65518.
> A (limited) workaround is to have separated Ruleflow-Groups,
> But this way does not solve the situation to back to the higher priority rules as it's previous Ruleflow-Group.
> To solve The request is that add two options into RuleSet properties. like,
> SequentialMaxPriority 10000
> SequentialMinPriority 1000
> By this optional properties, we can control the range of the salience of rules in the Decision Table Sheet. and it is possible safely to mix multiple Decision Table Sheets in a Ruleflow-Group.
> The SequentialMaxPriority is used to set the start value of the salience instead of 65518.
> The SequentialMinPriority is used to check if this minimum salience value is not violated in the Decision Table Compiler. (if it's violated, compilation error occurs.)
> Best Regards,
> Osamu Kuniyasu
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8610) Incorrect time unit in description of attribute slow-consumer-check-period
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-8610?page=com.atlassian.jira.plugin.... ]
Ingo Weiss moved JBEAP-10461 to WFLY-8610:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8610 (was: JBEAP-10461)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: (was: 7.1.0.DR14)
> Incorrect time unit in description of attribute slow-consumer-check-period
> --------------------------------------------------------------------------
>
> Key: WFLY-8610
> URL: https://issues.jboss.org/browse/WFLY-8610
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
>
> Slow consumer check period is configured in seconds. However, description of attribute {{slow-consumer-check-period}} says it is configured in minutes.
> {noformat}/subsystem=messaging-activemq/server=default/address-setting=#:read-resource-description{noformat}
> {panel}
> ....
> "slow-consumer-check-period" => {
> "type" => LONG,
> "description" => "How often to check for slow consumers on a particular queue.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => 5L,
> {color:#d04437}"unit" => "MINUTES",{color}
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> ....
> {panel}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years