You're experiencing some errors on Cloud SMSC for an application that was recently migrated from the old to the new NewNet PPG platform.
After some investigation, you may find the following events:
- Channels X, Y, and Z were closed due to network exception: Connection reset by peer
ioExceptionOccured: java.io.IOException: Connection reset by peer
- Mercury opens some connections
Registered the Channel: java.nio.channels.SocketChannel[connection-pending local=/<IP>:<PORT> remote=/<IP>:<PORT>]; KEY = channel=java.nio
- Mercury sends bind_transceiver requests:
announce channel event for key: channel=java.nio.channels.SocketChannel[connection-pending local=/<IP>:<PORT> remote=/<IP>:<PORT>], selector=sun.nio.ch.EPollSelectorImpl@72f77463, interestOps=9, readyOps=8; ready ops: 8
- SMSC returns error responses for all requests (error code 0xd)
On the Lithium SMSC side, you may find some errors in the Traffic Elements, such as:
Mar 16 03:38:57 RMD-SMSC_RTR-01 tp_hub: App '[appName]' - Outside session login failed - user: '[user]' - error: 'Too many sessions for this login'
Mar 16 03:38:58 RMD-SMSC_RTR-01 tp_hub: App: '[appName]' - 'bind_transceiver' on outside session caused 'tooManyUsersOfSameId'. Sent SMPP error 0x000d: Too many sessions for this login
Mar 16 03:38:58 RMD-SMSC_RTR-01 tp_hub: App: '[appName]' - Outside session was disconnected - reason:Connection closed
Mar 18 08:25:30 RMD-SMSC_RTR-02 tp_hub: App: '[appName]' - 'submit_sm' on outside session caused 'rtrBlockedByThroughputControl' (0x04000000). Sent SMPP error 0x0058: Throughput exceeded [3 times]
Mar 18 16:30:38 RMD-SMSC_RTR-02 textpass: AO throughput limit of application '[appName]' (ID 234) hit
The described situation happens mainly because of two problems:
If the information in this article is not enough to help you solve the issue, please create a support ticket and provide details about the SMPP connection to the Cloud SMSC, the system_id, short-number, or other details that can be used to identify the application on the Lithium SMSC side.
Not Available Connections on Lithium
When a connection is opened on Mercury, it creates a connection on Lithium as well. If for any reason the connection is closed on the Mercury's side, it remains open on the Lithium's side. It will only be closed by Lithium after one minute if there is no heartbeat request to keep it open.
The problem occurs because, when a connection is broken, Mercury tries to reopen it immediately. Since Lithium is still waiting for a heartbeat before closing the connection, the connection is still open. Therefore, the new Mercury's connection can be refused by Lithium if it exceeds the maximum number of connections.
This problem can be solved by configuring Mercury to open half or less the maximum number of connections allowed in Lithium (e.g., if Lithium allows 10 connections, Mercury should create 5 connections or less). As a consequence, if there is a network error, Mercury will immediately create a new connection and there will be available connections in Lithium, preventing the error from happening.
Not Available Throughput on Lithium
Lithium has a limit of 15 messages/second. Each connection sends about 3 messages/second. If the MMS ID and the content link are too long, Mercury needs to split one message in two. Therefore, if two PAP messages are received in one second and they will be sent in one connection, Mercury will send 4 messages/second. If there are, for example, 4 connections, the Lithium throughput will be exceeded.
The problem can be solved by reducing the number of connections to SMSC if the traffic allows it. For example, if your traffic is around 1-2 messages/minute, two connections are enough.