I confirm that we disabled eventadmin altogether (by removing the Karaf feature). In our case, we found a bottleneck in some internal queue or buffer inside pax-logging or the OSGi framework (Equinox or Felix, can't remember), that was holding up the system.
Cheers. --- Raúl Kripalani linkedin.com/in/raulkripalani | evosent.com <http://evosent.com/?utm_source=email&utm_medium=email&utm_campaign=evosent_raul> | blog: raul.io <http://raul.io?utm_source=email&utm_medium=email&utm_campaign=evosent_raul> | skype: raul.fuse On Wed, Apr 26, 2017 at 11:24 AM, 'Achim Nierbeck' via OPS4J < [email protected]> wrote: > Hi, > > nope it's not handled, log "events" are always send to the event admin > service [1] > > regards, Achim > > [1] - https://github.com/ops4j/org.ops4j.pax.logging/blob/ > master/pax-logging-service/src/main/java/org/ops4j/pax/ > logging/service/internal/PaxLoggingServiceImpl.java#L184-L194 > > 2017-04-26 11:41 GMT+02:00 Roberto Pierpaoli <[email protected]>: > >> Hi Achim, >> unfortunately we use the EventAdmin service a lot for the events dealing >> with our logic, otherwise it would certainly be already switched off :-) >> >> If the propagation can be already stopped on the PaxLogging side today, >> it would be great to know it, if it is not then we don't exclude to patch >> it by ourselves, we would just have to take a look at the code, since we >> never put our hands inside it: we just don't want to make a mess ':) >> >> Thanks again. >> >> Il giorno mercoledì 26 aprile 2017 11:32:59 UTC+2, Achim Nierbeck ha >> scritto: >>> >>> Hi, >>> >>> ok so now I've got a clearer view ;) >>> Do you need the event-admin in your context? >>> Maybe just turn that one off ... :) >>> >>> But either way, just open an issue for this and we'll see what is >>> possible. Or maybe you want to come up with a proper solution, in that case >>> we highly appreciate pull-requests :-D >>> >>> regards, achim >>> >>> >>> >>> 2017-04-26 11:23 GMT+02:00 Roberto Pierpaoli <[email protected]>: >>> >>>> Hi Achim, >>>> >>>> I can't say if the specification describes *how* log events should be >>>> propagated or *if* the propagation itself is mandatory, probably we >>>> should ask to the OSGi alliance :) >>>> >>>> We run our software over an embedded platform, with limited >>>> computational power, that's why we try to avoid anything that is not >>>> strictly needed, thus the will to turn off log events propagation at its >>>> root, rather than on the event-admin side. >>>> >>>> Anyway, if the latter is the only possible approach, we'll do what's >>>> allowed, clearly :) >>>> >>>> Thanks for your contribution! >>>> >>>> >>>> Il giorno mercoledì 26 aprile 2017 11:14:44 UTC+2, Achim Nierbeck ha >>>> scritto: >>>>> >>>>> Hi, >>>>> >>>>> according to the spec: >>>>> >>>>> 101.6.4 Log Events >>>>> >>>>> Log events must be delivered by the Log Service implementation to the >>>>> Event Admin service (if present) asynchronously under the topic: >>>>> org/osgi/service/log/LogEntry/<event type> >>>>> >>>>> For me this sounds a mandatory, one just doesn't need to consume from >>>>> that topic? >>>>> >>>>> But maybe I'm not aware of the real problem you seem to have with all >>>>> logs being send as events :) >>>>> >>>>> regards, Achim >>>>> >>>>> >>>>> >>>>> 2017-04-26 11:00 GMT+02:00 Roberto Pierpaoli <[email protected]>: >>>>> >>>>>> Hi Achim, thank you for the super-quick feedback. >>>>>> >>>>>> I'm sorry, I didn't know that it is mandatory to propagate log events >>>>>> to the event-admin service... I thought it could reasonably be a >>>>>> configuration option, since not everybody needs that for the business >>>>>> logic, but I guess it is needed by the underlying runtime implementation >>>>>> (Apache Karaf, in my case). >>>>>> >>>>>> Do you think that filtering at the event-admin level will be equally >>>>>> efficient, in terms of not congestioning the threadpools? >>>>>> >>>>>> Kind regards, >>>>>> >>>>>> Roberto >>>>>> >>>>>> Il giorno mercoledì 26 aprile 2017 10:47:02 UTC+2, Achim Nierbeck ha >>>>>> scritto: >>>>>>> >>>>>>> hmm ... I'm sure it's doable, though wasn't this mandatory from the >>>>>>> OSGi spec ?? >>>>>>> LOG events should always be send, if there is a event-admin >>>>>>> available ... why not filter on the eventadmin, you don't need to >>>>>>> consume >>>>>>> those? >>>>>>> So what is the use-case? >>>>>>> >>>>>>> regards, Achim >>>>>>> >>>>>>> 2017-04-26 10:42 GMT+02:00 Roberto Pierpaoli <[email protected]>: >>>>>>> >>>>>>>> Hi, I'm looking for the same solution: we would like to prevent >>>>>>>> PaxLogging from publishing anything to the OSGi Event Admin, is that >>>>>>>> actually possibile? >>>>>>>> >>>>>>>> Thanks in advance. >>>>>>>> >>>>>>>> >>>>>>>> Il giorno martedì 22 marzo 2016 15:52:35 UTC+1, Guillaume Nodet ha >>>>>>>> scritto: >>>>>>>>> >>>>>>>>> Adding a configuration option to disable that should be easy to do. >>>>>>>>> Would you mind writing a pull request for that ? >>>>>>>>> >>>>>>>>> Though, at the end, I'm not sure there will be much difference in >>>>>>>>> upgrading pax-logging or eventadmin, and given it's already supported >>>>>>>>> in >>>>>>>>> eventadmin, why not simply upgrading to a recent version of it ? >>>>>>>>> >>>>>>>>> On Tue, Mar 22, 2016 at 3:02 PM, <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Is it possible to disable the publishing of LogEntry events to >>>>>>>>>> the org/osgi/service/log/LogEntry/* topic in the OSGi Event >>>>>>>>>> Admin? >>>>>>>>>> >>>>>>>>>> I am seeing nasty contention in a log-heavy application due to >>>>>>>>>> congestion in the EventAdmin threadpools. Increasing the size of the >>>>>>>>>> threadpools [1] is just a workaround, and ignoring the events via >>>>>>>>>> EventAdmin config is not an option because we're running on Felix >>>>>>>>>> EventAdmin 1.3.2. >>>>>>>>>> >>>>>>>>>> Moreover, there are no handlers subscribed to these topics OOTB, >>>>>>>>>> so it's not like we'd lose functionality by disabling the generation >>>>>>>>>> of the >>>>>>>>>> event in the first place. Is it possible to do so? >>>>>>>>>> >>>>>>>>>> qtp1225771956-3286 <--- Frozen for at least 23 sec >>>>>>>>>> >>>>>>>>>> EDU.oswego.cs.dl.util.concurrent.PooledExecutor.execute(Runnable) >>>>>>>>>> >>>>>>>>>> *org.apache.felix.eventadmin.im >>>>>>>>>> <http://org.apache.felix.eventadmin.im>pl.tasks.DefaultThreadPool.executeTask(Runnable) >>>>>>>>>> DefaultThreadPool.java:101* >>>>>>>>>> >>>>>>>>>> org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks.execute(Collection, >>>>>>>>>> Event) AsyncDeliverTasks.java:105 >>>>>>>>>> >>>>>>>>>> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.postEvent(Event) >>>>>>>>>> EventAdminImpl.java:100 >>>>>>>>>> >>>>>>>>>> org.apache.felix.eventadmin.impl.adapter.LogEventAdapter$1.logged(LogEntry) >>>>>>>>>> LogEventAdapter.java:281 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.logback.internal.LogReaderServiceImpl.fire(LogListener, >>>>>>>>>> LogEntry) LogReaderServiceImpl.java:92 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.logback.internal.LogReaderServiceImpl. >>>>>>>>>> access$300(LogReaderServiceImpl, LogListener, LogEntry) >>>>>>>>>> LogReaderServiceImpl.java:46 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.logback.internal.LogReaderServiceImpl$1.fireEvent(LogEntry) >>>>>>>>>> LogReaderServiceImpl.java:114 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.logback.internal.PaxLoggingServiceImpl$1.handleEvents(Bundle, >>>>>>>>>> ServiceReference, int, String, Throwable) >>>>>>>>>> PaxLoggingServiceImpl.java:138 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.logback.internal.PaxLoggerImpl.inform(String, >>>>>>>>>> Throwable, String) PaxLoggerImpl.java:198 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.internal.TrackingLogger.inform(String, >>>>>>>>>> Throwable, String) TrackingLogger.java:116 >>>>>>>>>> >>>>>>>>>> org.ops4j.pax.logging.slf4j.Slf4jLogger.log(Marker, String, int, >>>>>>>>>> String, Object[], Throwable) Slf4jLogger.java:1098 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.common.logging.Slf4jLogger.internalLogFormatted(String, >>>>>>>>>> LogRecord) Slf4jLogger.java:139 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.common.logging.AbstractDelegatingLogger.internalLog(LogRecord) >>>>>>>>>> AbstractDelegatingLogger.java:353 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.common.logging.AbstractDelegatingLogger.doLog(LogRecord) >>>>>>>>>> AbstractDelegatingLogger.java:335 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.common.logging.AbstractDelegatingLogger.log(LogRecord) >>>>>>>>>> AbstractDelegatingLogger.java:46 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.interceptor.AbstractLoggingInterceptor.log(Logger, >>>>>>>>>> String) AbstractLoggingInterceptor.java:239 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.interceptor.LoggingInInterceptor.logging(Logger, >>>>>>>>>> Message) LoggingInInterceptor.java:157 >>>>>>>>>> >>>>>>>>>> org.apache.cxf.interceptor.LoggingInInterceptor.handleMessage(Message) >>>>>>>>>> LoggingInInterceptor.java:79 >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> [1] https://felix.apache.org/documentation/subprojects/apach >>>>>>>>>> e-felix-event-admin.html >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Raúl. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -- >>>>>>>>>> ------------------ >>>>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "OPS4J" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>> -- >>>>>>>> ------------------ >>>>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>>>> >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "OPS4J" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Apache Member >>>>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>>>> Committer & Project Lead >>>>>>> blog <http://notizblog.nierbeck.de/> >>>>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>>>> >>>>>>> Software Architect / Project Manager / Scrum Master >>>>>>> >>>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - [email protected] >>>>>> >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "OPS4J" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Apache Member >>>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>>>> Committer & Project Lead >>>>> blog <http://notizblog.nierbeck.de/> >>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>>>> >>>>> Software Architect / Project Manager / Scrum Master >>>>> >>>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - [email protected] >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OPS4J" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> >>> Apache Member >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer >>> & Project Lead >>> blog <http://notizblog.nierbeck.de/> >>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>> >>> Software Architect / Project Manager / Scrum Master >>> >>> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - [email protected] >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> > > Software Architect / Project Manager / Scrum Master > > -- > -- > ------------------ > OPS4J - http://www.ops4j.org - [email protected] > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OPS4J" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/ops4j/th6_uZe0lnk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
