On Nov 22, 2007 5:09 PM, André Bargull <[EMAIL PROTECTED]> wrote:
> Not approved. This would bust "queuerequests" totally.
>
> Request-queuing is handled (SWF) resp. should be handled (DHTML, nyi) by
> the LzHTTPLoader (and LzLoader).
> So what we want to have, is a single "LzHTTPDataRequest"/"LzHTTPLoader"
> for normal-requesting and for queued-requesting (so we can reuse these
> objects) and just for multi-requesting we need several
> "LzHTTPDataRequest"- resp. "LzHTTPLoader"-objects (apparently, this
> isn't fully specified, see "LzDataset#doRequest(..)" and
> "LzHTTPDataProvider#doRequest(..)".)
>
> Also see LPP-4584 for "LzDataset.dsloadDel" issues we once had:
> We're unregistering the "dsloadDel" in
> "LzDataset#handleDataResponse(..)" because of "multirequest" (I think).
> [But "multirequest" itself needs some reworking, because at the moment
> it leads to excessive memory consumption (we create a new
> "LzHTTPDataRequest" object for every request and we store it in the
> subnodes-array of the dataset, but we never release the
> datarequest-instances. For the same reason, we shouldn't create a new
> "LzHTTPDataRequest" in case of queued-requests...)]
Yes I agree it is very wasteful to instantiate a new LzLoader/LzHTTPLoader
instance for queued requests,
because we ought to be able to reuse the same one sequentially.
But I am not sure about reusing the same DataRequest object.
If we don't create a new datarequest for each queued doRequest() call, the
question is where should we store the request information (the
query URL , and a couple of other dataset parameters such as nsprefix,
trimwhitespace)?
>
>
> function doRequest() {
> [..]
> if (this.dsloadDel == null) {
> this.dsloadDel = new LzDelegate(this, "handleDataResponse",
> dreq, "onstatus");
> } else if (this.multirequest) {
> this.dsloadDel.register(dreq, "onstatus");
> }
> [..]
> }
>
> function handleDataResponse (datareq) {
> if (this.dsloadDel != null && this.multirequest) {
> //TODO: unregistering just for multirequest -> reason: prevent
> memory-leaks?
> this.dsloadDel.unregisterFrom(datareq.onstatus);
> }
> [..]
> }
>
> On 11/22/2007 4:25 PM, Henry Minsky wrote:
> > Change 20071122-hqm-2 by [EMAIL PROTECTED] on 2007-11-22 10:19:28 EST
> > in /cygdrive/c/users/hqm/openlaszlo/trunk/WEB-INF/lps/lfc
> > for http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc
> > <http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc>
> >
> > Summary: fix for bug with ondata event with queuerequests
> >
> > New Features:
> >
> > Bugs Fixed: LPP-5144
> >
> > Technical Reviewer: andre
> > QA Reviewer: pbr
> > Doc Reviewer:
> >
> > Documentation:
> >
> > Release Notes:
> >
> > Details:
> >
> > If queuerequests is true, we need to allocate a new datarequest object
> > for each request, otherwise
> > the secondincoming response will not send an ondata event, because the
> > handler which is registered
> > for the datarequest onstatus event is being unregistered by the
> > handleDataResponse routine
> >
> >
> > Tests:
> >
> > test case in bug report
> >
> > test/lfc/data/alldata.lzx (we need to add this test case to the
> > regression tests!)
> >
> >
> > Files:
> >
> > M data/LzDataset.lzs
> >
> > Changeset:
> http://svn.openlaszlo.org/openlaszlo/patches/20071122-hqm-2.tar
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
