I didn't cut it yet. It will be in the releases.
Working on it now. On Fri, May 5, 2017 at 2:06 PM Denis V. Kirpichenkov < [email protected]> wrote: > Hello, Clebert! > > I made 2 Pull requests (1.x/master). > > I guess I've missed the release, but anyway next release will be more > stable and reliable. > > Thanks > > > -- > > Denis > > > On 5/5/17 6:59 PM, Clebert Suconic wrote: > > I'm just running a personal errand and I should cut the release in 2 > > hours. I can wait a little longer but I don't want to pass today > > (everything fixed) > > .. > > > > unless it's a big change.. > > > > On Thu, May 4, 2017 at 11:43 PM, Denis V. Kirpichenkov > > <[email protected]> wrote: > >> Justin, thank you, so I'm going to make a pull request with ThreadGroup > >> removal. > >> > >> -- > >> Denis > >> > >> > >> On 5/5/17 7:47 AM, Justin Bertram wrote: > >>> I'm actually not sure why ActiveMQThreadFactory needs a thread group at > >>> all. As long as the threads are named appropriately I think there > doesn't > >>> need to be a group and that would solve this leak. Otherwise we'd have > to > >>> figure out a way to call destroy() on the group when pool is shutdown > and > >>> that isn't obvious. > >>> > >>> > >>> Justin > >>> > >>> ----- Original Message ----- > >>> From: "Denis V. Kirpichenkov" <[email protected]> > >>> To: [email protected] > >>> Sent: Thursday, May 4, 2017 12:48:43 PM > >>> Subject: ARTEMIS-874 ThreadGroup memory leak > >>> > >>> Hello, All! > >>> > >>> Recently I faced with a memleak described in > >>> https://issues.apache.org/jira/browse/ARTEMIS-874. And my question is > >>> why does ActiveMQThreadFactory.defaultThreadFactory() create its own > >>> ThreadGroup? May be it is fine to work without it? > >>> > > > > > > -- Clebert Suconic
