Thank you all for the feedback. Guillaume, that is exactly what we did in the end. For mere curiosity: in your opinion, would it be more performing to have PaxLogging not publishing at all or it wouldn't make a significant difference?
Il giorno venerdì 28 aprile 2017 13:41:29 UTC+2, Guillaume Nodet ha scritto: > > Filtering can be done in Felix EventAdmin using > org.apache.felix.eventadmin.IgnoreTopic property in the > org.apache.felix.eventadmin.impl.EventAdmin pid. > If you specify org.osgi.service.log.*, all log events should be discarded > without going through the EventAdmin thread pools at all. > > > 2017-04-26 11:00 GMT+02:00 Roberto Pierpaoli <rob...@iooota.com > <javascript:>>: > >> 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 <rob...@iooota.com>: >>> >>>> 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, <ra...@evosent.com> 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/apache-felix-event-admin.html >>>>>> >>>>>> Cheers, >>>>>> Raúl. >>>>>> >>>>>> -- >>>>>> -- >>>>>> ------------------ >>>>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>>>> >>>>>> --- >>>>>> 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 ops4j+un...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>> >>>> --- >>>> 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 ops4j+un...@googlegroups.com. >>>> 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 - op...@googlegroups.com <javascript:> >> >> --- >> 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 ops4j+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > ------------------------ > Guillaume Nodet > > -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- 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 ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
