" /> Tserver Closes URS connection complains about it being too slow. How and where? - Genesys CTI User Forum
« previous next »
Pages: [1]   Go Down

Author Topic: Tserver Closes URS connection complains about it being too slow. How and where?  (Read 5846 times)

Offline ademince

  • Newbie
  • *
  • Posts: 16
  • Karma: 0
Tserver Closes URS connection complains about it being too slow. How and where?
« on: August 06, 2010, 01:18:55 AM »
Advertisement
Dear All,

Our Tserver is closing the client URS connection, complaining about it being too slow? what is too slow? where do we tell the system to wait a bit longer.
I would greatly appreciate if anyone can help.
ps. I couldn't attach the log file some how however here is the part with error.

AttributeTimeinSecs 1281051273 (09:34:33)
AttributeExtensions [137] 00 04 02 00..


'GCTI_GLOB_CID' bin: A1 4A 5B 4C.. (len=8)
'GCTI_SUPERVISED_TRANSFER' 0


'GCTI_NAT_INDICATIONTYPE' 'Public:National'
'GCTI_NAT_INDICATION' '362712212'


AttributeNetworkCallID a14a5b4c0c510200
AttributeCustomerID 'Resources'
AttributeANI '362712212'


AttributeDNIS '4584'
AttributeCallUUID 'P1VNV5VMOT6EJ1F0H55DQ08TL8002161'
AttributeConnID

008201d51aa6fdf8
AttributeCallID 20748
AttributeCallType 2
AttributeCallState 23


AttributeThisQueue '4584'
AttributeThisTrunk 262404
AttributeThisDNRole 2
AttributeThisDN

'4584'
AttributeOtherTrunk 262404
AttributeOtherDNRole 1
AttributeOtherDN '362712212'
@09:34:33.3190 [ISCC] Translate: '362712212' -> ''; result 1 ()
@09:34:33.3190 [ISCC] Party object is removed:

p:0000000000000000,00000000 n::
09:34:33.319 Int 04544 Interaction message "EventRouteUsed" generated
09:34:33.319

Trc 04542 EventRouteUsed sent to [1280] (0000327c URS 172.21.135.40:2426)
09:34:33.319 Trc 04542 EventRouteUsed sent

to [736] (0000001b StatServer_URS 172.21.135.40:3968)
09:34:33.319 Trc 04542 EventRouteUsed sent to [628] (00000011

StatServer_Hist 172.21.135.41:4263)
09:34:33.319 Trc 04542 EventRouteUsed sent to [640] (00000012

StatServer_Realtime 172.21.135.40:3972)
09:34:33.319 Trc 04542 EventRouteUsed sent to [604] (0000000f WFM_StatServer

172.21.135.42:4304)
09:34:33.319 Trc 04542 EventRouteUsed sent to [544] (0000000a URS_HA 172.20.105.54:3425)
09:34:33.319 Trc 04542 EventRouteUsed sent to [568] (0000000c StatServer_Realtime_HA 172.20.105.54:3427)
09:34:33.319 Trc 04542 EventRouteUsed sent to [556] (0000000b StatServer_URS_HA 172.20.105.54:3426)
09:34:33.319 Trc

04542 EventRouteUsed sent to [496] (00000007 StatServer_Hist_HA 172.20.105.52:1424)
09:34:33.319 Trc 04542

EventRouteUsed sent to [532] (00000009 WFM_StatServer_Bak 172.20.105.53:2787)
09:34:33.319 Trc 04542 EventRouteUsed

sent to [520] (00000008 StatServer_CCP_Melbourne 172.20.105.55:1700)
09:34:33.334 Trc 04542 EventRouteUsed sent to

[1376] (00003182 HGFeeder++ 172.16.16.99:2413)
  PartyRQueue::<510c:510c:4584@017E9788>: Additional message is

sent
@09:34:33.3340 [0] 7.6.003.05 distribute_event: message EventDiverted
AttributeEventSequenceNumber

000000000003f67b
AttributeTimeinuSecs 334000
AttributeTimeinSecs 1281051273 (09:34:33)


AttributeOtherDN '362712212'
AttributeOtherDNRole 1
AttributeOtherTrunk 262404


AttributeThisDN '4584'
AttributeThisDNRole 2
AttributeThisTrunk 262404
AttributeThisQueue

'4584'
AttributeCallState 23
AttributeCallType 2
AttributeCallID 20748
AttributeConnID

008201d51aa6fdf8
AttributeCallUUID 'P1VNV5VMOT6EJ1F0H55DQ08TL8002161'
AttributeDNIS '4584'


