harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Regis Xu (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext searches for jndi.properties every contruction time
Date Wed, 24 Oct 2007 08:29:50 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Regis Xu updated HARMONY-4942:
------------------------------

    Attachment: Harmony-4942.fix.diff

last path doesn't fix file.exists problem,  this one can fix it correctly, I think.
And after this path on my machine, the performance of harmony is better than ri.

Sergey, It's very kind of you and very helpful if you could use SPECjAppServer2004 
measure the path. Thanks.

> [classlib][jndi] InitialContext searches for jndi.properties every contruction time
> -----------------------------------------------------------------------------------
>
>                 Key: HARMONY-4942
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4942
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Sergey Dmitriev
>            Assignee: Tony Wu
>         Attachments: Harmony-4942.diff, Harmony-4942.fix.diff, Harmony-4942.new.diff,
Harmony-4942.new.diff, jndi3.java, jndi3_POC.patch, jndi3perf.java, MyDefaultInitialContextFactory.java,
MyInitialContext.java
>
>
> I'd like to bring attention of JNDI guys to the following issue.
> This is about InitialContext. Currently the InitialContext constructor implementation
roughly speaking does the following:
> 1. gets the properties passed to constructor (if any)
> 2. searches the system properties for corresponding to JNDI stuff
> 3. searches for jndi.properties in CLASSPATH and gets the properties from that (if any)
> (in case of InitialContext() we don't have the first step)
> This is quite cool until we face big amount of InitialContext() creations - then we see
a lot of file system operations from step 3. For example during the Oracle App Server startup
(with SPECjAppServer2004 onboard) - there is a lot of "new InitialContext()", every Bean creation.
So we see about 27 millions of searches for "jndi.properties" in jar files from the Oracle
App Server classpath (tens of jars).
> Is there anything can be done on this?..
> Well as it turned out the JDK1.6.0 DOES NOT searches for the "jndi.properties" in CLASSPATH
for the second time we create InitialContext(). Once it's loaded the "jndi.properties" properties
for the first time it does not bother to do it later. I suggest to do the same in harmony.
Here is the output of the test demonstrating such a behaviour difference:
> {man@earth:~/tmp} cat jndi3.java
> import java.io.*;
> import javax.naming.*;
> public class jndi3 {
>     public static void main(String args[]) throws Exception {
>         createJndiPropertiesFile(); // create valid jndi.properties
>         InitialContext context1 = new InitialContext();
>         System.out.println("context1=    "+context1);
>         System.out.println("context1.env="+context1.getEnvironment());
>         deleteJndiPropertiesFile(); // delete jndi.properties
>         InitialContext context2 = new InitialContext();
>         System.out.println("context2=    "+context2);
>         System.out.println("context2.env="+context2.getEnvironment());
>     }
>     public static void createJndiPropertiesFile() throws Exception {
>         FileOutputStream fos = new FileOutputStream("jndi.properties");
>         PrintStream ps = new PrintStream(fos);
>         ps.println("java.naming.factory.initial=MyDefaultInitialContextFactory");
>         ps.close();
>     }
>     public static void deleteJndiPropertiesFile() throws Exception {
>         File f = new File("jndi.properties");
>         f.delete();
>     }
> }
> {man@earth:~/tmp} /export/jdk1.6.0/bin/java jndi3
> context1=    javax.naming.InitialContext@1034bb5
> context1.env={}
> context2=    javax.naming.InitialContext@15f5897
> context2.env={}
> {man@earth:~/tmp} ~/harmony579850.clean/bin/java jndi3
> context1=    javax.naming.InitialContext@108d9d1f
> context1.env={}
> context2=    javax.naming.InitialContext@109242b5
> Uncaught exception in main:
> javax.naming.NoInitialContextException: Failed to create InitialContext using factory
specified in hashtable {} [Root exception is java.lang.NullPointerException]
>         at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:239)
>         at javax.naming.InitialContext.initializeDefaultInitCtx(InitialContext.java:261)
>         at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:291)
>         at javax.naming.InitialContext.getEnvironment(InitialContext.java:540)
>         at jndi3.main(jndi3.java:17)
> Caused by: java.lang.NullPointerException
>         at java.lang.Class.forName(Unknown Source)
>         at javax.naming.spi.NamingManager$1.run(NamingManager.java:772)
>         at javax.naming.spi.NamingManager$1.run(NamingManager.java:1)
>         at java.security.AccessController.doPrivilegedImpl(Unknown Source)
>         at java.security.AccessController.doPrivileged(Unknown Source)
>         at javax.naming.spi.NamingManager.classForName(NamingManager.java:768)
>         at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:227)
>         at javax.naming.InitialContext.initializeDefaultInitCtx(InitialContext.java:261)
>         ... 3 more
> I've created a simple proof-of-concept of my idea: what about to not to do any of steps
(1, 2, 3) not just 3? So please note that THIS IS NOT THE FIX! The actual fix should avoid
only step 3 and probably should do it more carefully. Here are some measurements with respect
to this (see jndi3per.java in attachment):
> {man@earth:~/tmp} ~/harmony579850.clean/bin/java jndi3perf 20000
> 20000 constructor calls
> 1. 17442 millis
> 2. 11281 millis
> 3. 11598 millis
> 4. 10951 millis
> 5. 10906 millis
> ^C
> {man@earth:~/tmp} ~/harmony579850.jndi3/bin/java jndi3perf 20000
> 20000 constructor calls
> 1. 466 millis
> 2. 114 millis
> 3. 107 millis
> 4. 110 millis
> 5. 107 millis
> ^C
> Talking back about Oracle App Server and SPECjAppServer2004: startup times burst comparing
harmony without and with the proposed patch are: 
> -Xem:client - 4X
> -Xem:server - 2x
> Furthermore SPECjAppServer2004 execution period is concerned to this as well: as it turned
out we have ABOUT 3000 OF LOOKUPS of "jndi.properties" in jar files PER SECOND (transaction
rate is about two hundreds). I'd say handling this should not decrease our current scores
on SjAS2004. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message