I didn't say that this method could be sure that the processes copying to
the destination is responsive. I didn't say it was perfect. In fact I said
it wasn't. I also said that I could not think of a perfect way of doing
it, but this would be more foolproof against fools like me that want to
use scp to release files to remote machines.
Observe:
> > > 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.
David Green
On Thu, 28 Jun 2001, Jim Brownfield wrote:
> 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: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of David
> > Green
> > Sent: Thursday, June 28, 2001 8:38 AM
> > To: [EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]On
> > Behalf Of David
> > > > Green
> > > > Sent: Thursday, June 28, 2001 8:08 AM
> > > > To: [EMAIL PROTECTED]
> > > > 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
> > > > [EMAIL PROTECTED]
> > > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
