Hi Rajesh,
For the Server log, we lean on the third-party "logback" library.
The factory configuration file,
lightstreamer_log_conf.xml, also contains the available documentation of the log categories (i.e. loggers) in which the produced log is divided. We suggest opening it with a text editor.
For instance, Data Adapter updates are covered by "LightstreamerLogger.subscriptions.upd" at DEBUG level, whereas subscriptions towards the Data Adapter are covered by "LightstreamerLogger.subscriptions" at DEBUG level.
The single subscriptions by each client session are not logged directly, but they are notified to the Metadada Adapter through the notifyNewTables and notifyTablesClose callbacks.
You can have different loggers print on different files by leveraging logback's "appenders".
On the client side, the logging technique may differ among the SDKs, but in general it is based on a custom interface.
See the javascript case, for instance, where the entry point is the
setLoggerProvider method.
In this case, the library log is divided into "categories" for each of which the application should provide a "logger" object which will handle the log. These loggers are provided through a custom object of the "LoggerProvider" class.
If the application sticks to the basic implementation (the SimpleLoggerProvider), it can instead define one or more "appenders" and, for each one, specify the categories it should handle.
However, the client log is only meant as a debugging tool. The report of the application activity, with regard to subscriptions and received data, should be logged by the application.
