RE: TomEE 7.0.6 + Primefaces 7.0 + Omnifaces 2.7.3
For anybody hitting the same issue, it was resolved by adding org.omnifaces to the resources/META-INF/scan.xml Cheers, Dmitry Shultz Senior Software Developer [cid:image001.png@01D051C6.BA585530] 1540 Kalamalka Lake Rd. Vernon, BC V1T 6V2 t: 250.558.3200 (x 547) KalTire.com From: Shultz, Dmitry Sent: Tuesday, February 11, 2020 12:32 PM To: users@tomee.apache.org Subject: TomEE 7.0.6 + Primefaces 7.0 + Omnifaces 2.7.3 Hi All, I'm running service that is using Deltaspike + Primefaces in TomEE (7.0.6) quite successfully, but experiencing some issue when trying to add Omnifaces components to the page (full stacktrace below). Note, adding Omnifaces websocket (o:socket) works pretty good, but I had to register the org.omnifaces.ApplicationListener in web.xml Message:Undefined component type org.omnifaces.component.input.Formjavax.faces.FacesException: Undefined component type org.omnifaces.component.input.Form at org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1437) at org.apache.myfaces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1405) at javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123) at javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123) at javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123) at javax.faces.application.ApplicationWrapper.createComponent(ApplicationWrapper.java:123) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.createComponent(ComponentTagHandlerDelegate.java:605) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:285) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:50) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:521) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:575) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:553) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240) at org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:228) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:86) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178) at org.apache.myfaces.view.facelets.impl.TemplateContextImpl$TemplateManagerImpl.apply(TemplateContextImpl.java:193) at org.apache.myfaces.view.facelets.impl.TemplateContextImpl.includeDefinition(TemplateContextImpl.java:136) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:475) at org.apache.myfaces.view.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:94) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:55) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:374) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:50) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:195) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:521) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:575) at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:553) at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240) at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:151) at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59) at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48) at
RE: TomEE microprofile memory consumption
Hello Jonathan, JIRA ticket created: TOMEE-2771 If you can answer to the following question(already asked in the ticket) : Could you confirm that if we haven't this entry in the system.properties or set to none then all MP specifications are disabled et runtime ? It should be fine. Best Regards. -Original Message- From: COURTAULT Francois [mailto:francois.courta...@thalesgroup.com] Sent: mercredi 12 février 2020 09:51 To: users@tomee.apache.org Subject: RE: TomEE microprofile memory consumption Hello Jonathan I will do so (Jira). BTW, is this property tomee.mp.scan documented somewhere ? Best Regards. -Original Message- From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] Sent: mardi 11 février 2020 19:25 To: users@tomee.apache.org Subject: Re: TomEE microprofile memory consumption Awesome, thanks for the feedback. We'd still want to fix the actual issue. If you get time, if you can file a JIRA, that would be great. Jon On Tue, Feb 11, 2020 at 6:01 PM COURTAULT Francois < francois.courta...@thalesgroup.com> wrote: > Hello Jonathan, > > We did the test (remove tomee.mp.scan = all entry in > system.properties) with TomEE MP and it solves the issue we have: a > lot of opentracing objects created. > We don't have this issue (a lot of opentracing objects created) in > TomEE Plus because this entry doesn't exist in system.properties !!! > > Best Regards. > > -Original Message- > From: COURTAULT Francois > Sent: mardi 11 février 2020 10:32 > To: users@tomee.apache.org > Subject: RE: TomEE microprofile memory consumption > > Hello Jonathan, > > As I have mentioned, we see the issue in TomEE MP but not in TomEE Plus ! > So I did a comparison of the 2 flavors: lib + conf > > The only difference I have seen is in the system.properties where I > have the line below in TomEE MP and not this one in TomEE Plus ! > This could explain. We will try to remove this line to see if it > solves the memory issue we have and will let you know. > > Best Regards. > > -Original Message- > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] > Sent: lundi 10 février 2020 23:14 > To: users@tomee.apache.org > Subject: Re: TomEE microprofile memory consumption > > Allow me start over, if I may. > > What are you seeing in your memory dumps that's a concern - a large > number of ScopeImpl objects? Could you provide some screenshots from > VisualVM for us? I'd be interested in object counts, and whether there > are references, and if so, what they are. > > The TaskThread comes from Tomcat. It being present doesn't sound like > an issue, but I appreciate you've asked because you have some concern > - can you provide some more context? > > > You didn't answer to this question: Is there a way to disable > > opentracing > in TomEE MP ? Is it possible ? > > Its a setting in the Geronimo OpenTracing project: > https://github.com/apache/geronimo-opentracing. Try setting > geronimo.opentracing.filter.active to false (an entry in > conf/system.properties should do the trick). > > Jon > > On Mon, Feb 10, 2020 at 6:46 PM COURTAULT Francois < > francois.courta...@thalesgroup.com> wrote: > > > Hello Jonathan, > > > > Quite complex for us what you ask for. > > > > BTW, have you any idea about this > > org.apache.tomcat.util.threads.TaskThread in the memory dump we have. > > Where could it come from ? > > > > You didn't answer to this question: Is there a way to disable > > opentracing in TomEE MP ? Is it possible ? > > > > Best Regards. > > > > -Original Message- > > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] > > Sent: lundi 10 février 2020 18:21 > > To: users@tomee.apache.org > > Subject: Re: TomEE microprofile memory consumption > > > > > I can provide you some memory dumps if you want . > > > > Some details on how to reproduce with a small sample would be helpful. > > Memory dumps tend to be quite large and contain confidential > > information, so we prefer to not exchange those on the list. > > > > Jon > > > > On Mon, Feb 10, 2020 at 5:10 PM COURTAULT Francois < > > francois.courta...@thalesgroup.com> wrote: > > > > > Hello everyone, > > > > > > We have 2 microservices: one using TomEE Plus and the other using > > > TomEE > > MP. > > > These 2 µS don't use at all OpenTracing features: no @Trace > > > We have no memory issue with the µS using TomEE Plus. This is > > > strange because TomEE Plus somehow is a superset of TomEE MP. > > > > > > The issue is due to the usage of > > > org.apache.geronimo.microprofile.opentracing.impl.ScopeImpl but we > > > don't know what trigger that usage. > > > We also see a lot of org.apache.tomcat.util.threads.TaskThread > > > (don't know where it comes from) which uses the above ScopeImpl. > > > > > > I can provide you some memory dumps if you want . > > > > > > Is there a way to disable opentracing in TomEE MP ? > > > > > > Best Regards. > > > > > > > > > > > > > > >
Re: TOMEE-2770
Hi Francois,
thanks for the minimal example.
Due to my other duties, I wasn't able to dig into the issue.
Best,Richard
Am Mittwoch, den 12.02.2020, 08:51 + schrieb COURTAULT Francois:
> Hello Richard,
> Have you been able to reproduce the issue ?
> Best Regards.
> -Original Message-From: COURTAULT Francois Sent: mardi 11
> février 2020 10:42To: users@tomee.apache.orgCc:
> dev@tomee.apache.orgSubject: RE: TOMEE-2770
> Hello Richard,
> It's really easy to reproduce.
> Just this class to be deploy in a war:
> @Stateless@Path("v1/notifications")public class NotificationResource
> {
> public static final String QUEUE_NAME = "jms/myQueue";
> @Resource(name = QUEUE_NAME)private Queue messageQueue;
> @Injectprivate JMSContext jmsContext;
> @GET@Path("downloadInfo")public Response
> postDownloadInfoJMS()
> {jmsContext.createProducer().send(messageQueue,
> jmsContext.createTextMessage("Test"));System.out.println(
> "Message sent !");return Response.accepted().build();}}
> And a beans.xml with bean-discovery-mode="all".
> Then perform several GET calls with a browser and you will the number
> of dynamicProducer increase (1 per call).
> Best Regards.
> -Original Message-From: Zowalla, Richard [mailto:
> richard.zowa...@hs-heilbronn.de] Sent: lundi 10 février 2020 20:14To:
> users@tomee.apache.orgCc:
> dev@tomee.apache.orgSubject: AW: TOMEE-2770
> Hi Francois,
> it would be beneficial, if you could provide a little sample project,
> which can reproduce the issue.
> With this in hands, it will be much easier to dig into this issue.
> BestRichardVon: COURTAULT
> Francois [francois.courta...@thalesgroup.com]Gesendet: Montag, 10.
> Februar 2020 12:51An: users@tomee.apache.orgCc:
> dev@tomee.apache.orgBetreff: RE: TOMEE-2770
> Hello Jonathan,
> Tried with TomEE 8.0.0 and 8.0.1: same issue.
> "Am I correct in thinking that if you invoke a business method on an
> EJB with this code may
> times:*jmsContext*.createProducer().send(*messageQueue*, *jmsContext*
> .createTextMessage(*"Test"*));"Yes.
> "in a heap dump you see a number of producers that aren't being
> cleared up?"Not in a heap sump: looking at the MBeans using jconsole
> Best Regards.
> -Original Message-From: Jonathan Gallimore [mailto:
> jonathan.gallim...@gmail.com]Sent: lundi 10 février 2020 12:46To:
> users@tomee.apache.orgCc: dev@tomee.apache.orgSubject: Re: TOMEE-2770
> There was some work done in this area between TomEE 8.0.0 and 8.0.1,
> so if you haven't yet tried 8.0.1, please do. In terms of what you're
> seeing, am I correct in thinking that if you invoke a business method
> on an EJB with this code may times:
> *jmsContext*.createProducer().send(*messageQueue*, *jmsContext*
> .createTextMessage(*"Test"*));
> in a heap dump you see a number of producers that aren't being
> cleared up?
> Jon
> On Mon, Feb 10, 2020 at 8:20 AM COURTAULT Francois <
> francois.courta...@thalesgroup.com> wrote:
> Hello everyone,
> Could you look at
> https://issues.apache.org/jira/browse/TOMEE-2770please ?This is
> blocking for us :(
> Best Regards.
>
>
>
smime.p7s
Description: S/MIME cryptographic signature
RE: TOMEE-2770
Hello Richard,
Have you been able to reproduce the issue ?
Best Regards.
-Original Message-
From: COURTAULT Francois
Sent: mardi 11 février 2020 10:42
To: users@tomee.apache.org
Cc: d...@tomee.apache.org
Subject: RE: TOMEE-2770
Hello Richard,
It's really easy to reproduce.
Just this class to be deploy in a war:
@Stateless
@Path("v1/notifications")
public class NotificationResource {
public static final String QUEUE_NAME = "jms/myQueue";
@Resource(name = QUEUE_NAME)
private Queue messageQueue;
@Inject
private JMSContext jmsContext;
@GET
@Path("downloadInfo")
public Response postDownloadInfoJMS() {
jmsContext.createProducer().send(messageQueue,
jmsContext.createTextMessage("Test"));
System.out.println("Message sent !");
return Response.accepted().build();
}
}
And a beans.xml with bean-discovery-mode="all".
Then perform several GET calls with a browser and you will the number of
dynamicProducer increase (1 per call).
Best Regards.
-Original Message-
From: Zowalla, Richard [mailto:richard.zowa...@hs-heilbronn.de]
Sent: lundi 10 février 2020 20:14
To: users@tomee.apache.org
Cc: d...@tomee.apache.org
Subject: AW: TOMEE-2770
Hi Francois,
it would be beneficial, if you could provide a little sample project, which can
reproduce the issue.
With this in hands, it will be much easier to dig into this issue.
Best
Richard
Von: COURTAULT Francois [francois.courta...@thalesgroup.com]
Gesendet: Montag, 10. Februar 2020 12:51
An: users@tomee.apache.org
Cc: d...@tomee.apache.org
Betreff: RE: TOMEE-2770
Hello Jonathan,
Tried with TomEE 8.0.0 and 8.0.1: same issue.
"Am I correct in thinking that if you invoke a business method on an EJB with
this code may times:
*jmsContext*.createProducer().send(*messageQueue*, *jmsContext*
.createTextMessage(*"Test"*));"
Yes.
"in a heap dump you see a number of producers that aren't being cleared up?"
Not in a heap sump: looking at the MBeans using jconsole
Best Regards.
-Original Message-
From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com]
Sent: lundi 10 février 2020 12:46
To: users@tomee.apache.org
Cc: d...@tomee.apache.org
Subject: Re: TOMEE-2770
There was some work done in this area between TomEE 8.0.0 and 8.0.1, so if you
haven't yet tried 8.0.1, please do. In terms of what you're seeing, am I
correct in thinking that if you invoke a business method on an EJB with this
code may times:
*jmsContext*.createProducer().send(*messageQueue*, *jmsContext*
.createTextMessage(*"Test"*));
in a heap dump you see a number of producers that aren't being cleared up?
Jon
On Mon, Feb 10, 2020 at 8:20 AM COURTAULT Francois <
francois.courta...@thalesgroup.com> wrote:
> Hello everyone,
>
> Could you look at https://issues.apache.org/jira/browse/TOMEE-2770
> please ?
> This is blocking for us :(
>
> Best Regards.
>
>
>
>
RE: TomEE microprofile memory consumption
Hello Jonathan I will do so (Jira). BTW, is this property tomee.mp.scan documented somewhere ? Best Regards. -Original Message- From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] Sent: mardi 11 février 2020 19:25 To: users@tomee.apache.org Subject: Re: TomEE microprofile memory consumption Awesome, thanks for the feedback. We'd still want to fix the actual issue. If you get time, if you can file a JIRA, that would be great. Jon On Tue, Feb 11, 2020 at 6:01 PM COURTAULT Francois < francois.courta...@thalesgroup.com> wrote: > Hello Jonathan, > > We did the test (remove tomee.mp.scan = all entry in > system.properties) with TomEE MP and it solves the issue we have: a > lot of opentracing objects created. > We don't have this issue (a lot of opentracing objects created) in > TomEE Plus because this entry doesn't exist in system.properties !!! > > Best Regards. > > -Original Message- > From: COURTAULT Francois > Sent: mardi 11 février 2020 10:32 > To: users@tomee.apache.org > Subject: RE: TomEE microprofile memory consumption > > Hello Jonathan, > > As I have mentioned, we see the issue in TomEE MP but not in TomEE Plus ! > So I did a comparison of the 2 flavors: lib + conf > > The only difference I have seen is in the system.properties where I > have the line below in TomEE MP and not this one in TomEE Plus ! > This could explain. We will try to remove this line to see if it > solves the memory issue we have and will let you know. > > Best Regards. > > -Original Message- > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] > Sent: lundi 10 février 2020 23:14 > To: users@tomee.apache.org > Subject: Re: TomEE microprofile memory consumption > > Allow me start over, if I may. > > What are you seeing in your memory dumps that's a concern - a large > number of ScopeImpl objects? Could you provide some screenshots from > VisualVM for us? I'd be interested in object counts, and whether there > are references, and if so, what they are. > > The TaskThread comes from Tomcat. It being present doesn't sound like > an issue, but I appreciate you've asked because you have some concern > - can you provide some more context? > > > You didn't answer to this question: Is there a way to disable > > opentracing > in TomEE MP ? Is it possible ? > > Its a setting in the Geronimo OpenTracing project: > https://github.com/apache/geronimo-opentracing. Try setting > geronimo.opentracing.filter.active to false (an entry in > conf/system.properties should do the trick). > > Jon > > On Mon, Feb 10, 2020 at 6:46 PM COURTAULT Francois < > francois.courta...@thalesgroup.com> wrote: > > > Hello Jonathan, > > > > Quite complex for us what you ask for. > > > > BTW, have you any idea about this > > org.apache.tomcat.util.threads.TaskThread in the memory dump we have. > > Where could it come from ? > > > > You didn't answer to this question: Is there a way to disable > > opentracing in TomEE MP ? Is it possible ? > > > > Best Regards. > > > > -Original Message- > > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] > > Sent: lundi 10 février 2020 18:21 > > To: users@tomee.apache.org > > Subject: Re: TomEE microprofile memory consumption > > > > > I can provide you some memory dumps if you want . > > > > Some details on how to reproduce with a small sample would be helpful. > > Memory dumps tend to be quite large and contain confidential > > information, so we prefer to not exchange those on the list. > > > > Jon > > > > On Mon, Feb 10, 2020 at 5:10 PM COURTAULT Francois < > > francois.courta...@thalesgroup.com> wrote: > > > > > Hello everyone, > > > > > > We have 2 microservices: one using TomEE Plus and the other using > > > TomEE > > MP. > > > These 2 µS don't use at all OpenTracing features: no @Trace > > > We have no memory issue with the µS using TomEE Plus. This is > > > strange because TomEE Plus somehow is a superset of TomEE MP. > > > > > > The issue is due to the usage of > > > org.apache.geronimo.microprofile.opentracing.impl.ScopeImpl but we > > > don't know what trigger that usage. > > > We also see a lot of org.apache.tomcat.util.threads.TaskThread > > > (don't know where it comes from) which uses the above ScopeImpl. > > > > > > I can provide you some memory dumps if you want . > > > > > > Is there a way to disable opentracing in TomEE MP ? > > > > > > Best Regards. > > > > > > > > > > > > > > >
