LiteralBaseProvider and SmartDataProvider Instantiation

oliverwetterau

Hello,

I am running into the following strange issue. I have created two adapters:

public class DataAdapter implements SmartDataProvider
public class MetadataAdapter extends LiteralBasedProvider

In MetadataAdapter's constructor a static instance variable gets set (the only write access to the instance variable in the whole project):

public MetadataAdapter() {
super();
metadataAdapterInstance = this;
}

Read access is provided by:

public static MetadataAdapter instance() {
return metadataAdapterInstance;
}

But when this instance variable is accessed it is sometimes set and sometimes null. E.g. it is always null when accessing it within DataAdapters's constructor:

public DataAdapter() {
logger.debug("[constructor] instance = {}", MetadataAdapter.instance());
}

The adapters.xml looks like this (shortened):
<adapters_conf id="online-consulting">
<metadata_adapter_initialised_first>Y</metadata_adapter_initialised_first>
<metadata_provider>
<adapter_class>xyz.MetadataAdapter</adapter_class>
<classloader>log-enabled</classloader>

...
</metadata_provider>
<data_provider>
<adapter_class>xyz.DataAdapter</adapter_class>
</data_provider>
</adapters_conf>

Interestingly enough, in my debugging environment everything works fine (Intellij). The setings are:
Main class: com.lightstreamer.LS
VM options: -Dcom.lightstreamer.kernel_lib_path=lib/lightstreamer.jar -Dcom.lightstreamer.logging_lib_path=lib/ls-logging-utilities.jar -Dcom.lightstreamer.internal_lib_path=lib/ls-monitor.jar:lib/core/*:lib/mpn/*:lib/mpn/apns/*:lib/mpn/gcm/*:shared/lib/*
Program arguments: conf/lightstreamer_conf.xml

Any idea what might cause this strange (and show stopping) behaviour?

Best regards,
Oliver

Gianluca Finocchiaro

Hi Oliver,

there is no guarantee about the order of instantiation for MetadataAdapter and DataProvider classes, so you cannot leverage on that in order to setup this kind of communication between instances, as in your example.

The only order that can be assured is relative to the invocation of init methods, which should be used to place all the initialization logic for both classes.
By using the following settting:
[SYNTAX=XML]<metadata_adapter_initialised_first>Y</metadata_adapter_initialised_first>[/SYNTAX]
as you did in your adapters.xml configuration file, you ensure that the invocation of 'init' method for the MetadataAdapter ends before the 'init of the DataAdapter is called (and, in general, before any 'init' of all Data Apdaters provided in the same Adapter Set). It means that you should not access the static 'instance' method of your 'MetadataAdapter' class in the constructor of 'DataAdapter', but rather in its 'init' method, as follows:

[SYNTAX=JAVA]public DataAdapter() {
// DO NOT DO THIS!
// logger.debug("[constructor] instance = {}", MetadataAdapter.instance());
}

@Override
public void init(Map params, File dir) throws MetadataProviderException {
// Safe place to do this:
logger.debug("[constructor] instance = {}", MetadataAdapter.instance());
}[/SYNTAX]
Obviously, you get back to the similar problem by configuring the parameter with 'N', because in that case the MetadataAdapter and DataApater instances get intialized in parallel, so the final behavior is unpredictable. Anyway, default value is 'Y'.

Let me know if this explanation is enough for you.

Thanks and Regards,
Gianluca

oliverwetterau

Hi Gianluca,

your explanation helps to understand instantation of the adapter classes, but unfortunately it does not solve my problem.

When I access the MetadataAdapter within the DataAdapters init() method (as described in your answer), it returns a Null for the MetadataAdapter instance.

The actual issue I am dealing with is that the MetadataAdapter instance is null when DataAdapters's subscribe method is being called where I definitely need that instance and am now running into a null pointer exception.

Interestingly enough, after a few calls of the subscribe method the MetadataAdapter instance seems to be set.

And as I said, this problem does not appear when running in debug mode from Intellij Idea.

Best regards,
Oliver

Gianluca Finocchiaro

Hi Oliver,

which version of Lightstreamer Server?

Gianluca

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:

[SYNTAX=XML]<logger name="LightstreamerLogger.init" level="DEBUG"/>[/SYNTAX]

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:
[SYNTAX=XML]<classloader>log-enabled</classloader>[/SYNTAX]
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:
[SYNTAX=xml]<param name="log_config">../adapters_log_conf.xml</param>
<param name="log_config_refresh_seconds">10</param>[/SYNTAX]
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):

execute "start.sh" script from the bin/unix-like directory, as stated in the GETTING_STARTED.txt file.
execute "LS.sh run" command from the bin/unix-like directory
execute "unix/LS.sh run" command from the "bin" directory
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