#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)
Change History (14)
comment:1 follow-up: 2 Changed 12 years ago by
Component: | General → Data |
---|---|
Owner: | changed from anonymous to Jared Jurkiewicz |
comment:2 Changed 12 years ago by
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 follow-up: 4 Changed 12 years ago by
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 Changed 12 years ago by
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 follow-up: 6 Changed 12 years ago by
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 Changed 12 years ago by
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 12 years ago by
I think there's two levels to this bug:
- 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).
- 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
- [doc-enh] the aforementioned doc issues (abort() vs. close())
- [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 12 years ago by
Attachment: | dojo.data.ItemFileReadStore_abort_20090107.patch added |
---|
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 12 years ago by
comment:9 Changed 12 years ago by
comment:10 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:11 Changed 12 years ago by
comment:12 Changed 12 years ago by
comment:13 Changed 12 years ago by
Milestone: | tbd → 1.3 |
---|
batch move of tickets marked 'tbd' fixed in the 1.3 timeframe
I don't think this is a bug, as user should use store's close() method, but passing to Jared to close.