How to release snapshot dependencies in a TomEE release (Re: TomEE 8 Release Notes Preview)

[David Blevins]

> On Sep 28, 2018, at 3:00 AM, Roberto Cortez  
> wrote:
> 
> While we wait for the official BVal release, I plan do create a preview 
> release of TomEE 8 so we can start trying it out and hopefully speed up the 
> process. Please, let me know if anyone has any feedback.

As a community we've done ad-hoc releases other projects on a frequent basis 
when best case scenario (they release their code) doesn't pan out.

I doug around to try and refresh my own memory.  

Pre-2013 we would use svn as a maven repo and push builds in with the version 
number suffixed with the svn version indicating the source.  The groupIds were 
left the same:

 - https://svn.apache.org/viewvc/openejb/repo/org/apache/xbean/?pathrev=1432803

This meant we had to include https://svn.apache.org/repos/asf/openejb/repo/ as 
a repository in the TomEE/OpenEJB pom.xml so we could release.  When the 
project was renamed to tomee and that path changed to  
https://svn.apache.org/repos/asf/tomee/repo/ all those old builds broke.

Post-2013 we would copy the source into our section of svn, update the groupId 
to ours with ".patch" appended, then add "nonfinal-" to the 
version number and release it to mvn central.

 - svn log -v http://svn.apache.org/repos/asf/tomee/deps | less
 - 
https://mvnrepository.com/artifact/org.apache.openejb.patch/openjpa-kernel/2.4.0-nonfinal-1598334

This would be done as part of the TomEE release that needed them, such that the 
Nexus staging repo contained both TomEE 1.2.3 and say OpenJPA 
2.4.0-nonfinal-1598334.  When the project voted, it'd be voting on all the 
binaries.  In your case it would be TomEE, BVal and Geronimo validation spec.

You could potentially do a separate vote for BVal and Geronimo validation spec. 
 If the project's get their releases up for a vote, great we use those releases 
for TomEE 8.  If not, we have something to fall back on.  The benefit of this 
is you would not have to keep rerolling these two each time you have to reroll 
TomEE 8 release binaries.  I swore we did this once, but I couldn't find the 
vote thread as I don't recall exactly what artifact it was.

Anyway, hope this helps.  It likely should be added to our release process 
documentation.


-David

Re: EclipseLink NPE Warning occurs every time during first use TomEE 7.0.5

[exabrial12]

So first thing, it looks like you can ignore this warning safely in
production. Out of sheer curiosity I wanted to see what was up.

It looks like OpenEJBServerPlatform extends JMXServerPlatformBase, which
declares a field "private MBeanRuntimeServicesMBean runtimeServicesMBean =
null;". This is never being set, hence the NPE. So to get rid of this
warning, OpenEJBServerPlatform needs to call setRuntimeServicesMBean() with
a value. 

I figured I'd take a look at what other JMX Platform implementations do,
namely Glassfish. So the GlassfishPlatform platform also implements
JMXEnabledPlatform and inside there prepareServerSpecificServicesMBean()
calls setRuntimeServicesMBean(). So really, this is probably a bug in
EclipseLink. They shouldn't rely on a value being there if the platform
doesn't implement JMXEnabledPlatform.

Drilling down little further, they create an instance of
MBeanGlassfishRuntimeServices, which turns around calls super on
GlassfishRuntimeServices, which the implementation included with EclipseLink
calls super on RuntimeServices.


So I guess I'll implement the required interface and do the same thing
EclipseLink is and see what happens.  Could be fun :)



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

EclipseLink NPE Warning occurs every time during first use TomEE 7.0.5

[exabrial12]

Here's the info, I'm following up with an analysis in a reply.

