Re: Mavibot cache experiment
Le 9/11/13 4:44 AM, Kiran Ayyagari a écrit : > On Tue, Sep 10, 2013 at 9:35 PM, Emmanuel Lécharny wrote: > >> Le 9/10/13 5:40 PM, Emmanuel Lécharny a écrit : >>> Hi guys, >>> >>> yestrday and today, I was implementing a cache in Mavibot to replace the >>> WeakReferences we were using previously. The rational was that with the >>> WeakReferences, we were unable to inject more than 50 000 entries in the >>> server (at this point, the GC is just going crazy trying to free some >>> WeakReferences, and it slows down the server to a pint it's unusable...) >>> >>> So after a day fighting with an EhCache implementation in Mavibot, I was >>> able to load 100K entries in the server. So far, so good, except that >>> the performances are anything but good. I can add 26 entries per second, >>> and fetch 555 entries per second. Worse than JDBM... >>> >>> Why is it so slow, especially for a search operation ? There are two >>> reasons : >>> - first, I configured the cache to store only 1000 elements (mainly >> nodes) >>> - second, when we try to update a leaf, we mostly have to load it from >>> disk, as we rarely have it in memory >>> - third, a leaf contains from 8 to 16 entries, and everytime we fetch a >>> leaf from disk, we have to deserialize the Entries, which is extremely >>> costly >>> >>> Fixing this third problem would save us a lot of time, and it's a matter >>> of adding one level of indirection (the entries would be kept as byte[], >>> and deserialized only when needed). >>> >>> If anyone has a better idea... >> indeed : the pb is that we serialize/deserialize too late. It would be >> > I think you mean 'too _early_' No, we should serialize the entry (or the values in general) before we store it into the Leaf. Leaves should only store binary values. That has 2 consequences : - we should never compare 2 values - we should add a cache to avoid fetching a value from the btree for better performances In other words, the Managed BTree cache will cache binary values, not plain java objects. Fetching an element from a BTree will then following this algorithm : - first check if the value is present in the cache using its key - if not, fetch the value from the BTree. If the leaf containing this entry is in cache, deserialize the value and return it. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Mavibot cache experiment
On Tue, Sep 10, 2013 at 9:35 PM, Emmanuel Lécharny wrote: > Le 9/10/13 5:40 PM, Emmanuel Lécharny a écrit : > > Hi guys, > > > > yestrday and today, I was implementing a cache in Mavibot to replace the > > WeakReferences we were using previously. The rational was that with the > > WeakReferences, we were unable to inject more than 50 000 entries in the > > server (at this point, the GC is just going crazy trying to free some > > WeakReferences, and it slows down the server to a pint it's unusable...) > > > > So after a day fighting with an EhCache implementation in Mavibot, I was > > able to load 100K entries in the server. So far, so good, except that > > the performances are anything but good. I can add 26 entries per second, > > and fetch 555 entries per second. Worse than JDBM... > > > > Why is it so slow, especially for a search operation ? There are two > > reasons : > > - first, I configured the cache to store only 1000 elements (mainly > nodes) > > - second, when we try to update a leaf, we mostly have to load it from > > disk, as we rarely have it in memory > > - third, a leaf contains from 8 to 16 entries, and everytime we fetch a > > leaf from disk, we have to deserialize the Entries, which is extremely > > costly > > > > Fixing this third problem would save us a lot of time, and it's a matter > > of adding one level of indirection (the entries would be kept as byte[], > > and deserialized only when needed). > > > > If anyone has a better idea... > indeed : the pb is that we serialize/deserialize too late. It would be > I think you mean 'too _early_' > way better if we process serialized values until the point we return the > result to the user : > > - addition : we receive an object, we immediately serialize it into a > byte[] and process the addition using this byte[]. We don't anymore have > to deserialize all the values from the page we will add the new value, > they are all byte[] > - search : same thing, we don't deserialize the values until we return > it to the user. > > +1 > The gain will be huge ! > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Kiran Ayyagari http://keydap.com
Re: Mavibot cache experiment
Le 9/10/13 5:40 PM, Emmanuel Lécharny a écrit : > Hi guys, > > yestrday and today, I was implementing a cache in Mavibot to replace the > WeakReferences we were using previously. The rational was that with the > WeakReferences, we were unable to inject more than 50 000 entries in the > server (at this point, the GC is just going crazy trying to free some > WeakReferences, and it slows down the server to a pint it's unusable...) > > So after a day fighting with an EhCache implementation in Mavibot, I was > able to load 100K entries in the server. So far, so good, except that > the performances are anything but good. I can add 26 entries per second, > and fetch 555 entries per second. Worse than JDBM... > > Why is it so slow, especially for a search operation ? There are two > reasons : > - first, I configured the cache to store only 1000 elements (mainly nodes) > - second, when we try to update a leaf, we mostly have to load it from > disk, as we rarely have it in memory > - third, a leaf contains from 8 to 16 entries, and everytime we fetch a > leaf from disk, we have to deserialize the Entries, which is extremely > costly > > Fixing this third problem would save us a lot of time, and it's a matter > of adding one level of indirection (the entries would be kept as byte[], > and deserialized only when needed). > > If anyone has a better idea... indeed : the pb is that we serialize/deserialize too late. It would be way better if we process serialized values until the point we return the result to the user : - addition : we receive an object, we immediately serialize it into a byte[] and process the addition using this byte[]. We don't anymore have to deserialize all the values from the page we will add the new value, they are all byte[] - search : same thing, we don't deserialize the values until we return it to the user. The gain will be huge ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Mavibot cache experiment
Hi guys, yestrday and today, I was implementing a cache in Mavibot to replace the WeakReferences we were using previously. The rational was that with the WeakReferences, we were unable to inject more than 50 000 entries in the server (at this point, the GC is just going crazy trying to free some WeakReferences, and it slows down the server to a pint it's unusable...) So after a day fighting with an EhCache implementation in Mavibot, I was able to load 100K entries in the server. So far, so good, except that the performances are anything but good. I can add 26 entries per second, and fetch 555 entries per second. Worse than JDBM... Why is it so slow, especially for a search operation ? There are two reasons : - first, I configured the cache to store only 1000 elements (mainly nodes) - second, when we try to update a leaf, we mostly have to load it from disk, as we rarely have it in memory - third, a leaf contains from 8 to 16 entries, and everytime we fetch a leaf from disk, we have to deserialize the Entries, which is extremely costly Fixing this third problem would save us a lot of time, and it's a matter of adding one level of indirection (the entries would be kept as byte[], and deserialized only when needed). If anyone has a better idea...
[jira] [Updated] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRSTUDIO-948: - Attachment: Screen Shot 2013-09-10 at 17.47.36.png I added a new integer text field to specify the 'Sort/Filter Limit' in the 'Search Result Editor' preference page. The limit has been raised to 10.000 by default. > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Assignee: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0-M9, 2.0.0 > > Attachments: ejfbhjae.png, Screen Shot 2013-09-10 at 17.47.36.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot resolved DIRSTUDIO-948. -- Resolution: Fixed Fix Version/s: 2.0.0 Fixed at revision 1521528. http://svn.apache.org/r1521528 > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Assignee: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0-M9, 2.0.0 > > Attachments: ejfbhjae.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Cache and partitions...
On Mon, Sep 9, 2013 at 11:13 AM, Emmanuel Lécharny wrote:
> Le 9/9/13 4:46 AM, Kiran Ayyagari a écrit :
> > On Sun, Sep 8, 2013 at 1:38 PM, Emmanuel Lécharny >wrote:
> >
> >> Hi guys,
> >>
> >> we need to use a cache in the partitions, for entries, aliases, and also
> >> for whatever cache the partitins could need (assuming that this can be
> >> configurable : for instance, JDBM has its own cache, but Mavibot does
> not).
> >>
> >> This cache could be handled by the CacheService, which is created in the
> >> ApacheDsService, the DefaultDirectoryServiceFactory, or in the
> >> DefautDirectoryService if it's not injected in this class.
> >>
> >> AbstractBTreePatition alady has support for entry cache and likewise
> Index
> > implementations as well
> > have support for storing the tuples in the cache
>
> Actually, the
>
> AbstractBTreePatition has the following methods :
>
> public void addToCache( String id, Entry entry )
> {
> }
>
> and
> public Entry lookupCache( String id )
> {
> return null;
> }
>
> As you can see this class is ready to suport an entry cache, but does not
> have any...
>
> ya, I just left it empty so that subclasses can decide whether to use an
entry cache or not instead
of forcing them
> The indexes can be configured so that their internal cache can benefit
> from this configuration, but again, this is partition implementation
> dependent. Now, thinking about it, as Mavibot is pretty much a standalone
> projet, I'm not sure it worth it to propagate the ApacheDS cache to Mavibot.
>
> Mavibot should be using the cache for storing its internal constructs
(Node, PageIO etc)
and a Mavibot based partition can maintain entry cache besides Mavibot
holding its internal
cache(invisible to partition)
And now, Mavibot code can be written in a way so that it can accept an
external cache manager
or can create one when not available(say in a standalone mode), so ApacheDS
can inject
a cache manager from its cache service
> The question then is to know if it's a big deal to have 2 ehCache
> instances : one for the server and one in mavibot.
>
> no, there will be only one cache manager (either injected into or created
by Mavibot)
>
> >
> >> On a side note, the CacheService is a wrapper on top of EhCache, which
> >> is, IMO, not good enough : it should be an interface, with some factory
> >> which creates various instances of CacheService instances, one of them
> >> being based on EhCache. In case we wan't to use another cache later, or
> >> design our own, then we would just instanciate the correct CacheService
> >> instance using the factory.
> >>
> > +0 IMHO, I don't see any gain in this, _very_ few might go to this extent
> > of changing the cache
>
> The gain is null, but in case we decide later to switch to another cache
> (if ehcache license changes to something incompatible with AL 2.0, for
> instance, like what we had for the Tanuki wrapper), the it would be
> easier to have an interface.
> >
> >> That being said, I thing the CacheService should be propagated down to
> >> the partitions for them to be used - or not.
> >>
> >> this is alreay the case
>
> Ahhh, you are right !
>
>
> >> The CacheService should also be configurable through the LDIF
> >> configuration file - we don't necessarily need to make the CacheService
> >> a fully configured system, because then we would face a chicken/egg pb :
> >> how do we read the configuration if we can't configure the cacheService,
> >> which will be used by the LdifPartition ?
> >>
> >> one aspect that is present in the cache service is it copies the cache
> > configuration
> > file to the config folder (not sure if this code is still present, but it
> > was present before)
>
> We have to clarify this part. There is a XML file that is used to
> configure the cache, but we also have some parameters in the partition
> and index configurations that is used for the cache (but they are not
> targetting the same cache).
>
correct, this configuration present in LDIF configuration is for the lower
level cache
of the respective backend and the XML file based one is for partition level
am sure this will be confusing and we should fix this by converging the
configuration
parameters (a big TODO)
>
> At this point, the CacheService must be started before the
> DirectoryService is started, which can be a problem. OTOH, we can't
> really wait before starting teh CacheService, because it's being
> propagated to the partitions, including the configuration partition.
> That means we need an external cache configuration.
>
> As I said, it's a typical chicken/egg situation. How do we solve it ?
>
> I think by converging both configurations, but this needs to be discussed
further
>
> >
> >> Those are elements to think about, because they are pretty critical from
> >> the performance POV. However, this is by no mean urgent : this won't fix
> >> a bug, it will just make the server to run faster.
> >>
> >> I suggest we focus on decoupling
[jira] [Commented] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762978#comment-13762978 ] Joakim Ganse commented on DIRSTUDIO-948: Brilliant, thanks. Now one of my customers will use this tool instead of buying Softerra. > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Assignee: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0-M9 > > Attachments: ejfbhjae.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRSTUDIO-948: - Fix Version/s: (was: 2.0.0-M10) 2.0.0-M9 > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Assignee: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0-M9 > > Attachments: ejfbhjae.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Arnaud Marcelot updated DIRSTUDIO-948: - Fix Version/s: 2.0.0-M10 Assignee: Pierre-Arnaud Marcelot > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Assignee: Pierre-Arnaud Marcelot >Priority: Critical > Fix For: 2.0.0-M10 > > Attachments: ejfbhjae.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762918#comment-13762918 ] Pierre-Arnaud Marcelot commented on DIRSTUDIO-948: -- Sorry, I did miss the "Search Results" keyword in the issue description. Thanks for the screenshot. :) Looking at the code, indeed we have a hard coded limitation set to 1000 search results. Maybe we should have a field for that in the preference page of Search Result Editor to allow our users to increase it (with a tooltip indicating that it's a very costly operation). Thanks for the report, that's a perfectly valid observation! > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Priority: Critical > Attachments: ejfbhjae.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Ganse updated DIRSTUDIO-948: --- Attachment: ejfbhjae.png This is my view so you can see what I'm talking about: > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Priority: Critical > Attachments: ejfbhjae.png > > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762894#comment-13762894 ] Joakim Ganse commented on DIRSTUDIO-948: Thank you for your quick reply. Unfortunately this is not the case, sorting in the tree-view works good. What I want is to sort the results on the right side where all the resulting attributes are shown and right now I can only do this by exporting and using a spreadsheet. > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Priority: Critical > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
[ https://issues.apache.org/jira/browse/DIRSTUDIO-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13762888#comment-13762888 ] Pierre-Arnaud Marcelot commented on DIRSTUDIO-948: -- Hi Joakim, Are we talking about sorting in the LDAP Browser view (the tree-view on the left of the perspective)? If yes, did you have a look at the Sorting options (accessible from the little triangle menu)? See this page on the documentation for more details: http://directory.apache.org/studio/users-guide/ldap_browser/tools_browser_view_overview.html#tools_browser_view_sortdialog Hope this helps. > Sorting search results does not work with over 1000 results > --- > > Key: DIRSTUDIO-948 > URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 > Project: Directory Studio > Issue Type: Bug > Components: studio-ldapbrowser >Affects Versions: 2.0.0-M8 (2.0.0.v20130628) > Environment: Windows 7 >Reporter: Joakim Ganse >Priority: Critical > > When Searching a large directory sorting is not possible if there are more > than 1000 results. > What I do is a standard search and then click on the attribute tab. If I have > fewer that 1000 results they sort nicely but with more than 1000 no sorting > occurs. > I can understand this from an performance perspective but it would be nice to > have the option to set the limit as we have in other areas. > Maybe it is possible but I just have not found the right place to adjust it. > Thanks > Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DIRSTUDIO-948) Sorting search results does not work with over 1000 results
Joakim Ganse created DIRSTUDIO-948: -- Summary: Sorting search results does not work with over 1000 results Key: DIRSTUDIO-948 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-948 Project: Directory Studio Issue Type: Bug Components: studio-ldapbrowser Affects Versions: 2.0.0-M8 (2.0.0.v20130628) Environment: Windows 7 Reporter: Joakim Ganse Priority: Critical When Searching a large directory sorting is not possible if there are more than 1000 results. What I do is a standard search and then click on the attribute tab. If I have fewer that 1000 results they sort nicely but with more than 1000 no sorting occurs. I can understand this from an performance perspective but it would be nice to have the option to set the limit as we have in other areas. Maybe it is possible but I just have not found the right place to adjust it. Thanks Joakim -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
