Results 1 to 9 of 9
  1. #1

    LiteralBaseProvider and SmartDataProvider Instantiation

    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

  2. #2
    Administrator
    Join Date
    Feb 2008
    Location
    Siracusa
    Posts
    149
    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:

    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:


    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

  3. #3
    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
    Last edited by oliverwetterau; November 2nd, 2015 at 08:33 AM.

  4. #4
    Administrator
    Join Date
    Feb 2008
    Location
    Siracusa
    Posts
    149
    Hi Oliver,

    which version of Lightstreamer Server?

    Gianluca

  5. #5
    Lightstreamer Server 6.0.1 build 1780

  6. #6
    Administrator
    Join Date
    Feb 2008
    Location
    Siracusa
    Posts
    149
    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:



    Regards
    Gianluca

  7. #7
    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
    Attached Files Attached Files
    Last edited by oliverwetterau; November 2nd, 2015 at 10:03 AM.

  8. #8
    Administrator
    Join Date
    Feb 2008
    Location
    Siracusa
    Posts
    149
    Oliver,

    from your previous posts I did not notice the following configuration:

    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:

    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

  9. #9
    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

 

 

Similar Threads

  1. Replies: 3
    Last Post: February 12th, 2009, 10:31 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 10:11 PM.