Does something need to failover in this scenario, in order to reproduce it?
Jon On Mon, Sep 30, 2019 at 8:49 PM Jonathan S. Fisher <exabr...@gmail.com> wrote: > Here's the ref: https://issues.apache.org/jira/browse/AMQ-6391 The > scenario mentioned in the ticket is sending a message from an MDB, which > call connectionPool.getConnecion() twice. We actually haven't observed that > problem in practice (doesn't mean it's not happening though). > > > I’d expect that transaction caching in the pooling would result in all > connection handles being associated with one managed connection in one > transaction > I actually wasn't aware this existed (go figure). This could be why we're > not seeing the issue on the MDB/Send a Message scenario. > > The scenario where we can reliably reproduce the problem is to have a Bean > Managed Transaction start, send a bunch of messages, then commit the > transaction, all in the loop. While this isn't explicitly stated in the > original ticket, it has the same leak. > > > > On Mon, Sep 30, 2019 at 1:13 PM David Jencks <david.a.jen...@gmail.com> > wrote: > > > Could you explain this scenario further? Are there multiple activemq > > managed connections to different brokers but associated with the same > > connection handle? Or one managed connection associated with more than > one > > “physical” connection? I’d expect that transaction caching in the pooling > > would result in all connection handles being associated with one managed > > connection in one transaction. > > > > Thanks > > David Jencks > > Sent from my iPhone > > > > > On Sep 30, 2019, at 10:10 AM, Jonathan S. Fisher <exabr...@gmail.com> > > wrote: > > > > > > It was 5.15.9 that was causing problems with the failover transport > > (Which > > > is a best practice to use). Essentially you memory leak when two or > more > > > physical activemq connections get involved in an XA transaction > > > > > > On Fri, Sep 27, 2019 at 3:55 AM Jonathan Gallimore < > > > jonathan.gallim...@gmail.com> wrote: > > > > > >> I'm not against updating ActiveMQ on 7.0.x, but I suspect that might > > mean > > >> we lose compatibility with Java 7. I forget which version Jonathan > > (Fisher) > > >> is running, but I suspect that's not an issue for him. > > >> > > >> I'll take a look at the versions, and start a thread so the community > > can > > >> decide what to do. > > >> > > >> Jon > > >> > > >> On Fri, Sep 27, 2019 at 9:39 AM Zowalla, Richard < > > >> richard.zowa...@hs-heilbronn.de> wrote: > > >> > > >>> Hi Jonathan, > > >>> > > >>> current 7.1.1-SNAPSHOT branch is on ActiveMQ 5.15.10 > > >>> > > >>> This update was conducted due to several CVE's related to its > transient > > >>> jackson-databind dependency. > > >>> > > >>> But, if I am right, you are still on 7.0.x - which has not been > updated > > >>> yet :) > > >>> > > >>> Best, > > >>> Richard > > >>> > > >>> Am Dienstag, den 24.09.2019, 10:57 -0500 schrieb Jonathan S. Fisher: > > >>> > > >>> So I've got a test case, but it will likely just be isolated to us. > We > > were > > >>> > > >>> upgrading the ActiveMQ RAR to 5.15.9 to enable strict host checking > on > > TLS > > >>> > > >>> certificates. If we keep the stock ActiveMQ rar/jar we don't see the > > >>> > > >>> problem. > > >>> > > >>> > > >>> So I guess take note of that if someone ever asks for an upgrade, the > > >>> > > >>> failover protocol will collapse a 32m JVM after about 10k messages. > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 5:20 PM Jean-Louis Monteiro < > > >>> > > >>> jlmonte...@tomitribe.com> wrote: > > >>> > > >>> > > >>> I have opened this ticket and pushed a fix on both Java EE 7 and 8 > API > > jar. > > >>> > > >>> New snapshot deployed. > > >>> > > >>> > > >>> I'm waiting for the full build on master to pass and then I'll close > > the > > >>> > > >>> ticket and fire up the 2 releases so you can move on with TomEE > > >>> > > >>> > > >>> -- > > >>> > > >>> Jean-Louis Monteiro > > >>> > > >>> http://twitter.com/jlouismonteiro > > >>> > > >>> http://www.tomitribe.com > > >>> > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 3:03 PM Jonathan Gallimore < > > >>> > > >>> jonathan.gallim...@gmail.com> wrote: > > >>> > > >>> > > >>> Oh wow, that would be amazing! > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 10:49 PM Jonathan S. Fisher < > > exabr...@gmail.com> > > >>> > > >>> wrote: > > >>> > > >>> > > >>> I'll get a reproducer project put together that demos the bug. > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 4:32 PM Jonathan Gallimore < > > >>> > > >>> jonathan.gallim...@gmail.com> wrote: > > >>> > > >>> > > >>> If we can come up with some good tests for it, I don't see why not. > > >>> > > >>> > > >>> Jon > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 10:25 PM Jonathan S. Fisher < > > >>> > > >>> exabr...@gmail.com> > > >>> > > >>> wrote: > > >>> > > >>> > > >>> We've been running 7.0.x latest in prod for a few weeks with no > > >>> > > >>> issues > > >>> > > >>> other than the ActiveMQ Failover protocol memory leak issue (which > > >>> > > >>> affects > > >>> > > >>> all versions of TomEE). > > >>> > > >>> https://issues.apache.org/jira/browse/AMQ-6391 This is an issue > > >>> > > >>> now > > >>> > > >>> because > > >>> > > >>> our JMS Context / Connection Factories will actually be > > >>> > > >>> transactional > > >>> > > >>> > > >>> Should/Could we patch the ActiveMQ jar? > > >>> > > >>> > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 3:24 PM Jean-Louis Monteiro < > > >>> > > >>> jlmonte...@tomitribe.com> wrote: > > >>> > > >>> > > >>> The Locator issue raised earlier today. Would be great to get the > > >>> > > >>> fix > > >>> > > >>> in > > >>> > > >>> before rolling. > > >>> > > >>> -- > > >>> > > >>> Jean-Louis Monteiro > > >>> > > >>> http://twitter.com/jlouismonteiro > > >>> > > >>> http://www.tomitribe.com > > >>> > > >>> > > >>> > > >>> On Mon, Sep 23, 2019 at 12:33 PM Jonathan Gallimore < > > >>> > > >>> jonathan.gallim...@gmail.com> wrote: > > >>> > > >>> > > >>> I'm just doing some cleanup on these branches. I'm thinking its > > >>> > > >>> probably time we put out new releases as these branches have > > >>> > > >>> seen > > >>> > > >>> some > > >>> > > >>> fixes. > > >>> > > >>> > > >>> Is there anything that we think is missing before I kick off > > >>> > > >>> some > > >>> > > >>> releases > > >>> > > >>> and votes? > > >>> > > >>> > > >>> I'd like to get the quartz-openejb-shade update if possible - > > >>> > > >>> that > > >>> > > >>> needs > > >>> > > >>> some more reviewers and votes. > > >>> > > >>> > > >>> Jon > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> Jonathan | exabr...@gmail.com > > >>> > > >>> Pessimists, see a jar as half empty. Optimists, in contrast, see it > > >>> > > >>> as > > >>> > > >>> half > > >>> > > >>> full. > > >>> > > >>> Engineers, of course, understand the glass is twice as big as it > > >>> > > >>> needs > > >>> > > >>> to > > >>> > > >>> be. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> Jonathan | exabr...@gmail.com > > >>> > > >>> Pessimists, see a jar as half empty. Optimists, in contrast, see it > as > > >>> > > >>> half > > >>> > > >>> full. > > >>> > > >>> Engineers, of course, understand the glass is twice as big as it > needs > > >>> > > >>> to > > >>> > > >>> be. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> Richard Zowalla, M.Sc. > > >>> Research Associate, PhD Student | Medical Informatics > > >>> > > >>> > > >>> > > >>> Hochschule Heilbronn – University of Applied Sciences > > >>> Max-Planck-Str. 39 > > >>> D-74081 Heilbronn > > >>> phone: +49 7131 504 6791 > > >>> mail: richard.zowa...@hs-heilbronn.de > > >>> web: http://www.mi.hs-heilbronn.de/ > > >>> > > >> > > > > > > -- > > > Jonathan | exabr...@gmail.com > > > Pessimists, see a jar as half empty. Optimists, in contrast, see it as > > half > > > full. > > > Engineers, of course, understand the glass is twice as big as it needs > to > > > be. > > > > > -- > Jonathan | exabr...@gmail.com > Pessimists, see a jar as half empty. Optimists, in contrast, see it as half > full. > Engineers, of course, understand the glass is twice as big as it needs to > be. >