locked
Workflow instance creation fails over > 10 KB RRS feed

  • Question

  • Hi,
    I get a Soap fault returned from a WCF hosted WF 4.0 service detailing what appears to be a somewhat cryptic message about a missing parameter/argument (see below for fault response in SoapUI). Ive checked the Soap header action and it seems fine.
    The interesting thing is I only get when the Soap request is above a certain size ~ 10Kb which is quite low. If I go under this it succeeds. The WCF default maxBufferSize for basicHttpBunding is supposed to be 64KB. Even if this were the cause I dont get the  "HTTP/1.1 413 Request Entity Too Large" so this doesn't appear to be the problem.

    All the IIS settings are pretty standard so Im a bit puzzled as to why requests > 10 KB are failing!!   So I wonder is the request being dropped due to memory pressure resulting in the ArgumeNullException?  Looking at the stack trace below it appears to be releated to the intialiseation of the Workflow around the construction of the WorkflowOperationContext object.

    Any feedback or ideas would be appreciated.

    Thanks

    B.


    <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
       <s:Body>
          <s:Fault>
             <faultcode xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</faultcode>
             <faultstring xml:lang="en-AU">Value cannot be null.
    Parameter name: value</faultstring>
             <detail>
                <ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                   <HelpLink i:nil="true"/>
                   <InnerException i:nil="true"/>
                   <Message>Value cannot be null.
    Parameter name: value</Message>
                   <StackTrace>at System.ServiceModel.Activities.WorkflowOperationContext.HandleEndResumeBookmark(IAsyncResult result)
       at System.ServiceModel.Activities.WorkflowOperationContext.OnResumeBookmark()
       at System.ServiceModel.Activities.WorkflowOperationContext..ctor(Object[] inputs, OperationContext operationContext, String operationName, Boolean performanceCountersEnabled, Boolean propagateActivity, Transaction currentTransaction, WorkflowServiceInstance workflowInstance, IInvokeReceivedNotification notification, WorkflowOperationBehavior behavior, TimeSpan timeout, AsyncCallback callback, Object state)
       at System.ServiceModel.Activities.Description.WorkflowOperationBehavior.WorkflowOperationInvoker.OnBeginServiceOperation(WorkflowServiceInstance workflowInstance, OperationContext operationContext, Object[] inputs, Transaction currentTransaction, IInvokeReceivedNotification notification, TimeSpan timeout, AsyncCallback callback, Object state)
       at System.ServiceModel.Activities.Dispatcher.ControlOperationInvoker.ControlOperationAsyncResult.PerformOperation()
       at System.ServiceModel.Activities.Dispatcher.ControlOperationInvoker.ControlOperationAsyncResult.HandleEndGetInstance(IAsyncResult result)
       at System.ServiceModel.Activities.Dispatcher.ControlOperationInvoker.ControlOperationAsyncResult.Process()
       at System.ServiceModel.Activities.Dispatcher.ControlOperationInvoker.ControlOperationAsyncResult..ctor(ControlOperationInvoker invoker, Object[] inputs, IInvokeReceivedNotification notification, TimeSpan timeout, AsyncCallback callback, Object state)
       at System.ServiceModel.Activities.Dispatcher.ControlOperationInvoker.InvokeBegin(Object instance, Object[] inputs, IInvokeReceivedNotification notification, AsyncCallback callback, Object state)
       at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&amp; rpc)
       at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&amp; rpc)
       at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc&amp; rpc)
       at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</StackTrace>
                   <Type>System.ArgumentNullException</Type>
                </ExceptionDetail>
             </detail>
          </s:Fault>
       </s:Body>
    </s:Envelope>

    Sunday, January 27, 2013 10:23 PM

Answers

  • Hi Melissa,

    Yes I enabled message-level tracing and showed the full soap envelopes with no problems. The problem in the end was around the Receive activity. I'll include my reply here from the WCF forum:

    I resolved the issue a couple of weeks back - the problem was around the WF Receive activity and its inability to accept the request of a particular size. There was no fault thrown on acceptance, it wouldn't initialize the string with the Soap message which I found strange. This, subsequently resulted in a ArgumentNullException being thrown downstream in the workflow.  The maxRecivedMessageSize was not the issue as this returns a Http request too large when its breached (see my original post). I redone the Receive activity with some small changes which seemed to work, so the exact cause I'm still unsure of. When deploying the updated workflow to production, I was finally receiving some useful exceptions returned around XmlReader limits so I increased the   
    <basicHttpBinding><bindings><binding><readerQuotas maxDepth="" maxBytesPerRead=""> which resolved that issue.   

    • Marked as answer by Molly Chen_ Monday, February 18, 2013 4:19 AM
    Monday, February 11, 2013 12:31 PM

All replies

  • Hi Brian,

    hope that you are doing good today.

    I would suggest in this scenario to collect WCF traces as from them we will understand which parameter value needs to be changed to increase the buffer value. You can enable tracing as per the article : http://msdn.microsoft.com/en-us/library/ms733025.aspx

    Please enable this in your web.config file and repro the issue and see what does it offer. If needed i can help out to review the traces. 

    Regards,

    Melissa-MSFT

    Friday, February 8, 2013 6:24 PM
  • Hi Melissa,

    Yes I enabled message-level tracing and showed the full soap envelopes with no problems. The problem in the end was around the Receive activity. I'll include my reply here from the WCF forum:

    I resolved the issue a couple of weeks back - the problem was around the WF Receive activity and its inability to accept the request of a particular size. There was no fault thrown on acceptance, it wouldn't initialize the string with the Soap message which I found strange. This, subsequently resulted in a ArgumentNullException being thrown downstream in the workflow.  The maxRecivedMessageSize was not the issue as this returns a Http request too large when its breached (see my original post). I redone the Receive activity with some small changes which seemed to work, so the exact cause I'm still unsure of. When deploying the updated workflow to production, I was finally receiving some useful exceptions returned around XmlReader limits so I increased the   
    <basicHttpBinding><bindings><binding><readerQuotas maxDepth="" maxBytesPerRead=""> which resolved that issue.   

    • Marked as answer by Molly Chen_ Monday, February 18, 2013 4:19 AM
    Monday, February 11, 2013 12:31 PM
  • Hi Brian,

    Thanks for sharing this with us :)

    Cheers!

    - Melissa

    Tuesday, February 12, 2013 1:57 PM