none
False Warning: did not match the metadata available. If this Stored Procedure or Polling Statement RRS feed

  • Question

  • We found the following Warning (not Error) in our production application EventLog.
    We have a sudden increase in volume, and increasing the timeouts on our WCF-SQL polling receive locations has solved the issue.

    Please see my questions after the error:

    The adapter "WCF-Custom" raised an error message. Details "Microsoft.ServiceModel.Channels.Common.AdapterException: The ResultSet returned as part of the Typed Stored Procedure or Typed Polling invocation did not match the metadata available. If this Stored Procedure or Polling Statement can return a variable number of result sets, consider using the un-typed Stored Procedure or un-typed Polling operation instead.
       at Microsoft.Adapters.Sql.GenericReaderWriter.GetResultSetMetadataForTypedSPPolling(StoredProcedureMetadata procedureMetadata, ReaderMetadata readerMetadata, Int32& possibleSchemaTableIndex)
       at Microsoft.Adapters.Sql.GenericReaderWriter.OnWriteBodyContents(XmlDictionaryWriter writer)
       at System.ServiceModel.Channels.BodyWriter.WriteBodyContents(XmlDictionaryWriter writer)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfMarshaller.CreateBizTalkMessageStream(Message wcfMessage, IAdapterConfigInboundMessageMarshalling config)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfMarshaller.CreateBizTalkMessage(IBaseMessageFactory messageFactory, IAdapterConfigInboundMessageMarshalling marshallingConfig, Message wcfMessage)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfMarshaller.CreateBizTalkSubmitMessage(IBaseMessageFactory factory, String inboundTransportLocation, String inboundTransportType, RLConfig config, Message wcfMessage, String ssoToken)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkSubmitBase..ctor(Message message, BizTalkEndpointContext endpointContext, ControlledTermination control, AsyncCallback realCallback, String ssoToken)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkOperation.Create(Message message, AsyncCallback callback, Object state, String ssoToken, Boolean bizTalkOneWay, BizTalkEndpointContext endpointContext, ControlledTermination control)
       at Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance.BeginOperation(Message message, AsyncCallback callback, Object state, Boolean bizTalkOneWay)".

    1. I am sure the message didn't get published to the MsgBox, because we have subscribers that didn't get it.  They put the message in another SQL table.

    2. Why is it a warning and not an error?

    3. Why didn't the message get suspended?  We monitor for Suspended Messages, and even errors in the eventlog; we don't spend a lot of time looking at warnings.

    4. Why isn't it a time-out message? It sounds like maybe it timed out, and the data being returned is maybe null, and therefore not matching a schema?

    5. Why doesn't the error include the name of the ReceiveLocation or the StoredProc  involved?  Not having this standard information makes debugging extremely difficult.

    Thanks,

    Neal Walters



    Wednesday, May 29, 2013 6:43 PM

Answers

  • Since it's a Polling operation, I'll assume you mean the Receive Location. 

    As it happens, I had to check out a Polling error today and the error the Adapter logged did contain the endpoint address.  So, I agree, it's a bug that that error doesn't include the endpoint address.  Sorry, I don't see a way around that.

    If you can repro or influence when it happens, enabling WCF tracing might give you some more insight.

    Have you considered limiting the result set to 1 and enabling Poll While Data Found?

    • Marked as answer by Pengzhen Song Tuesday, June 11, 2013 4:56 AM
    Tuesday, June 4, 2013 10:39 PM

All replies

  • Hi,

    Please refer the similar thread

    http://social.msdn.microsoft.com/Forums/en-US/biztalkgeneral/thread/21af9174-e1ed-4b02-92ac-ce6c39084e71

    Hope it can help you

    Thursday, May 30, 2013 7:09 AM
  • This is probably because the Adapter calls the SP first with SET FMTONLY to retrieve the metadata for the result set but the actual result set didn't match.

    The mismatch is probably because SET FMTONLY ignores conditionals in the query causing unexpected code paths to be evaluated.  I think there's also some wierdness with table variables too.

    Whether this should be a Warning or Error is debatable.  Either way, the Adapter should have abandoned the transaction, hence no message was actually retrieved.

    My recommendation would be to address why the Polling is taking so much longer with the increased volume.  Perhaps add a TOP n or some conditional filters to the stored procedure to make the result more manageable.

    Thursday, May 30, 2013 3:15 PM
  • Sven - I don't think that link is "on target".  As I said, I'm not in Development, I'm in Production (and have been for more than a year) and I'm not asking how to do work with typed/untyped schemas.  I'm getting an occasional error in Prod on an existing system.

    Boatseller - same concept.  First, I'm still trying to figure out which SPROC is bombing.  The "freaking" message doesn't even tell me the name of the SendPort nor the name of the StoredProc (I'm adding that as question 5 in my original post.) Since the error indicates the word "polling" though, that narrows it down to probably two suspects. 

    We have since found out that increasing the timeouts solved most of this issue, but it still happens now, but less often.  Our timesout are now 20, 20, 24.20, 20 for closeTimeout, openTimeout, receiveTimeout, sendTimeout.

    This page: http://msdn.microsoft.com/en-us/library/dd787981%28v=bts.10%29.aspx recommends setting all polling receiveTimeout to value: 24.20:31:23.6470000 (24 days), but it doesn't exactly explain why other than this is the max possible value.

    Neal

    Tuesday, June 4, 2013 1:35 PM
  • Since it's a Polling operation, I'll assume you mean the Receive Location. 

    As it happens, I had to check out a Polling error today and the error the Adapter logged did contain the endpoint address.  So, I agree, it's a bug that that error doesn't include the endpoint address.  Sorry, I don't see a way around that.

    If you can repro or influence when it happens, enabling WCF tracing might give you some more insight.

    Have you considered limiting the result set to 1 and enabling Poll While Data Found?

    • Marked as answer by Pengzhen Song Tuesday, June 11, 2013 4:56 AM
    Tuesday, June 4, 2013 10:39 PM