I had a play around with this, and got my previously failing JMSContextInjectionTest to work -- some of the time. ( https://github.com/apache/tomee/blob/e58ff848a3a80938d4d99fc9bcfeaade5a72d644/arquillian/arquillian-tomee-tests/arquillian-tomee-jms-tests/src/test/java/org/apache/openejb/arquillian/tests/jms/JMSContextInjectionTest.java ).
I'm getting some log output that I'm not expecting so I've rolled back my removal of @Ignore so I can dig into it some more. Jon On Tue, Aug 27, 2019 at 5:36 PM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > Hi Jonathan > > Thanks for this. I think I had run into some of the things you fixed I > little while back. I'll take a look at your change later today. Happy for > you to commit and I can review after, too. :) > > Cheers > > The other Jonathan > > > On Tue, Aug 27, 2019 at 2:59 AM Jonathan S. Fisher <exabr...@gmail.com> > wrote: > >> >> https://github.com/exabrial/tomee/commit/08dd4c744818702f3be5edfd8a1c4cf2b69d524d >> >> With these patches the JMS2.0 API works pretty well now :) If anyone wants >> to review, please go ahead, otherwise I'll commit them tomorrow. >> >> cheers, >> - [The other] Jonathan >> >> On Mon, Aug 26, 2019 at 3:45 PM Jonathan S. Fisher <exabr...@gmail.com> >> wrote: >> >> > I've narrowed down the problem to AutoConnectionTracker. It's not >> > completing, which isn't allowing the connections to be returned to the >> pool. >> > >> > >> https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/resource/AutoConnectionTracker.java#L174 >> > >> > getResource() is throwing an IllegalStateException. The JavaDoc ( >> > >> https://docs.oracle.com/javaee/7/api/javax/transaction/TransactionSynchronizationRegistry.html#getResource-java.lang.Object- >> ) >> > states it should throw an ISE if a current transaction is not Active. >> The >> > transaction is in the state ROLLED_BACK when AutoConnectionTracker >> tries to >> > call getResource(). >> > >> > I think the Geronimo implementation ( >> > >> https://github.com/apache/geronimo-txmanager/blame/trunk/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#L203 >> ) >> > maybe be a little too strict. The JTA Spec pdf doesn't offer exact >> hints of >> > which statuses ( >> > https://docs.oracle.com/javaee/7/api/javax/transaction/Status.html) >> > should be have getResource _not_ throw an ISE unfortunately. I was >> thinking >> > of changing Geronimo's implementation to check for anything >> > but STATUS_UNKNOWN, and STATUS_NO_TRANSACTION. >> > >> > The other way is to cast Transaction to the Geronimo implementation and >> > use Geronimo specific APIs to get call getResource(). Do you guys have >> any >> > preference which route I should take to fix? >> > >> > >> > On Mon, Aug 26, 2019 at 9:15 AM Jonathan S. Fisher <exabr...@gmail.com> >> > wrote: >> > >> >> https://github.com/exabrial/tomee-jms2-bug/tree/connection-pool-leak >> >> >> >> Here's a project that reproduces the bug. This project intentionally >> >> exceeds the transaction timeout (of 1s). Each invocation, the >> connection is >> >> not returned to the pool and eventually you run out, causing your >> >> application to freeze. >> >> >> >> >> >> >> >> On Fri, Aug 23, 2019 at 2:37 PM Jonathan S. Fisher <exabr...@gmail.com >> > >> >> wrote: >> >> >> >>> Hello Apache friends :) I have a question about the JTA and JMS/RA >> specs: >> >>> >> >>> If you borrow something from a RA, like a JMS Connection, and you're >> in >> >>> XA Transaction, is it necessary to call connection.close()? It would >> seem >> >>> JTA should be smart enough to know the connection is enrolled for 2 >> phase >> >>> commit and should be smart enough to close it, but I'm not sure if >> that's >> >>> part of the spec. >> >>> >> >>> In TomEE 7.0.6 we're noticing that if you borrow a JMS Connection with >> >>> connectionFactory.createConnection(), and your code fails to call >> close() >> >>> before the transaction completion, the connection leaks. (And >> >>> unfortunately, calling close() after the transaction completes doesn't >> >>> mitigate the problem). It took awhile for us to track this down. >> >>> >> >>> This becomes a huge problem if you're calling external services in >> your >> >>> transaction. Let's say you have a reasonable transaction timeout of >> 30s >> >>> set. You call three services, and they end up taking 15s a piece. >> Even if >> >>> you're doing the right thing and you have connection.close() in a >> finally >> >>> block, because your transaction isn't active when you call close, it >> leaks >> >>> and it just gets "stuck" as an active connection, which eventually >> you hit >> >>> the pool limit and your app freezes. >> >>> >> >>> On a separate note, we noticed if you open a connection outside of the >> >>> scope of a transaction, then start a transaction, then create a >> session >> >>> with session_transacted option, the session does not participate in >> the JTA >> >>> (which seems out of spec). One most open the connection inside the >> >>> transaction, AND open the session in the transaction, and close the >> >>> connection in the transaction for everything to work. >> >>> >> >>> I'll get a reproducing project created, but I was curious if anyone >> knew >> >>> offhand what the spec says. >> >>> >> >>> cheers, and thanks, >> >>> -[the other] Jonathan >> >>> >> >>> -- >> >>> 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. >> >> >> > >> > >> > -- >> > 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. >> >
