geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Problems building on windows
Date Wed, 29 Mar 2006 11:32:44 GMT
John,

First, thanks for the detailed response!  I'll have to try out some of 
the utilities that you mention, reproduce the problems, and get back 
with the details.  But I'd like to say how much I appreciate all of the 
advice you've provided.   More responses in-line.

John Sisson wrote:
> Joe Bohn wrote:
> 
>>
>> I've been encountering a number of problems building on Windows which 
>> seem to be steadily getting worse and I was wondering if anybody else 
>> is experiencing this (and hopefully has some work-arounds).
>>
>> - Out of Memory Errors.   These seem to be related to two different 
>> things:
>> 1)  Long file names.  If I remember correctly Windows has issues if 
>> the file names exceed 256 bytes.  I've been working with multiple 
>> levels of geronimo concurrently and so have had to name the root 
>> something other than simply geronimo.  It seems like if I start to get 
>> longer than 12 characters or so I begin to hit these problems.  I 
>> think we may be getting into trouble here with the depth of our 
>> packages and embedded classes.
> 
> Yes, it is concerning..  
> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200601.mbox/%3C43C45F7B.6070703@gmail.com%3E

> 
> I also have had to shorten my directory path I am building in.  The long 
> file name issue should go way when we move to JDK 1.5_06 but a number of 
> other programs on Windows that deal with files also have the issue (e.g. 
> Windows File Explorer, WinZip, Visual SourceSafe) so this issue could 
> bite us with users complaining that other tools they are using can't 
> work with Geronimo's long directory paths.
> Do we have a JIRA for this issue?

I'm not aware of a JIRA for this.  I'll search again and if I can't find 
  one I'll create one.  Another tool to add to the list is xcopy.

> 
>> 2)  Extra garbage hanging around in %temp% from previous builds.  The 
>> geronimo build leaves a lot of trash in %temp% and when that seems to 
>> cause problems with out of memory errors and subsequent builds.
>>
> See http://issues.apache.org/jira/browse/GERONIMO-777

Hmmm ... I had seen this JIRA and all the discussion but somehow I 
always only focused on the config-store part of it and I haven't noticed 
that problem recently.

> 
> Are you seeing these problems on trunk, 1.0 or 1.1 branches or all?  

I'm seeing them on 1.0 and trunk for sure.   I haven't been keeping 
careful tabs on 1.1 but I'd be surprised if it was any different there.

> What JDK are you using?

Sun JDK 1.4.2_08 (build 1.4.2_08-b03)

> 
> For a long time I have been using the following (from memory I think 
> there was something in maven or one of the libraries it uses that had a 
> leak - not sure if this still exists)
> 
> SET MAVEN_OPTS=-Xmx512m -XX:MaxPermSize=128m
> 
> What command are you using to build?  (this could possibly affect what 
> code gets invoked and how much memory is used).  Do you have MAVEN_OPTS 
> environment variables set?

No, I don't have MAVEN_OPTS set but I'll certainly give that a try.  I 
build with many different commands and from many different location 
depending upon what I'm doing.  This problem seems more pronounced when 
I do a full clean build with itests .... "maven m:clean new" from 
geronimo root.

> 
> I will try to reproduce with the same JDK level and commands once you 
> provide the info.
> 
>> - File IO errors when running the CRLF plugin. These may be related to 
>> the %temp% storage but I seem to get them at times even when I've just 
>> cleaned out my %temp%.  Running back to back I get different results.
> 
> One thing to try is disabling XP's file indexing (which I have done).  
> It looks like this has caused problems for Java elsewhere (see the 
> workaround in this bug).. 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5006328
> 
> I also found that 
> http://www.sysinternals.com/Utilities/ProcessExplorer.html utility is 
> good for tracking down processes that have file handles open.  Use the 
> Find-->Find Handle menu option and specify the file name.
> I had some similar problems for a while and ended up tracking it down my 
> incorrectly configured Diskeeper disk defragmenter that had paused 
> defragmentation and held file handles open.
> Have you tried with real-time virus checking disabled to check it isn't 
> a virus checker causing issues?
> What files are you getting the IO errors on?  Can you include the error 
> output?

Thanks for the pointers to utilities.  I'll give them a try (including 
disabling the real-time virus checker but it seems to happen with too 
great a frequency to be this).  The FileIO errors are always on files 
deep within the config-store when it fails during the CRLF plugin ... 
perhaps related to the long file names again.

> 
> It makes me wonder if we need to have some kind of retry logic for file 
> operations if we are possibly competing with file indexers etc so we can 
> run on a Windows box without problems.  I noticed some of the Ant tasks 
> have retry logic for some file operations:
> 
> http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Mkdir.java?view=markup

> 
> http://svn.apache.org/viewcvs.cgi/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Delete.java?view=markup

> 
> 
> Regards,
> 
> John
> 
>>
>> Thanks for the help,
>> Joe
>>
> 
> 

-- 
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message