-
October 27th, 2009, 10:45 AM
#1
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
-
October 27th, 2009, 11:09 AM
#2
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
-
October 28th, 2009, 06:22 AM
#3
Alessandro,
You were spot on. Thanks for pointing those things out -- we had them all setup wrong. It's working now.
Best,
Erik
-
October 28th, 2009, 09:29 AM
#4
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
-
October 28th, 2009, 09:59 AM
#5
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
-
October 28th, 2009, 05:41 PM
#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
-
By pluczak in forum Adapter SDKs
Replies: 1
Last Post: April 26th, 2012, 10:50 AM
-
By bhathiya in forum Client SDKs
Replies: 2
Last Post: April 11th, 2011, 08:38 AM
-
By ctranfd in forum Client SDKs
Replies: 3
Last Post: June 5th, 2009, 11:45 AM
-
By juls in forum Adapter SDKs
Replies: 1
Last Post: March 4th, 2009, 09:00 AM
-
By yanhu in forum Adapter SDKs
Replies: 1
Last Post: July 25th, 2007, 01:07 AM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 11:12 PM.
Bookmarks