churrusco
Hi all,
My tests with Lightstreamer have been really successful and definitely show a great product. 4000 concurrent clients moving data continuously over one entire day at the same time and maintaining a 88% CPU level and with no apparent memory leaks show quite a good software.
My last question over this product is quite simple. Is there a way to guarantee delivery? I've seen that when you really stress Lightstreamer you start to get lost alert messages. With this you could implement such a thing, but I would really want to know if there is something already done to provide such guarantee.
Aside of this, I don't really understand the conceptual difference between two messages I saw: A warning saying "possible loss of events" and a update lost alert severe message.
Cheers,
Martin
Mone
Hi,
please take a look here:
http://www.lightstreamer.com/vb/faq.php?faq=server_side#faq_guaranteed_delivery
let me know if further explanation is needed.
Bye!
Dario Crivelli
Hi Martin,
about your second question:
The severe error message about lost updates occurs for an item that was subscribed to in RAW mode or with unfiltered dispatching specified, when events are dropped by the Server for performance problems. The Server notifies the Client of this case.
The "possible loss of events" message is issued in a broader range of cases, when there is a discontinuity in the events flow. The possible case depends on the item subscription characteristics. One common case is an automatic reconnection to recover from an unexpected disconnection.
Dario
msignorini
I'm subscribing in RAW mode and I've got a question on the "bufferSize".
From FAQ:
"Should the internal buffer (whose maximum physical size depends on the memory of the server box) get full (quite an impossible event for a portfolio), then one or more updates are LOST: in this case a notification is sent to the Client with high priority (on the same stream connection but in front of the buffered updates) so that the Client application can choose to take some recovery action."
from GeneralConcepts.pdf:
"In all cases where the bufferSize is unlimited, the Kernel is free at runtime to leverage a “robustness mechanism” which puts a limit on the maximum dimension of the buffer. This means that the Kernel can block a further growth of buffer size to protect itself. If the mode is RAW or unfiltered dispatching has been requested, the Kernel must also signal to the Client that one or more events were lost;"
I think that all bold buffers refer to the same one. Is there a way to view the growth of that buffer? What is the parameter in conf/startup file that manage the total amount of memory dedicated to that buffer?
Thanks,
Marco
Dario Crivelli
Distinct buffers are set up for each single subscription. For instance, if the same item is subscribed to twice in the same session, two buffers will be prepared.
Each subscription can either allow or disallow filtering (with some complication for COMMAND mode);
in the former case, the buffer size can be configured, while in the latter case (which includes RAW mode) the buffer size is unlimited;
however, in both cases, the <max_buffer_size> setting poses an upper limit.
Anyway, memory is actually allocated only when needed, that is, when updates cannot be sent and have to be queued.
There is no cumulative limit for the memory allocated for the buffers that can be set. Only the mentioned <max_buffer_size> setting, which applies to any individual buffer, is available.
Unfortunately, there is no indication of the current usage of the buffers.
Note that, in normal cases, the buffers should always be empty. In case a buffer fills up, updates are said to be "filtered out" or "lost", depending on whether or not the subscription allows filtering.
Information about filtered out / lost updates will be available for each subscription, through JMX, with the next release of Lightstreamer. Aggregate data will also be made available by the Internal Monitor.
