"scott.stark(a)jboss.org" wrote :
| The locking and enableModifiedDeploymentChecks were hacks to get the hot deployment
scanning from interfering with copying new deployment content. The repository itself could
either have this flag if its still needed, or just put the burden on the repository
implementation to handle concurrency better. The externalized locking and
enableModifiedDeploymentChecks were hacks to avoid concurrency problems I was seeing, so
first consider just removing them.
|
Okay good to know - that's why i was thinking that DeploymentManager should suspends
the profile automatically from scanning.
As we might allow a profile definition like this (at one point):
| <hotdeployment-profile name="myhotdeploymentProfile">
| <profile source .../>
| <scan-period>12345</scan-period>
| </hotdeployment-profile>
|
Therefore we could have one HDScanner thread per profile and DeploymentManager suspends
the scanner,
when it's uploading contents.
Because i think in the end there will be quite a lot of immutable profiles (defined over
xml), where you basically
don't have hot-deployment scanning.
And just the deploy/ directory and the clustering directories as hot-deployment profiles.
IMHO as soon, as you define deployments in a profile, it does not make sense to search for
new content.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205975#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...