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
