Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: PFCCWA on June 19, 2014, 11:29:34 AM
-
Hello,
Apparently there is a default addp timeout between scs and lca - 9 seconds.
Does this still apply if addp trace is not set?
We have host disconnection alarm generated when loss is less than 1 second but as you can in scs logs, the addp setting is set to 9000 msec so wondering why alarm is still generated.
12:12:00.958 Connecting to LCAServer [4999:<host>]
addp-trace no
(addp_xconfig) local 9000 msec, remote OFF, trace off
thanks.
-
Remote or local timeout? Which site has failed? Addp-trace just affects writting to the log files. It is necessary to check if your connection between components use the addp protocol
-
Connection to host lost alarm, lasted less than 1 second then connected again.
I understand the local timeout is loss of connection between scs and lca (where connection is lost to), but wondering why it not take into account 9 seconds before generating alarm.
-
What was the detect event number for the alarm? ADDP is used when communication stops between two applications and polling starts to make sure both can still talk to each other. However if there was an actual disconnect message sent from LCA to SCS indicating that the connection was closing, I believe LCA would send the detect event and an generate an alarm as soon as that happened without considering addp settings.
-
Agreed with mduran22, it looks like actual disconnects message.
ADDP, simple make sure both application can talk or not, and as per configured timeout it pings the application, so the connection never sits ideal or braked out.
-
There is Genesys solution suggesting the addp settings can be applied to host - https://c.na12.visual.force.com/apex/pkb_Home?id=kA0U00000004Tae&q=host+addp&l=en_US&fs=Search&pn=1.
In my case, host LCA has 'lost' connection to SCS, therefore generating alarm.
My question was why didn't the default scs-lca timeout of 9 seconds apply here, when the connection loss is less than a second. Unless that default timeout is application specific.
-
The ADDP timeouts are specific between applications. However the timeout (which would have actually be 18 seconds before ADDP closed the connection) didn't apply because there was an actual disconnect event that was received by SCS in that second. You can probably see the detect event number in the logs for SCS.
-
Ok, so are you suggesting there isn't a way to stop the host disconnect alarms?
These are generated even though the connection loss (between SCS and LCA) is less than 1 second.
-
Well to stop them is to fix the reason why they lose connection so continuously.
-
You really want to know why the disconnects are occurring. There are ways to remove or suppress the alarms, but I would highly recommend against it. You could also put a clear event when the connection is established again. Look at why the host is sending the disconnect event. Keep in mind, this isn't just a lull in communication for a second, there is an actual event that is being sent that is triggering the alarm.