INFO: Starting ProtocolHandler ["http-nio-8080"]
Sep 28, 2018 2:57:24 PM sun.reflect.DelegatingMethodAccessorImpl invoke
INFO: Starting ProtocolHandler ["ajp-nio-8009"]
Sep 28, 2018 2:57:24 PM sun.reflect.DelegatingMethodAccessorImpl invoke
INFO: Server startup in 5809 ms
[http-nio-8080-exec-2] INFO c.e.a.s.initiator.jaxrs.VueJsEndpoint -
getTexts() sfid:abcd
[EL Info]: 2018-09-28 14:57:39.39--ServerSession(1903518886)--EclipseLink,
version: Eclipse Persistence Services - 2.6.5.v20170607-b3d05bd
[EL Info]: 2018-09-28
14:57:39.628--ServerSession(1903518886)--/file:/Users/jonathan.fisher/servers/apache-tomee-plume-7.0.5/wtpwebapps//WEB-INF/classes/_
login successful
[EL Warning]: 2018-09-28 14:57:39.63--ServerSession(1903518886)--Problem
while registering MBean: java.lang.NullPointerException

The stack trace of that exception is:
Daemon Thread [http-nio-8080-exec-3] (Suspended (exception
NullPointerException))  
owns: EntityManagerFactoryDelegate  (id=256)
owns: PhaseInterceptorChain  (id=257)   
owns: NioEndpoint$NioSocketWrapper  (id=258)
DefaultMBeanServerInterceptor.registerMBean(Object, ObjectName) line: 
315   
JmxMBeanServer.registerMBean(Object, ObjectName) line: 522  
LocalMBeanServer.registerMBean(Object, ObjectName) line: 172

OpenEJBServerPlatform(JMXServerPlatformBase).serverSpecificRegisterMBean()
line: 355   
OpenEJBServerPlatform(ServerPlatformBase).registerMBean() line: 581 
ServerSession(DatabaseSessionImpl).postConnectDatasource() line: 873
ServerSession(DatabaseSessionImpl).loginAndDetectDatasource() line: 778 
EntityManagerFactoryProvider.login(DatabaseSessionImpl, Map, boolean) 
line:
265 
EntityManagerSetupImpl.deploy(ClassLoader, Map) line: 734   
EntityManagerFactoryDelegate.getAbstractSession() line: 207 
EntityManagerFactoryDelegate.createEntityManagerImpl(Map,
SynchronizationType) line: 307  
EntityManagerFactoryImpl.createEntityManagerImpl(Map, 
SynchronizationType)
line: 337   
EntityManagerFactoryImpl.createEntityManager(SynchronizationType, Map)
line: 318   
ReloadableEntityManagerFactory.createEntityManager(SynchronizationType,
Map) line: 208  
JtaEntityManagerRegistry.getEntityManager(EntityManagerFactory, Map,
boolean, String, SynchronizationType) line: 125 
JtaEntityManager.getEntityManager() line: 145   
JtaEntityManager.typedProxyIfNoTx(Method, Object...) line: 382  
JtaEntityManager.createNamedQuery(String, Class) line: 430   
DatabaseService.getTexts(String) line: 203  
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]   
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43  
Method.invoke(Object, Object...) line: 498  

InterceptorInvocationContext(AbstractInvocationContext).directProceed()
line: 113   
InterceptorInvocationContext(AbstractInvocationContext).proceed()
line: 106   
InterceptorInvocationContext.proceed() line: 67  
MandatoryInterceptor(InterceptorBase).intercept(InvocationContext) 
line: 67 
MandatoryInterceptor.intercept(InvocationContext) line: 36  
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]   
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43  
Method.invoke(Object, Object...) line: 498  
CdiInterceptorBean(InterceptorBean).intercept(InterceptionType, T,
InvocationContext) line: 136
InterceptorInvocationContext.proceed() line: 63  
DefaultInterceptorHandler.invoke(Method, Object[]) line: 139 
DatabaseService$$OwbInterceptProxy0.getTexts(String) line: not 
available
DatabaseService$$OwbNormalScopeProxy0.getTexts(String) line: not 
available  
TextController.getTexts(String) line: 52
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]   
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43  
Method.invoke(Object, Object...) line: 498  

