I agree with Andrew's points. The admin UI is intended for troubleshooting and administration, and definitely not recommended as something to be "in the loop" for a bulk data process. You haven't said how old the standalone version was, but it may have predated features that syntax highlight and improve usability for the intended functions. If it was REALLY old it may have pre-dated the angular-js ui and had a lot less javascript and browser memory requirements as well.
The quick/temporary hack that *might* work for emergency purposes with zero engineering (depending on how your browser is treating the returned data, and depending on how much memory you have on the server) is: - run your query but with rows=10 and then click on the url displayed above the response display in the admin UI - This will open a window displaying ONLY the results and no admin UI (and re-execute the query in the process) - Edit the rows parameter to return what you require. - If your browser is attempting to present the data with pretty colorized syntax and collapsable elements it may still bog down and you may need to fiddle with its settings to prevent that. - If the browser seems to be the limiting factor, the URL for 10 results can be pasted and tweaked in a shell with a command line "curl" or "wget" command, but this does nothing to alleviate the dangerous load on the server such requests make. This is still not good practice and not recommended as a long term solution. Long term you should probably write an iterative cursor-mark script as suggested, or use the export handler (but you may have difficulty with /export if your legacy schema hasn't been updated to add doc values) If this is a frequently updated system, depending on how fast the script iterates, you may have an increased window for inconsistent results (see https://solr.apache.org/guide/solr/latest/query-guide/pagination-of-results.html#how-basic-pagination-is-affected-by-index-updates and https://solr.apache.org/guide/solr/latest/query-guide/pagination-of-results.html#how-cursors-are-affected-by-index-updates ) In truth there is always such a window for inconsistency on a single request because commits are not guaranteed to complete simultaneously among shards. Solr is fundamentally "eventually consistent" But iterating with a script takes more time and presents a few new ways it can return inconsistencies. If you can use /export that will usually be best. On Wed, Aug 20, 2025 at 5:02 AM Andrew Hankinson <andrew.hankinson@rism.digital> wrote: > You are going to run into all sorts of problems. > > 1. Solr itself pre-allocates the memory for the number of requested rows, > regardless of the number of results. So you're going to run into memory > limits with very high result counts. > 2. The Admin UI will slow to a crawl, and likely your browser will crash, > when it tries to parse and display that number of rows. You're asking for > an extremely high number of HTML elements and CSS rules. > > -Andrew > > > On 20 Aug 2025, at 10:24, Ariolu, Joshua <joshua.ari...@invesco.com.INVALID> > wrote: > > > > I’m asking about the Solr Admin UI. What I want to know is whether it’s > possible to retrieve a very large number of documents directly from the UI, > without having to use pagination or write an extra script. > > > > > > Previously, when we used standalone (user-managed) Solr, we could pull > that many documents in one go(100000). But now that we’ve moved to > SolrCloud, the same approach doesn’t work. > > > > > > So my question is, could this be a configuration issue with my SolrCloud > setup, or is it simply not recommended (or not possible) to pull that many > documents directly from the Solr Admin UI when working with solr cloud due > to its distributed nature? > > > > Thanks > > > > ________________________________ > > Can you elaborate on what you mean by "directly in the UI"? The solr > admin > > ui? The ui you are writing for your app? > > > > You already mentioned the two features designed for exactly that task. > Can > > you clarify why you are dissatisfied with them? > > > > Also, note that the other "just script it" reply here is either > forgetting > > to mention cursormark, or hasn't yet understood why deep paging is costly > > in distributed search systems. > > > > > > On Tue, Aug 19, 2025 at 10:43 AM Ariolu, Joshua > > <joshua.ari...@invesco.com.invalid> wrote: > > > >> Hi Solr Community, > >> I'm currently trying to retrieve around 100,000 documents directly from > >> the SolrCloud UI, but I'm encountering lock errors when attempting to > fetch > >> that many at once. Interestingly, smaller batches work fine. > >> Aside from using pagination with cursorMark or the /export request > >> handler, are there any other recommended approaches or best practices > for > >> retrieving large result sets directly from the UI without running into > such > >> issues? > >> Thanks in advance! > >> > >> Invesco Asset Management Limited, Company No. 949417, Firm Reference No. > >> 122674 > >> Invesco Fund Managers Limited, Company No. 898166, Firm Reference No. > >> 119298 > >> Invesco Pensions Limited, Company No. 3507379, Firm Reference No. 188249 > >> Invesco UK Services Limited, Company No. 06649814 > >> Invesco UK Limited, Company No. 3004959 > >> > >> The first two listed companies are authorised and regulated by the > >> Financial Conduct Authority. The third company is authorised by the > >> Prudential Regulation Authority and regulated by the Financial Conduct > >> Authority and the Prudential Regulation Authority. All companies are > >> registered in England and Wales with their registered offices at > Perpetual > >> Park, Perpetual Park Drive, Henley-on-Thames, Oxfordshire, RG9 1HH, > United > >> Kingdom. UK Group VAT No. 245 055 771. > >> > >> **************************************************************** > >> Confidentiality Note: The information contained in this > >> message, and any attachments, may contain confidential > >> and/or privileged material. It is intended solely for the > >> person(s) or entity to which it is addressed. Any review, > >> retransmission, dissemination, or taking of any action in > >> reliance upon this information by persons or entities other > >> than the intended recipient(s) is prohibited. If you received > >> this in error, please contact the sender and delete the > >> material from any device. > >> **************************************************************** > >> > > > > > > -- > > > https://urldefense.com/v3/__http://www.needhamsoftware.com__;!!PVeQBqD1!ouOJpGQ_7Q9vcV5F__Avyl3XwGmhDakefrMX8tXJbKEfBy7w9kcp1pjc8HGE_joUcbPIC0Vfle_PxgvWjwn9$ > (work) > > > https://urldefense.com/v3/__https://a.co/d/b2sZLD9__;!!PVeQBqD1!ouOJpGQ_7Q9vcV5F__Avyl3XwGmhDakefrMX8tXJbKEfBy7w9kcp1pjc8HGE_joUcbPIC0Vfle_PxtTG8QLU$ > (my fantasy fiction book) > > > > Invesco Asset Management Limited, Company No. 949417, Firm Reference No. > 122674 > > Invesco Fund Managers Limited, Company No. 898166, Firm Reference No. > 119298 > > Invesco Pensions Limited, Company No. 3507379, Firm Reference No. 188249 > > Invesco UK Services Limited, Company No. 06649814 > > Invesco UK Limited, Company No. 3004959 > > > > The first two listed companies are authorised and regulated by the > Financial Conduct Authority. The third company is authorised by the > Prudential Regulation Authority and regulated by the Financial Conduct > Authority and the Prudential Regulation Authority. All companies are > registered in England and Wales with their registered offices at Perpetual > Park, Perpetual Park Drive, Henley-on-Thames, Oxfordshire, RG9 1HH, United > Kingdom. UK Group VAT No. 245 055 771. > > > > **************************************************************** > > Confidentiality Note: The information contained in this > > message, and any attachments, may contain confidential > > and/or privileged material. It is intended solely for the > > person(s) or entity to which it is addressed. Any review, > > retransmission, dissemination, or taking of any action in > > reliance upon this information by persons or entities other > > than the intended recipient(s) is prohibited. If you received > > this in error, please contact the sender and delete the > > material from any device. > > **************************************************************** > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
