[jbosstools-dev] Critical bug in servertools, short on time

[Rob Stryker]

There is currently no JIRA for this. I discovered it while investigating 
some solutions for FuseIDE, while integrating with my servertools code, 
so it was only replicatable there, and not even in master.

My workaround in ASTools was committed as part of JBIDE-17612, and the 
workaround was just to remove a dummy non-existent listener.

On 06/17/2014 03:13 AM, Len DiMaggio wrote:
> Rob - what is the URL for the JIRA for this one?  --Len
>
>
> (Sent from my iPhone)
>
>
>
>> On Jun 13, 2014, at 11:18 AM, Rob Stryker <rstryker at redhat.com> wrote:
>>
>> I found a workaround which I've been using with great success for a few
>> hours now. I basically remove a dummy listener (ie a listener that was
>> never added) from the server, which  ensures that the notification
>> manager is instantiated first. Even if there's somehow a race condition
>> during the removal, the odds of a race condition during my next command
>> are hugely hugely decreased. I wouldn't say its impossible, as there's
>> certainly a way to replicate it if you pause the entire vm and only
>> allow certain threads to proceed at certain occasions.
>>
>> There's more details on the upstream bug. At this point I don't think
>> I'll be opening a local bug for it, since there's no clear symptoms with
>> this workaround in place. I think a patched version of org.eclipse.* is
>> not needed.
>>
>> What did the bug impact? Basically, our united server listeners and
>> anyone who extends or uses them. The United Server Listenerse are
>> basically just a convenience API to be alerted to all server events if
>> you want, rather than have to add lifecycle listeners, and then add
>> individual listeners to each server based on lifecycle events, which
>> becomes very annoying.
>>
>> If the United listener can't be registered, then many of our listeners
>> that use this class also don't get events.
>>
>> With my workaround, the bug is no longer replicatable.
>>
>> This bug could only occur basically at startup... but its effects would
>> persist for the entire session since several of our listeners would be
>> missing.
>>
>> At this point, I want WTP to fix it so that we can guarantee it won't
>> happen, but, the odds of it ever happening now are very very low after
>> my workaround.
>>
>>> On 06/13/2014 09:51 PM, Max Rydahl Andersen wrote:
>>>> On 13 Jun 2014, at 14:28, Nick Boldt wrote:
>>>>
>>>> If it's bad enough we can consider providing a patched version of an
>>>> org.eclipse.* plugin/feature in JBT/JBDS. There is time for that in
>>>> Beta3, should it be necessary. We could also put the patch into
>>>> Central, like we did for JDK 8 support for Kepler.
>>> once there is a jira actually listing what this bug impacts we can
>>> consider these - but they gotta be serious ones ;)
>>>
>>> and no, i don't think the central approach fits this issue. Its not
>>> new piece of functionality.
>>>
>>> /max
>>>
>>>> Nick
>>>>
>>>>> On 06/13/2014 07:32 AM, Max Rydahl Andersen wrote:
>>>>> before we push too hard the bug should at least have a description on
>>>>> what effects it has to users and how to reproduce.
>>>>>
>>>>> Also, please create jira on our side to track it if its this critical.
>>>>>
>>>>> /max
>>>>>
>>>>>> Hey Gorkem:
>>>>>>
>>>>>> Wanted to point you to
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=437351
>>>>>>
>>>>>> I've currently marked it as a hotbug, but I suspect this isn't correct
>>>>>> since technically we have committers on the project (you).
>>>>>>
>>>>>> If you can assist at pushing this through, I'd be most grateful. I
>>>>>> think you're supposed to mark it as p1, since you're a committer.
>>>>>>
>>>>>> The patch suggestion (adding a synchronized) is safe, and, is clearly
>>>>>> the right solution. It's an internal private method, and should in no
>>>>>> way NOT be synchronized, so I think this should be an uncontroversial
>>>>>> fix for you.
>>>>>>
>>>>>> Can you do the legwork to get the approvals we need? We're short on
>>>>>> time. This race condition is nasty.
>>>>>>
>>>>>> - Rob
>>>>>
>>>>> /max
>>>>> http://about.me/maxandersen
>>>>> _______________________________________________
>>>>> jbosstools-dev mailing list
>>>>> jbosstools-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>> -- 
>>>> Nick Boldt :: JBoss by Red Hat
>>>> Productization Lead :: JBoss Tools & Dev Studio
>>>> http://nick.divbyzero.com
>>>
>>> /max
>>> http://about.me/maxandersen
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev