You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ivan <xh...@gmail.com> on 2012/04/01 03:29:13 UTC
Reduce the file copying in the application deployment
Hi, while deploying one common application in the Geronimo server, now we
copy the files for three times,
a. Copy the deployed application file to a temp directory, there are some
comments in the Deployer.java file :
// todo jar url handling with Sun's VM on Windows leaves a lock on the
module file preventing rebuilds
// to address this we use a gross hack and copy the file to a
temporary directory
// the lock on the file will prevent that being deleted
properly until the URLJarFile has
// been GC'ed.
b. Extract the application file to a temp directory
c. Copy the extracted application files to the corresponding repository
directory.
I am thinking that we may only do one time copying action, which is to
extract the application file to the repository directory directly.
For #a, after checking the svn log, it is added long long ago, I am not
sure whether we still have this issue, in my environment, it looks to me
that the file is not locked, may be this only occurs in some special
scenarios.
For #b, since we also keep the application extracted in the repository
directory, think that it is possible to skip that.
My idea is to introduce a 'fast.deploy' system property, and it is enabled
by default, with this property configured, the deployer will skip the step
#a and #b. Thoughts ?
--
Ivan
Re: Reduce the file copying in the application deployment
Posted by Ivan <xh...@gmail.com>.
Open a JIRA https://issues.apache.org/jira/browse/GERONIMO-6318 for this.
2012/4/1 Forrest Xia <fo...@gmail.com>
>
>
> On Sat, Mar 31, 2012 at 9:29 PM, Ivan <xh...@gmail.com> wrote:
>
>> Hi, while deploying one common application in the Geronimo server, now we
>> copy the files for three times,
>> a. Copy the deployed application file to a temp directory, there are some
>> comments in the Deployer.java file :
>>
>> // todo jar url handling with Sun's VM on Windows leaves a lock on the
>> module file preventing rebuilds
>> // to address this we use a gross hack and copy the file to a
>> temporary directory
>> // the lock on the file will prevent that being deleted
>> properly until the URLJarFile has
>> // been GC'ed.
>>
>> b. Extract the application file to a temp directory
>> c. Copy the extracted application files to the corresponding repository
>> directory.
>>
>> I am thinking that we may only do one time copying action, which is to
>> extract the application file to the repository directory directly.
>> For #a, after checking the svn log, it is added long long ago, I am not
>> sure whether we still have this issue, in my environment, it looks to me
>> that the file is not locked, may be this only occurs in some special
>> scenarios.
>>
> For #a, I think we may get some clue by referring to
> https://issues.apache.org/jira/browse/GERONIMO-4037.
>
>> For #b, since we also keep the application extracted in the repository
>> directory, think that it is possible to skip that.
>>
>> My idea is to introduce a 'fast.deploy' system property, and it is
>> enabled by default, with this property configured, the deployer will skip
>> the step #a and #b. Thoughts ?
>>
> Reducing file copy times when deployment is a nice improvement idea, let's
> move forwards for now :-)
>
>> --
>> Ivan
>>
>
>
>
> --
> Thanks!
>
> Regards, Forrest
>
>
--
Ivan
Re: Reduce the file copying in the application deployment
Posted by Forrest Xia <fo...@gmail.com>.
On Sat, Mar 31, 2012 at 9:29 PM, Ivan <xh...@gmail.com> wrote:
> Hi, while deploying one common application in the Geronimo server, now we
> copy the files for three times,
> a. Copy the deployed application file to a temp directory, there are some
> comments in the Deployer.java file :
>
> // todo jar url handling with Sun's VM on Windows leaves a lock on the
> module file preventing rebuilds
> // to address this we use a gross hack and copy the file to a
> temporary directory
> // the lock on the file will prevent that being deleted
> properly until the URLJarFile has
> // been GC'ed.
>
> b. Extract the application file to a temp directory
> c. Copy the extracted application files to the corresponding repository
> directory.
>
> I am thinking that we may only do one time copying action, which is to
> extract the application file to the repository directory directly.
> For #a, after checking the svn log, it is added long long ago, I am not
> sure whether we still have this issue, in my environment, it looks to me
> that the file is not locked, may be this only occurs in some special
> scenarios.
>
For #a, I think we may get some clue by referring to
https://issues.apache.org/jira/browse/GERONIMO-4037.
> For #b, since we also keep the application extracted in the repository
> directory, think that it is possible to skip that.
>
> My idea is to introduce a 'fast.deploy' system property, and it is enabled
> by default, with this property configured, the deployer will skip the step
> #a and #b. Thoughts ?
>
Reducing file copy times when deployment is a nice improvement idea, let's
move forwards for now :-)
> --
> Ivan
>
--
Thanks!
Regards, Forrest