There are so many blog posts in draft mode on my OneNote that I’m taking a little time to dispatch them. Today, I have another Error and Warning, Cause, and Solution, this time using the BizTalk Server Oracle DB adapter.
Some time ago, I was helping a client to diagnose a problem in their solution and try to find out the reason why there were so many issues logged in the event viewer with the following error:
The adapter “WCF-Custom” raised an error message. Details “Microsoft.ServiceModel.Channels.Common.TargetSystemException: ORA 01013: user requested cancel of current operation —> Oracle.DataAccess.Client.OracleException: ORA 01013: user requested cancel of current operation
Cause
“ORA-01013: user requested cancel of current operation” means your client told Oracle to abort the current call. Most likely, you have a timeout setting configured in your client software. In other words, it simply means that BizTalk Server gave up waiting for a response from the database.
This error usually means:
- That problem is on your client’s side, not in the database.
In fact, the BizTalk Server has plenty of timeout settings, but for this particular case, the important setting we need to focus on is the sendTimeout. And in our case, the settings were 58 seconds:
And the default settings of BizTalk Server are not that different, 2 seconds more:
To be honest, this was running fine without significant issues for a long time (years), and from one day to the other, it started giving this error, so:
- That is not a problem on your client’s side. It is on the database side.
This can happen for several reasons:
- Databases have started to become too large, and the queries are now very slow.
- Someone made configuration changes on the database or server, causing performance issues.
- And so on.
The important thing to diagnose and solve those issues is to speak with the Oracle Database team to understand what is happening with those statements and why they take so long to return the responses.
Solution
While this is not solved, the only thing you can do to minimize the issues is to extend the timeout on the sendTimeout property. For example, set it to 2 minutes. From there, analyze and fine-tune this value.
Also, be aware of fine-tuning the pollingInterval property. Don’t set the sendTimeout property to 2 minutes, and leave the pollingInterval property with a polling interval of less than 2 minutes. At this point in time, you are minimizing problems. You know that ORACLE will take more than 1 minute to return the response. If you continually open a connection string without getting responses back, you will stress the Oracle DB even more. So, at least put the pollingInterval as 120 seconds (2 min).
Emphasize that this is not the solution, it is just a band-aid.
I hope you find this helpful! If you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego!
