We are having a problem with run-away HTTP calls from a grid client to the server when we filter the grid view using server-side filtering. The situation occurs when a previous filter is removed and a new filter is immediately set by the user. The steps are:
- Remove a previous filter. An HTTP call is made to the server to return all the rows of the grid. Let’s name this “call #1”. This call takes approximately 3 seconds and returns approximately 2000 rows.
- The users sets another filter before call #1 returns. Another call is made to the server to get the filtered set of rows. Let’s name this “call #2”. The call intends to return the first 200 rows, but it returns 182 rows because that is all the rows that meet the filter criteria. Call #2 returns before call #1 returns.
- Then, without further user action, after call #1 returns, the grid makes additional calls to the server that will repeat indefinitely. Let’s name these “calls #3+”. These calls intends to return the rows over the first 200 row. But there are no such rows because of the filter. So the return contains no rows. Calls #3+ will go on indefinitely, but will stop if the users sets another filter.
- While calls #3+ are going on indefinitely, other grid actions sometimes become unstable.
Here is a network call log: https://drive.google.com/file/d/0B7RpzsijBAm-MjByZ2V1dWlGZUU/view?usp=sharing
Here is a picture of the call timing: https://drive.google.com/file/d/0B7RpzsijBAm-MjU0QV9kdHRYLUk/view?usp=sharing
Here is the code we use to set the filter headers and two callbacks we used to identify the issue:
$mygrid.attachHeader("#connector_select_filter,#connector_text_filter,#connector_text_filter,#connector_text_filter,#connector_select_filter");
$mygrid.attachEvent(“onDataReady”, function(){
log.debug(“pisgrid onDataReady event fired”);
});
$mygrid.attachEvent(“onFilterStart”, function(){
log.debug(“pisgrid onFilterStart event fired”);
});
Can you help us avoid these repeated calls?