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

[Rob Stryker]

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