InterceptorInvocationContext(AbstractInvocationContext).directProceed()
line: 113   
InterceptorInvocationContext(AbstractInvocationContext).proceed()
line: 106   
InterceptorInvocationContext.proceed() line: 67  
RequiredInterceptor(InterceptorBase).intercept(InvocationContext) line: 
67  
RequiredInterceptor.intercept(InvocationContext) line: 35   
NativeM

Re: [GitHub] tomee pull request #172: [7.0.x][Tomee-2243] jmx on managed executors

[exabrial12]

We're running this patch in staging along with JGallimore's JMX patch[es].
It's humming along beautifully, we'd appreciate a merge!

Here's a visualization from Chronograf: 

 



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Connector issues

[Jonathan Gallimore]

I was thinking the same - do it through the registry. Let me have a go at
hacking on that and I'll post back here. Many thanks for the feedback.

Jon

On Fri, Sep 28, 2018 at 3:15 PM Romain Manni-Bucau 
wrote:

> that is what I had in mind, throught it was already the case to be honest
> through the transaction registry - excess of enthusiasm probably ;)
>
> Side note: dropped G for now, if we find something impacting g-txmgr we'll
> add it back
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 28 sept. 2018 à 16:11, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
> > I apologize, I CC'd Geronimo in case there was anything relevant on the
> > Geronimo connector side. Happy to drop the CC if its not relevant.
> >
> > Thanks for the quick response!
> >
> > Off the top of my head, I wonder if we could keep a reference to the
> > connection proxy in the transaction (if there is one), and remove the
> > reference when the transaction is complete?
> >
> > Jon
> >
> > On Fri, Sep 28, 2018 at 2:57 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Hi Jon,
> > >
> > > I experienced that kind of "surprise" in recent jvm since gc is way
> more
> > > aggressive - cause lambda are way more memory consuming ;). This lead
> to
> > > this kind of issue where the GC happens before the object should
> actually
> > > be finalizable.
> > > I suspect we need to rework the AutoConnectionTracker to take into
> > account
> > > these new behaviors and actually take into consideration the lifecycle
> of
> > > the underlying connection.
> > >
> > > Maybe I got it wrong but I see the ability to disable the proxying as a
> > > quickfix/workaround - which is ok - but it means we need to fix the
> > source
> > > anyway as a long term solution. Am I understanding it right? If so we
> > need
> > > to ensure to keep the reference until the connection is released at
> least
> > > and ensure it was not closed in the pool (kind of testOnXXX).
> > > Also wonder if there is anything related to geronimo since you cc-ed
> it.
> > > IIRC this logic is only in TomEE, no?
> > >
> > > side note: reference queue is supposed thread safe yes.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 28 sept. 2018 à 15:49, Jonathan Gallimore <
> > > jonathan.gallim...@gmail.com> a écrit :
> > >
> > > > Hi Folks,
> > > >
> > > > I have been looking into some issues with TomEE using Websphere MQ,
> > > > specifically issues where XA resources are returning a -7 error
> during
> > a
> > > > transaction commit when the system is under load. The -7 error
> > indicates
> > > > that the resource is closed.
> > > >
> > > > The result of this error seems to be resources staying in the system
> > > > somehow associated with the connection, and subsequently, these can't
> > be
> > > > enlisted in transactions (because they are closed).
> > > >
> > > > The stacktrace is like this, and happens over and over again as the
> > > server
> > > > attempts to process more messages from the queue.
> > > >
> > > > WARN  Transaction- Unable to enlist XAResource
> > > >
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource@3dd56e90
> > ,
> > > > errorCode: -7
> > > > javax.transaction.xa.XAException: The method 'xa_start' has failed
> with
> > > > errorCode '-7' due to the resource being closed.
> > > > at
> > com.ibm.mq.jmqi.JmqiXAResource.start(JmqiXAResource.java:946)
> > > > ~[com.ibm.mq.jmqi.jar:7.5.0.5 - p750-005-150424]
> > > > at
> > com.ibm.mq.connector.xa.XARWrapper.start(XARWrapper.java:581)
> > > > ~[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> > > > at
> > > >
> > >
> >
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.start(WrapperNamedXAResource.java:111)
> > > > ~[geronimo-transaction-3.1.4.jar:3.1.4]
> > > > at
> > > >
> > >
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.enlistResource(TransactionImpl.java:209)
> > > > [geronimo-transaction-3.1.4.jar:3.1.4]
> > > > at
> > > >
> > >
> >
> org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:60)
> > > > [geronimo-connector-3.1.4.jar:3.1.4]
> > > > at
> > > >
> > >
> >
> org.apache.geronimo.connector.outbound.TransactionCachingInterce

