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

[Rob Stryker]

They will not be re-spinning Luna for this, but will instead push it to 
a feature patch.  Since we've already worked around the issue, and since 
the issue does not fit the requirements for a feature request, I will 
not be pushing the issue any further.

I think we missed our chance.

On 06/17/2014 02:52 PM, Rob Stryker wrote:
> 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
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev