[ https://issues.jboss.org/browse/AS7-4583?page=com.atlassian.jira.plugin.s... ] jaikiran pai reassigned AS7-4583: --------------------------------- Assignee: jaikiran pai (was: Jason Greene) -- 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-4583?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-4583: ----------------------------------- I have got a commit in my branch which fixes one part of this issue https://github.com/jaikiran/jboss-as/commit/06e3c8a3775c20919d4f1a3166790.... Specifically, the following usecase now works: 1) Start a server (which doesn't have any deployments) 2) Add a new deployment The new deployment will be hot deployed and subsequent updates to the deployments will also be picked up including any undeployments. However, there's one other case which is still broken. That one is as follows: 1) Start a server which already has a deployment 2) Try updating that deployment In this case the hot deployment doesn't work. The problem seems to be the way the one-off scan that's triggered by the (new) boot-time scanner. From what I see the one off scan gets triggered in the add operation of the deployment scanner handler. Note that it's triggered even before the add operation ends up installing the deployment scanner service. Now that one off scan first enables the scan and then starts deployment any available deployments. This internally triggers the deployment scanner service start() which ends up calling startScanner() on the scanner. However the startScanner finds that the scan is already enabled (by the one off scan which is still in progress in a different thread) and skips the relevant actions that are necessary for the scanner. The one off scan then completes it's task and switch back the scan enabled to false. This is based on just a quick look via the debugger. I might have missed a few things. I'm not sure about the original requirement which triggered this changed in FS deployment. So I'll let either Brian or Stuart handle this, since I guess they might know more about it. -- 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-4583?page=com.atlassian.jira.plugin.s... ] jaikiran pai edited comment on AS7-4583 at 4/22/12 12:12 PM: ------------------------------------------------------------- I have got a commit in my branch which fixes one part of this issue https://github.com/jaikiran/jboss-as/commit/06e3c8a3775c20919d4f1a3166790.... Specifically, the following usecase now works: 1) Start a server (which doesn't have any deployments) 2) Add a new deployment The new deployment will be hot deployed and subsequent updates to the deployments will also be picked up including any undeployments. However, there's one other case which is still broken. That one is as follows: 1) Start a server which already has a deployment 2) Try updating that deployment In this case the hot deployment doesn't work. The problem seems to be the way the one-off scan that's triggered by the (new) boot-time scanner. From what I see the one off scan gets triggered in the add operation of the deployment scanner handler. Note that it's triggered even before the add operation ends up installing the deployment scanner service. Now that one off scan first enables the scan and then starts deployment any available deployments. This internally triggers the deployment scanner service start() which ends up calling startScanner() on the scanner. However the startScanner finds that the scan is already enabled (by the one off scan which is still in progress in a different thread) and skips the relevant actions that are necessary for the scanner. The one off scan then completes it's task and switch back the scan enabled to false. This is based on just a quick look via the debugger. I might have missed a few things. I'm not sure about the original requirement which triggered this change in FS deployment. So I'll let either Brian or Stuart handle this, since I guess they might know more about it. [Edited to fix a minor typo] was (Author: jaikiran): I have got a commit in my branch which fixes one part of this issue https://github.com/jaikiran/jboss-as/commit/06e3c8a3775c20919d4f1a3166790.... Specifically, the following usecase now works: 1) Start a server (which doesn't have any deployments) 2) Add a new deployment The new deployment will be hot deployed and subsequent updates to the deployments will also be picked up including any undeployments. However, there's one other case which is still broken. That one is as follows: 1) Start a server which already has a deployment 2) Try updating that deployment In this case the hot deployment doesn't work. The problem seems to be the way the one-off scan that's triggered by the (new) boot-time scanner. From what I see the one off scan gets triggered in the add operation of the deployment scanner handler. Note that it's triggered even before the add operation ends up installing the deployment scanner service. Now that one off scan first enables the scan and then starts deployment any available deployments. This internally triggers the deployment scanner service start() which ends up calling startScanner() on the scanner. However the startScanner finds that the scan is already enabled (by the one off scan which is still in progress in a different thread) and skips the relevant actions that are necessary for the scanner. The one off scan then completes it's task and switch back the scan enabled to false. This is based on just a quick look via the debugger. I might have missed a few things. I'm not sure about the original requirement which triggered this changed in FS deployment. So I'll let either Brian or Stuart handle this, since I guess they might know more about it. -- 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-4583?page=com.atlassian.jira.plugin.s... ] Stuart Douglas resolved AS7-4583. --------------------------------- Fix Version/s: 7.1.1.Final Resolution: Done Should be fixed now. -- 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