Re: Connector issues

[Romain Manni-Bucau]

that is what I had in mind, throught it was already the case to be honest
through the transaction registry - excess of enthusiasm probably ;)

Side note: dropped G for now, if we find something impacting g-txmgr we'll
add it back

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 28 sept. 2018 à 16:11, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> I apologize, I CC'd Geronimo in case there was anything relevant on the
> Geronimo connector side. Happy to drop the CC if its not relevant.
>
> Thanks for the quick response!
>
> Off the top of my head, I wonder if we could keep a reference to the
> connection proxy in the transaction (if there is one), and remove the
> reference when the transaction is complete?
>
> Jon
>
> On Fri, Sep 28, 2018 at 2:57 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Jon,
> >
> > I experienced that kind of "surprise" in recent jvm since gc is way more
> > aggressive - cause lambda are way more memory consuming ;). This lead to
> > this kind of issue where the GC happens before the object should actually
> > be finalizable.
> > I suspect we need to rework the AutoConnectionTracker to take into
> account
> > these new behaviors and actually take into consideration the lifecycle of
> > the underlying connection.
> >
> > Maybe I got it wrong but I see the ability to disable the proxying as a
> > quickfix/workaround - which is ok - but it means we need to fix the
> source
> > anyway as a long term solution. Am I understanding it right? If so we
> need
> > to ensure to keep the reference until the connection is released at least
> > and ensure it was not closed in the pool (kind of testOnXXX).
> > Also wonder if there is anything related to geronimo since you cc-ed it.
> > IIRC this logic is only in TomEE, no?
> >
> > side note: reference queue is supposed thread safe yes.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 28 sept. 2018 à 15:49, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> a écrit :
> >
> > > Hi Folks,
> > >
> > > I have been looking into some issues with TomEE using Websphere MQ,
> > > specifically issues where XA resources are returning a -7 error during
> a
> > > transaction commit when the system is under load. The -7 error
> indicates
> > > that the resource is closed.
> > >
> > > The result of this error seems to be resources staying in the system
> > > somehow associated with the connection, and subsequently, these can't
> be
> > > enlisted in transactions (because they are closed).
> > >
> > > The stacktrace is like this, and happens over and over again as the
> > server
> > > attempts to process more messages from the queue.
> > >
> > > WARN  Transaction- Unable to enlist XAResource
> > > org.apache.geronimo.transaction.manager.WrapperNamedXAResource@3dd56e90
> ,
> > > errorCode: -7
> > > javax.transaction.xa.XAException: The method 'xa_start' has failed with
> > > errorCode '-7' due to the resource being closed.
> > > at
> com.ibm.mq.jmqi.JmqiXAResource.start(JmqiXAResource.java:946)
> > > ~[com.ibm.mq.jmqi.jar:7.5.0.5 - p750-005-150424]
> > > at
> com.ibm.mq.connector.xa.XARWrapper.start(XARWrapper.java:581)
> > > ~[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> > > at
> > >
> >
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.start(WrapperNamedXAResource.java:111)
> > > ~[geronimo-transaction-3.1.4.jar:3.1.4]
> > > at
> > >
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.enlistResource(TransactionImpl.java:209)
> > > [geronimo-transaction-3.1.4.jar:3.1.4]
> > > at
> > >
> >
> org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:60)
> > > [geronimo-connector-3.1.4.jar:3.1.4]
> > > at
> > >
> >
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:101)
> > > [geronimo-connector-3.1.4.jar:3.1.4]
> > > at
> > >
> >
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
> > > [geronimo-connector-3.1.4.jar:3.1.4]
> > > at
> > >
> >
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
> > > [geronimo-connector-3.1.4.jar:3.1.4]
> > > at
> > >
> >
> org.apache.geronim