AttributeANI '362712212'
AttributeCustomerID 'Resources'
AttributeNetworkCallID a14a5b4c0c510200


AttributeExtensions [137] 00 04 02 00..
'GCTI_GLOB_CID' bin: A1 4A 5B 4C.. (len=8)


'GCTI_SUPERVISED_TRANSFER' 0
'GCTI_NAT_INDICATIONTYPE' 'Public:National'


'GCTI_NAT_INDICATION' '362712212'
@09:34:33.3340 [ISCC] Translate: '362712212' -> ''; result 1 ()
@09:34:33.3340

[ISCC] Party object is removed: p:0000000000000000,00000000 n::
09:34:33.334 Int 04544 Interaction message

"EventDiverted" generated
09:34:33.334 Trc 04542 EventDiverted sent to [1280] (0000327c URS 172.21.135.40:2426)
09:34:33.334 Trc 04542 EventDiverted sent to [736] (0000001b StatServer_URS 172.21.135.40:3968)
09:34:33.334 Trc

04542 EventDiverted sent to [628] (00000011 StatServer_Hist 172.21.135.41:4263)
09:34:33.334 Trc 04542 EventDiverted

sent to [640] (00000012 StatServer_Realtime 172.21.135.40:3972)
09:34:33.334 Trc 04542 EventDiverted sent to [604]

(0000000f WFM_StatServer 172.21.135.42:4304)
09:34:33.334 Trc 04542 EventDiverted sent to [544] (0000000a URS_HA

172.20.105.54:3425)
09:34:33.334 Trc 04542 EventDiverted sent to [568] (0000000c StatServer_Realtime_HA

172.20.105.54:3427)
09:34:33.334 Trc 04542 EventDiverted sent to [556] (0000000b StatServer_URS_HA

172.20.105.54:3426)
09:34:33.334 Trc 04542 EventDiverted sent to [496] (00000007 StatServer_Hist_HA

172.20.105.52:1424)
09:34:33.334 Trc 04542 EventDiverted sent to [532] (00000009 WFM_StatServer_Bak

172.20.105.53:2787)
09:34:33.334 Trc 04542 EventDiverted sent to [520] (00000008 StatServer_CCP_Melbourne

172.20.105.55:1700)
09:34:33.334 Trc 04542 EventDiverted sent to [1376] (00003182 HGFeeder++ 172.16.16.99:2413)
 

treatmentsClean: removing pending for (510c:510c:4584@017E9788)(0)
  treatmentsClean: removing pending for

(510c:510c:4584@017E9788)(1)
  PartyRQueue: <510c:510c:4584@017E9788> removed, state = (0-4)
@09:34:33.3340 [BSYNC]

Trace: Send to backup (TServer_Melbourne_HA) [1388]:
message EventUserEvent
AttributeServerRole 0


AttributeUserEvent EventRouteUsed
AttributeThisDN '4584'
AttributeCallID 20748
AttributeConnID

008201d51aa6fdf8
AttributeReserved_2 1793
AttributeCause 26
attr_#1005 a14a5b4c0c510200
@09:34:33.3340 [BSYNC] Trace: Sent
  CallList::Delete: call (2:510c:1@01BAA008) to be deleted
@09:34:33.3340 [BSYNC]

Trace: Send to backup (TServer_Melbourne_HA) [1388]:
message EventUserEvent
AttributeServerRole 0


AttributeUserEvent [1011]
AttributeCallID 20748
attr_#1005 a14a5b4c0c510200
attr_#1007 0
@09:34:33.3340 [BSYNC] Trace: Sent
  Party::Release: for <510c:510c:362712212@01CA2778/dialling/Forwarded> with

cause (Failed[57])
@09:34:33.3340 [ISCC] Party removed [ssp view]:
@ c:008201d51aa6fdf8,01baa008 @

m:0000000000000000,00000000,0000000000000000 p:1 i:0000510c nw:00000000:a14a5b4c0c510200 t:2
- p:01ca2778 @

c:008201d51aa6fdf8,01baa008 r:1 t:1 s:0 n:362712212
@09:34:33.3340 [ISCC] Party removed:
@

c:008201d51aa6fdf8,01baa008 @ m:0000000000000000,00000000 p:1 i:0000510c nw:a14a5b4c0c510200 t:2
-

p:0000000000000000,01ca2778 @ c:008201d51aa6fdf8,01baa008 r:1 ------ n:362712212:
@09:34:33.3340 [ISCC] Party object

is removed: p:0000000000000000,00000000 n:362712212:
  Party::commit::deleted[1]: for

