Results 1 to 6 of 6
  1. #1
    Member
    Join Date
    Mar 2009
    Location
    Kapolei
    Posts
    6

    Misconfigured Vivace / Delayed Updates with Data Provider

    We've upgraded from the Moderato edition to the Vivace edition in order to see how it will handle with unlimited updates. We've been using Moderato for months. Unfortunately, we're not seeing the updates happen; still only about 1 update per second and very high data loss. We've verified that the data is leaving our pipe to LS & LS is not throwing any exceptions such as malformed data. We're doing a very simple console.log(....) to output updates sent to browser as a test case.

    We have the lightstreamer_conf.xml setup correctly for the version:
    <lightstreamer_edition>Vivace</lightstreamer_edition>

    logs/Lightstreamer.log:27-Oct-09 09:03:10,056 |INFO |LightstreamerLogger.init |main |Lightstreamer Server starting in Vivace edition


    We're using the Data/Metadata API.


    What might we be doing wrong? What more information can I supply to help diagnose the problem?

    Best,


    Erik Osterman

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    Hi Erik,

    Fist, we should make sure that you didn't configure a frequency limit of 1 update/s at the API level. This can be done on both the client side and the server side.

    On the client side, assuming you are using the Web client, you can specify a filtering frequency with the setRequestedMaxFrequency method.

    On the server side, you can impose a maximum update frequency through your custom Metadata Adapter.

    If no API-level frequency limit was imposed, we can move to further investigation.

    Regards,

    Alessandro

  3. #3
    Member
    Join Date
    Mar 2009
    Location
    Kapolei
    Posts
    6
    Alessandro,

    You were spot on. Thanks for pointing those things out -- we had them all setup wrong. It's working now.

    Best,

    Erik

  4. #4
    Member
    Join Date
    Mar 2009
    Location
    Kapolei
    Posts
    6
    So, while this fixed the number of updates per second, we're still seeing significant data loss. We've set max bandwidth and updates to 'unlimited':
    * table.setRequestedMaxFrequency('unlimited');
    * lsEngine.policy.setMaxBandwidth('unlimited');
    * <max_delay_millis>0</max_delay_millis>



    In our use case, and "item" is a user's subscription plan ("plastic widgets"). Within a millisecond, we can send a burst of more than 50 updates to this item representing current prices for 50 different types of "plastic widgets". We cannot have LS compress these updates in any way.

    We notice that if we send a burst of updates, we tend to get the first packet and the last packet, but missing all the ones in between, or in othercases just the last packet.

    Example output from the JS:
    /*
    table.onItemUpdate = function(item, updateInfo, itemName) {
    var arr = [];
    for(var i = 0; i < schema.length; i++) {
    var val = updateInfo.getNewValue(schema[i]);
    if(val)
    {
    //data[schema[i]] = val;
    arr.push(schema[i] + ':' + val);
    }
    }
    console.log(arr);
    ....
    */

    Produces....


    ["ric:HGF1", "s_attempt:1919", "s_update:1", "s_total:14", "timestamp:1256721362"]
    ["ric:HGF0", "s_attempt:1919", "s_update:14", "s_total:14", "timestamp:1256721363"]
    ["ric:HGH0", "s_attempt:1925", "s_update:6", "s_total:6", "timestamp:1256721364"]
    ["ric:HGV0", "s_attempt:1941", "s_update:13", "s_total:13", "timestamp:1256721371"]
    ["ric:HGM1", "s_attempt:1954", "s_update:1", "s_total:13", "timestamp:1256721375"]
    ["ric:HGV0", "s_attempt:1954", "s_update:13", "s_total:13", "timestamp:1256721375"]
    ["ric:HGM1", "s_attempt:1975", "s_update:1", "s_total:6", "timestamp:1256721384"]
    ["ric:HGX9", "s_attempt:1975", "s_update:6", "s_total:6", "timestamp:1256721384"]
    ["ric:HGF0", "s_attempt:1976", "s_update:17", "s_total:17", "timestamp:1256721384"]
    ["ric:HGF0", "s_attempt:1977", "s_update:2", "s_total:2", "timestamp:1256721384"]
    ["ric:HGV9", "s_attempt:1978", "s_update:3", "s_total:3", "timestamp:1256721385"]
    ["ric:HGF0", "s_attempt:1979", "s_update:2", "s_total:2", "timestamp:1256721385"]
    ["ric:HGF0", "s_attempt:1984", "s_update:5", "s_total:5", "timestamp:1256721387"]

    Where,

    s_attempt: a counter representing a single burst of multiple UD3 packets to LS
    s_update: a counter representing a specific UD3 packet within the burst
    s_total: a counter representing the total number of UD3 packets (s_updates) within the burst

    What I would expect to see for burst 1984 is:

    ["ric:HGF0", "s_attempt:1984", "s_update:1", "s_total:5", "timestamp:1256721387"]
    ["ric:HGG1", "s_attempt:1984", "s_update:2", "s_total:5", "timestamp:1256721387"]
    ["ric:HGH2", "s_attempt:1984", "s_update:3", "s_total:5", "timestamp:1256721387"]
    ["ric:HGI3", "s_attempt:1984", "s_update:4", "s_total:5", "timestamp:1256721387"]
    ["ric:HGJ4", "s_attempt:1984", "s_update:5", "s_total:5", "timestamp:1256721387"]

    Instead, I only see the last packet.

    Note attempts: 1919, 1954, 1975 (first and last packet)
    All other attempts only received *last* packet of burst

    What can we do differently to avoid this behavior?


    Best,

    Erik Osterman

  5. #5
    Administrator
    Join Date
    Jul 2006
    Location
    Milan, Italy
    Posts
    517
    Hi Erik,

    For your requirements, you should use "RAW" subscription mode. Is it possible you are currently using "MERGE"?

    On a side note, it is not recommended setting <max_delay_millis> to 0, as this will impose a much higher stress on the network, the server, and the client, without a perceivable advantage for the final user. Even a small value, like 30 ms, is better than 0.

    Cheers,

    Alessandro

  6. #6
    Member
    Join Date
    Mar 2009
    Location
    Kapolei
    Posts
    6
    Alessandro,

    Right again! The RAW mode is what we wanted. Setting <max_delay_millis/> to zero was just out of frustration. Will bump it up.

    Thanks,

    Erik Osterman

 

 

Similar Threads

  1. Single data provider and multiple data sources
    By pluczak in forum Adapter APIs
    Replies: 1
    Last Post: April 26th, 2012, 10:50 AM
  2. Using tomcat as the web server - no data updates
    By bhathiya in forum Client APIs
    Replies: 2
    Last Post: April 11th, 2011, 08:38 AM
  3. Updates dropped when restart is performed
    By ctranfd in forum Client APIs
    Replies: 3
    Last Post: June 5th, 2009, 11:45 AM
  4. Data Provider Protocol Method Tags
    By juls in forum Adapter Protocol
    Replies: 1
    Last Post: March 4th, 2009, 09:00 AM
  5. Data Provider question
    By yanhu in forum Adapter APIs
    Replies: 1
    Last Post: July 25th, 2007, 01:07 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 07:10 PM.