Re: Connector issues

[Jonathan Gallimore]

I apologize, I CC'd Geronimo in case there was anything relevant on the
Geronimo connector side. Happy to drop the CC if its not relevant.

Thanks for the quick response!

Off the top of my head, I wonder if we could keep a reference to the
connection proxy in the transaction (if there is one), and remove the
reference when the transaction is complete?

Jon

On Fri, Sep 28, 2018 at 2:57 PM Romain Manni-Bucau 
wrote:

> Hi Jon,
>
> I experienced that kind of "surprise" in recent jvm since gc is way more
> aggressive - cause lambda are way more memory consuming ;). This lead to
> this kind of issue where the GC happens before the object should actually
> be finalizable.
> I suspect we need to rework the AutoConnectionTracker to take into account
> these new behaviors and actually take into consideration the lifecycle of
> the underlying connection.
>
> Maybe I got it wrong but I see the ability to disable the proxying as a
> quickfix/workaround - which is ok - but it means we need to fix the source
> anyway as a long term solution. Am I understanding it right? If so we need
> to ensure to keep the reference until the connection is released at least
> and ensure it was not closed in the pool (kind of testOnXXX).
> Also wonder if there is anything related to geronimo since you cc-ed it.
> IIRC this logic is only in TomEE, no?
>
> side note: reference queue is supposed thread safe yes.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 28 sept. 2018 à 15:49, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> a écrit :
>
> > Hi Folks,
> >
> > I have been looking into some issues with TomEE using Websphere MQ,
> > specifically issues where XA resources are returning a -7 error during a
> > transaction commit when the system is under load. The -7 error indicates
> > that the resource is closed.
> >
> > The result of this error seems to be resources staying in the system
> > somehow associated with the connection, and subsequently, these can't be
> > enlisted in transactions (because they are closed).
> >
> > The stacktrace is like this, and happens over and over again as the
> server
> > attempts to process more messages from the queue.
> >
> > WARN  Transaction- Unable to enlist XAResource
> > org.apache.geronimo.transaction.manager.WrapperNamedXAResource@3dd56e90,
> > errorCode: -7
> > javax.transaction.xa.XAException: The method 'xa_start' has failed with
> > errorCode '-7' due to the resource being closed.
> > at com.ibm.mq.jmqi.JmqiXAResource.start(JmqiXAResource.java:946)
> > ~[com.ibm.mq.jmqi.jar:7.5.0.5 - p750-005-150424]
> > at com.ibm.mq.connector.xa.XARWrapper.start(XARWrapper.java:581)
> > ~[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> > at
> >
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.start(WrapperNamedXAResource.java:111)
> > ~[geronimo-transaction-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.enlistResource(TransactionImpl.java:209)
> > [geronimo-transaction-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:60)
> > [geronimo-connector-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:101)
> > [geronimo-connector-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
> > [geronimo-connector-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
> > [geronimo-connector-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66)
> > [geronimo-connector-3.1.4.jar:3.1.4]
> > at
> >
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:81)
> > [geronimo-connector-3.1.4.jar:3.1.4]
> > at
> >
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createManagedJMSConnection(ConnectionFactoryImpl.java:194)
> > [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> > at
> >
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnectionInternal(ConnectionFactoryImpl.java:153)
> > [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> > at
> >
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnection(ConnectionFactoryImpl.java:138)
> > [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> > at

Re: TomEE 8 Release Notes Preview

[Romain Manni-Bucau]

g-validation will be released (vote sent) likely next week - likely without
javadoc love for this iteration until somebody finds time in the week-end.
Then bval 2.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 28 sept. 2018 à 12:17, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> What's the status of the BVal release?
>
> On Fri, Sep 28, 2018 at 11:00 AM Roberto Cortez
> 
> wrote:
>
> > Hi everyone,
> >
> > While we wait for the official BVal release, I plan do create a preview
> > release of TomEE 8 so we can start trying it out and hopefully speed up
> the
> > process. Please, let me know if anyone has any feedback.
> >
> > Cheers,
> > Roberto
> >
> > > On 27 Sep 2018, at 11:00, Jonathan Gallimore <
> > jonathan.gallim...@gmail.com> wrote:
> > >
> > > For TomEE 8 and 7.1.x, definitely. We can upgrade it on earlier
> branches
> > > too, but it does require Java 8, so that would be the required minimum
> > for
> > > branches with this dependency. TomEE 7.0.x does still build with Java 7
> > and
> > > TomEE 1.7.x still builds with Java 6, but keeping Java at those levels
> is
> > > getting harder. Maybe its time to set those to Java 8.
> > >
> > > Jon
> > >
> > > On Wed, Sep 26, 2018 at 7:42 PM exabrial12  wrote:
> > >
> > >> Is it possible to upgrade ActiveMQ to the latest 5.15.6? It contained
> an
> > >> important fix for client TLS hostname verification
> > >>
> > >>
> > >>
> > >> --
> > >> Sent from:
> > >> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> > >>
> >
> >
>

Re: Connector issues

[Romain Manni-Bucau]

Hi Jon,

I experienced that kind of "surprise" in recent jvm since gc is way more
aggressive - cause lambda are way more memory consuming ;). This lead to
this kind of issue where the GC happens before the object should actually
be finalizable.
I suspect we need to rework the AutoConnectionTracker to take into account
these new behaviors and actually take into consideration the lifecycle of
the underlying connection.

Maybe I got it wrong but I see the ability to disable the proxying as a
quickfix/workaround - which is ok - but it means we need to fix the source
anyway as a long term solution. Am I understanding it right? If so we need
to ensure to keep the reference until the connection is released at least
and ensure it was not closed in the pool (kind of testOnXXX).
Also wonder if there is anything related to geronimo since you cc-ed it.
IIRC this logic is only in TomEE, no?

side note: reference queue is supposed thread safe yes.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 28 sept. 2018 à 15:49, Jonathan Gallimore <
jonathan.gallim...@gmail.com> a écrit :

> Hi Folks,
>
> I have been looking into some issues with TomEE using Websphere MQ,
> specifically issues where XA resources are returning a -7 error during a
> transaction commit when the system is under load. The -7 error indicates
> that the resource is closed.
>
> The result of this error seems to be resources staying in the system
> somehow associated with the connection, and subsequently, these can't be
> enlisted in transactions (because they are closed).
>
> The stacktrace is like this, and happens over and over again as the server
> attempts to process more messages from the queue.
>
> WARN  Transaction- Unable to enlist XAResource
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource@3dd56e90,
> errorCode: -7
> javax.transaction.xa.XAException: The method 'xa_start' has failed with
> errorCode '-7' due to the resource being closed.
> at com.ibm.mq.jmqi.JmqiXAResource.start(JmqiXAResource.java:946)
> ~[com.ibm.mq.jmqi.jar:7.5.0.5 - p750-005-150424]
> at com.ibm.mq.connector.xa.XARWrapper.start(XARWrapper.java:581)
> ~[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> at
> org.apache.geronimo.transaction.manager.WrapperNamedXAResource.start(WrapperNamedXAResource.java:111)
> ~[geronimo-transaction-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.transaction.manager.TransactionImpl.enlistResource(TransactionImpl.java:209)
> [geronimo-transaction-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:60)
> [geronimo-connector-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:101)
> [geronimo-connector-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
> [geronimo-connector-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
> [geronimo-connector-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66)
> [geronimo-connector-3.1.4.jar:3.1.4]
> at
> org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:81)
> [geronimo-connector-3.1.4.jar:3.1.4]
> at
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createManagedJMSConnection(ConnectionFactoryImpl.java:194)
> [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> at
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnectionInternal(ConnectionFactoryImpl.java:153)
> [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> at
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnection(ConnectionFactoryImpl.java:138)
> [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
> at
> com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnection(ConnectionFactoryImpl.java:123)
> [com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
>
> The issue itself bears some resemblance to these posts:
>
>
> http://tomee-openejb.979440.n4.nabble.com/Unable-to-enlist-XAResource-error-td4666552.html
>
> http://tomee-openejb.979440.n4.nabble.com/Does-tomEE-issue-double-rollbacks-td4666090.html
>
> http://tomee-openejb.979440.n4.nabble.com/errorcode-100-when-using-websphere-MQ-with-tomee-td4666519.html
>
> com.ibm.mq.jmqi.JmqiXAResource has a isClosed field, and this is set when
> close_internal() is calle

Connector issues

[Jonathan Gallimore]

Hi Folks,

I have been looking into some issues with TomEE using Websphere MQ,
specifically issues where XA resources are returning a -7 error during a
transaction commit when the system is under load. The -7 error indicates
that the resource is closed.

The result of this error seems to be resources staying in the system
somehow associated with the connection, and subsequently, these can't be
enlisted in transactions (because they are closed).

The stacktrace is like this, and happens over and over again as the server
attempts to process more messages from the queue.

WARN  Transaction- Unable to enlist XAResource
org.apache.geronimo.transaction.manager.WrapperNamedXAResource@3dd56e90,
errorCode: -7
javax.transaction.xa.XAException: The method 'xa_start' has failed with
errorCode '-7' due to the resource being closed.
at com.ibm.mq.jmqi.JmqiXAResource.start(JmqiXAResource.java:946)
~[com.ibm.mq.jmqi.jar:7.5.0.5 - p750-005-150424]
at com.ibm.mq.connector.xa.XARWrapper.start(XARWrapper.java:581)
~[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
at
org.apache.geronimo.transaction.manager.WrapperNamedXAResource.start(WrapperNamedXAResource.java:111)
~[geronimo-transaction-3.1.4.jar:3.1.4]
at
org.apache.geronimo.transaction.manager.TransactionImpl.enlistResource(TransactionImpl.java:209)
[geronimo-transaction-3.1.4.jar:3.1.4]
at
org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.getConnection(TransactionEnlistingInterceptor.java:60)
[geronimo-connector-3.1.4.jar:3.1.4]
at
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.getConnection(TransactionCachingInterceptor.java:101)
[geronimo-connector-3.1.4.jar:3.1.4]
at
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConnection(ConnectionHandleInterceptor.java:43)
[geronimo-connector-3.1.4.jar:3.1.4]
at
org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLInterceptor.java:39)
[geronimo-connector-3.1.4.jar:3.1.4]
at
org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.getConnection(ConnectionTrackingInterceptor.java:66)
[geronimo-connector-3.1.4.jar:3.1.4]
at
org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:81)
[geronimo-connector-3.1.4.jar:3.1.4]
at
com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createManagedJMSConnection(ConnectionFactoryImpl.java:194)
[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
at
com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnectionInternal(ConnectionFactoryImpl.java:153)
[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
at
com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnection(ConnectionFactoryImpl.java:138)
[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]
at
com.ibm.mq.connector.outbound.ConnectionFactoryImpl.createConnection(ConnectionFactoryImpl.java:123)
[com.ibm.mq.connector.jar:7.5.0.5-p750-005-150424]

The issue itself bears some resemblance to these posts:

http://tomee-openejb.979440.n4.nabble.com/Unable-to-enlist-XAResource-error-td4666552.html
http://tomee-openejb.979440.n4.nabble.com/Does-tomEE-issue-double-rollbacks-td4666090.html
http://tomee-openejb.979440.n4.nabble.com/errorcode-100-when-using-websphere-MQ-with-tomee-td4666519.html

com.ibm.mq.jmqi.JmqiXAResource has a isClosed field, and this is set when
close_internal() is called. I tracked this call using AspectJ, and it
appeared to happen here:

com.ibm.mq.jmqi.JmqiXAResource.close_internal(JmqiXAResource.java:296),
com.ibm.mq.jmqi.JmqiXAResource.close(JmqiXAResource.java:423),
com.ibm.mq.jmqi.JmqiXAResource.close(JmqiXAResource.java:410),
com.ibm.msg.client.wmq.internal.WMQXASession.close(WMQXASession.java:163),
com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:375),
com.ibm.msg.client.jms.internal.JmsSessionImpl.close(JmsSessionImpl.java:303),
com.ibm.mq.jms.MQSession.close(MQSession.java:298),
com.ibm.mq.connector.outbound.ManagedConnectionImpl.destroy(ManagedConnectionImpl.java:298),
org.apache.geronimo.connector.outbound.MCFConnectionInterceptor.returnConnection(MCFConnectionInterceptor.java:67),
org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor.returnConnection(XAResourceInsertionInterceptor.java:47),
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.internalReturn(AbstractSinglePoolConnectionInterceptor.java:148),
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.returnConnection(AbstractSinglePoolConnectionInterceptor.java:129),
org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.returnConnection(TransactionEnlistingInterceptor.java:118),
org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.returnConnection(TransactionCachingInterceptor.java:119),
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.returnC

[GitHub] tomee pull request #174: Allow proxy to be disabled

[jgallimore]

GitHub user jgallimore opened a pull request:

https://github.com/apache/tomee/pull/174

Allow proxy to be disabled



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jgallimore/tomee proxy-disable-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tomee/pull/174.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #174


commit f01f230fc6b6fc075839cfb7fc7d0e5220c7ec94
Author: Jonathan Gallimore 
Date:   2018-09-26T15:48:47Z

Allow proxy to be disabled




---

Re: TomEE 8 Release Notes Preview

[Jonathan Gallimore]

What's the status of the BVal release?

On Fri, Sep 28, 2018 at 11:00 AM Roberto Cortez 
wrote:

> Hi everyone,
>
> While we wait for the official BVal release, I plan do create a preview
> release of TomEE 8 so we can start trying it out and hopefully speed up the
> process. Please, let me know if anyone has any feedback.
>
> Cheers,
> Roberto
>
> > On 27 Sep 2018, at 11:00, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >
> > For TomEE 8 and 7.1.x, definitely. We can upgrade it on earlier branches
> > too, but it does require Java 8, so that would be the required minimum
> for
> > branches with this dependency. TomEE 7.0.x does still build with Java 7
> and
> > TomEE 1.7.x still builds with Java 6, but keeping Java at those levels is
> > getting harder. Maybe its time to set those to Java 8.
> >
> > Jon
> >
> > On Wed, Sep 26, 2018 at 7:42 PM exabrial12  wrote:
> >
> >> Is it possible to upgrade ActiveMQ to the latest 5.15.6? It contained an
> >> important fix for client TLS hostname verification
> >>
> >>
> >>
> >> --
> >> Sent from:
> >> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> >>
>
>

Re: TomEE 8 Release Notes Preview

[Roberto Cortez]

Hi everyone,

While we wait for the official BVal release, I plan do create a preview release 
of TomEE 8 so we can start trying it out and hopefully speed up the process. 
Please, let me know if anyone has any feedback.

Cheers,
Roberto

> On 27 Sep 2018, at 11:00, Jonathan Gallimore  
> wrote:
> 
> For TomEE 8 and 7.1.x, definitely. We can upgrade it on earlier branches
> too, but it does require Java 8, so that would be the required minimum for
> branches with this dependency. TomEE 7.0.x does still build with Java 7 and
> TomEE 1.7.x still builds with Java 6, but keeping Java at those levels is
> getting harder. Maybe its time to set those to Java 8.
> 
> Jon
> 
> On Wed, Sep 26, 2018 at 7:42 PM exabrial12  wrote:
> 
>> Is it possible to upgrade ActiveMQ to the latest 5.15.6? It contained an
>> important fix for client TLS hostname verification
>> 
>> 
>> 
>> --
>> Sent from:
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>>