<510c:510c:362712212@01CA2778/released> with cause/rel (0:0)
  Party: <510c:510c:362712212@01CA2778> removed, state

= (0-4)
08/06/10@09:34:33.334 --- Rq::RouteEndRequest ---
link (link-tcp) S->H: (0[4 / 1] requests pending)
09:34:33.334 Std 04523 Connection to client URS closed (reason: too slow) on [1280], id=0000327c
@09:34:33.3500

[ISCC] QUERY_MONITOR <URS:0000327c@> destroyed
@09:34:33.3500 [ISCC] Location URS:0000327c@/0 is removed
@09:34:33.3500 [ISCC] Location object URS:0000327c@/0/0 is removed
-AP[139]->-1244 @09:34:33.3500
-Ap[139]-<-1244

@09:34:33.3500
@09:34:33.522 DataFromSwitch 196 bytes
0000-000f: a1 81 c1 02 02 04 15 02-01 15 30 81 b7 55 04 02

|..........0..U..|
0010-001f: 1a f7 00 a0 48 a3 46 30-44 6b 0a 82 02 51 0c 83 |....H.F0Dk...Q..|
0020-002f: 04 0f 85

01 00 63 07 84-05 34 34 32 32 30 61 0b |.....c...44220a.|
0030-003f: 82 09 33 36 32 37 31 32-32 31 32 62 06 84 04 34

|..362712212b...4|
0040-004f: 35 38 34 64 06 84 04 34-35 38 34 6b 0a 82 02 51 |584d...4584k...Q|
0050-005f: 0c 83 04

01 04 01 04 4e-01 02 0a 01 16 7e 65 a0 |.......N.....~e.|
0060-006f: 0f 17 0d 31 30 30 38 30-36 30 39 33 35 32 37 5a

|...100806093527Z|
0070-007f: a1 52 30 0b 06 06 2b 0c-89 36 83 78 02 01 0f 30 |.R0...+..6.x...0|
0080-008f: 18 06 06

2b 0c 89 36 84-00 30 0e 80 0a 30 33 36 |...+..6..0...036|
0090-009f: 32 37 31 32 32 31 32 81-00 30 12 06 06 2b 0c 89

