Below are troubleshooting steps — symptoms, diagnostic steps, and workarounds or resolutions — for using Signalware with Rhino’s CGIN Resource Adaptor.
Rhino’s CGIN resource adaptor for the SS7 protocol family requires a native backend process, known as a Signalware backend, to communicate with the Signalware SS7 stack. The Signalware backend process must run on the Signalware host systems, and the resource adaptor communicates with it via TCP. Generally, the cause is configuration related or a version mismatch between the resource adaptor and backend.
If, when activating the resource adaptor (or starting the Rhino SLEE with the resource adaptor active) the following message immediately appears in the Rhino logs and an alarm is raised stating that a backend connection has been lost, then this indicates that the backend process is not reachable by the resource adaptor. Generally this would mean it is either not running or, due to resource adaptor or network misconfiguration, the resource adaptor is unable to establish a TCP connection to it.
2013-07-18 14:54:24.907 Major [rhino.facility.alarm.manager] <New I/O worker #47> Alarm 101:140617544395779 [RAEntityNotification[entity=insis-ptc-external],noconnection,localhost:10102] was raised at 2013-07-18 14:54:24.907 to level Major Lost connection to backend localhost:10102 2013-07-18 14:54:24.907 INFO [rhino.facility.alarm.csv] <New I/O worker #47> 2013-07-18 14:54:24.907,raised,2013-07-18 14:54:24.907,101:140617544395779,RAEntityNotification[entity=insis-ptc-external],noconnection,localhost:10102,Major,Lost connection to backend localhost:10102,
If the resource adaptor successfully established a connection to the backend but later one or both of the following messages appears in the logs this indicates that the connection to the backend process was setup successfully but lost due to backend or network failure.
2011-03-29 10:20:30.942 Warning [trace.cginra.backend.[sedition:24146]] <RAContextTimer-cginra> sedition:24146#4: connection heartbeat lost. Last sent: 1301347220, last received: 1301347210
2016-11-17 16:20:26.070 Major [rhino.facility.alarm.manager] <cginra-thread-1> Alarm 101:194478654849023 [RAEntityNotification[entity=cginra],noconnection,autotests-signalware:10101] was raised at 2016-11-17 16:20:26.069 to level Major Lost connection to backend autotests-signalware:10101 2016-11-17 16:20:26.071 Warning [trace.cginra.backend.[autotests-signalware:10101]] <cginra-thread-1> Connection autotests-signalware:10101#1 lost: Remote host closed connection
First determine whether the backend process is running. If the backend process is not running then either it or Signalware may be incorrectly configured.
If the backend process is running check that the host and port it is listening on is correctly configured in the resource adaptor entity configuration properties. Also verify that the host running the backend is reachable from the Rhino host and that the port is not blocked by a firewall on either host.
If a connection is established but gets dropped this indicates either a software failure in the backend or a network level failure. Check that the backend process is running and if not, restart it. Any error messages from a failed backend should be sent to your solution provider to determine the cause of failure. If the backend process is still running check for any network connectivity problems between the Rhino host and the host running the backend processes.
If one of Rhino’s Signalware Resource Adaptors has more than the configured maximum number of active dialogs with a single backend process it will fail to allocate new dialogs.
If the backend process has reached its maximum number of active dialogs an warning similar to the following will be logged by the Resource Adaptor:
2016-11-17 14:49:42.410 Warning [trace.cginra.backend.[signalware:10100]] <cginra-thread-2> Unable to allocate a dialog handle: Out of dialog ids
Additionally an error similar to the following will be visible in the output of the backend process:
2016-11-17 11:45:28.823003 rhino_252_1: Failed to allocate a new dialog ID. errno=7
By default each backend process supports up to 32,000 simultaneous dialogs. If the number of simultaneous dialogs exceeds this limit the above errors will occur. There are two approaches to working around this issue:
Increase the number of dialogs per backend process using the
-maxdialogs Nparameter (where N is the number of dialogs. Up to 32,000 concurrent dialogs are supported).
If the backend process is already configured for the maximum 32,000 dialogs add additional backend processes, then, to support more active calls, spread the load across additional processes. See the https://developer.opencloud.com/devportal/display/CGIN1v5/Using+the+Ulticom+Signalware+TCAP+Stack for details.
If the backend process has reached its maximum number of active dialogs the Signalware backend process will log something similar to the following:
2016-11-17 13:12:39.035658 rhino_252_1: cTCAPTakeMsg() failed: (ctcap_errno=12), Out of Dialog entries
The root cause and solution for this is identical to that for CGIN RA Cannot Create Outgoing Dialogs. Please see that section for details.
Please refer to the Signalware Installation Manual for more information about installing and configuring Signalware.
If you do not find a solution for your problem, contact your solution provider and provide the system report created by the