Re: [OpenMap Users] CADRG load time issue

On Jun 15, 2004, at 8:27 PM, Leah Wong wrote:
> It's not that the code is taking any longer. It's that while OpenMap
> is
> loading the CADRG data, it locks up my application. In version 4.5.3,
> while
> OpenMap was loading, my application still functioned. While loading,
> the
> little boxes on the lower right hand corner of my map display turned
> red. I
> knew the data was loaded once all the little boxes were green. Now,
> in 4.6,
> my entire application freezes, and the user can perform no other
> functions
> while OpenMap is loading. I haven't gotten a chance to dig into v4.6
> much
> at all yet, but I'm guessing from the behavior, the i/o work is no
> longer
> being done in a background thread. I say this because while the i/o
> work is
> being done, my machine doesn't lock up, only my application.

I've confirmed a new thread is being launched for the RpfLayer work
reading the A.TOC file.

This may be a JVM issue, where I/O can overload the JVM?

- Don

> -----Original Message-----
> From: owner-openmap-users@bbn.com [mailto:owner-openmap-users@bbn.com]
> On
> Behalf Of Don Dietrick
> Sent: Tuesday, June 15, 2004 11:42 AM
> To: Lonnie Goad
> Cc: openmap-users@bbn.com
> Subject: Re: [OpenMap Users] CADRG load time issue
>
> Lonnie,
>
> I think there is a major problem in that the RpfTocHandler checks to
> see of the frames actually exist while it is loading the layer for the
> first time. While this is taking place in a separate thread, I think
> the I/O burden it places on the system is causing all resources to be
> diverted to that process, and it the machine kind of hangs. I've seen
> this effect in the DTEDCoverageLayer when it is building the coverage
> file and checking what frame files it has (it's even more dumb, and
> more intensive, actually). I'm not sure why you see a performance
> difference in the RpfLayer between 4.5.3 and later versions, the code
> that does this work hasn't changed for much longer than that (It wasn't
> written with checking for Gb of data over the network in mind).
>
> I've made modifications to the RpfTocHandler and other classes in the
> package so they don't do that check. I also want to reorganize how the
> coverage boxes are organized in the RpfTocHandler, so they are grouped
> by scale, limiting the search algorithm for pertinent coverage to
> scales that make sense for the given projection scale.
>
> The first set of changes will be in the maintenance release this month.
> The second set of changes may be.
>
> - Don
>
> On Jun 14, 2004, at 1:29 PM, Lonnie Goad wrote:
>
>> I noticed that I and another person had posted on this issue before
>> and I was wondering if anybody else had the same issue and if they had
>> come to a resolution.  The issue is that when initially loading data
>> for an RpfLayer the time for this has increased significantly since
>> OpenMap 4.5.3.  The load time isn’t even the real issue; the real
>> issue is that loading CADRG data freezes the application until it is
>> done.  I have gone so far as to make sure that the thread for loading
>> the data is working properly and it appears to be doing so, but
>> something is still causing the application to hang up.  This occurs if
>> the CADRG layer is turned on at startup or if turned on during run
>> time.  I am using a lot of data and it is taking approximately 2.5
>> minutes to load.  I have tried making a new TOC file with MakeToc and
>> have cut the time down to just over 2 minutes.  Combining Toc files is
>> not a realistic solution in the first place because my application
>> doesn’t provide map data and my users are not going to know how to
>> handle doing that.  I guess I am just hoping that somebody out there
>> has found the bottleneck and is willing to share the info.
>>
>>  
>>
>> Thanks,
>>
>>  
>>
>> ************************
>>
>> Lonnie Goad - Programmer
>>
>> OptiMetrics Inc.
>>
>> 2107 Laurel Bush Rd. Suite 209
>>
>> Bel Air, Md. 21015
>>
>> LGoad@OptiMetrics.org
>>
>> http://www.OptiMetrics.org
>>
>> (410)569-6081 ext: 105
>>
>> fax: (410)569-6083
>>
>>  
>>
>
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Don Dietrick, dietrick@bbn.com
> BBN Technologies, Cambridge, MA
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> --
> [To unsubscribe to this list send an email to "majdart@bbn.com"
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]
>
> --
> [To unsubscribe to this list send an email to "majdart@bbn.com"
> with the following text in the BODY of the message "unsubscribe
> openmap-users"]
>
>

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, dietrick@bbn.com
BBN Technologies, Cambridge, MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
[To unsubscribe to this list send an email to "majdart@bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]