Error in Lightstreamer Android Client: network.error with tryRecovery=true

Vahid Garousi

Hello,

We are utilizing Lightstreamer in our Android project and have encountered the following error in the logs:
lightstreamer.netty websocket disconnected [e98a838b] lightstreamer.session android.trader E Error event while RECEIVING reason: network.error tryRecovery=true timeLeft=15000 isRecoveryDisabled=false closedOnServer=false unableToOpen=true wsError=false serverBusyError=false

This error indicates a network issue during data reception, with the client attempting to recover the connection. We have verified that the internet connection is stable and the Lightstreamer server is accessible.

Has anyone experienced a similar issue? What steps can we take to resolve this problem?

lightStreamerAndroidClient="4.2.8"
lightStreamerJavaAdapter="1.0.2"

Thank you, Vahid Garousi

Alessandro.Carioni

In the event of network outages, the Lightstreamer Client is designed to automatically reconnect and attempt to preserve the current session. Therefore, if the network issue was brief, it's understandable that you might not have noticed anything except for the log entry.

On the contrary, did you experience a long disconnection of the client from the network?
If so, could you please share the entire log?

Vahid Garousi

Alessandro.Carioni

This issue occurs intermittently; the client generally works, but it’s concerning that the disconnection and reconnection cycle happens frequently. Is this repetitive behavior expected?

One of our subscriptions fails to subscribe entirely, while the others connect successfully. We suspect this issue might be related, especially since it doesn’t occur in the plain HTML test page provided by our backend team, nor on our PWA platform. Could this repeated disconnection be affecting the subscription stability?

Alessandro.Carioni

Sometimes, the internet connection on mobile devices can be unstable, which may explain the frequent reconnections under certain circumstances.

However, I would rule out reconnections as the cause of the subscription failures, since the client is designed to reissue a subscription if a connection problem prevents its completion.
But what error is reported by the SubscriptionListener.onSubscriptionError method?

Vahid Garousi

Alessandro.Carioni

There’s no specific error mentioned in the SubscriptionListener.onSubscriptionError method—only the issues I’ve already shared are logged. I honestly have no clue what’s causing this, and it feels like searching for a needle in a haystack.

Alessandro.Carioni

From what I can tell, the client is performing well. When the connection drops, it quickly recovers.
Therefore, I wouldn't be concerned about the occasional reconnections.

Vahid Garousi

WebSocket write failed [adb4e173]: control LS_reqId=67&LS_op=add&LS_subId=24&LS_mode=MERGE&LS_group=GeneralNotification&LS_schema=notificationType title message description&LS_data_adapter=NotificationCenter&LS_snapshot=false& io.netty.channel.StacklessClosedChannelException at io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object, ChannelPromise)(Unknown Source)

Websocket write failed [10482c64]: control (Ask Gemini) LS_reqId=109&LS_op=add&LS_subId=59&LS_mode=COMMAND&LS_group=NMD1_B&LS_schema=key command isin price quantity side count&LS_data_adapter=MarketDepth&LS_snapshot=false& javax.net.ssl.SSLException: SSLEngine closed already at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:854) at io.netty.handler.ssl.SslHandler.wrapAndFlush(SslHandler.java:811) at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:792) at io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750) at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:742) at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:728) at io.netty.channel.ChannelOutboundHandlerAdapter.flush(ChannelOutboundHandlerAdapter.java:125) at io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750) at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:765) at io.netty.channel.AbstractChannelHandlerContext$WriteTask.run(AbstractChannelHandlerContext.java:1071) at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at java.lang.Thread.run(Thread.java:1012)

Has anyone encountered similar WebSocket write failures or network errors with frequent reconnection attempts? Any advice would be appreciated.

Alessandro.Carioni

As previously mentioned, the error you're encountering is likely due to an unstable network connection. The client cannot prevent this issue. However, the client can mitigate it by transparently recovering the session (as it does) when the connection drops.

Vahid Garousi

This resolved the issue and made it work as expected:

return arrayOf(
    COMMAND,
    KEY,
    ISIN,
    PRICE,
    QUANTITY,
    SIDE,
    COUNT
)

Previously, using the following order didn't work and caused frequent disconnections:

return arrayOf(
    KEY,
    COMMAND,
    ISIN,
    PRICE,
    QUANTITY,
    SIDE,
    COUNT
)

It seems the "COMMAND" field absolutely needs to be at the first index for proper functionality.

Alessandro.Carioni

The order of the fields in a command-mode subscription is irrelevant. The only requirement is that there are two fields named key and command.
Additionally, an issue with a subscription does not affect the session. At worst, the subscription fails but the session remains active.