[WEBCLIENT-293] A large number of results when searching by name hangs the webclient Created: 21/Sep/15 Updated: 18/Sep/19 Resolved: 28/Aug/19 |
|
| Status: | Closed |
| Project: | i2b2 Web Client |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.7.12 |
| Type: | Bug | Priority: | Major |
| Reporter: | Nathan Graham | Assignee: | Reeta Metta |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: | The webclient/JBoss server runs CentOS release 6.6, 8G RAM, PostgreSQL. We've seen the issue with various client computers/browsers. | ||
| Sprint: | Deferred |
| Affects View/s: |
Find Terms
|
| i2b2 Feature/s: |
Find by Name
|
| i2b2 Sponsored Project/s: |
i2b2 Web Client
|
| Affects Database/s: |
PostgreSQL
|
| Other Database: | I presume all databases are affected, though we only have PostgreSQL to try. |
| Affects Web Browser/s: |
Chrome, Firefox
|
| Reproduction Notes: | I am able to reproduce some of this issue but I'm not able to reproduce the hanging and this may be due to the fact that I am testing with demo data. Here is what I can reproduce in the demo and testing environments.
1. The exceed limit warning is appearing more than once (I was only able to get it to appear two times. 2. The second warning is a newer warning in which an additional prompt is added to the bottom of the message that allows users to check it off to prevent additional windows from popping up. 3. Sometimes when you check this new prompt preventing additional pop-ups the Web Client will crash (completely close the Web Client). This one is harder to reproduce. The above issues where found using Chrome. Additional testing would be needed on the other browsers to find any other issues. Also, in the demo data you can use Diabetes as Aspirin has less than 200. The other option is to lower the count to 20. This will force the warning message. |
| Participant/s: |
| Description |
|
Babel (https://babel.gpcnetwork.org/) is an installation of i2b2 we use to load terms from all GPC sites so members can see what other sites have in their i2b2.
One of the more important features is the ability to search for terms across all sites. Unfortunately, searching for something with a large number of results ends up freezing the client browser. We have 13,197,373 rows in the various metadata tables. Reproduction steps: * Click the "Find" tab, then enter "aspirin" (something common) in the search box (the default values for the drop-downs: "Containing" and "AnyCategory") * Leave the default "Maximum Number of Children to Display" (green check box in the top right of the ontology/find panel). * Click "Find" A dialog pops up saying: "The number of terms that were returned exceeded the maximum number currently set to 200. Please try again with a more specific search or increase the maximum number of terms that can be returned as defined in the options screen". Click "OK" - the dialog keeps popping up (rather than limiting the results to 200). After the dialog reappears a few times, the webclient "freezes" (cannot click buttons, scroll in any of the panels, etc). Eventually, a dialog pops up saying "Page Unresponsive - the following page has become unresponsive. You can wait for it to become responsive or kill it". In Chrome, Selecting "Wait" results in the page still being frozen. Selecting "Kill" sends you to an error page (generated by Chrome). Firefox has similar behavior, though killing the script sometimes doesn't actually seem to kill it the first time. Searching for something much more specific (for example, "Note Concepts (EPIC#ROOTNODE)" which only exists a couple of times seems to work as expected - the single result is found. We'd like to be able to see results even if there are a lot of them. It would at least be nice to avoid freezing the browser in these cases - it seems like the option to limit the number of results doesn't have the desired behavior. |
| Comments |
| Comment by Nich [ 09/Dec/15 ] |
|
It appears that the current behavior is that the browser waits until the search is completed (to be able to have the results rendered in the correct place), which means that the slow down is most likely on the database end. I would make sure that the proper indexes are on all of the metadata tables -- and/or split them up via table_access as necessary.
I am going to defer this to 1.7.08 when we can explore the searching mechanism in the web client -- mainly, switching to asynchronous so the browser doesn't freeze. |
| Comment by Jeffrey Klann [ 12/Jun/19 ] |
| v1.7.12 will improve find-by-name efficiency on both server and client. Deferring until after. Unless you would like to be a tester? |
| Comment by Jeffrey Klann [ 26/Aug/19 ] |
| This is massively improved in 1.7.12. Can you re-test in the upcoming second beta of 1.7.12? |
| Comment by Reeta Metta [ 18/Sep/19 ] |
| this is fixed now because of filter implementation on Find Terms |