[
https://issues.apache.org/jira/browse/FELIX-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346409#comment-17346409
]
Amit Mondal commented on FELIX-6407:
------------------------------------
Thanks, Tom, for the comprehensive explanation. I agree with you that the new
functionality benefits us to use the _*LoggerAdmin*_ for such configurable
loggers. And that was one of the points we discussed with Peter before Peter
started refactoring the logging in SCR.
The primary intention with Peter's PR was to introduce an OSGi-SCR-incompatible
extension where SCR can have its own log level so that SCR will not use the log
level of the extended bundle to log the messages.
And that's why Peter introduced _*ExtLogManager*_, which explicitly used SCR's
bundle instance to retrieve the log level that has been set explicitly. That is
the reason SCR's bundle instance is used. However, this is only true if and
only if the extended logging configuration has been set
(_*ds.log.extension=true*_).
However, the default behaviour has been left untouched, where SCR will keep on
using the log level of the extended bundle to log the messages. In this
scenario, the _*ExtLogManager*_ is not used, and hence we use the bundle
instance of the extended bundle. So, the SCR bundle instance is only used in
one scenario when the _*ds.log.extension*_ property is set to _*true*_.
If we don't use the SCR bundle instance in _*ExtLogManager*_, it will behave as
same as when the _*ds.log.extension*_ property is not set. There was a minor
bug. I noticed that _*ExtLogManager*_ still uses the bundle instance of the
extended bundle, which is not intended. I discussed this with Peter too, and
Peter agreed that the _*ExtLogManager*_ should use the SCR's bundle instance.
This is one of the bugs I fixed in my PR. I also noticed another critical issue
that is very crucial for low-memory IoT devices. I noticed that even after
fixing the bug as mentioned above, the _*ExtLogManager*_ still uses the
_*BundleListener*_ to keep track of all bundles' log levels, which is very
costly in such low-memory devices where we have around _*300+*_ bundles. If the
user decides to use _*ds.log.extension*_ (SCR's own log level), there is no
point in tracking the rest of the bundles.
I fixed this in my PR too. Since I was already at it, I thought the SCR's
logging can be optimized and cleaned up further to provide an extension for
users to decide if the SCR logging is required at all. In more significant IoT
installations, people are very cautious about logging as it can quickly become
very costly, and that's why we are always careful about logging in low-memory
IoT devices. In our scenario, for production IoT gateways, we can disable the
logging completely, which saves resources that are not required at all, such as
unnecessary bundle and service trackers.
In addition, I also noticed another interesting problem in our IoT gateway
runtime. For very optimized logging in low-memory IoT devices, we have
implemented the _*OSGi Log Service specification*_ from scratch. And the bundle
listener that at startup tries to retrieve the log levels of every bundle of
the runtime also attempts to retrieve the log level of the log bundle, leading
to the infamous _*ServiceFactory getService() resulted in cycle*_. The log
service implementation bundle itself does not use any logging at all, and
trying to retrieve its log level is also not required if the
_*ds.log.extension*_ is set to _*true*_.
In conclusion, I have tried to consider these scenarios in my PR and enhanced
the SCR logging for further extensibility. The functionality to change log
levels of the SCR using _*LoggerAdmin*_ is an extension for users to configure
the log levels more precisely, but I firmly believe that the fixes I tried to
work on will also be helpful for users to optimize the SCR logging behaviour
according to their needs. These fixes will also save us from unnecessary waste
of resources in scenarios where it is considered very essential.
> SCR Log Extension still logs using the log level of the extended bundle
> -----------------------------------------------------------------------
>
> Key: FELIX-6407
> URL: https://issues.apache.org/jira/browse/FELIX-6407
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.1.24, scr-2.1.26
> Reporter: Amit Mondal
> Priority: Minor
> Labels: pull-request-available
>
> The SCR incorporates 3 different types of logging:
> * Logging for SCR main code (_*ScrLogger*_)
> * Logging on behalf of the bundle comprising the SCR component
> (_*BundleLogger*_)
> * Logging on behalf of the component under processing (_*ComponentLogger*_)
> According to the current implementation, the SCR logging is by default
> enabled and it logs using the log levels of the bundles comprising the SCR
> components.
> This [PR|https://github.com/apache/felix-dev/pull/36] by [~pkriens] has been
> merged to introduce a non-OSGi standard extension which enables consumers to
> extend the SCR logging functionality, that is, a consumer can on demand set
> the log level of the SCR bundle itself which after setting a specific
> property (_*ds.log.extension*_) will be enabled. Now, SCR will be able to use
> the log level of itself for all the logging. It won't use the log levels of
> the bundles under processing.
> The specified SCR versions still log using the log levels of the bundles
> under processing even though _*ds.log.extension*_ framework property is
> correctly set.
> This feature to extend SCR logging is useful in very low memory IoT devices
> where many bundles (>200) are installed and SCR's intensive logging becomes
> very costly.
> The feature can further be extended to disable the logging completely. Hence,
> I am proposing the following approach:
> We should introduce another framework property to disable the SCR logging
> completely, let's say _*ds.log.enabled*_
> By default, this property will not be set which means the logging is enabled
> by default, otherwise consumer can decide to disable the logging by setting
> it to _*false*_
> If the logging is still enabled, the consumer now has two options:
> * Use the log level of the extended bundle (bundle under processing)
> * Use the log level of the SCR bundle itself
> If we decide to let SCR use its own log level, the _*ds.log.extension*_ needs
> to be set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
