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. 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. 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
