LiteralBaseProvider and SmartDataProvider Instantiation

[oliverwetterau]

Lightstreamer Server 6.0.1 build 1780

[gianluca.finocchiaro]

Ok,

could you please send us the log showing the startup of Lightstreamer Server (not running in the development environment)? We need to analyse the order of initialization of Metadata Adapter and Data Adapter classes, so please leave the logger.debug statement inside method init of your DataAdapter.
Also update the lightstreamer_log_conf.xml as follows:

<logger name="LightstreamerLogger.init" level="DEBUG"/>

Regards
Gianluca

[oliverwetterau]

Hi Gianluca,

I have attached the requested log file.

One other thing that seems a bit strange: I can only start LS.sh within the Lightstreamer/bin directory. From all other locations (e.g. /opt/Lightstreamer by calling bin/unix-like/LS.sh) the Lightstreamer server home directory analysed by LS.sh is wrong (e.g. "/opt") and leads to Lightstreamer not starting. Maybe that's part of the problem.

Best regards,
Oliver

[gianluca.finocchiaro]

Oliver,

from your previous posts I did not notice the following configuration:
<classloader>log-enabled</classloader>
This specific setting, basically used to share logging configuration with the server, configures a dedicated ClassLoader which does not inherit from the Adapter Set ClassLoader. It means that no sharing of classes is possible among the Adapters (even among Metadata Adapter class and Data Adapter classes in the same Adapter Set). In other words, in your case 'MetadataAdapter' will be assigned an Adapter ClassLoader ("log-enabled"), which is totally unrelated with the one assigned to 'DataAdapter' ("common", the default Adapter Set ClassLoader). Please have a look here and at the comments you can find in DOC-SDKs/sdk_adapter_java_inprocess/doc/adapter_conf_template/adapters.xml file of your Lightstreamer installation for a more detailed understanding.

As a consequence of this, to make things works you have to give up using shared logging and, instead, switch to Adapter's own logging, for example by adding specific parameters which could be used for logging configuration, as follows:
<param name="log_config">../adapters_log_conf.xml</param><br /> <param name="log_config_refresh_seconds">10</param>
This is the same approach we used in our In-Process Java Adapter demos

For what concerns the startup of Lightstreamer Server, different options are available (at least on a unix system and provided that you have right permissions):

1. execute "start.sh" script from the bin/unix-like directory, as stated in the GETTING_STARTED.txt file.
2. execute "LS.sh run" command from the bin/unix-like directory
3. execute "unix/LS.sh run" command from the "bin" directory
4. execute "/opt/Lightstreamer/bin/unix/LS.sh run" command from any directory.

I confirm that execution of LS.sh script is not related with the aforementioned ClassLoader issue.

Regards,
Gianluca

[oliverwetterau]

Hi Ginluca,

your last post really solved the problem. Thanks!

But I must admit that I had preferred it to be able to use shared logging...

Best regards,
Oliver