Solved

SQLTimeoutException: ORA-01013: user requested cancel of current operation

  • 6 January 2024
  • 3 replies
  • 184 views
M
Rank
Userlevel 4
Badge +8

We have an interface, sending in 1000s of messages through connect to application messages, and about 10 - 15% ends with error:

ExecutionException from Sender thread

Caused by: ifs.fnd.connect.senders.ConnectSender$PermanentFailureException: Request has been aborted or timed out

Caused by: ifs.fnd.base.UserAbortException: Request has been aborted or timed out

Caused by: java.sql.SQLTimeoutException: ORA-01013: user requested cancel of current operation

 

Caused by: oracle.jdbc.OracleDatabaseException: ORA-01013: user requested cancel of current operation

 

We have three connect pods set to 1 minute time out. 

What could be a reason for this to happen?

We are on 23R1 SU6.

 

icon

Best answer by udlelk 9 January 2024, 05:26

View original

3 replies

U
Rank
Userlevel 5
Badge +14

Please add more details about the flow. Specially, about the Routing Address is used in this flow and about the timeout that you have set to 1min.

M
Rank
Userlevel 4
Badge +8

Customer has changed connect pod deployment directly in Lens, setting queryTimeout to 60. This is then being reset as soon as the pod is restarted.

When i add that to the ifscloud-values.yaml, it does not change. If i add it to ifsappodata, i can see a change if i do describe on the pod, but it does not change for the connect pod.

From ifscloud-values.yaml:

ifsappconnect:
  connectQueryTimeout: 60
  queryTimeout: 60

ifsappodata:
  queryTimeout: 60
 

 

The routing address is using plsql address.
 

This is being processed from the application message, and sometimes the application message ends up with the “user requested cancel of current operation” error. The messages sent in can have many different transactions in them, so it could potentially take longer than 30 seconds to run them.

When an application message is processed, is it the connect pod or odata pod that is processing it? I thought it was the connect pod, which then would not have an impact if i changed the value for the odata pod.

U
Rank
Userlevel 5
Badge +14

IFS Connect PL/SQL query timeout parameter (IFS_QUERY_TIMEOUT) is exposed to custom_values.yaml as connectQueryTimeout from 23R1SU7 onwards.

Reply


Terms & ConditionsCookie settings