| Summary: | w/ lots of compat groups defined, scrolling quickly to bottom of table on #Inventory/Groups/AllGroups view, causes gwt RequestTimeoutException | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Ian Springer <ian.springer> |
| Component: | Core UI | Assignee: | Robert Buck <rbuck> |
| Status: | CLOSED WORKSFORME | QA Contact: | Mike Foley <mfoley> |
| Severity: | high | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 4.0.1 | CC: | ccrouch, hrupp, mazz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-10-12 19:54:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 678340, 717358, 722548, 729848, 730796 | ||
Should try to reproduce first and then fix/mitigate as appropriate I could not reproduce this. I had 579 compat groups and scrolling was good enough for me. I could scroll across the whole group in 3 seconds or so. Please confirm this as an issue, Ian. This worked perfectly for me. |
In the perf env, I have 358 compat groups defined. When I go to the #Inventory/Groups/AllGroups, the view loads fine. But if I then scroll quickly to the bottom of the table, I get the following error and the table is blank: Failed to load group composite data. This occurred because the server is taking a long time to complete this request. Please be aware that the server may still be processing your request and it may complete shortly. You can check the server logs to see if any abnormal errors occurred. Severity : Warning Time : Monday, July 11, 2011 3:47:51 PM Etc/GMT+4 Detail : com.google.gwt.http.client.RequestTimeoutException:A request timeout has expired after 10000 ms --- STACK TRACE FOLLOWS --- A request timeout has expired after 10000 ms at Unknown.com_google_gwt_http_client_RequestTimeoutException_$RequestTimeoutException__Lcom_google_gwt_http_client_RequestTimeoutException_2Lcom_google_gwt_http_client_Request_2ILcom_google_gwt_http_client_RequestTimeoutException_2(Unknown source:0) at Unknown.com_google_gwt_http_client_Request_$fireOnTimeout__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_RequestCallback_2V(Unknown source:0) at Unknown.com_google_gwt_http_client_Request$3_run__V(Unknown source:0) at Unknown.com_google_gwt_user_client_Timer_fire__V(Unknown source:0) at Unknown.anonymous(Unknown source:0) at Unknown.com_google_gwt_core_client_impl_Impl_entry0__Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2(Unknown source:0) at Unknown.anonymous(Unknown source:0) at Unknown.anonymous(Unknown source:0) We'll need to increase the 10000 timeout to a much larger number to find out how long the RPC call takes to complete. Once we have that info, we can decide whether we want to permanently increase the timeout and/or tune the performance of the underlying SLSB method.