I certainly don't think it's foolish to want to use scp to deploy. One
possible way to do this more atomically might be to add a pre-deployment
directory to the JBoss. In this directory, JBoss scans for
<filename>.deploy files; the ".deploy" file is empty. Once it finds the
deploy file, it looks for a corresponding ".ear,.war, or .jar" file, "mv"s
that file to the deploy directory, and deletes the ".deploy" file. Then the
service could signal JBoss to "auto-deploy". This would help make sure that
files in the "deploy" directory are actually deployable.
Probably still too complicated... :(
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Green
> Sent: Thursday, June 28, 2001 9:26 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] Auto-Deploy
>
>
> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
