Misconfigured Vivace / Delayed Updates with Data Provider

[exchangepulse]

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

[Alessandro]

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

[exchangepulse]

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