Well, please remember you are always welcome to initiate discussions, feature proposals, JIRAs to express your thoughts and ideas. You can of course submit code contributions to back them or further demonstrate ideas, etc..
A couple of important notes here. This would need to be in the 1.x line. The 0.x line is no longer supported so I would only expect case by case very select specific bugs/vulnerabilities to even be considered to show up in an 0.7.x release. The concept of what you're asking for makes sense to me. However, the challenge is that the ability to introspect these queues to a much deeper level has complex performance and behavior considerations. The top 100 things we can design for and we dont have to worry about swapping, etc.. But if we want to let the user change sort order, etc.. then we also have to consider swapped out flowfiles, etc.. I think our judgement in the past on this has been the juice is not worth the squeeze. I'm not saying the idea is not sound but I'm suggesting the complexity and effort to get it is really high if even achievable without really bad side effects. Thanks On Thu, Oct 19, 2017 at 9:03 AM, James McMahon <[email protected]> wrote: > I see. Thank you Joe. Would the ability to sort the flowfiles displayed by > "List queue" be something the developers would consider if I was to open a > ticket, or would it be considered beyond the scope and intent of the "List > queue" feature? Many times when I show a customer their content in flow > processing they ask to see the latest data in the queue. > > On Thu, Oct 19, 2017 at 8:52 AM, Joe Witt <[email protected]> wrote: >> >> There is not presently a way to alter the sort order as it is purely >> meant to 'look at the queue as it is' so you can see and understand >> how the prioritization is happening and peak at the data/attributes >> involved. >> >> On Thu, Oct 19, 2017 at 7:21 AM, James McMahon <[email protected]> >> wrote: >> > Related to Alex' question, are we able to alter the sort order of the >> > 100 >> > queued files that get displayed in the UI? Often when debugging our team >> > wishes to see the most recent entries in the queue by Queued Duration. >> > It >> > appears that what gets presented are the queued files with largest >> > Queued >> > Duration. This means we aren't able to see the newest files in queue. >> > Can >> > this behavior be altered in the UI display? I am running a legacy 0.7.x >> > version of Apache NiFi. Thanks in advance. -Jim >> > >> > On Wed, Oct 18, 2017 at 10:39 AM, Willmer, Alex (UK Defence) >> > <[email protected]> wrote: >> >> >> >> Pierre, Thank you for confirming that. >> >> >> >> I was trying to debug some flowfiles that were getting routed to the >> >> Failure queue of a MergeContent block. Typing this now, it occurs to me >> >> that >> >> I could fork a PutFile processor from the Failure output of the >> >> MergeContent >> >> processor. >> >> >> >> Alex >> >> >> >> ________________________________ >> >> From: Pierre Villard [[email protected]] >> >> Sent: 18 October 2017 11:31 >> >> To: [email protected] >> >> Subject: Re: Listing more that 100 flowfiles from a queue? >> >> >> >> Hi Alex, >> >> >> >> Listing only supports the top 100 items. It is not meant to provide >> >> exhaustive listing of flow files in a given queue. It's more a way to >> >> have a >> >> live look into the queue: check attributes, content, ordering, etc. >> >> >> >> What is your use case? Any specific reason to list all the flow files >> >> in a >> >> given queue? >> >> >> >> Pierre >> >> >> >> >> >> 2017-10-18 11:35 GMT+02:00 Willmer, Alex (UK Defence) >> >> <[email protected]>: >> >>> >> >>> Hello all, >> >>> >> >>> Is it possible to list more than 100 flow files in a Queue? Either >> >>> through specifying a higher maxResults, or requesting paged results? >> >>> >> >>> The endpoint when creating a listing request defaults to >> >>> maxResults=100, >> >>> and doesn't appear to allow overriding it. E.g. to give an anonymised >> >>> example, using HTTPie as the client against NIFI 1.2.0 from HDF >> >>> 3.0.0.0 >> >>> >> >>> $ http POST >> >>> >> >>> https://example.org/nifi-api/01234567-89ab-cdef-0123-456789abcdef/listing-requests >> >>> POST /nifi-api/01234567-89ab-cdef-0123-456789abcdef/listing-requests >> >>> HTTP/1.1 >> >>> Accept: application/json, */* >> >>> Accept-Encoding: gzip, deflate >> >>> Content-Type: application/json >> >>> Host: example.org >> >>> >> >>> { >> >>> "listingRequest": { >> >>> ... >> >>> "maxResults": 100, >> >>> ... >> >>> } >> >>> } >> >>> >> >>> Sending {"maxRequests": 1000} or {"listingRequest": {"maxResults": >> >>> 1000}) >> >>> in the request body has the same result. Sending maxRequests=1000 as a >> >>> URL >> >>> parameter or form data causes an HTTP 500 error. >> >>> >> >>> Is 100 results a hard coded limit? If so, is that intentional? >> >>> >> >>> With thanks, Alex >> >>> -- >> >>> Alex Willmer | Developer >> >>> Space, Defence and National Security | CGI >> >>> 250 Brook Drive, Green Park, Reading, RG2 6UA >> >>> [email protected] | cgi-group.co.uk >> >> >> >> >> > > >
