Just beware that whatever effort we make to get this bug fixed, Luna build is done so it won't be in Luna nor in our target-platform. In the best case, it will be part of Luna *SR1* (October)

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

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(a)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

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(a)redhat.com&gt; 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(a)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

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(a)redhat.com&gt; 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

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