[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] udig-1.2-M3.linux.gtk.x86 locking up
|
On Thu, Apr 16, 2009 at 12:26 PM, MrR08040 <MrR08040@xxxxxxxxx> wrote:
> On Wed, Apr 15, 2009 at 7:02 PM, Jody Garnett <jody.garnett@xxxxxxxxx> 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 <MrR08040@xxxxxxxxx> wrote:
> On Wed, Apr 15, 2009 at 7:02 PM, Jody Garnett <jody.garnett@xxxxxxxxx> 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 <jody.garnett@xxxxxxxxx> 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 <MrR08040@xxxxxxxxx> 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 <jody.garnett@xxxxxxxxx> 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 <MrR08040@xxxxxxxxx> 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 <jody.garnett@xxxxxxxxx> 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 <MrR08040@xxxxxxxxx> 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
>>
>
