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

Tue Jun 17 17:56:58 EDT 2014

Eh? You got the fix in. It will be available as feature patch and part of sr1. How is that missing chance ?

/max (sent from my phone)

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