You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Sergey Dmitriev (JIRA)" <ji...@apache.org> on 2007/10/13 13:48:50 UTC
[jira] Created: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
[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
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.
Fwd: [jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext searches for jndi.properties every contruction time
Posted by Tony Wu <wu...@gmail.com>.
Hi Sergey,
I tried this patch on my local machine and it works. The performance
got highly improved on your test case. I want to know whether this fix
has good effect on SPECjAppServer as your micro benchmark. Would you
pls help to verify it? And I'll apply this patch if it the answer is
true. Thanks.
---------- Forwarded message ----------
From: Sergey Dmitriev (JIRA) <ji...@apache.org>
Date: Oct 24, 2007 9:22 PM
Subject: [jira] Commented: (HARMONY-4942) [classlib][jndi]
InitialContext searches for jndi.properties every contruction time
To: commits@harmony.apache.org
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537320
]
Sergey Dmitriev commented on HARMONY-4942:
------------------------------------------
Regis thanks for you fix! Unfortunately due to technical reasons I
cannot check the performance of your fix. I just can say that your
patch works. I'll try to check the performance as soon as it will be
possible.
I looked at the diff and and just caught you're using HashMap: don't
you think we can have a sync issues because of using HashMap not
Hashtable as a map [classloader -> props]?
> [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.
--
Tony Wu
China Software Development Lab, IBM
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535042 ]
Regis Xu commented on HARMONY-4942:
-----------------------------------
Yes, the performance is very low, I agree that search the whole CLASSPATH should do one time. But this is a problems:
we use thread context classloader (Thread.currentThread().getContextClassLoader()) to do the step 3, different classloaders
may have different properties value. It very useful for app server which use different classloaders separate apps context. If just
use static variable will cause conflict between classloaders. I'm not sure how ri do this, i will write test soon.
> [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
> Attachments: 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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538647 ]
Regis Xu commented on HARMONY-4942:
-----------------------------------
Sergey thanks for your reminder! I agree the sync issues is necessary, I will fix it soon.
Thanks again for your helps!
> [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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ 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.new.diff
> [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.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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536964 ]
Sergey Dmitriev commented on HARMONY-4942:
------------------------------------------
Regis, the numbers of your last improvement (11000 millis -> 300 millis) are really cool.
> [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.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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536189 ]
Sergey Dmitriev commented on HARMONY-4942:
------------------------------------------
Regis I am watching this issue. Thank you for you work! Yesterday I've made performance measurements with respect to your first patch Harmony-4942.diff. Comparing to my POC version ( jndi3_POC.patch) your patch is 3% slower. But of course this is just for the record because my patch is not valid. The test I used is SPECjAppServer2004 on Oracle Application Server.
I will post the measurement number of your second patch soon.
> [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.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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Dmitriev updated HARMONY-4942:
-------------------------------------
Attachment: MyDefaultInitialContextFactory.java
> [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
> Attachments: 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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536171 ]
Regis Xu commented on HARMONY-4942:
-----------------------------------
Hi Tony,
I have test the ri's behavior, you are right, ri doesn't reload the property file under "java.home/lib/jndi.properties" after jvm init,
the test prove it:
===================start====================
Hashtable<Object, Object> env = new Hashtable<Object, Object>();
env
.put("java.naming.factory.initial",
"org.apache.harmony.jndi.tests.javax.naming.spi.mock.MockContextFactory");
InitialContext context = new InitialContext(env);
System.out.println(context.getEnvironment().containsKey(
"java.naming.provider.url"));
// generate properties file
File propsFile = new File(System.getProperty("java.home")
+ "/lib/jndi.properties");
FileOutputStream fos = new FileOutputStream(propsFile);
PrintStream ps = new PrintStream(fos);
ps.println("java.naming.provider.url=http://test1");
ps.close();
context = new InitialContext(env);
System.out.println(context.getEnvironment().containsKey(
"java.naming.provider.url"));
propsFile.delete();
========================end=================
the output is:
false
false
I will re-create a path to fix it soon.
> [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, 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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Tony Wu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536160 ]
Tony Wu commented on HARMONY-4942:
----------------------------------
Hi Regis,
Seems the performance is not as good as ri. I did a quick look and found the bottleneck is that we call the file.exists() every time, basically, it is a very time-consuming operation with jni call. I suppose that ri just check the property file when vm init, would you please have a try on that?
> [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, 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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Dmitriev updated HARMONY-4942:
-------------------------------------
Attachment: jndi3_POC.patch
> [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
> Attachments: 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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ 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.new.diff
Is there anyone to this?
> [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.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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537320 ]
Sergey Dmitriev commented on HARMONY-4942:
------------------------------------------
Regis thanks for you fix! Unfortunately due to technical reasons I cannot check the performance of your fix. I just can say that your patch works. I'll try to check the performance as soon as it will be possible.
I looked at the diff and and just caught you're using HashMap: don't you think we can have a sync issues because of using HashMap not Hashtable as a map [classloader -> props]?
> [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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Dmitriev updated HARMONY-4942:
-------------------------------------
Attachment: jndi3perf.java
> [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
> Attachments: jndi3.java, 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.
[jira] Commented: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536938 ]
Regis Xu commented on HARMONY-4942:
-----------------------------------
Sergey, I test Harmony-4942.new.diff using your test case on my machine, the performance is still low than ri but have great improvement.
the output is:
on ri:
20000 constructor calls (default)
1. 167 millis
2. 81 millis
3. 82 millis
4. 85 millis
5. 86 millis
6. 83 millis
7. 82 millis
8. 86 millis
on harmony:
20000 constructor calls (default)
1. 653 millis
2. 339 millis
3. 316 millis
4. 324 millis
5. 317 millis
6. 324 millis
7. 329 millis
8. 333 millis
In this case, all properties files will be read only once. And because there is only one classloader, CLASSPATH will search once, i think
there would be another bottleneck somewhere, i will try to find it.
> [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.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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ 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.diff
the path fix the problem that InitialContext search the whole CLASSPATH every construction time
> [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
> Attachments: Harmony-4942.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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Dmitriev updated HARMONY-4942:
-------------------------------------
Attachment: jndi3.java
> [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
> Attachments: jndi3.java, 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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Sergey Dmitriev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Dmitriev updated HARMONY-4942:
-------------------------------------
Attachment: MyInitialContext.java
> [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
> Attachments: 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.
[jira] Assigned: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Tony Wu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tony Wu reassigned HARMONY-4942:
--------------------------------
Assignee: Tony Wu
> [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, 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.
[jira] Updated: (HARMONY-4942) [classlib][jndi] InitialContext
searches for jndi.properties every contruction time
Posted by "Regis Xu (JIRA)" <ji...@apache.org>.
[ 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.syn.fix.diff
this patch(Harmony-4942.syn.fix.diff) use Hashtable instead of HashMap for propsCache to
make it thread safe.
> [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, Harmony-4942.syn.fix.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.