Disable StreamSense via Web Client

Soot

Hi all,

I would like to disable StreamSense to avoid the fallback to smart polling connection.

The "isPolling" flag I can set via "LS_polling=<true/false>". But how do I set the "enableStreamSense" flag in a Web client?

Thanks in advance!

Soot

Gianluca Finocchiaro

Hi Soot,

to completely disable the Stream-Sense algorithm through the Unified Web Client API, you have to "force" a fixed transport or a fixed combination of a transport and a connection type. Please have a look here for more in-depth details.

Hope this helps.

Regards,
Gianluca

Soot

Hi Gianluca,

Could you please tell me the correct GET parameter name to set "forcedTransport" in an URL call (e.g. isPolling -> LS_polling) ?

I wasn't able to find it in the documentation.

Best regards,

Erik

Gianluca Finocchiaro

Hi Soot,

I am sorry, maybe I misunderstood your original request, could you please confirm that you are not using the Unified Web Client API? Are you going to implement the Lightstreamer Server Text Mode protocol?

Soot

Hi Gianluca,

Sorry for the unclarity.

I have implemented LightStreamer using the libcurl library in a C++ application. It's using the Text Mode protocol. Everything is working almost perfect, but the streaming connections aren't really stable. The disconnection rate is around 20 percent.

When doing some digging I have found out, that sometimes the PROBE messages aren't received. As my application is using them to check the health of the connections in case no other data is received, it causes issues. Now I'm trying to understand, why the PROBE messages aren't reliable. Normally they should be sent out every 5 seconds.

I have stumbled about the documentation of the isPolling flag for the Java client. There the Smart Polling mechanism is explained. So I'm wondering, if Smart Polling is available for the Text Mode protocol also and could cause the missing PROBE messages. That's why I wanted to ensure Smart Polling is disabled, but couldn't find any hint how to do so.

I hope you can help me out.

Thanks in advance!

Best regards,
Soot

Gianluca Finocchiaro

Hi Soot,

thank you very much for your clarification.

Let me first clarify that "Stream-Sense" and "Smart Polling" are not initiated by the Server, but on the contrary these are mechanisms which should be implemented at client side, as they are not available "as-is" for the Text Protocol. As a consequence, it is up to the specific client implementation to enable such algorithms, as all client SDKs do.

That said, it is strange that PROBE messages are not pushed by the Server, so please let us know how you compose your http request, in order to verify whether something is not correct.

Please also tell us more about your environment, just to ensure that no intermediate network node may negatively affect the stream connection.

Thanks and Regards,
Gianluca

Soot

Hi Gianluca,

My application sending messages like the ones below to the server is used by hundreds of users. So there might be some situations indeed, where the PROBE messages might get lost on the way. But I would doubt, that this would be the case for the 20 percent of all streaming connections.

In case a PROBE message or the reception of payload is outstanding for more than 20 seconds, the application is initiating a complete reconnect. Is there a better way to handle those kind of situations?

---

LS_session=S2c1b6d480d5ba51eT4021693&LS_op=add&LS_table=1&LS_id=CLIENTACCOUNTMARGIN&LS_mode=MERGE&LS_schema=Cash+Currency+Margin+OpenTradeEquity+MarginIndicator+NetEquity&LS_snapshot=true&LS_data_adapter=CLIENTACCOUNTMARGIN

LS_session=S2c1b6d480d5ba51eT4021693&LS_op=add&LS_table=2&LS_id=ORDERS&LS_mode=RAW&LS_schema=OrderId+MarketId+ClientAccountId+TradingAccountId+CurrencyId+Direction+OpenPrice+Price+OriginalQuantity+Quantity+Type+Status+ReasonId&LS_data_adapter=ORDERS

LS_session=S2c1b6d480d5ba51eT4021693&LS_op=add&LS_table=3&LS_id=TRADEMARGIN&LS_mode=RAW&LS_schema=ClientAccountId+OrderId+Quantity+MarginRequirementConverted&LS_snapshot=true&LS_data_adapter=TRADEMARGIN

LS_session=S2c1b6d480d5ba51eT4021693&LS_op=add&LS_table=4&LS_id=QUOTES&LS_mode=RAW&LS_schema=QuoteId&LS_snapshot=true&LS_data_adapter=QUOTES

LS_session=S2c1b6d480d5ba51eT4021693&LS_op=add&LS_table=5&LS_id=PRICE.99508&LS_data_adapter=PRICES&LS_mode=MERGE&LS_Snapshot=true&LS_schema=Price+Bid+Offer+High+Low

---

Thanks in advance!

Best regards,

Soot

Gianluca Finocchiaro

Hi Soot,

I confirm that the strategy you have implemented is considered a best practice, but please also consider that PROBE messages are sent by the server only when no real-time updates are available.

Another possible way is the one implemented by the Java Script SDK, which waits the Keepalive Interval + the Stalled Timeout + the Reconnect Timeout, before disconnecting and trying to reconnect again to the Server (where Stalled Timeout and Reconnect Timeout are generally set to 2 and 3 seconds respectively).

Lastly, you may consider adopting a programmatic approach, through sending a fake message and waiting for the synchronous response. Obviously, you should accept such message in the implementation for the notifyUserMessageof your MetadataAdapter, in order to avoid throwing any exception. Please have a look at Paragraph 4.4.1 of our Network Protocol tutorial for more details.

To further investigate the reasons why the server PROBE messages seem so irregular, you should be able to prepare a test on your environment, after having changed the server log configuration as follows:

<logger name="LightstreamerLogger.subscriptions" level="DEBUG">
<logger name="LightstreamerLogger.requests" level="DEBUG"/>
<logger name="LightstreamerLogger.push" level="DEBUG"/>

After that, please upload the log files.

Thanks and Regards,
Gianluca