[jbosstools-issues] [JBoss JIRA] (JBIDE-18862) when removing a module from AS runtime marker files are not removed automatically

Rob Stryker (JIRA) issues at jboss.org
Thu Dec 11 08:33:29 EST 2014


    [ https://issues.jboss.org/browse/JBIDE-18862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027024#comment-13027024 ] 

Rob Stryker commented on JBIDE-18862:
-------------------------------------

My race condition had to do if we put a .dodeploy marker, and the server has not yet switched it to a .deploying marker.  In this case, the filesystem scanner has not yet begun to pick up the deployment. If I then delete the .dodeploy marker, to make some incremental changes, and don't add a .dodeploy marker back, then the server *never* picks up the deployment. 

1) We copy a full publish directory structure to a clean deployments folder
2) we add a .dodeploy marker
3) an incremental publish to the same module is invoked in eclipse
4) the server has not yet picked up the deployment is present.  The .dodeploy marker is still there
5) We (eclipse) delete the .dodeploy marker
6) We add whatever incremental file changes need to be made
7) We do not add another .dodeploy marker, since we are doing an incremental publish and are trying to minimize redeployments
8) The server never picks up the deployment at all. It did not get to see a .dodeploy marker ever. We removed it during the incremental publish before the server saw it, and we did not add one back. 

This is the race condition I'm referring to. 

To do this properly, I would need to verify the incremental publish is not pre-empting a full publish / .dodeploy marker, and then re-add the .dodeploy marker after the incrementa publish... but this would complicate things quite a bit.  Furthermore, if there was a stale .dodeploy there that wasn't supposed to be there, I'd probably assume I was pre-empting an actual full deployment, and re-add the marker when I wasn't supposed to. 

Also, I'm not sure that ever deleting an .isdeploying marker is *ever* appropriate. I'm not clued into the details on the server side, but, this seems like it'd be interrupting a deployment or canceling a deployment that was in progress.  If it's an incremental publish that's deleting the .isdeploying (and thus canceling the server's deployment), I would need to know to re-add the .dodeploy marker yet again, even though I'm doing an incremental publish and wouldn't typically add a .dodeploy marker in that case. 

This problem isn't as simple as it seems. 



> when removing a module from AS runtime marker files are not removed automatically
> ---------------------------------------------------------------------------------
>
>                 Key: JBIDE-18862
>                 URL: https://issues.jboss.org/browse/JBIDE-18862
>             Project: Tools (JBoss Tools)
>          Issue Type: Feature Request
>          Components: server
>         Environment: Windiws7 64bit, JDK 8u25
>            Reporter: Darryl Miles
>            Priority: Minor
>             Fix For: 4.2.2.Final, 4.3.0.Alpha1
>
>
> module removal does not delete the various marker files relating to it:
> *.undeployed
> *.dodeploy
> The same should be true when ADDING a module, it should clean out any marker files.
> Setup an deploy-inhibiting marker file to ensure it won't try to deploy it before the *.ear is full written.
> Write out the*.ear file.
> Then adjust the marker files as necessary to reflect the intended state of the module (if it should be started then remove the inhibiting marker file in the previous step).



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)


More information about the jbosstools-issues mailing list