[Source] [Xj3D Bug 444] GeoLOD stop loading with stopping throttle message

[Norbraten, Terry]

I'll roll a new build and notify when ready


On 7/7/10 12:13 AM, "Don Brutzman" <brutzman at nps.edu> wrote:

> cc:  x3d-earth, source mailing lists
> 
> Rex, thanks for this important diagnosis.
> 
> It's not clear from your final note that this is resolved
> once and for all however.  If there is still a duplicate
> download, shouldn't the bug still be open?
> 
> Dale and Terry, we need to get the Xj3D updates and test on
> Dale's recent X3D-Earth trees.
> 
> 
> On 6/28/2010 2:07 PM, bugzilla at xj3d.org wrote:
>> 
>> http://bugzilla.xj3d.org/show_bug.cgi?id=444
>> 
>> Rex Melton <rex.melton at comcast.net> changed:
>> 
>> What |Removed |Added
>> ----------------------------------------------------------------------------
>> Status|NEW |RESOLVED
>> Resolution| |FIXED
>> 
>> --- Comment #4 from Rex Melton <rex.melton at comcast.net> 2010-06-28
>> 13:53:46 PDT ---
>> 
>> Tracing with a network sniffer and reviewing code, the issue is with the
>> image
>> load handling.
>> 
>> The org.xj3d.impl.core.loading.ContentLoadHandler gets an
>> org.ietf.uri.ResourceConnection for each URL and does a connect() on it
>> before
>> calling getContent(). Under the covers in the uri library, this sends
>> the GET
>> request to the server and the download of the file is initiated immediately.
>> 
>> For image files, the getContent() call is serviced by the
>> org.xj3d.ui.awt.net.content.AWTImageContentHandler which determines
>> whether the
>> native image loaders or the JRE image loaders will be used. But in
>> either case,
>> it does not (and cannot) use the ResourceConnection that has already been
>> established. It instantiates a java.net.URLConnection with a url
>> extracted from
>> the ResourceConnection and performs a getContent() with the new
>> connection to
>> the server.
>> 
>> Thus, for every image requested, 2 separate downloads occur. One is actually
>> connected to a real content handler that is reading and processing the data.
>> And the other (the first connection made through the ResourceConnection
>> object)
>> is unhandled - and the data is presumably being queued up.
>> 
>> Depending on timing and circumstances, the stream that is -not- being
>> read and
>> processed can reach it's TCP congestion window limit. The server
>> recognizes the
>> situation and stops -all- downloading to the client, including to the stream
>> that is actively processing image data. And this is where it hangs. The
>> stream
>> that's being serviced gets no more data - so it can never complete and
>> close.
>> The stream that's not being serviced will never drain it's queue anyway. The
>> server and client continue to exchange window size messages, but to no
>> avail.
>> 
>> The quick workaround to prevent this stalemate is to get the InputStream
>> from
>> the ResourceConnection in the AWTImageContentHandler and close it
>> immediately.
>> In my experiments, this prevents a lockup. It does not however terminate the
>> unnecessary download. It does appear to alter the client's handing of the
>> congestion window sizing such that the server will continue to stream data.
> 
> all the best, Don