on 2012 Nov 23 8:14 AM
One of our Bex workbook query is timing out intermittently. Mostly in the morning and sometimes in the afternoons and evenings. There is no specific trend except it times out once every morning. The workbook query executed has the same selection for all the runs and is never changed.
We have increased web dispatcher timeout and appropriate icm time outs but we dont believe increasing timeout is an ideal solution.
One thing i am puzzled about is, only the early morning first run takes several work processes in the backend BW system and is timing out. Whereas later runs use less work processes and read the same tables quickly. Could this be due to the amount of data.
Another aspect here is sometimes when the run takes place immediately after a timedout run or successful run, the query outputs data immediately (in 15 seconds sometimes), it is here we observe that the backend work processes are not doing any reads on the fact tables. This implies that sometimes its either reading from some sort of query cache of sorts. Can you please point me to any documentation regarding how queries cache data.
Today, due to the impact its having on the Morning runs, we have further revised web dispatcher time out, ICM times outs in PROCTIMEOUT,TIMEOUT etc....however it still timed out when ran via web dispatcher and directly on a specific ABAP server. The error when it timed out is "Traffic Control: Nettimeout (30) exceeded by peer:". My troubleshooting yielded we need to review icm/traffic_control However we are on NW 701 (EHP1) and not on NW 730. Does any one know how we can accomodate increasing icm/traffic_control
Also any thoughts on why workbook query run times differ from time to time. I have checked the sql statements and corresponding reads etc...but i couldn't find significant difference.
Regards
Kalyan
Hi Kalyan,
I think this Note can help you: note 1662376 - '.Net client cannot communicate with Application Server'.
Best Regards,
Michael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Michael,
Many thanks for responding
We are running on SAP Kernel : 720_EXT_REL Kernel Patch number : 300.
Would the note be still applicable to us I am unable to verify with the note as it doesn't state for 720_EXT_REL at the bottom although it states for 721 EXT and just 720 Kernels.
Also this is the exact error message. Perhaps you can recollect more with this ?
[Thr 1464] {00ad6d5e} Traffic Control: Nettimeout (30) exceeded by peer: x.x.x.x:55082 [icxxthr.c 4285]
[Thr 1464] CONNECTION (id=173/27998):
used: 1, type: default, role: Server(1), stateful: 0
NI_HDL: 1712, protocol: HTTP(1)
local host: x.x.x.1:8020 ()
remote host: x.x.x.x:55082 ()
status: READ_REQUEST
connect time: 23.11.2012 07:09:04
MPI request: <6203> MPI response: <6204>
request_buf_size: 0 response_buf_size: 0
request_buf_used: 0 response_buf_used: 0
request_buf_offset: 0 response_buf_offset: 0
In the above x.x.x.x is the IP for Central Instance ABAP and x.x.x.1 is the IP of dialogue instance.
Regards
Kalyan
User | Count |
---|---|
62 | |
9 | |
8 | |
6 | |
6 | |
6 | |
6 | |
6 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.