On Tue, Apr 28, 2009 at 4:25 AM, MrR08040 <[email protected]> wrote: > On Thu, Apr 16, 2009 at 12:26 PM, MrR08040 <[email protected]> wrote: >> On Wed, Apr 15, 2009 at 7:02 PM, Jody Garnett <[email protected]> wrote: >>> Could you try setting a breakpoint in the worker thread and see if the >>> worker thread manages to timeout on at least one icon? I am trying to >>> see if it is deadlocked; or if it is just stuck waiting on 47 >>> getlegendgraphic requests all queued up? >> >> OK, I'll try that and let you know.
> I wanted to follow up on this. We've punted on this for now in that > we're looking to use JMapPane in GeoTools to display our map. That is dissapointing indeed; thank you for your effort to debug this. Michael Bedward and myself are doing a QA run on JMapPane this upcoming weekend. > We have a lose requirement to run our app over VNC and for some reason > uDig failed to startup properly under that environment. This coupled > with the lock-ups made us go with a "lighter weight" approach. I have used uDig with VNC before. > Many thanks for all the help! > > Rob > > > On Thu, Apr 16, 2009 at 12:26 PM, MrR08040 <[email protected]> wrote: >> On Wed, Apr 15, 2009 at 7:02 PM, Jody Garnett <[email protected]> wrote: >>> Could you try setting a breakpoint in the worker thread and see if the >>> worker thread manages to timeout on at least one icon? I am trying to >>> see if it is deadlocked; or if it is just stuck waiting on 47 >>> getlegendgraphic requests all queued up? >> >> OK, I'll try that and let you know. >> >>> If it does make it through one timeout; we can try and throw a switch >>> for that WMS and no longer let it make getlegend graphic requests. >>> >>> On trunk I added support for a timeout to WMS activities; could we >>> make use of this and set a reduced timeout for getlegendgraphic >>> requests? >> >> While that all sounds plausible, what's troublesome is that this >> problem isn't occurring on other platforms (i.e. Win32/OS X). >> >> So here are some more data points... >> >> I traced back up the call stack to where the create image call was >> originating from and did the following: >> >> #P net.refractions.udig.project.ui >> Index: >> src/net/refractions/udig/project/ui/internal/LayerGeneratedGlyphDecorator.java >> =================================================================== >> --- >> src/net/refractions/udig/project/ui/internal/LayerGeneratedGlyphDecorator.java >> (revision >> 31218) >> +++ >> src/net/refractions/udig/project/ui/internal/LayerGeneratedGlyphDecorator.java >> (working >> copy) >> @@ -153,7 +153,8 @@ >> } >> } >> try { >> - boolean notifyIcon = refreshIcon(layer); >> + boolean notifyIcon = true; >> >> boolean notifyLabel = refreshLabel(layer); >> >> And voila, no more lock ups! Well, until it happened again so traced >> back again and did the following... >> >> #P net.refractions.udig.project >> Index: src/net/refractions/udig/project/render/Tile.java >> =================================================================== >> --- src/net/refractions/udig/project/render/Tile.java (revision 31218) >> +++ src/net/refractions/udig/project/render/Tile.java (working copy) >> @@ -147,7 +147,7 @@ >> // System.out.println((msg.getNewIntValue() == >> IRenderer.DONE) + "; state = done"); >> if( swtImage == null || >> msg.getNewIntValue()==IRenderer.DONE){ >> //we only care about done events >> - disposeSWTImage(); >> +// disposeSWTImage(); >> } >> } >> } >> >> Which has "cured" the lock up problem so far. Obviously this really >> isn't a proper fix, but it is allowing me to make progress on my >> prototype. >> >> Thanks again for the help and I'll let you know what I find next. >> >> Rob >> >> >> On Wed, Apr 15, 2009 at 7:02 PM, Jody Garnett <[email protected]> wrote: >>> That is a good bit of debugging! That worker thread should not be >>> holding up the user interface :-( The idea of fetching legend graphics >>> in a worker thread is specifically so these kind of lock ups do not >>> happen. >>> >>> Could you try setting a breakpoint in the worker thread and see if the >>> worker thread manages to timeout on at least one icon? I am trying to >>> see if it is deadlocked; or if it is just stuck waiting on 47 >>> getlegendgraphic requests all queued up? >>> >>> If it does make it through one timeout; we can try and throw a switch >>> for that WMS and no longer let it make getlegend graphic requests. >>> >>> On trunk I added support for a timeout to WMS activities; could we >>> make use of this and set a reduced timeout for getlegendgraphic >>> requests? >>> >>> Jody >>> >>> On Thu, Apr 16, 2009 at 12:37 AM, MrR08040 <[email protected]> wrote: >>>> Hi Jody, >>>> >>>> Thanks so much for taking the time to try to help resolve this issue! >>>> >>>> I really think this is a platform specific problem because 1.2-M3 runs >>>> fine on my Mac. >>>> >>>> Here are some more data points: >>>> >>>> - This lock-up occurs with the udig-1.1.1-linux.gtk.x86 release as well. >>>> - When I only use WMS layers from the "nasa jpl" link everything works >>>> fine but when I use layers from other WMS servers that's when things >>>> lock up. >>>> - The difference I notice with the "nasa jpl" WMS server is that uDig >>>> does not do a GetLegendGraphic request as it does with the other WMS >>>> servers. >>>> - When I run uDig in a debugger (or with jconsole) I see the worker >>>> thread that's waiting on a lock is trying to create an icon. I've >>>> attached screen shots of jconsole showing the threads' stack traces. >>>> >>>> To reproduce this problem simply click on any WMS link in the Web view >>>> (sans "nasa jpl" - that one works), pick a layer and click finish. >>>> Close uDig and re-run and watch it freeze. >>>> >>>> Again, I firmly believe this is only happening on Linux. >>>> >>>> Many thanks, >>>> Rob >>>> >>>> >>>> On Wed, Apr 15, 2009 at 9:11 AM, Jody Garnett <[email protected]> >>>> wrote: >>>>> Other then deleting your udig workspace and starting again very >>>>> carefully I have no other suggestions. If you do have the ability to >>>>> run a java stack dump (connect with a debugger is one way to do this) >>>>> I would love to know what threads are blocked. Also if you can give me >>>>> step by step instructions to reproduce the problem I can try doing the >>>>> steps in my development environment. I would not expect any operating >>>>> system differences to be involved here (but I am using windows so it >>>>> would not be an exact test). >>>>> >>>>> Are there any other signs? what does "top" say - is it using 100% cpu >>>>> for or it completely idle. >>>>> >>>>> My volunteer time is being taken with the "climate change intergration >>>>> plugfest" (sample data and services for the foss4g conference) as such >>>>> I have not had any volunteer time for udig. >>>>> >>>>> Jody >>>>> >>>>> On Wed, Apr 15, 2009 at 10:30 PM, MrR08040 <[email protected]> wrote: >>>>>> I let it run for 10 minutes and it's still locked up. >>>>>> >>>>>> Any other suggestions? >>>>>> >>>>>> Thanks, >>>>>> Rob >>>>>> >>>>>> >>>>>> On Tue, Apr 14, 2009 at 7:06 PM, Jody Garnett <[email protected]> >>>>>> wrote: >>>>>>> Interesting; is it a deadlock or a timeout? If you leave it alone for >>>>>>> 2 minuets is it able to resume? >>>>>>> My thought is: If we manage to get the URL wrong on resume; and a >>>>>>> mistake is made allowing the user interface to "block" on contacting >>>>>>> the URL. >>>>>>> >>>>>>> Let me know what you find out? >>>>>>> Jody >>>>>>> >>>>>>> On Wed, Apr 15, 2009 at 4:49 AM, MrR08040 <[email protected]> wrote: >>>>>>>> Hi folks, >>>>>>>> >>>>>>>> I'm on a CentOS 5.3 instance and I'm seeing lockups with 1.2-M3 under >>>>>>>> jdk-6u13. Here's how to do it: >>>>>>>> >>>>>>>> - Remove any existing uDig workspace >>>>>>>> - Run uDig >>>>>>>> - Click on the Web tab at the bottom >>>>>>>> - Click on the "jpl nasa" link and add the "Blue Marble, Global MODIS >>>>>>>> derived image" resource >>>>>>>> - Click Finish >>>>>>>> - Let the map re-draw >>>>>>>> - Click on the "dm solutions" link and the "Province" resource >>>>>>>> - Click Finish >>>>>>>> - Let the map re-draw >>>>>>>> - Close uDig >>>>>>>> - Run uDig again and witness the lock up >>>>>>>> >>>>>>>> I first noticed this lock up doing some prototyping with the trunk >>>>>>>> baseline. I narrowed it down to what I believe is a deadlock >>>>>>>> condition between two threads. Initially I thought it was something I >>>>>>>> was doing wrong, but now that I can reproduce it with the RCP I think >>>>>>>> there is indeed a problem in the baseline. I'll try to get some >>>>>>>> jconsole screen shots and post them here. >>>>>>>> >>>>>>>> Any help on this will be greatly appreciated! >>>>>>>> >>>>>>>> Rob >>>>>>>> _______________________________________________ >>>>>>>> User-friendly Desktop Internet GIS (uDig) >>>>>>>> http://udig.refractions.net >>>>>>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> User-friendly Desktop Internet GIS (uDig) >>>>>>> http://udig.refractions.net >>>>>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>>>>> >>>>>> _______________________________________________ >>>>>> User-friendly Desktop Internet GIS (uDig) >>>>>> http://udig.refractions.net >>>>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>>>> >>>>> _______________________________________________ >>>>> User-friendly Desktop Internet GIS (uDig) >>>>> http://udig.refractions.net >>>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>>> >>>> >>>> _______________________________________________ >>>> User-friendly Desktop Internet GIS (uDig) >>>> http://udig.refractions.net >>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>> >>>> >>> _______________________________________________ >>> User-friendly Desktop Internet GIS (uDig) >>> http://udig.refractions.net >>> http://lists.refractions.net/mailman/listinfo/udig-devel >>> >> > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
