Re: Can I use LoginModulePlugins in Oak?
hi bertrand IMHO the LoginModulePlugin mechanism in sling has some fundamental flaws. for example it extends from a implementation detail in jackrabbit core (DefaultLoginModule) that is pluggable by means of changing the configuration and not a built-in functionality. then, the individual implementations such as FormLoginModulePlugin.java register themselves as service, which basically shows a fundamental misunderstanding of how the JAAS LoginModule works and is designed (every login gets it's own instance). afaik there is no reasonable way how you can get that fixed with oak. if i was you i would just deprecate that unfortunate part of sling that intended to make the login module pluggable at runtime and drop it asap. kind regards angela On 11/1/13 5:49 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, Some Sling integration tests (SLING-3221) are failing, due to a form login mechanism that's supported by Sling's FormLoginModulePlugin [1] when running on Jackrabbit, and is not present on our Oak setup. Can I use plugins that implement org.apache.sling.jcr.jackrabbit.server.security.LoginModulePlugin in Oak (and how), or is there a similar mechanism? -Bertrand [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/auth/form/src/main/ja va/org/apache/sling/auth/form/impl/FormLoginModulePlugin.java
Re: Can I use LoginModulePlugins in Oak?
Hi Angela, On Mon, Nov 4, 2013 at 9:53 AM, Angela Schreiber anch...@adobe.com wrote: ...if i was you i would just deprecate that unfortunate part of sling that intended to make the login module pluggable at runtime and drop it asap Ok, but how do you suggest implementing the use case that's covered by Sling's current FormLoginModulePlugin? http://jackrabbit.apache.org/jackrabbit-configuration.html says if JAAS authentication is not available or (as is often the case) too complex to set up, Jackrabbit allows you to specify a repository-specific JAAS LoginModule that is then used for authenticating repository users. I'm basically looking for the equivalent in Oak, something that a Sling instance can setup by default, without requiring users to do any configuration. -Bertrand
Re: Can I use LoginModulePlugins in Oak?
hi bertrand there is no replacement for the repository.xml configuration in OAK; for neither of the elements mentioned on the jackrabbit configuration documentation. as far as the authentication is concerned the statement wrt JAAS setup is IMO no longer true. thanks to the effort made by Chetan to incorporate that direct on the Felix level, setting up runtime pluggable authentication with JAAS should no longer be an issue. and writing a LoginModule definitely can't be considered difficult. the separation between 'local' (repository.xml) and JAAS setup in jackrabbit used to be quite awkward IMO. as far as our products are concerned i am not aware of any customer making use of that local setup... are you sure that it is really the configuration part that you are fighting with? or are you rather looking for the replacement of the DefaultLoginModule? kind regards anglea On 11/4/13 9:59 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Angela, On Mon, Nov 4, 2013 at 9:53 AM, Angela Schreiber anch...@adobe.com wrote: ...if i was you i would just deprecate that unfortunate part of sling that intended to make the login module pluggable at runtime and drop it asap Ok, but how do you suggest implementing the use case that's covered by Sling's current FormLoginModulePlugin? http://jackrabbit.apache.org/jackrabbit-configuration.html says if JAAS authentication is not available or (as is often the case) too complex to set up, Jackrabbit allows you to specify a repository-specific JAAS LoginModule that is then used for authenticating repository users. I'm basically looking for the equivalent in Oak, something that a Sling instance can setup by default, without requiring users to do any configuration. -Bertrand
Re: [oak] ACL cache performance
On Monday, November 4, 2013, Angela Schreiber wrote: hi thanks for the figures and the effort. btw... this discussion belong oak dev list and not to the adobe internal list - moving. if the global cache doesn't add to much to the performance gain then i would suggest that we drop it immediately... sure, I'll look at it again. in jackrabbit the caching on a global level was the most troublesome part of the whole permission evaluation and i would definitely want to avoid running into the same issues again. i would suggest to change this to an 'everyone' only cache as i proposed it earlier to you in a private discussion which also included a first draft of such an everyone-cache. yes. although it should be a general cache that looks at the principals that have a lot permission entries. this might be the everyone, but can also be other ones. regards Toby regards angela On 11/1/13 8:43 AM, Tobias Bocanegra tri...@adobe.com wrote: Hi, I quickly tested the ACL performance again using the ManyUserReadTest. The tests consists of reading 10k items from a 120k item repository which has an ACL set on every 10th node. Each tests uses a different user (1 of 1000) which each is member of 10 groups. if my tests are accurate, oak shows now the same performance as jackrabbit. for admin sessions, it's even faster than jackrabbit. I find it still not acceptable, that the non-admin case is 3 times slower than the admin case. it's also of significance, that the global cache does not really gain much performance for this test. see the last section of numbers. I think that the global ACL cache is only beneficial for some principals, like everyone that are used for every request. and/or only really makes a difference, if the overall ACL evaluation overhead is reduced. Regards, Toby Executing benchmarks as admin: false on Oak-Tar --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Oak-Tar , 1,565,578,600,615, 627, 34 Oak-Tar , 2,653,681,715,761, 798, 56 Oak-Tar , 4,822,989, 1053, 1101, 1126, 78 Oak-Tar , 8, 1509, 1626, 1722, 1798, 1893, 96 Oak-Tar , 10, 1905, 2041, 2175, 2298, 2375,100 Oak-Tar , 15, 2545, 2850, 3201, 3484, 3663,103 Oak-Tar , 20, 3519, 3852, 4254, 4737, 5251,100 Oak-Tar , 50, 2666, 9504, 10450, 11440, 13050,104 Executing benchmarks as admin: false on Jackrabbit --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Jackrabbit , 1,455,495,539,625, 1148, 36 Jackrabbit , 2,507,512,575,841, 1264, 62 Jackrabbit , 4,768,789,861, 1220, 1266, 88 Jackrabbit , 8, 1416, 1516, 1624, 1999, 2038, 96 Jackrabbit , 10, 1764, 1812, 2074, 2796, 2859, 90 Jackrabbit , 15, 3030, 3077, 3611, 3841, 3950, 90 Jackrabbit , 20, 4495, 4683, 4874, 5031, 5121,100 Jackrabbit , 50, 12219, 12546, 12827, 13232,
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/3591 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1538589 Blamelist: thomasm BUILD FAILED: failed compile sincerely, -The Buildbot
jackrabbit-oak build #2530: Broken
Build Update for apache/jackrabbit-oak - Build: #2530 Status: Broken Duration: 349 seconds Commit: b2d18fc664d7732b308034516313fe822a09ec11 (trunk) Author: Thomas Mueller Message: OAK-1080: MongoMK: improved concurrency git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538589 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/d48596ba8bed...b2d18fc664d7 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13471605 -- sent by Jukka's Travis notification gateway
Re: jackrabbit-oak build #2530: Broken
Sorry about that, should be fixed now. On 11/4/13 2:33 PM, Travis CI ju...@apache.org wrote: Build Update for apache/jackrabbit-oak - Build: #2530 Status: Broken Duration: 349 seconds Commit: b2d18fc664d7732b308034516313fe822a09ec11 (trunk) Author: Thomas Mueller Message: OAK-1080: MongoMK: improved concurrency git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538589 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/d48596ba8bed...b2d18fc664 d7 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13471605 -- sent by Jukka's Travis notification gateway
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/3594 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1538619 Blamelist: angela BUILD FAILED: failed compile sincerely, -The Buildbot
jackrabbit-oak build #2533: Still Failing
Build Update for apache/jackrabbit-oak - Build: #2533 Status: Still Failing Duration: 1394 seconds Commit: 574c9832c731f89b7c343639a1e21e5b4a2c6c80 (trunk) Author: Angela Schreiber Message: OAK-64: privilege mgt - remove unused code - change signature of getInstance(PrivilegeBits) to allow for specifying multiple base privileges git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538618 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/8f6fc6151459...574c9832c731 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13473849 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2534: Still Failing
Build Update for apache/jackrabbit-oak - Build: #2534 Status: Still Failing Duration: 1437 seconds Commit: eb0c4ef665208aaca9916b615918ab4988f54baa (trunk) Author: Angela Schreiber Message: OAK-527: permissions - improve calculation of readstatus in case the target node and all it's properties can be read git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538619 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/574c9832c731...eb0c4ef66520 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13473930 -- sent by Jukka's Travis notification gateway
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/3595 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1538638 Blamelist: angela Build succeeded! sincerely, -The Buildbot
jackrabbit-oak build #2535: Errored
Build Update for apache/jackrabbit-oak - Build: #2535 Status: Errored Duration: 3003 seconds Commit: a776ce5901c1633c6c98a7d5e4345684d223d930 (trunk) Author: Angela Schreiber Message: OAK-64: privilege mgt - change signature of getInstance(PrivilegeBits) to allow for specifying multiple base privileges git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538638 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/eb0c4ef66520...a776ce5901c1 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13475610 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2538: Errored
Build Update for apache/jackrabbit-oak - Build: #2538 Status: Errored Duration: 3002 seconds Commit: f57fd51e35bfb74890751112c8e38242c789e966 (trunk) Author: Angela Schreiber Message: OAK-527: minor improvement (unused import, javadoc, unused methods) git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538643 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/4fabddb8a131...f57fd51e35bf View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13476281 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2536: Errored
Build Update for apache/jackrabbit-oak
-
Build: #2536
Status: Errored
Duration: 3002 seconds
Commit: 122c97282671f61740e2ac3add98125e269283f9 (trunk)
Author: Angela Schreiber
Message: OAK-527: remove unused imports, coding style: replace code by {@code}
git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538641
13f79535-47bb-0310-9956-ffa450edef68
View the changeset:
https://github.com/apache/jackrabbit-oak/compare/a776ce5901c1...122c97282671
View the full build log and details:
https://travis-ci.org/apache/jackrabbit-oak/builds/13476008
--
sent by Jukka's Travis notification gateway
jackrabbit-oak build #2539: Errored
Build Update for apache/jackrabbit-oak - Build: #2539 Status: Errored Duration: 3003 seconds Commit: ec2424561541d6a6665955c3d2611e1f7302671b (trunk) Author: Marcel Reutegger Message: OAK-1080: MongoMK: improved concurrency - always write back _lastRev in background thread to make sure it contains in fact the last modified revision for this cluster instance git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538644 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/f57fd51e35bf...ec2424561541 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13476396 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2540: Errored
Build Update for apache/jackrabbit-oak - Build: #2540 Status: Errored Duration: 3002 seconds Commit: d3d8b28c4f1eb2637d51c0a5b98fc27b17875ae7 (trunk) Author: Jukka Zitting Message: OAK-1015: Optimise path parsing Handle the foo:bar:baz case brought up by Michael git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538647 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/ec2424561541...d3d8b28c4f1e View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13476941 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2541: Errored
Build Update for apache/jackrabbit-oak - Build: #2541 Status: Errored Duration: 3002 seconds Commit: 9350863b7ecfbf8db049923fa22f741869f1ecb7 (trunk) Author: Angela Schreiber Message: OAK-527: benchmark script; type and minor improvement git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538650 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/d3d8b28c4f1e...9350863b7ecf View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13477673 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2542: Errored
Build Update for apache/jackrabbit-oak - Build: #2542 Status: Errored Duration: 3002 seconds Commit: 6a77a7d6d3a0eb5244894116ea74c18091f2acbf (trunk) Author: Jukka Zitting Message: OAK-781: Clarify / fix effects of MISSING_NODE as base state of NodeBuilder NodeBuilder.getBaseState() can no longer return null git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538700 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/9350863b7ecf...6a77a7d6d3a0 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13484706 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #2543: Passed
Build Update for apache/jackrabbit-oak - Build: #2543 Status: Passed Duration: 1532 seconds Commit: b6e93066022d63df671a1f0863441de9a067423b (trunk) Author: Tobias Bocanegra Message: OAK-1138 Implement global per principal permission entry cache (wip) - make EntryIterator even more lazy (avoid seekNext() in next()) - only cache 'everyone's entries globally git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1538870 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/6a77a7d6d3a0...b6e93066022d View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/13509500 -- sent by Jukka's Travis notification gateway
Re: [oak] ACL cache performance
Hi, I made some minor changes to cache handling, so that it only caches the everyone's entries. I also optimized the entry iterator slightly, so that it's even more lazy. together with the improvements of jukka the micro benchmarks look really good, at least for the ManyUserReadTest. If we also get rid of the SecurityContext, I expect even further improvements. Regards, Toby Benchmarks: ManyUserReadTest Fixtures: Oak-Tar Jackrabbit Runtime: 10 Num Items: 1 Concurrency: 1,2,4,8,10,15,20,50 Random User: true Profiling: false -- Executing benchmarks as admin: false on Oak-Tar --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Oak-Tar , 1,292,302,308,316, 326, 33 Oak-Tar , 2,322,335,343,357, 365, 60 Oak-Tar , 4,416,453,474,501, 515, 87 Oak-Tar , 8,699,717,746,770, 800,112 Oak-Tar , 10,790,889,940,991, 1027,110 Oak-Tar , 15,711, 1315, 1428, 1518, 1590,111 Oak-Tar , 20, 1430, 1603, 1919, 2090, 2240,117 Oak-Tar , 50, 2519, 2997, 4640, 5632, 6626,127 Executing benchmarks as admin: false on Jackrabbit --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Jackrabbit , 1,328,338,347,383, 705, 28 Jackrabbit , 2,399,404,432,647, 856, 44 Jackrabbit , 4,528,539,565,959, 979, 64 Jackrabbit , 8, 1106, 1130, 1166, 1514, 1554, 72 Jackrabbit , 10, 1368, 1399, 1467, 1833, 1886, 70 Jackrabbit , 15, 2016, 2137, 2259, 2617, 2710, 75 Jackrabbit , 20, 1496, 1562, 3357, 3595, 3729, 70 Jackrabbit , 50, 8222, 8563, 8814, 9022, 9416,100 Executing benchmarks as admin: true on Oak-Tar --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Oak-Tar , 1,127,128,132,136, 140, 76 Oak-Tar , 2,144,148,155,160, 165,130 Oak-Tar , 4,188,206,217,227, 243,186 Oak-Tar , 8,314,343,355,367, 395,231 Oak-Tar , 10,289,432,462,498, 534,220 Oak-Tar , 15,386,624,703,785, 868,219 Oak-Tar , 20,535,832,948, 1125, 1357,215 Oak-Tar , 50, 1372, 1810, 2415, 3013, 3692,223 Executing benchmarks as admin: true on Jackrabbit --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Jackrabbit , 1,245,247,259,300, 630, 37 Jackrabbit , 2,296,301,310,360, 631, 60 Jackrabbit , 4,413,428,474,711, 762, 80 Jackrabbit , 8,465,783,872, 1137, 1200, 89 Jackrabbit , 10,927,981, 1114, 1494, 1599, 92 Jackrabbit , 15, 1328, 1446, 1710, 2210, 2681, 90 Jackrabbit , 20,914, 1787, 2327, 3238, 3425, 88 Jackrabbit , 50, 1305, 1691, 10351, 10852, 11269, 61 On Mon, Nov 4, 2013 at 2:01 AM, Tobias Bocanegra tri...@apache.org wrote: On Monday, November 4, 2013, Angela Schreiber wrote: hi thanks for the figures and the effort. btw... this discussion belong oak dev list and not to the adobe internal list - moving. if the global cache doesn't add to much to the performance gain then i would suggest that we drop it immediately... sure, I'll look at it again. in jackrabbit the caching on a global level was the most troublesome part of the whole permission evaluation and i would definitely want to avoid running into the same issues again. i would suggest to change this to an 'everyone' only cache as i proposed it earlier to you in a private discussion which also included a first draft of such an everyone-cache. yes. although it should be a general cache that looks at the principals that have a lot permission entries. this might be the everyone, but can also be other ones. regards Toby regards angela On
Re: [oak] ACL cache performance
hi great... btw. i also added some improvement to the treepermission implementation such that for unambiguous cases the read-permission for properties present with a node is not evaluated individually. this is currently very simple and i will try if improvements allow further performance gain... e.g. if a node is not access controlled at all the read status of the parent might be inherited right away. for that matter i added another test ConcurrentReadRandomNodeAndItsPropertiesTest that doesn't randomly read items but rather reads random nodes and subsequently it's properties... while reading *all* properties is probably artificial, i assume that reading at least a couple of properties for each node is very common (e.g. reading the sling:resourceType property, reading the title of a page or reading the name of a user). kind regards angela On 11/5/13 7:40 AM, Tobias Bocanegra tri...@apache.org wrote: Hi, I made some minor changes to cache handling, so that it only caches the everyone's entries. I also optimized the entry iterator slightly, so that it's even more lazy. together with the improvements of jukka the micro benchmarks look really good, at least for the ManyUserReadTest. If we also get rid of the SecurityContext, I expect even further improvements. Regards, Toby Benchmarks: ManyUserReadTest Fixtures: Oak-Tar Jackrabbit Runtime: 10 Num Items: 1 Concurrency: 1,2,4,8,10,15,20,50 Random User: true Profiling: false -- Executing benchmarks as admin: false on Oak-Tar --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Oak-Tar , 1,292,302,308,316, 326, 33 Oak-Tar , 2,322,335,343,357, 365, 60 Oak-Tar , 4,416,453,474,501, 515, 87 Oak-Tar , 8,699,717,746,770, 800,112 Oak-Tar , 10,790,889,940,991, 1027,110 Oak-Tar , 15,711, 1315, 1428, 1518, 1590,111 Oak-Tar , 20, 1430, 1603, 1919, 2090, 2240,117 Oak-Tar , 50, 2519, 2997, 4640, 5632, 6626,127 Executing benchmarks as admin: false on Jackrabbit --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Jackrabbit , 1,328,338,347,383, 705, 28 Jackrabbit , 2,399,404,432,647, 856, 44 Jackrabbit , 4,528,539,565,959, 979, 64 Jackrabbit , 8, 1106, 1130, 1166, 1514, 1554, 72 Jackrabbit , 10, 1368, 1399, 1467, 1833, 1886, 70 Jackrabbit , 15, 2016, 2137, 2259, 2617, 2710, 75 Jackrabbit , 20, 1496, 1562, 3357, 3595, 3729, 70 Jackrabbit , 50, 8222, 8563, 8814, 9022, 9416,100 Executing benchmarks as admin: true on Oak-Tar --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Oak-Tar , 1,127,128,132,136, 140, 76 Oak-Tar , 2,144,148,155,160, 165,130 Oak-Tar , 4,188,206,217,227, 243,186 Oak-Tar , 8,314,343,355,367, 395,231 Oak-Tar , 10,289,432,462,498, 534,220 Oak-Tar , 15,386,624,703,785, 868,219 Oak-Tar , 20,535,832,948, 1125, 1357,215 Oak-Tar , 50, 1372, 1810, 2415, 3013, 3692,223 Executing benchmarks as admin: true on Jackrabbit --- # ManyUserReadTest , C,min,10%,50%,90%, max, N Jackrabbit , 1,245,247,259,300, 630, 37 Jackrabbit , 2,296,301,310,360, 631, 60 Jackrabbit , 4,413,428,474,711, 762, 80 Jackrabbit , 8,465,783,872, 1137, 1200, 89 Jackrabbit , 10,927,981, 1114, 1494, 1599, 92 Jackrabbit , 15, 1328, 1446, 1710, 2210, 2681, 90 Jackrabbit , 20,914, 1787, 2327, 3238, 3425, 88 Jackrabbit , 50, 1305, 1691, 10351, 10852, 11269, 61 On Mon, Nov 4, 2013 at 2:01 AM, Tobias Bocanegra tri...@apache.org wrote:
