To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=64357
                  Issue #:|64357
                  Summary:|javaldx search too promiscuously
                Component:|framework
                  Version:|OOo 2.0.2
                 Platform:|Sun
                      URL:|
               OS/Version:|Solaris
                   Status:|UNCONFIRMED
        Status whiteboard:|
                 Keywords:|
               Resolution:|
               Issue type:|DEFECT
                 Priority:|P3
             Subcomponent:|code
              Assigned to:|tm
              Reported by:|quenelle





------- Additional comments from [EMAIL PROTECTED] Wed Apr 12 16:59:52 -0700 
2006 -------
My machine has an auto-mounted directory called /java which links to many
many NFS filesystems inside on many different hosts.  When I try to run
OpenOffice.org a program called "javaldx" searches in many places on my system
for a JDK.

1971:   access("/j2re", F_OK)                           Err#2 ENOENT
1971:   access("/j2se", F_OK)                           Err#2 ENOENT
1971:   access("/j2sdk", F_OK)                          Err#2 ENOENT
1971:   access("/jdk", F_OK)                            Err#2 ENOENT
1971:   access("/jre", F_OK)                            Err#2 ENOENT
1971:   access("/java", F_OK)                           = 0
1971:   access("/java", F_OK)                           = 0
1971:   lstat("/java", 0xFFBFE04C)                      = 0


Now the /java directory will not have anything helpful, but javaldx searches
a whole bunch of subdirectories anyway.

For EACH and EVERY subdirectory inside /java the program searches for
the following inner subdirectories:

1971:   getdents64(4, 0xFF3A4000, 8192)                 = 2136
1971:   access("/java/jle_build", F_OK)                 = 0
1971:   lstat("/java/jle_build", 0xFFBFE04C)            = 0
1971:   access("/java/jle_build/java", F_OK)            Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/bin/java", F_OK)        Err#2 ENOENT
1971:   access("/java/jle_build/jre/bin/java", F_OK)    Err#2 ENOENT
1971:   access("/java/jle_build/gij", F_OK)             Err#2 ENOENT
1971:   access("/java/jle_build/bin/gij", F_OK)         Err#2 ENOENT


Sooner or later, it comes to a filesystem that won't respond over NFS and
the whole process hangs, which hangs OpenOffice.org.

I see multiple possible solutions to this:

1. don't search in ALL subdirectories of /java, just the directory names
that look like they might have a JRE inside.

2. search in a different and more intelligent order, so that my
Solaris 10 system results in a match before the search process
gets to /java. (And stop when you get a good match)

3. Set a timeout on the thread which is doing this probe so that a hang
doesn't hang forever (or shorten the time out if there is already one).
Don't rely on the OS'es NFS timeout to be the only limit.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to