[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Dimitris Andreadis updated AS7-2392: ------------------------------------ Attachment: TEST-org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase.xml Attached the surefire report -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Jason Greene updated AS7-2392: ------------------------------ Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) Moving all non-critical issues to the CR. If you finish it before we release beta please correct the fix-for version. Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Stuart Douglas commented on AS7-2392: ------------------------------------- This path is built in org.jboss.as.ejb3.deployment.processors.TimerServiceDeploymentProcessor.addTimerService, and I don't have a windows machine handy to test. It looks like DeploymentUnit.getName() is returning the wrong value, but I am not sure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Dimitris Andreadis commented on AS7-2392: ----------------------------------------- I don't think I see the failure happening anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Thomas Diesler commented on AS7-2392: ------------------------------------- Now seeing {code} 18:31:03,058 ERROR [org.jboss.as.ee.deployment.spi] (main) JBAS016151: Deployment validation failed: java.io.IOException: JBAS016157: Cannot delete existing deployment: C:\DOCUME~1\hudson\LOCALS~1\Temp\deployment-app.ear at org.jboss.as.ee.deployment.spi.DeploymentManagerImpl.createDeployment(DeploymentManagerImpl.java:474) at org.jboss.as.ee.deployment.spi.DeploymentManagerImpl.doDistribute(DeploymentManagerImpl.java:354) at org.jboss.as.ee.deployment.spi.DeploymentManagerImpl.distribute(DeploymentManagerImpl.java:326) at org.jboss.as.test.smoke.jsr88.EnterpriseDeploymentTestCase.jsr88Deploy(EnterpriseDeploymentTestCase.java:290) at org.jboss.as.test.smoke.jsr88.EnterpriseDeploymentTestCase.testListAvailableModules(EnterpriseDeploymentTestCase.java:175) {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reassigned AS7-2392: ----------------------------------- Assignee: Brian Stansberry (was: Thomas Diesler) Assigning to Brian for review -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-2392: -------------------------------- Description: I get there consistent test failures on win7 in the integration testsuite: {code} Failed tests: testDistributeEjbApp(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase): expected:<Completed> but was:<Failed> testDistributeEARApp(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase): expected:<Completed> but was:<Failed> testListAvailableModules(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase) By looking in the logs, I think the problem is traced back to this deployment problem that affects all failures: Caused by: java.lang.RuntimeException: Could not create timer file store directory X:\src\jboss-as\testsuite\integration\target\smoke\standalone\data\timer-service-data\file:\C:\Users\dimitris\AppData\Local\Temp\deployment-ejb.jar at org.jboss.as.ejb3.timerservice.mk2.persistence.filestore.FileTimerPersistence.start(FileTimerPersistence.java:101) at org.jboss.as.ejb3.timerservice.TimerServiceFactoryService.start(TimerServiceFactoryService.java:77) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] ... 3 more {code} It concatenates the testsuite target dir with the user's temp dir.? Looking quickly I couldn't find where the path to this file is created. Maybe it's a ShrinkWrap issue? was: I get there consistent test failures on win7 in the integration testsuite: Failed tests: testDistributeEjbApp(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase): expected:<Completed> but was:<Failed> testDistributeEARApp(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase): expected:<Completed> but was:<Failed> testListAvailableModules(org.jboss.as.test.smoke.embedded.deployment.EnterpriseDeploymentTestCase) By looking in the logs, I think the problem is traced back to this deployment problem that affects all failures: Caused by: java.lang.RuntimeException: Could not create timer file store directory X:\src\jboss-as\testsuite\integration\target\smoke\standalone\data\timer-service-data\file:\C:\Users\dimitris\AppData\Local\Temp\deployment-ejb.jar at org.jboss.as.ejb3.timerservice.mk2.persistence.filestore.FileTimerPersistence.start(FileTimerPersistence.java:101) at org.jboss.as.ejb3.timerservice.TimerServiceFactoryService.start(TimerServiceFactoryService.java:77) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA] ... 3 more It concatenates the testsuite target dir with the user's temp dir.? Looking quickly I couldn't find where the path to this file is created. Maybe it's a ShrinkWrap issue? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Thomas Diesler edited comment on AS7-2392 at 1/12/12 3:56 AM: -------------------------------------------------------------- What happens is that the JSR88 layer generates a tmp file and passes the URL to which to the AS7 management API. During the building of the ADD step an InputStream for that URL is opened and stored as content to the ADD step. When deployment is done, the JSR88 layer attempts to delete the tmp file, which fails w2k8 presumably because the associated input stream is not closed. See the client [test log file|https://hudson.qa.jboss.com/hudson/view/JBossOSGi/job/jboss-as7-as23...] and search for deployment-app.ear. {code} 03:19:18,396 INFO [org.jboss.as.ee.deployment.spi] (Thread-179) JBAS016101: End deploy: [target=http://org.jboss.as.ee.deployment/jsr88?targetType=as7,parent=null,type=ear,id=file:/C:/DOCUME~1/hudson/LOCALS~1/Temp/deployment-app.ear] 03:19:18,397 WARN [org.jboss.as.ee.deployment.spi] (Thread-179) JBAS016103: Cannot delete deployment file C:\DOCUME~1\hudson\LOCALS~1\Temp\deployment-app.ear, will be deleted on exit {code} This particular test fails because it tries to deploy the same EAR twice, but cannot use the same tmp file name. In branch [as2392|https://github.com/tdiesler/jboss-as/tree/as2392] I implemented a workaround that assigns a different tmp file name when it already exists and cannot be deleted. The underlying issue IMHO is however in the AS7 deployment layer and its handling of input streams associated with user provided URLs. This should be a general issue for all management clients running on w2k8 was (Author: thomas.diesler): What happens is that the JSR88 layer generates a tmp file and passes the URL to which to the AS7 management API. During the building of the ADD step an InputStream for that URL is opened and stored as content to the ADD step. When deployment is done, the JSR88 layer attempts to delete the tmp file. The tmp file cannot be deleted on w2k8, presumably because the associated input stream is not closed. See the client [test log file|https://hudson.qa.jboss.com/hudson/view/JBossOSGi/job/jboss-as7-as23...] and search for deployment-app.ear. {code} 03:19:18,396 INFO [org.jboss.as.ee.deployment.spi] (Thread-179) JBAS016101: End deploy: [target=http://org.jboss.as.ee.deployment/jsr88?targetType=as7,parent=null,type=ear,id=file:/C:/DOCUME~1/hudson/LOCALS~1/Temp/deployment-app.ear] 03:19:18,397 WARN [org.jboss.as.ee.deployment.spi] (Thread-179) JBAS016103: Cannot delete deployment file C:\DOCUME~1\hudson\LOCALS~1\Temp\deployment-app.ear, will be deleted on exit {code} This particular test fails because it tries to deploy the same EAR twice, but cannot use the same tmp file name. In branch [as2392|https://github.com/tdiesler/jboss-as/tree/as2392] I implemented a workaround that assigns a different tmp file name when it already exists and cannot be deleted. The underlying issue IMHO is however in the AS7 deployment layer and its handling of input streams associated with user provided URLs. This should be a general issue for all management clients running on w2k8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Thomas Diesler updated AS7-2392: -------------------------------- Component/s: Domain Management (was: Test Suite) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2392: --------------------------------------- OK, thanks. The general rule is if a caller passes an InputStream into an API method in controller-client, it's the caller's responsibility to close it when done. If a convenience method is used where the caller passes in a File or URI, it's the responsibility of controller-client code to close the InputStream it creates. Basically, whoever opens the IS closes it. If that isn't happening it's a controller-client bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2392: --------------------------------------- I haven't had time to really attack this yet; just doing some investigation. So these are notes to self or in case I assign this to someone else: After a quick look it seems the logic to close streams we open only happens if there is some sort of error condition. It happens in the DeploymentPlanBuilderImpl.cleanup() method and that seems to only get called in case of failure. If ^^^ is correct, a fix would require that we: 1) Call cleanup() in a finalizer method for the DPBI. 2) More critically, make sure that if build() is called, the resulting DeploymentPlan closes the streams. Once build() is called, the streams are "owned" by the DeploymentPlan. 3) The DeploymentPlan should also do cleanup in a finalizer. But that should be a final line of defense; the main solution to 2) should be doing cleanup as soon as the plan is executed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-2392: --------------------------------------- The managed domain stuff looks ok. Any passed in File or URL immediately gets sent up the the DC, and then the created IS is closed in a finally block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-2392?page=com.atlassian.jira.plugin.s... ] Thomas Diesler reopened AS7-2392: --------------------------------- The workaround in the JSR88 layer can now be removed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira