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

[Rob Stryker]

I believe there were questions about the order of plugins starting, 
whether one plugin should force-start another, or whether a plugin 
should be involved in early-startup. I also believe you had suggested we 
just ensure that a view contribution were made, which would accomplish 
the bundle's start method once servers view was shown, without 
specifically declaring an early startup for the bundle.

I don't remember other workarounds specifically, but I do remember 
debugging this issue in the past for other issues and pulling my hair 
out over it.

On 06/14/2014 01:09 PM, Max Rydahl Andersen wrote:
> You mentioned it was cause of workarounds for issues in past ? What kind of issues ?
>
> /max (sent from my phone)
>
>
>> On 13/06/2014, at 17.18, 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