ItemFileReadStore: can't cancel fetch

[Les]

It appears there's no way to cancel fetch in the ItemFileReadStore? store. This is potentially a large problem since widgets backed up by this store won't be able to cancel requests for data. Possibly other stores have the same problem.

http://dojotoolkit.org/forum/dojo-core-dojo-0-9/dojo-core-support/how-cancel-store-fetch

[bill]

I don't think this is a bug, as user should use store's close() method, but passing to Jared to close.

[Les]

Replying to bill:

I don't think this is a bug, as user should use store's close() method, but passing to Jared to close.

I'd appreciate if you could provide an example of canceling a fetch that would result in the dojo.xhrGet ajax request used by _fetchItems() being canceled.

[Jared Jurkiewicz]

Well, keep in mind ItemFile?*Store fetches *one* time from the server. After that, all the lookups are in-memory for the store.

From that sense, it doesn't make sense to kill the xhr, as it needs the data to load at least once for any sort of fetching to work. This is also why .abort operates the way it does in simpleFetch, if the store is all in-memory processing, then there isn't any xhr requests occuring outside of the very first one which populates it in the first place.

[Les]

Replying to jaredj:

Well, keep in mind ItemFile?*Store fetches *one* time from the server. After that, all the lookups are in-memory for the store.

From that sense, it doesn't make sense to kill the xhr, as it needs the data to load at least once for any sort of fetching to work. This is also why .abort operates the way it does in simpleFetch, if the store is all in-memory processing, then there isn't any xhr requests occuring outside of the very first one which populates it in the first place.

Here's my problem: I have a custom widget that uses a store to fetch data. The widget is created and then right away destroyed. However, the store's fetch keeps downloading data even though the widget that created it is destroyed. I want to cancel the fetch and there's no way to do it.

[bill]

FWIW this is what widgets have a destroy() method for.

I suspect close() w/no arguments is the equivalent for dojo.data stores but the documentation is unclear to me.

[Les]

Replying to bill:

FWIW this is what widgets have a destroy() method for.

I suspect close() w/no arguments is the equivalent for dojo.data stores but the documentation is unclear to me.

I store's close could kill the (pending) xhr that fetch started, that would be a good solution. Right now close is just resetting store's variables. It's not canceling any requests.

[jameyg]

I think there's two levels to this bug:

1. the response from IFRS.fetch() does not comply w/ the API of data.api.Request as it does not contain an abort() method (it's not added until an dojo.xhr callback is executed).

2. when the IFRS is fetching data from a URL, the expected behavior of IFRSRequest.abort() is to a) act as a proxy to xhrGetDeferred.cancel() and b) prevent any fetch() callbacks from getting called. NOTE that this expectation is established by the documentation of Read.fetch(), but those docs (and others) are not clear if Request.abort() or Read.close() is the correct mechanism to cancel. NOTE that neither abort() or close() works as expected. Further note that the abort() that is added to IFRSRequest during the onItem() iteration phase is, with regard to the nature of IFRS, a sensible implementation for that phase of the fetch() cycle.

and two more that should be tracked elsewhere

3. [doc-enh] the aforementioned doc issues (abort() vs. close())

4. [enh] possibly an onCancel/Abort/Close/Whatever callback (but this is a dojo.data API issue and should be tracked via a separate ticket)

N.B. that browser connections to a server are a limited resource, so there needs to be a way to clean them up, hence the need to do what is effectively an XMLHttpRequest.abort(). Even w/ a well behaved server application, there's still network glitches, etc. that results in HTTP requests that don't get a response.

[Jared Jurkiewicz]

Patch that proxies to the Deferred.cancel from the xhr* call for fetch. This will trigger the onError to fire as it recieves an xhr cancelled error event from the deferred.

[Jared Jurkiewicz]

(In [16261]) Adding in an abort linkup in ItemFile?*Store to proxy the abort call. \!strict refs #8315

[Jared Jurkiewicz]

(In [16262]) Adding in abort hooks for AndOr?\*Store. \!strict refs #8315

[Jared Jurkiewicz]

(In [16279]) Tweak to testcase for abort to be nicer about timing (finish before abort is called), and only running in async cases, the browser. \!strict refs #8315

[Jared Jurkiewicz]

(In [16280]) Tweak to testcase for abort to be nicer about timing (finish before abort is called), and only running in async cases, the browser. \!strict refs #8315

[Adam Peller]

batch move of tickets marked 'tbd' fixed in the 1.3 timeframe