DataSource WARN Issue re Record Clamping

[chimpeenuts]

Using Smart GWT 3.0 nightly build. Power version.

Using hibernate-based data sources to populate my data grids.

My data grids are using paging with data page size = 50.

Based on selections in my UI, the grids are re-freshed (calling grid.fetchData). Many of my tables have less than 50 records and in Eclipse/Google Development tab I see a collection of WARN statements saying the endRows are being clamped at the total record size:

Exception:

[ERROR] [SNAP] - 19:15:54.208:XRP0:WARN:ResultSet:isc_ResultSet_7 (created by: isc_ListGrid_4):fetchData callback: dsResponse.endRow set to:35. dsResponse.totalRows set to:2. endRow cannot exceed total dataset size. Clamping endRow to the end of the dataset (2).

Stack Trace:

com.smartgwt.client.core.JsObject$SGWT_WARN: 19:15:54.208:XRP0:WARN:ResultSet:isc_ResultSet_7 (created by: isc_ListGrid_4):fetchData callback: dsResponse.endRow set to:35. dsResponse.totalRows set to:2. endRow cannot exceed total dataset size. Clamping endRow to the end of the dataset (2).
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at com.google.gwt.dev.shell.MethodAdaptor.invoke(MethodAdaptor.java:105)
    at com.google.gwt.dev.shell.MethodDispatch.invoke(MethodDispatch.java:71)
    at com.google.gwt.dev.shell.OophmSessionHandler.invoke(OophmSessionHandler.java:172)
    at com.google.gwt.dev.shell.BrowserChannelServer.reactToMessages(BrowserChannelServer.java:292)
    at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:546)
    at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:363)
    at java.lang.Thread.run(Thread.java:680)

I have two questions:
1) Why doesn't the Smart GWT backend just set endRows to the total record size and NOT write the WARN message? In my own custom DMI handlers, I set DSResponse.setEndRow so was wondering if Smart GWT backend does indeed do this and, if it does.

2) Will that WARN message affect production performance? And if so, is there any way to turn off the WARN messages.

Thanks in Advance!

[Isomorphic]

So far as we know, the built-in connector never does this. Can you modify one of the samples to make this happen?

[chimpeenuts]

So far as we know, the built-in connector never does this. Can you modify one of the samples to make this happen?

I didn't try to modify one of the samples, but I imagine this is fairly easy to re-produce on your end.

I went in to where I init my listgrid and looked at my 'paging' settings:

table = new ListGrid();
table.setHeight100();
table.setWidth100();

// Set up data paging
// Tweak data page size and draw ahead ratio to trade off
// performance and server data calls
table.setShowAllRecords(false); // starts data paging
table.setDataPageSize(50); // indicates number of records to draw on each fetch
table.setDrawAheadRatio(5f); // How much data to fetch outside of current draw view

When I comment out setDrawAheadRatio the WARN message disappears.

I would like to leave this value at 5f because about half the time the grid will be displaying hundreds of records and we'd like somewhat smooth scrolling. But other times, the grid will only show 10-15 records.

It is during these 10-15 record shows that the WARN message appears.

Are you able to reproduce this WARN in Eclipse's Google Development Mode View?

[chimpeenuts]

Did some more testing...

It appears that as long as I load more than 55 records in the grid, no WARN message appears.

But if I try to load < 55 records, I get the WARN message consistently every time.

Again removing the setDrawAheadRatio eliminates the WARN but I would like to keep it higher than the default 1.3.

[Isomorphic]

We tried modifying the Hibernate Advanced Filter example to use a large drawAhead ratio yet return only 7-20 records - no warning. Let us know if you can come up with a reproducible case suggesting a framework issue.