Quoting Kevin O'Neill <[EMAIL PROTECTED]>: > Actually exist does this quiet well now in it's XML-RPC driver. Internally > it just stores the list of node ids matched. This keeps the result > document reasonably small and allows the results to be lazy loaded so, for > example, if you are paging your results you will only wear the cost of the > 5 documents you actaully call "next()" on.
I cannot see how this fixes the problem. It only increases the critical limit. Besides, it would obviously be more performant to push out (and read) the documents in streaming mode rather than fetching it one by one, depending on the ID. > The lack of iterators in methods like Collection.listCollections and > Collection.listResources is a problem when the collection size get large > (I'm looking at a test that involves adding over 1,000,000 documents to a > collection. Getting the list back involves a java array of 1,000,000 > elements :S). I found it critical with far less documents. On a heavily loaded web server with 10 simultaneous requests and a total response size of 5 MB each you'll see the result easily. The same server behaved astonishingly well as soon as I changed its internals to pure streaming mode. Jochen
