[JBoss JIRA] (WFLY-5858) Testsuite on windows sometimes fails with file locks on standalone-*.xml
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5858?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-5858.
-------------------------------
Resolution: Done
> Testsuite on windows sometimes fails with file locks on standalone-*.xml
> -------------------------------------------------------------------------
>
> Key: WFLY-5858
> URL: https://issues.jboss.org/browse/WFLY-5858
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 10.0.0.CR3
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 10.1.0.Final
>
>
> ModelPersistenceTestCase.testSimpleOperation occasionally fails with the following pattern:
> {code}
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at org.jboss.as.test.integration.management.api.ModelPersistenceTestCase.testSimpleOperation(ModelPersistenceTestCase.java:119)
> ------- Stdout: -------
> 14:06:18,604 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0081: Failed to back up C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml
> at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:552)
> at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:65)
> at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:780)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:207)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:129)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:151)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:147)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:147)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:299)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:519)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.nio.file.FileSystemException: C:\BuildAgent\work\a31d203e70e89f90\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone_xml_history\standalone.last.xml: The process cannot access the file because it is being used by another process.
> at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> at sun.nio.fs.WindowsFileCopy.copy(WindowsFileCopy.java:165)
> at sun.nio.fs.WindowsFileSystemProvider.copy(WindowsFileSystemProvider.java:278)
> at java.nio.file.Files.copy(Files.java:1274)
> at org.jboss.as.controller.persistence.FilePersistenceUtils.copyFile(FilePersistenceUtils.java:73)
> at org.jboss.as.controller.persistence.ConfigurationFile.fileWritten(ConfigurationFile.java:550)
> ... 23 more
> {code}
> The test fails because the standalone.last.xml file isn't being updated as expected; the file isn't updated due to the "The process cannot access the file because it is being used by another process" IOException.
> 3 generally possibilities come to mind:
> 1) There's some other process on the CI server that really is using the file. Something like antivirus that touches lots of files briefly. (Not suggesting its actually AV.) It's odd we don't get other failures though; e.g. failures to persist the main config file.
> 2) It's the test driver process that's holding the file, conflicting with the server process. This is certainly possible. I've looked though and the test driver seems to be correct in terms of how it handles the file, reading it to calculate a CRC and then closing the stream used to do that in a finally block. It's also odd that this would only happen on Windows CI. Still, since we know we have 2 processes, test driver and server, both touching a file and we are getting an exception about 2 processes conflicting over that file, something in this area seems most likely.
> 3) There's some flaw in ConfigurationFile itself. But it's odd that a flaw there would produce an exception talking about how the file "is being used by another process".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1197) Enhance missing capability logging during subsystem testing
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1197?page=com.atlassian.jira.plugi... ]
Tomaz Cerar resolved WFCORE-1197.
---------------------------------
Fix Version/s: 3.0.0.Alpha3
(was: 3.0.0.Alpha4)
Resolution: Done
This was already fixed if you still see it, please reopen.
> Enhance missing capability logging during subsystem testing
> -----------------------------------------------------------
>
> Key: WFCORE-1197
> URL: https://issues.jboss.org/browse/WFCORE-1197
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Test Suite
> Affects Versions: 2.0.4.Final
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha3
>
>
> Making changes to the Undertow subsystem I was presented with the following failure: -
> {noformat}
> <testcase name="testRuntime" classname="org.wildfly.extension.undertow.UndertowSubsystemTestCase" time="1.611">
> <error type="java.lang.NullPointerException:">java.lang.NullPointerException: null
> at org.wildfly.extension.undertow.UndertowSubsystemTestCase.testRuntime(UndertowSubsystemTestCase.java:118)
> {noformat}
> It was only after enabling other logging I found the real cause: -
> {noformat}
> ec 08, 2015 6:19:22 PM org.jboss.as.controller.OperationContextImpl validateCapabilities
> ERROR: WFLYCTL0362: Capabilities required by resource '/subsystem=undertow/application-security-domain=other' are not available:
> org.wildfly.security.http-server-mechanism-factory.elytron-factory; There are no known registration points which can provide this capability.
> {noformat}
> The NullPointerException above is because it is detected the booting failed but the error was never made available.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ]
Matteo Mortari closed DROOLS-1215.
----------------------------------
Resolution: Won't Fix
> import function(s) with collision on declared Pojo field names odd behavior and no warning
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-1215
> URL: https://issues.jboss.org/browse/DROOLS-1215
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: DROOLS-1215.zip
>
>
> Hello,
> not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype:
> {code}
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> WantToKeep( condition == "color" )
> Measurement( id == "color", $colorVal : val )
> then
> controlSet.add($colorVal);
> end
> declare WantToKeep
> condition : String
> end
> rule "kickstart"
> salience 999
> when
> eval( true )
> then
> insert(new WantToKeep( "color" ));
> end
> {code}
> This works as expected until adding the following import statement:
> {code}
> import function org.jooq.impl.DSL.*;
> {code}
> and then the test will fail.
> I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form.
> I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking.
> I will attach reproducer and workaround in the appropriate sections.
> Thank you,
> Ciao,
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1215:
----------------------------------------
This is not strictly related to Drools issue and more MVEL related.(in details, this is related to the order by which MVEL would resolve between imports, variables and fields, both during compilation phase and evaluation phase).
Given workarounds do exist and are effective, will close as won't fix.
Other identified workarounds (beside the original one noted above):
* in the LHS, call the getter by explicit method instead of mvel style, i.e.: avoid {{WantToKeep( condition ...}} and use {{WantToKeep( getCondition() ...}} instead.
* in the use-case presented in this reproducer, the import-star is used to enable all the (jOOQ's) DSL methods. Instead of using the import-star, do import only those DSL methods really required to avoid name conflict.
* in the use-case presented in this reproducer, use separation of concern, and keep the (jOOQ's) DSL usage in a separate DRL file, or even better refactor the (jOOQ's) DSL code into a dedicated Java class
> import function(s) with collision on declared Pojo field names odd behavior and no warning
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-1215
> URL: https://issues.jboss.org/browse/DROOLS-1215
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: DROOLS-1215.zip
>
>
> Hello,
> not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype:
> {code}
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> WantToKeep( condition == "color" )
> Measurement( id == "color", $colorVal : val )
> then
> controlSet.add($colorVal);
> end
> declare WantToKeep
> condition : String
> end
> rule "kickstart"
> salience 999
> when
> eval( true )
> then
> insert(new WantToKeep( "color" ));
> end
> {code}
> This works as expected until adding the following import statement:
> {code}
> import function org.jooq.impl.DSL.*;
> {code}
> and then the test will fail.
> I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form.
> I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking.
> I will attach reproducer and workaround in the appropriate sections.
> Thank you,
> Ciao,
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1215) import function(s) with collision on declared Pojo field names odd behavior and no warning
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1215?page=com.atlassian.jira.plugi... ]
Matteo Mortari reassigned DROOLS-1215:
--------------------------------------
Assignee: Matteo Mortari (was: Mario Fusco)
> import function(s) with collision on declared Pojo field names odd behavior and no warning
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-1215
> URL: https://issues.jboss.org/browse/DROOLS-1215
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: DROOLS-1215.zip
>
>
> Hello,
> not sure (yet) what is causing this odd behavior, but considering the following rule-base in the attached reproducer, evolved from the usual kie example archetype:
> {code}
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> WantToKeep( condition == "color" )
> Measurement( id == "color", $colorVal : val )
> then
> controlSet.add($colorVal);
> end
> declare WantToKeep
> condition : String
> end
> rule "kickstart"
> salience 999
> when
> eval( true )
> then
> insert(new WantToKeep( "color" ));
> end
> {code}
> This works as expected until adding the following import statement:
> {code}
> import function org.jooq.impl.DSL.*;
> {code}
> and then the test will fail.
> I suspect because some "functions"/static method exists on {{org.jooq.impl.DSL}} with name "condition" which is colliding with the declared Pojo field name "condition", but I can't understand why this supposed collision happens as in the LHS I'm looking for the field not a method invocation with the {{condition()}} form.
> I'm willing to investigate more on this later, for the time being I thought worthy at least to raise this JIRA record for tracking.
> I will attach reproducer and workaround in the appropriate sections.
> Thank you,
> Ciao,
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1231) Container is not upgraded until restarted
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1231?page=com.atlassian.jira.plugi... ]
Maciej Swiderski moved RHBPMS-4111 to DROOLS-1231:
--------------------------------------------------
Project: Drools (was: JBoss BPMS Platform)
Key: DROOLS-1231 (was: RHBPMS-4111)
Workflow: GIT Pull Request workflow (was: CDW v1)
Docs QE Status: NEW
Component/s: core engine
kie server
(was: Kie-Server)
Affects Version/s: 7.0.0.Beta1
(was: 6.3.0.GA)
QE Status: NEW
> Container is not upgraded until restarted
> -----------------------------------------
>
> Key: DROOLS-1231
> URL: https://issues.jboss.org/browse/DROOLS-1231
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 7.0.0.Beta1
> Reporter: Maciej Swiderski
> Assignee: Mario Fusco
>
> If you create a container, and then upgrade it to a higher kjar version - the resources (processes, rules) are not actually upgraded until you STOP/START this container
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months