Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#8315 closed defect (fixed)

ItemFileReadStore: can't cancel fetch

Reported by: Les Owned by: Jared Jurkiewicz
Priority: high Milestone: 1.3
Component: Data Version: 1.2.3
Keywords: ItemFileReadStore Cc:
Blocked By: Blocking:

Description

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

Attachments (1)

dojo.data.ItemFileReadStore_abort_20090107.patch (5.8 KB) - added by Jared Jurkiewicz 11 years ago.
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.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 11 years ago by bill

Component: GeneralData
Owner: changed from anonymous to Jared Jurkiewicz

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

comment:2 in reply to:  1 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by 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.

comment:4 in reply to:  3 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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.

comment:6 in reply to:  5 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by 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).
  1. 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

  1. [doc-enh] the aforementioned doc issues (abort() vs. close())
  1. [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.

Changed 11 years ago by 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.

comment:8 Changed 11 years ago by Jared Jurkiewicz

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

comment:9 Changed 11 years ago by Jared Jurkiewicz

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

comment:10 Changed 11 years ago by Jared Jurkiewicz

Resolution: fixed
Status: newclosed

comment:11 Changed 11 years ago by 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

comment:12 Changed 11 years ago by 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

comment:13 Changed 11 years ago by Adam Peller

Milestone: tbd1.3

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

Note: See TracTickets for help on using tickets.