RE: [JBoss-dev] Auto-Deploy

[Jim B. <Jim...@ra...>]

I guess I don't see it as a problem; I see it as a Unix "feature" :).

The problem I see with trying to "sleep and check" is that you can never be
sure that the process copying to the destination is responsive enough to
have made progress during the sleep period.  This is especially true with
scp or ftp done over a network.  We have situations over the net where no
bytes are moved for many seconds (or even minutes).  Also, you cannot be
sure the copying process hasn't terminated unexpectedly before the copying
process completes.

If this is going to be placed in the JBoss baseline, I'd rather see a more
definitive solution -- possibly some kind of deployment service MBean that
allowed (with proper authentication) transfer of a deployment resource into
some kind of pre-deployment directory until it's sure the resource has been
properly transfered (probably through meta-information about the resource).

Seems a bit complicated.  Personally, I find cp/mv or ftp/rename to be fine.
;)

> -----Original Message-----
> From: jbo...@li...
> [mailto:jbo...@li...]On Behalf Of David
> Green
> Sent: Thursday, June 28, 2001 8:38 AM
> To: jbo...@li...
> Subject: RE: [JBoss-dev] Auto-Deploy
>
>
> I'm quite aware of how to get around the problem. If I wasn't, I wouldn't
> have been able to write code to fix the problem generically :)
>
> We use 'scp' not 'cp'.
>
> David Green
>
> On Thu, 28 Jun 2001, Jim Brownfield wrote:
>
> > If you're on Linux, you shouldn't be using "cp" to create the deployment
> > jar, you should use the "mv" command.  If you're using ftp to upload the
> > file, upload it to a non-jar resource, and then use the
> "rename" command to
> > move it to its final location.  This is typical under any Unix
> for almost
> > any file creation of a file that could be in use (or have an
> attempted use)
> > at the time you're creating the file.  First, you copy the file onto the
> > same device ("same device" is important!), then you execute an
> "mv" command,
> > which is pretty much an atomic operation if the source and
> destination are
> > on the same device.
> >
> > > -----Original Message-----
> > > From: jbo...@li...
> > > [mailto:jbo...@li...]On
> Behalf Of David
> > > Green
> > > Sent: Thursday, June 28, 2001 8:08 AM
> > > To: jbo...@li...
> > > Subject: [JBoss-dev] Auto-Deploy
> > >
> > >
> > >
> > > The auto-deploy feature is awesome. However, it starts
> unzipping my files
> > > before I even finish copying them...
> > >
> > > Fortunately, Linux keeps updating the timestamp on the file during the
> > > process of being copied, so it usually tries again and again.
> Sometimes,
> > > it tries right before the file is finished, and doesn't try
> again... so i
> > > have to go 'touch' the file.
> > >
> > > I have a suggestion for fixing this problem. Unfortuneately, I don't
> > > think there's any way to know if a file is done being written to. So
> > > I think a timer in the appropriate place would provide for the most
> > > foolproof operation.
> > >
> > > I haven't tested this code, but it should work fine... There might be
> > > a typo or two.
> > >
> > > I included a couple of other changes, like checking to see if a file's
> > > modification time has changed rather than increased. This is because,
> > > at least under unix, if you untar a .tar file, it might preserve
> > > modification times, resulting in the .jar changing in the deploy area,
> > > but not being redeployed. Other commands show this behaviour too.
> > >
> > > // Check watched URLs
> > > for (int i = 0; i < watchedURLs.size(); i++)
> > > {
> > >   Deployment deployment = (Deployment)watchedURLs.get(i);
> > >   long lm;
> > >   File file = null;
> > >   if (deployment.watch.getProtocol().startsWith("file")) {
> > >     file = new File(deployment.watch.getFile());
> > >     lm = file.lastModified();
> > >   } else {
> > >     // Use URL connection to get timestamp
> > >     lm = deployment.watch.openConnection().getLastModified();
> > >   }
> > >   if (file != null && deployment.lastModified != lm) {
> > >     // wait for file to stop growing...
> > >     long size = 0;
> > >     while (true) {
> > >       size = file.length();
> > >       Thread.sleep(DEPLOYMENT_DELAY);
> > >       long newSize = file.length();
> > >       long newLM = file.lastModified();
> > >       if (size == newSize && lm == newLM) break;
> > >       lm = file.lastModified();
> > >       log.log("Waiting for file to stop changing: " + deployment.url);
> > >     }
> > >   }
> > >
> > >   // Check old timestamp -- always deploy if first check
> > >   if (deployment.lastModified == 0 || deployment.lastModified != lm)
> > >   {
> > >     log.log("Auto deploy of "+deployment.url);
> > >     // continue normally
> > >
> > > BTW, Why the check for deployment.lastModified == 0? The only
> time that
> > > would be true but (deployment.lastModified != lm) would be false
> > > would be if
> > > (lm == 0). And if (lm == 0) then we're going to start an infinite
> > > auto-deploy loop anyway because of the (deployment.lastModified == 0)
> > > check.
> > >
> > > Also, the wait loop could be implemented as a separate thread that is
> > > launched so that other stuff can deploy while we're waiting
> on this one
> > > file to stop growing... probably not necessary though.
> > >
> > > DEPLOYMENT_DELAY could be configured by the user in one of the conf
> > > files... I'd personally set it to something like 5 seconds or more,
> > > although a default of 1 second might be appropriate.
> > >
> > > David Green
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > Jbo...@li...
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > Jbo...@li...
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
> _______________________________________________
> Jboss-development mailing list
> Jbo...@li...
> http://lists.sourceforge.net/lists/listinfo/jboss-development