[
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 Tue, Apr 28, 2009 at 4:25 AM, MrR08040 <MrR08040@xxxxxxxxx> wrote:
> 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.
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 <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
>>>
>>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
