4

Running BizTalk 2013r2 standard.

I have a WCF-Custom Oracle send port to select data from an Oracle database. This is bound to an orchestration which has been working great until last week.

It has timeouts set as follows:

enter image description here

In the event of a timeout, I would like the adapter to retry. Problem is, even when a select request has been running for many hours, it doesn't time out.

The following screen grab taken from the admin console shows the message with a status of "In process" that was sent at 5am (it is now 10:36am).

enter image description here

Querying the service instances shows the same (the dehydrated instance is an orchestration bound to the send port)

enter image description here

I know the connection to the Oracle database can be unreliable. That would be ok if the adapter would timeout and retry.

My understanding from the MSDN doc (https://msdn.microsoft.com/en-us/library/dd788467.aspx) is that the adapter should work against the OpenTimeout value of 30 minutes. Can anyone see where I went wrong?

Change of understanding! After reviewing WCF traces from this morning's data build, I can see that the problem is not that the adapter doesn't timeout but rather that the send port fails to complete after receiving the select response.

The following shows the Request written and closed. However, the response is written but not closed:

enter image description here

When I look at the trace for a successful Oracle select triggered from a different orchestration then I see:

enter image description here

The orchestration that makes the select is as follows:

enter image description here

The expression shape between the SendSelect and RcvPromResult contains the following trace statement which I do get to see output if debigview: " Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation.TraceManager. WorkflowComponent.TraceInfo( "Promo request call made");"

However, I don't get the output from the statement within the "Trace Result" expression shape

The logical send is called from a scope shape for which an exception handler routes to the esb exception framework. This exception handler does not get triggered

Any ideas on why the problem connection is not being closed after receiving the select result?

Rob Bowman
  • 7,632
  • 22
  • 93
  • 200
  • Are you positive it's actually connected to Oracle and didn't timeout there but got dehydrated for some other reason? – Dan Field Apr 01 '16 at 15:48
  • 1
    I have the same problem this morning. The orchestration has dehydrated as I'd expect, hitting a persistence point on the logical send port. The physical send is still marked as "Active", 5 hours after issuing the select. There are no clues in the event log. If this were sql server I'd run profiler but I'm afraid I don't have access to similar Oracle tools. I will run a WCF trace and report back... – Rob Bowman Apr 02 '16 at 10:14
  • This is looking like a bug to me - might be worth contacting Microsoft with the data you have. Other than that, I'm not really sure what's getting hung up. Maybe writing a custom WCF behavior to help handle this could help as a workaround, but I'm not really sure. – Dan Field Apr 03 '16 at 14:31
  • I've gotten issues like this in other scenarios. I thought the issue was a malformed response. I'm wondering if the WCF layer is failing. Did you perhaps exceed the max size allowable for wcf message? – Jay May 11 '16 at 18:35
  • 1
    If your send port is marked for 'ordered delivery' it will stay active even if it's doing nothing. – Jay Feb 26 '18 at 20:10

0 Answers0