[jboss-jira] [JBoss JIRA] Updated: (JBAS-6879) pullNewDeployments in FarmMemberService is buggy
Brian Stansberry (JIRA)
jira-events at lists.jboss.org
Thu May 7 10:27:46 EDT 2009
[ https://jira.jboss.org/jira/browse/JBAS-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Stansberry updated JBAS-6879:
-----------------------------------
JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154345
Affects Version/s: JBossAS-4.2.3.GA
JBossAS-4.2.2.GA
JBossAS-4.2.1.GA
JBossAS-4.2.0.GA
JBossAS-4.0.5.GA
JBossAS-4.0.4.GA
JBossAS-4.0.3 SP1
JBossAS-4.0.3 Final
JBossAS-4.0.2 Final
JBossAS-4.0.1 SP1
JBossAS-4.0.1 Final
JBossAS-4.0.0 Final
Moved issue from JBCLUSTER to JBAS. Linked in the forum thread. "Affects Version" is basically all the releases before AS 5; this has been there from the first revision of the code.
Clustered deployment in AS 5.1 is radically different and doesn't have this issue.
This fix looks to be along the line of what's discussed on the forum thread. I'll check it out and if OK commit it to Branch_4_2. Note however that we do not expect to produce any further releases from Branch_4_2.
> pullNewDeployments in FarmMemberService is buggy
> ------------------------------------------------
>
> Key: JBAS-6879
> URL: https://jira.jboss.org/jira/browse/JBAS-6879
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: JBossAS-4.0.0 Final, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA, JBossAS-4.0.5.GA, JBossAS-4.2.0.GA, JBossAS-4.2.1.GA, JBossAS-4.2.2.GA, JBossAS-4.2.3.GA
> Environment: jboss 4.2.2 onwards
> Reporter: sachin mishra
> Assignee: Brian Stansberry
>
> pullNewDeployments method in FarmMemberService is not working correctly during startup where there are more than 1 nodes in the cluster. Currently newly started cluster will always pull the files from the coordinator node as the call to DeployedURL du = (DeployedURL)parentDUMap.get(depName); will always return null on startup.
> Steps to reproduce:
> 1. create 2 or more nodes in 1 cluster
> 2. deploy app Test.war in the cluster
> 3. restart 1 of the nodes and you will see that this node is pulling the Test.war. Test.war hasn't changed therefore no need to pull it.
> This is currently causing a lot of issues in our server as we have lots of apps ( over 100) deployed and are quite big in size , therefore pull all the files at startup causes the server to become available after a very long time.
> Possible Fix;
> @Override
> protected void pullNewDeployments(HAPartition partition, HashMap farmed)
> {
> if(ServiceMBean.STARTING == getState()){
> if(doInit){
> init();
> doInit = false;
> }
> }else{
> logger.info("using pullNewDeployments on FarmMemberService as we are not in starting state... " );
> super.pullNewDeployments(partition, farmed);
> return;
> }
>
> Iterator it = farmed.keySet().iterator();
> String parentName= null;
> File destFile = null;
> while (it.hasNext())
> {
> String depName = (String)it.next();
> Date last = (Date)farmed.get(depName);
> DeployedURL du = (DeployedURL)parentDUMap.get(depName);
> int indexofParentName = depName.indexOf('/');
> parentName= depName.substring(0, indexofParentName);
> String child = depName.substring(indexofParentName+1, depName.length());
> File parentFolder = findParent(parentName);
> if(parentFolder == null){
> IllegalStateException stateException = new IllegalStateException("Can't find the farmed folder " + parentName);
> logger.error(stateException,stateException);
> throw stateException;
> }
> destFile = new File(parentFolder,child);
> Date localDeployedDate = new Date(destFile.lastModified());
> logger.info("parentname=" + parentName + " destfile= " +destFile.getAbsolutePath() + " isexist=" + destFile.exists() + " local mode date=" + localDeployedDate + " remote deploy date=" + last);
> if(destFile.exists() && !localDeployedDate.before(last)){
> logger.info(" no need to pull " + depName + " from remote server as the timestamps are same");
> }else{
> logger.info(" going to pull " +depName + " from remote server.....");
> pullRemoteFile(new File(depName), parentName);
> }
> }
> }
> private void init() {
> try{
> HAPartition lHAPartition = null;
> if (mClusterPartition != null)
> {
> lHAPartition = mClusterPartition.getHAPartition();
> }
> if (lHAPartition == null)
> {
> // Old style config with PartitionName was used -- have to
> // look up the partition in JMX
> lHAPartition = (HAPartition) getServer().getAttribute(
> mClusterPartitionName,
> "HAPartition"
> );
> }
> mFileTransfer = new ClusterFileTransfer(lHAPartition, buildParentFolderMapping());
> logger.warn("Created mFileTransfer successfully");
> }catch(Exception e){
> logger.error("Error Starting ClusterMemberService ",e);
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list