Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
The webclient/JBoss server runs CentOS release 6.6, 8G RAM, PostgreSQL. We've seen the issue with various client computers/browsers.
-
Deferred
-
Find Terms
-
Find by Name
-
i2b2 Web Client
-
PostgreSQL
-
I presume all databases are affected, though we only have PostgreSQL to try.
-
Chrome, Firefox
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.
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.