|2712212..0...+..|
00a0-00af: 36 84 09 04 08 a1 4a 5b-4c 0c 51 02 00 30 15 06 |6.....J[L.Q..0..|
00b0-00bf: 06 2b 0c

89 36 84 0b a3-0b 82 09 33 36 32 37 31 |.+..6......36271|
00c0-00c3: 32 32 31 32            -                       

|2212            |
08/06/10@09:34:33.522 RECEIVED: 196 bytes
aPDU-rose invoke { -- SEQUENCE --
  invokeID 1045,
 

operationValue 21,
  argument { -- SEQUENCE --
    crossRefIdentifier '021af700'H  -- "..÷." --,
   

eventSpecificInfo callEvent deliveredEvent { -- SEQUENCE --
      connection { -- SEQUENCE --
        call '510c'H 

-- "Q " --,
        device dynamicID '0f850100'H  -- ".….." --
      },
      alertingDevice deviceIdentifier

implicitPrivate '3434323230'H  -- "44220" --,
      callingDevice deviceIdentifier implicitPublic

'333632373132323132'H  -- "362712212" --,
      calledDevice deviceIdentifier implicitPrivate '34353834'H  -- "4584"

--,
      lastRedirectionDevice deviceIdentifier implicitPrivate '34353834'H  -- "4584" --,
     

originatingConnection { -- SEQUENCE --
        call '510c'H  -- "Q " --,
        device dynamicID '01040104'H  --

"...." --
      },
      localConnectionInfo 2,
      cause 22
    },
    extensions { -- SEQUENCE --
      security

{ -- SEQUENCE --
        timeStamp '3130303830363039333532375a'H  -- "100806093527Z" --
      },
      privateData {

-- SEQUENCE/SET OF --
        privateData { -- SEQUENCE --
          manufacturer {1 3 12 1206 504},
          15
 

    },
        privateData { -- SEQUENCE --
          manufacturer {1 3 12 1206 512},
          { -- SEQUENCE --
 

        callingPartyName '30333632373132323132'H  -- "0362712212" --,
            alertingPartyName ''H  -- "" --
 

        }
        },
        privateData { -- SEQUENCE --
          manufacturer {1 3 12 1206 521},
Logged

Offline Fra

  • Hero Member
  • *****
  • Posts: 856
  • Karma: -3
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #1 on: August 06, 2010, 09:43:36 AM »
Client too slow generally means that the client is not responding to server requests on time, due usually to network latency. Check the network connection - delay, jitter, blips - and add ADDP if you haven't yet.

Fra
Logged

Offline ademince

  • Newbie
  • *
  • Posts: 16
  • Karma: 0
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #2 on: August 06, 2010, 02:15:06 PM »
Hi Fra,

Our network is very stable as we have other more sensetive apps between the sites with faults and network guys are unable find any fault on their side. We added ADDP with timeouts from 20 seconds to even 300 seconds but still same issue. When TServer closes the URS connection it drops all the waiting calls to default.

Also what does below error mean? as each time it happens, below error comes on TServer Log:

[ISCC] QUERY_MONITOR <URS:0000327c@> destroyed
@09:34:33.3500 [ISCC] Location URS:0000327c@/0 is removed
@09:34:33.3500 [ISCC] Location object URS:0000327c@/0/0 is removed
Logged

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #3 on: August 07, 2010, 02:55:49 PM »
300? That is useless...try 10 in local and 5 in remote
Logged

Offline Fra

  • Hero Member
  • *****
  • Posts: 856
  • Karma: -3
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #4 on: August 09, 2010, 10:51:00 AM »
[quote author=ademince link=topic=5771.msg25151#msg25151 date=1281104106]
Hi Fra,

Our network is very stable as we have other more sensetive apps between the sites with faults and network guys are unable find any fault on their side. We added ADDP with timeouts from 20 seconds to even 300 seconds but still same issue. When TServer closes the URS connection it drops all the waiting calls to default.

Also what does below error mean? as each time it happens, below error comes on TServer Log:

[ISCC] QUERY_MONITOR <URS:0000327c@> destroyed
@09:34:33.3500 [ISCC] Location URS:0000327c@/0 is removed
@09:34:33.3500 [ISCC] Location object URS:0000327c@/0/0 is removed

[/quote]

Have you got any firewalls in between?
When TServer closes the connection it default routes all calls, obviously, as it's aware it can't get the destination from URS.

The snippet posted is just telling that Tserver is removing the URS from its connections. However, it is not clear to me why it links URS to ISCC...

Fra
Logged

Offline ademince

  • Newbie
  • *
  • Posts: 16
  • Karma: 0
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #5 on: August 09, 2010, 11:53:31 PM »
Cavagnaro,

I have changed setting as per your suggestion however the drop outs are more frequent therefore I have changed back to not using the ADDP at all. The drop outs are less frequent this way.

Fra,

No, there is no firewall between the sites. The URS is located in site A, no issues reported at site A, however the dropouts happen on site B and C. If I promote site B URS to be primary then I have issues at site A and site C and no issues reported on site B. I know that this sounds like a network issue however the network techos as well as the carrier gone thru so much checks but could not find any fault. We even increased our bandwith to be the double the size yet the same drop outs happening. The CPU usage of the servers involved are around 1%, all ping tests are succesfull without any drop of packets etc. We even disabled the virus scan on all servers yet no help...very frustrating.....help...!!!!
Logged

Offline cavagnaro

  • Administrator
  • Hero Member
  • *****
  • Posts: 7641
  • Karma: 56330
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #6 on: August 10, 2010, 01:42:13 AM »
[quote author=ademince link=topic=5771.msg25162#msg25162 date=1281398011]
Cavagnaro,

I have changed setting as per your suggestion however the drop outs are more frequent therefore I have changed back to not using the ADDP at all. The drop outs are less frequent this way.

[/quote]

Well if that is the case it is a clear indicator that something wrong is going on yourt network. You say that a ping was successful, but a ping of how many bytes? 32? That is nothing. Try to do a continous ping with 1024 bytes (-l 1024) and see how this behaves. You can have 3Gb of bandwidth but without QoS is almost the same as there must be a point on your network that will not handle such speed...
Logged

Offline ecki

  • Sr. Member
  • ****
  • Posts: 329
  • Karma: 8
Re: Tserver Closes URS connection complains about it being too slow. How and where?
« Reply #7 on: August 10, 2010, 02:21:12 AM »
Ademince,

Well, the network guys always tend to blame others before they admit that the problem really could be in network. So you have to come with real proof in order to make them really do something with it. Therefore I would not put a big relevance what they are actually saying.
Check your SCS logs whether there are no intermittent and short lasting host disconnections reported.
Secondly what you can check is to try transfer big files (50MB) between affected hosts and check transfer speed.
And the last step is to install Wire-shark on both host and monitor the network traffic.

Additionally you can try to run URS on the same host as TServer in order to prove functionality without having network in the picture .

Good luck.

E.

Logged
Pages: [1]   Go Up
« previous next »