Websocket connection is disconnecting using lseg.data library

Thank you for reaching out to us.

I have done a quick test and found that the library could reconnect and re-subscribe to items properly.

I found that the stream ID reaches 11940.

2025-08-11 01:54:05,523 - DEBUG - sessions.platform.default.0 - [OMMSTREAMING_PRICING_0.0] send {"ID": 11940, "Domain": "MarketPrice", "Streaming": true, "Key": {"Name": "LCOX5-J6"}}

Does the application subscribe to a lot of items?

You may contact the server team via LSEG Support to verify if the server cut the connection. Please include the URL of this discussion in your raised question to prevent it from being redirected back to this Q&A forum.

The library may not perform well when subscribing to a large number of streaming items. Please refer to the Choosing a Real-time Streaming API article for more information.

Hi @Jirapongse thank you for looking into this.

My application subscribes to up to ~2000 instruments - would you say that this is too many for the lseg.data library to handle?

I will reach out to LSEG support to see if they have any more insights.

It depends on the total of update rates of those instruments.

Did you see the following log in the log file?

[2025-08-13T14:11:10.681148+07:00] - [sessions.platform.deployed.0] - [DEBUG] - [35184 - Msg-Proc-ThreadOMMSTREAMING_PRICING_0.0] - [stream_connection] - [_get_messages] - [OMMSTREAMING_PRICING_0.0] received messages: 8 | processed messages: 8

You may consider disabling the debug log, as it can negatively affect the application's performance.

Yes, I have checked that received messages = processed messages. Just before the last disconnection I have in my logs:

received messages: 21256975 | processed messages: 21256975

I only enabled the debug logs because of this disconnection issue. Previously I had them disabled, but kept getting disconnected, which is why I turned them on.

I also contacted the support team and they say that it was a client-side disconnection. The logs from their side are pasted below.

Since I am using the lseg.data library, I am not handling any ping / reconnects myself. Is there anything else I can do to further diagnose this?

<ads-fanout-sm-az1-apse1-prd.1.ads:Info:Thu Aug 14 13:31:35.041971 2025> WS JSON2 disconnect from "GE-******" at position "10.1.210.54/lseg-realtime-acquisition-staging-7959d67c6d-h4w9z" on host "" and port number "19418" using application "256" on channel 73 (Client-side initiated disconnection). Reason:rsslRead() failed with code -1 and system error 0. Text:WS Code 1000 Normal Closure <END> <ads-fanout-sm-az2-apne1-prd.1.ads:Info:Wed Aug 13 18:12:08.269419 2025> WS JSON2 disconnect from "GE-******" at position "10.1.210.54/lseg-realtime-acquisition-staging-7959d67c6d-h4w9z" on host "" and port number "58125" using application "256" on channel 73 (Client-side initiated disconnection). Reason:rsslRead() failed with code -1 and system error 11. Text:<rwsReadTransportMsg:4444> Error:1002ipcRead() failure. System errno: (11)<END>

<ads-fanout-sm-az2-euw1-prd.1.ads:Info:Wed Aug 13 07:46:06.497160 2025> WS JSON2 disconnect from "GE-******" at position "10.1.210.45/lseg-volume-stream-5778f9bb47-v6m48" on host "" and port number "57606" using application "256" on channel 185 (Server-side initiated disconnection). Reason:Client application did not ping. <END>

There are both Client-side initiated disconnection and Server-side initiated disconnection.

Do you have the full debug log files when the problem occurred?

If yes, please share those files. We can check the ping/pong messages from the debug log files.

[2025-08-15T17:14:21.675195+07:00] - [sessions.platform.ldpv2.0] - [DEBUG] - [35244 - Msg-Proc-ThreadOMMSTREAMING_PRICING_0.0] - [omm_stream_connection] - [_process_message] - [OMMSTREAMING_PRICING_0.0] process message {"Type": "Ping"}
[2025-08-15T17:14:21.675195+07:00] - [sessions.platform.ldpv2.0] - [DEBUG] - [35244 - Msg-Proc-ThreadOMMSTREAMING_PRICING_0.0] - [stream_connection] - [send_message] - [OMMSTREAMING_PRICING_0.0] send {"Type": "Pong"}

I have looked into my debug logs and found the 3 corresponding disconnection events to match up with what was reported by your support team on the server side.

I see that there indeed seems to be different disconnect reasons.

I've attached the logs on my side for the first 2 instances. In order to send it here, I have had to apply a filter. Even within a single 20 second ping/pong window, I have >100MB of logs. The filter I applied removes any line that contains either "ELEKTRON_DD" or "received_messages". Please let me know if there's a better way for me to create a filter such that we don't lose any relevant information.

The file names are timestamped to the disconnection event. I have just realized the third event (at Wed Aug 13 07:46:06.497160) was from a test application, so we do not need to look into that one.

Logs-2025-08-13-18_12_08.txt

Logs-2025-08-14-13_31_35.txt

Appreciate your time looking into this and any insights you can provide.

The server sends a ping message every 20 seconds. If it doesn't receive a response (a pong message) from the client within 30 seconds, it will terminate the connection.

I reviewed the log file and found that the ping and pong messages appear to be functioning correctly.

If you're connecting to the server through a proxy or firewall, please check with your IT support team to determine whether the disconnections are originating from those systems.

I’ve reached out to the product team to verify the log files.

Thanks for looking into this. I will investigate potential network issues on my side in the meantime.

I have another question related to this. When the reconnection occurs, the stream object that I initially defined when opening the connection appears to get dropped and another stream object is replacing it in the background.

E.g. if I start the stream using:

definition = ld.content.pricing.Definition(universe=mkt_list)
stream = definition.get_stream()
stream.open()

Then, after a disconnection event, my stream variable no longer points to the new stream that lseg.data has created on the reconnect. Is there any way to reattach to that stream?

How did you retrieve the data from the stream?

Please share the snippet code.

I tested the disconnection behavior and found that the library is able to reconnect to the server successfully.
After reconnection, any previously opened streams continue to receive data from the server.

You can check the state of a stream using the following code:

stream.open_state

To check the state of an individual item within the stream, use the following code:

stream["JPY="].code