[ognl] internal cache performance improvement
Hi all OGNL folks, my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? Looking forward to your feedbacks, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] internal cache performance improvement
2011/6/6 Simone Tripodi simonetrip...@apache.org my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Pretty naive, i suppose. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). Probably you are referring to TreeMap, HashMap uses a fixed array with collisions lists. The problem with TreeMap is that any inserted key must implement Comparable, or a Comparator must be supported. Since it is a cache, wouldn't an LRUMap be more useful? http://commons.apache.org/collections/api-release/org/apache/commons/collections/map/LRUMap.html WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? I think you can go on. Surely a Map should be used, the implementation of that Map could be considered at a later stage. Antonio
Re: [pool] getNumActive returning -1
On 6/5/11 7:32 PM, Phil Steitz wrote: The AbandonedObjectPool test case that I just commented out in [dbcp] trunk is failing because GOP getNumActive returns -1. My first thought was that this is a timing issue due to lack of synchronization in invalidate and general non-protection of _allObjects and _idleObjects; but I can't demonstrate this. Looking into it now... I found the problem. The test object class was not threadsafe, resulting in multiple equal instances generated by the factory. This results in returnObject replacing rather than duplicating instances in _allObjects, which causes _allObjects to have fewer instances than _idleObjects. We need to think about this setup a little, as it will break if equal instances are ever generated by object factories and in circulation at the same time. I think it is a reasonable expectation that distinct instances generated by object factories must not be equal; but this is a new requirement and it needs to be documented and we might want to consider a guard for it. Phil Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-lang3 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-lang3 has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-lang3 : utilities for the classes that are in java.lang's hierarchy Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-lang3/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-lang3-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/lang/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/lang/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-lang3/gump_work/build_apache-commons_commons-lang3.html Work Name: build_apache-commons_commons-lang3 (Type: Build) Work ended in a state of : Failed Elapsed: 46 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/lang/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/lang] M2_HOME: /opt/maven2 - Running org.apache.commons.lang3.text.translate.UnicodeUnescaperTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.lang3.text.translate.EntityArraysTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running org.apache.commons.lang3.text.translate.LookupTranslatorTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.commons.lang3.text.ExtendedMessageFormatTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.281 sec Running org.apache.commons.lang3.text.StrSubstitutorTest Tests run: 36, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.lang3.text.CompositeFormatTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.lang3.text.StrTokenizerTest Tests run: 55, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.apache.commons.lang3.text.StrBuilderTest Tests run: 77, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec Running org.apache.commons.lang3.text.FormattableUtilsTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.lang3.StringUtilsStartsEndsWithTest Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.lang3.RandomStringUtilsTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.128 sec Running org.apache.commons.lang3.StringUtilsTest Tests run: 81, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.46 sec FAILURE! Results : Failed tests: test_isAssignable_ClassArray_ClassArray(org.apache.commons.lang3.ClassUtilsTest): null testPrimitivesToWrappers(org.apache.commons.lang3.ClassUtilsTest): null - null testWrappersToPrimitivesNull(org.apache.commons.lang3.ClassUtilsTest): Wrong result for null input testToClass_object(org.apache.commons.lang3.ClassUtilsTest): Expected: null but was: [Ljava.lang.Class;@6f7cf6b6 testStripAll(org.apache.commons.lang3.StringUtilsTrimEmptyTest): expected:null but was:[Ljava.lang.String;@61f1680f testJoin_Objectarray(org.apache.commons.lang3.StringUtilsTest): null expected:null but was: Tests run: 1873, Failures: 6, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/lang/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 45 seconds [INFO] Finished at: Mon Jun 06 08:24:35 UTC 2011 [INFO] Final Memory: 35M/92M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-lang3/rss.xml - Atom:
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 29 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 13 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.157 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 seconds [INFO] Finished at: Mon Jun 06 11:07:44 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
Re: [ognl] internal cache performance improvement
Hi Antonio, thanks for reviewing and providing feedbacks! In the existing codebase I don't see any eviction policy, I wonder if that data structure purpose is not for storing large amount of data, but rather just a memory area where quickly looking-up already processed Class related data - I know that could imply OOME but I would see it in action, maybe Struts mates can confirm if they've ever had issues with OGNL's memory. TreeMap sounds reasonable, it's an RB Tree implementation and insert/retrieve operations have both O(log n) complexity[1], I'd suggest to start with it and see how things are going, then switch to LRU if needed. WDYT? Many thanks in advance! Simo [1] http://www.coderfriendly.com/wp-content/uploads/2009/05/java_collections_v2.pdf http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Jun 6, 2011 at 9:26 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/6/6 Simone Tripodi simonetrip...@apache.org my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Pretty naive, i suppose. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). Probably you are referring to TreeMap, HashMap uses a fixed array with collisions lists. The problem with TreeMap is that any inserted key must implement Comparable, or a Comparator must be supported. Since it is a cache, wouldn't an LRUMap be more useful? http://commons.apache.org/collections/api-release/org/apache/commons/collections/map/LRUMap.html WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? I think you can go on. Surely a Map should be used, the implementation of that Map could be considered at a later stage. Antonio - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] internal cache performance improvement
2011/6/6 Simone Tripodi simonetrip...@apache.org TreeMap sounds reasonable, it's an RB Tree implementation and insert/retrieve operations have both O(log n) complexity[1], I'd suggest to start with it and see how things are going, then switch to LRU if needed. WDYT? Many thanks in advance! +1, TreeMap is fine for now. Antonio
Re: [GUMP@vmgump]: Project commons-lang3 (in module apache-commons) failed
On 6 June 2011 09:24, Gump iss...@commons.apache.org wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-lang3 has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-lang3 : utilities for the classes that are in java.lang's hierarchy Oops - that was caused by my fixes for the Eclipse warnings about varargs invocatiions. Only the (Class?[]) casts work. I'll fix up the errors shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Travel Assistance applications open for ApacheCon North America 2011
The Apache Software Foundation (ASF)'s Travel Assistance Committee (TAC) is now accepting applications for ApacheCon North America 2011, 7-11 November in Vancouver BC, Canada. The TAC is seeking individuals from the Apache community at-large --users, developers, educators, students, Committers, and Members-- who would like to attend ApacheCon, but need some financial support in order to be able to get there. There are limited places available, and all applicants will be scored on their individual merit. Financial assistance is available to cover flights/trains, accommodation and entrance fees either in part or in full, depending on circumstances. However, the support available for those attending only the BarCamp (7-8 November) is less than that for those attending the entire event (Conference + BarCamp 7-11 November). The Travel Assistance Committee aims to support all official ASF events, including cross-project activities; as such, it may be prudent for those in Asia and Europe to wait for an event geographically closer to them. More information can be found at http://www.apache.org/travel/index.html including a link to the online application and detailed instructions for submitting. Applications will close on 8 July 2011 at 22:00 BST (UTC/GMT +1). We wish good luck to all those who will apply, and thank you in advance for tweeting, blogging, and otherwise spreading the word. Regards, The Travel Assistance Committee - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCE] Commons NET 3.0.1 released
The Apache Commons Net team are pleased to announce the release of Commons Net version 3.0.1. *** This is a bug-fix release which corrects a regression in 3.0 *** * NET-409: FTPClient truncates file (storeFile method). All users are encouraged to upgrade to 3.0.1. This release is binary compatible with 2.2 (and 3.0), but there are some minor changes to source compatibility, please read the release notes for full details: http://www.apache.org/dist/commons/net/RELEASE-NOTES.txt [These are also included with the binary and source archives] The changes are also available at: http://commons.apache.org/net/changes-report.html Binary and source archives are available from the usual download locations. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] internal cache performance improvement
Does concurrency need to be taken into account for the cache? If so, you need to consider how access to the cache will be synchronized. An intrinsic lock? A ConcurrentHashMap? and so on. Gary On Mon, Jun 6, 2011 at 2:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all OGNL folks, my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? Looking forward to your feedbacks, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [ognl] internal cache performance improvement
Gary hit the nail on the head, considering that OGNL usually runs in a multi-thread environment like struts, concurrency is a must. At first glance LRUMap would seem the appropriate choice (it was thought for this purpose), unfortunately LRUMap is not thread safe, surely we can wrap using Collections#synchronizedMap, but it will always a bottlenecks. On the other hand ConcurrentHashMap seems the appropriate choice (Currently the synchronized keyword has 18 match inside the OgnlRuntime class). We could eventually consider to allow the user to decide which implementation to choose. Since I have many complex struts application in production, I can do a little test. On 6 June 2011 16:55, Gary Gregory garydgreg...@gmail.com wrote: Does concurrency need to be taken into account for the cache? If so, you need to consider how access to the cache will be synchronized. An intrinsic lock? A ConcurrentHashMap? and so on. Gary On Mon, Jun 6, 2011 at 2:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all OGNL folks, my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? Looking forward to your feedbacks, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [ognl] internal cache performance improvement
-Original Message- From: maurizio.cucchi...@gmail.com [mailto:maurizio.cucchi...@gmail.com] On Behalf Of Maurizio Cucchiara Sent: Monday, June 06, 2011 12:14 To: Commons Developers List Subject: Re: [ognl] internal cache performance improvement Gary hit the nail on the head, considering that OGNL usually runs in a multi-thread environment like struts, concurrency is a must. While struts2 is multi-threaded access to a given value stack should be in a single thread, unless explicitly threaded by custom code of the OP. At first glance LRUMap would seem the appropriate choice (it was thought for this purpose), unfortunately LRUMap is not thread safe, surely we can wrap using Collections#synchronizedMap, but it will always a bottlenecks. On the other hand ConcurrentHashMap seems the appropriate choice (Currently the synchronized keyword has 18 match inside the OgnlRuntime class). We could eventually consider to allow the user to decide which implementation to choose. Since I have many complex struts application in production, I can do a little test. On 6 June 2011 16:55, Gary Gregory garydgreg...@gmail.com wrote: Does concurrency need to be taken into account for the cache? If so, you need to consider how access to the cache will be synchronized. An intrinsic lock? A ConcurrentHashMap? and so on. Gary On Mon, Jun 6, 2011 at 2:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all OGNL folks, my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? Looking forward to your feedbacks, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] internal cache performance improvement
Jason, you're right there is one OGNL context per request in struts, but at the time that the OGNL code was written, concurrency was taken into account, so at this point I think we don't have other choice (there could be other projects that rely on the OGNL thread-safety). On 6 June 2011 18:24, Jason Pyeron jpye...@pdinc.us wrote: -Original Message- From: maurizio.cucchi...@gmail.com [mailto:maurizio.cucchi...@gmail.com] On Behalf Of Maurizio Cucchiara Sent: Monday, June 06, 2011 12:14 To: Commons Developers List Subject: Re: [ognl] internal cache performance improvement Gary hit the nail on the head, considering that OGNL usually runs in a multi-thread environment like struts, concurrency is a must. While struts2 is multi-threaded access to a given value stack should be in a single thread, unless explicitly threaded by custom code of the OP. At first glance LRUMap would seem the appropriate choice (it was thought for this purpose), unfortunately LRUMap is not thread safe, surely we can wrap using Collections#synchronizedMap, but it will always a bottlenecks. On the other hand ConcurrentHashMap seems the appropriate choice (Currently the synchronized keyword has 18 match inside the OgnlRuntime class). We could eventually consider to allow the user to decide which implementation to choose. Since I have many complex struts application in production, I can do a little test. On 6 June 2011 16:55, Gary Gregory garydgreg...@gmail.com wrote: Does concurrency need to be taken into account for the cache? If so, you need to consider how access to the cache will be synchronized. An intrinsic lock? A ConcurrentHashMap? and so on. Gary On Mon, Jun 6, 2011 at 2:36 AM, Simone Tripodi simonetrip...@apache.orgwrote: Hi all OGNL folks, my today's topic is about internal cache, that can be IMHO improved in therms of performance; its implementation is a multi-value map alike, based on a fixed-size array, a function is applied to each key to calculate the array index, each array element is a Collection of element. Even if getting the list of element related to a general key 'k' has complexity of O(1), which is fine, insert/search operations are not the best because their complexity is O(m) where m is the size of list related to the key. Follow below my proposal: there's no need to reinvent the wheel, so the array implementation can be replaced with the already provided HashMap, where each map value is a simple implementation of balanced binary heap (AFAIK commons-collections already provides an implementation), that allows us reducing insert/search complexity to O(log m). WDYT? Is is a worth or trivial added value? I know that maybe cache dimension is relatively small, but linear search sounds too basic, isn't it? Looking forward to your feedbacks, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [GUMP@vmgump]: Project commons-lang3 (in module apache-commons) failed
On 6 June 2011 22:47, Jörg Schaible joerg.schai...@gmx.de wrote:
sebb wrote:
On 6 June 2011 09:24, Gump iss...@commons.apache.org wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-lang3 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build
Failed'. For reference only, the following projects are affected by this:
- commons-lang3 : utilities for the classes that are in java.lang's
hierarchy
Oops - that was caused by my fixes for the Eclipse warnings about
varargs invocatiions.
Only the (Class?[]) casts work. I'll fix up the errors shortly.
You could have done this:
= %
- assertNull(null - null,
ClassUtils.primitivesToWrappers((Class?[]) null)); // test both types of
...
- assertNull(null - null,
ClassUtils.primitivesToWrappers((Class?) null)); // ... varargs
invocation
+ assertNull(null - null, ClassUtils.primitivesToWrappers());
Fails, see below.
+ assertNull(null - null,
ClassUtils.primitivesToWrappers((Class?[]) null)); // explicit cast to
avoid warning
I was trying to fix the warning generated by the following code:
assertNull(null - null, ClassUtils.primitivesToWrappers(null));
i.e.
The argument of type null should explicitly be cast to Class?[] for
the invocation of the varargs method primitivesToWrappers(Class?...)
from type ClassUtils. It could alternatively be cast to Class? for a
varargs invocation
There are several ways to call the varargs method with a null parameter:
1) ClassUtils.primitivesToWrappers(null); // generates the warning
2) ClassUtils.primitivesToWrappers((Class?[]) null);
3) ClassUtils.primitivesToWrappers((Class?) null);
4) ClassUtils.primitivesToWrappers(); // no parameter
1) and 2) both result in passing a null parameter to the method, so
that is why I eventually chose to replace 1) by 2)
3) is equivalent to
ClassUtils.primitivesToWrappers(new Class?[]{null}); // i.e array
length 1 containing null
4) is equivalent to
ClassUtils.primitivesToWrappers(new Class?[0]); // empty array
or equally
ClassUtils.primitivesToWrappers(new Class?[]{}); // empty array
AFAICT, neither of these are currently tested; they probably should be.
Now the Javadoc says that an empty array is returned as an empty
array, so the following fails:
assertNull(null - null, ClassUtils.primitivesToWrappers());
The following succeeds:
assertTrue(empty - empty,
Arrays.equals(ArrayUtils.EMPTY_CLASS_ARRAY,
ClassUtils.primitivesToWrappers()));
= %
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ognl] internal cache performance improvement
Simone, a look at put( Class? key, T value )[1] implementation of Aside that put method is public, IIUC the only class that calls put is only the OgnlRuntime one (and almost every time it invokes inside a sync block). ClassCacheImpl: the whole block should be controlled by a concurrency policy, not only the access to the data structure... WDYT? The main reason of proposing a TreeMap instead of an LRU cache is that, in the curent implementation, for each key there could be more than one value, keeping the multiple values in a kind of inefficient linked list, that makes inserts/searches inefficient with complexity of O(n), with TreeMap we can decrease it to O(log n). I'm not sure understand what you mean, how do you think to handle the key collisions (not even TreeMap supports duplicate keys)? At least an HashMap implementation (et similia) can guarantee a lower complexity than TreeMap (unless the order is not important), or am I missing something? I supposed that the new map implementation will replace the _table array, please correct me if I'm wrong. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Travel Assistance applications now open for ApacheCon NA 2011
The Apache Software Foundation (ASF)'s Travel Assistance Committee (TAC) is now accepting applications for ApacheCon North America 2011, 7-11 November in Vancouver BC, Canada. The TAC is seeking individuals from the Apache community at-large --users, developers, educators, students, Committers, and Members-- who would like to attend ApacheCon, but need some financial support in order to be able to get there. There are limited places available, and all applicants will be scored on their individual merit. Financial assistance is available to cover flights/trains, accommodation and entrance fees either in part or in full, depending on circumstances. However, the support available for those attending only the BarCamp (7-8 November) is less than that for those attending the entire event (Conference + BarCamp 7-11 November). The Travel Assistance Committee aims to support all official ASF events, including cross-project activities; as such, it may be prudent for those in Asia and Europe to wait for an event geographically closer to them. More information can be found at http://www.apache.org/travel/index.html including a link to the online application and detailed instructions for submitting. Applications will close on 8 July 2011 at 22:00 BST (UTC/GMT +1). We wish good luck to all those who will apply, and thank you in advance for tweeting, blogging, and otherwise spreading the word. Regards, The Travel Assistance Committee - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
