I have a custom inbox, i want to retrieve the results when i only click the search button. currently we are getting the results on screen load.
Ex. in the Task List Management when we click on the Task List Management link it loads and will not get the results and when we click on the search we get the results , i also need the same functionality (as soon as the screen loads i should get the results and when i click the search button i need to retrieve the results).
Please let me do i need add something in the code to do the same.
This is likely controlled by the default value of the “runSearchOnDisplay” preference of your custom inbox searchbar portlet. If you change the default value to false it should show the “Ready to Search” message in the search result table on the initial screen.
Custom inbox is pulling max 1000 records by default , i need to increase this size / unlimited , is there any way to increase .
i tried by setting the preference of noMaxResults to true in portlet search bar , but throwing some GC overhead error and in the search bar Maximum ‘Max Results’ value is set to 2000 .
What is the use case for displaying more than 1000 rows to the end user?
Generally, it would be a bad design to return more than that amount of data for a web based user interface. A table with thousands (or an unlimted) number of rows would be huge which could severely limit the scalability of the solution. The page would likely load quite slowly in the web browser. Also, asking the end user to scroll through thousands of rows to find something is a poor choice from a usability perspective.
you will have to make sure that IS and MWS can handle that amount of data correctly.
If your result set exceeds the java memory available for the servers you will receive an OutOfMemory error.
If there are to many results in a too short time frame the Garbage Collector can not free enough space for the next run eventually resulting in the mentioned GC overhead error.
Users wants to pause the transactions on non business hours(not to process to downstreams), so we are creating the tasks and releasing on business hours by task schedulers , during this time user wants to search or see thier transactions, we provided few filters on some business data , if the search transactions is not available in the first 1000 records user not able to see that transaction ,untill he goes for a specific time frame search (created date and time). We already said it would be a run time issue if we increase these from 1000, still user wants to check any possibility and pros and cons.
Since they were known about the TLM which used to pull more than that so why cannot we do the same here , what is the difference between the TLM and the custom inbox , if it restricted it should be restricted there as well, so there is a point for them , so need a strong resaon to convince them.
I just took a quick look at the code for a custom inbox, and the ‘No Maximum’ checkbox is visible in the UI of the SearchBar options tab. Checking that box should remove the maxResults contraint from the next search invocation. The initial value of that checkbox is driven by the true or false default value of the “noMaxResults” portlet preference in your InboxBar portlet.
However, I will just re-iterate that if the page is not reasonably limiting the amount of data loaded into memory and/or returned to the end-user then you are making the server vulnerable to a denial-of-service attack as the end-user could just flood the server with requests to load that page and exhaust all of the server resources until it becomes unusable.
i have set value for the preference max results in the search bar portlet initially with 1000 and used the filters of created date and i click on the search button to search for the specific criteria , the amount of time it takes for me to search when it set the value 1000 is same when it set the value 200 for the first search, later searches i am getting the results very quickly, in both the cases huge volume of records in my custom inbox is around 13000 records.
i see here, no matter the max results number we set time taken for the results return based on the volume of records we have in custom inbox, if we have more volume in inbox it takes time to return the results though we have filters as well the less number for the max results preference.
how do i fine tune the query to get the quick results when i have a huge volume or it is a expected behavior with respective the custom inboxes.
I suspect in your test case that the search result portlet may be limiting the number of visible rows to a slice of the total set or rows? If so, then the client-side performance may not be impacted by a large result set since you are only ever seeing a slice of the total set of rows at any time in the browser.
As for the server-side performance – Depending on which type of task search content provider you are using, your application may be consuming a lot of server-side memory since the framework might have to load the entire set of rows into a (in memory) list to sort and limit it before the visible rows are rendered for the client. If you are testing on a server that is not under load or memory constrained, you may not notice much impact. However, if you have lots of users interacting with this page at the same time, you may run out of memory eventually.
If you want to avoid extra memory consumption related to sorting the results, then you would want to make sure you are utilizing the “indexed search content provider” capability since, in that implementation it would do the sorting in database SQL query so you don’t have to load all the rows into memory to sort it.
The most dangerous scenario for the client-side performance is combining a large (or unbounded) max results from the search bar with a search result portlet that is configured with the “Number of Rows to Display” preference specified as “Show All”. In that case you are rendering all the rows at once and not utilizing the large-list paging capabilities of the table control to limit the visible part to a smaller slice.
In any case, the best practice to guard against excessive server-side memory consumption and client-side browser performance would be limit the result set to a reasonable max size.
Sorry for resurrecting an ancient post but I’m quite desperate at this stage. We’re currently experiencing the performance issues mentioned above with a CAF project created for us by SAG. We now have a bunch of users who have all set their preferences to “Show All” results and I’ve no idea how to override these selections in our custom task inbox search. I can see multiple options to restrict results by default, but everything I’ve tried seems to be overridden/ignored if you already have preferences set.
Is there a way to limit maximum search results, ignoring a user preferences? I basically want to just hardcode 20 results at this stage. There is little utility in showing anything greater than this in the UI as our users have ample search options.