RE: BizTalk 2004 SOAP Adapter Tuning, ThreadPool

From: Markus (anonymous_at_discussions.microsoft.com)
Date: 09/06/04

  • Next message: david: "creating a custom function for business rule engine"
    Date: Mon, 6 Sep 2004 01:00:46 -0700
    
    

    Hi,
    First of all, your answer is assuming that we have control
    over the web service host. We dont have control over
    either the web service or the host, this is 3 party.

    The problem is actually as simple as this:
    I have a scenario where a large file is split into
    multiple messages
    (200-700 x) all going to a web service (3 party). The soap
    adaper fails
    with this error:
     
    The "SOAP" adapter is suspending an outbound message going
    to destination
    URL:"http://cuk497:8500/axis/services/DataLoaderWS".
    Details:"There were not enough free threads in the
    ThreadPool object to
    complete the operation. ".

    Note the following: this is not a timeout issue, nor a
    problem with the remote web service.

    I have tuned and changed the values in the mngt service
    table with
    watermarks etc, and the machine.config connections. And
    this partly
    solve the problem. I am able to eliminate the problem by
    this approach,
    BUT i dont believe it is the right way of doing it, and it
    dont scale at
    all. I think this is a bug, are you of a different
    opinion? or do you
    have any suggestion on how to approach this?

    Regards,
    Markus

    >-----Original Message-----
    >You are describing more than one issue so I'll try to
    answer one by one.
    >
    >1.>> queued requests in IIS actually going through
    successfully over an
    >hour later, even though the message was retried right up
    to its retry count
    >and written to disc via its backup transport -
    >Where do you send the messages? It looks to me that the
    receiving web
    >service performs a long running operation (let's say over
    2 minutes) and as
    >a result the connection is timing out. Could you confirm
    my assumption? If
    >this is the case then it might be a design problem in
    your web service. You
    >should be able to workaround this. Basically what is
    happening right now is
    >- BizTalk sends the message, your web service executes
    the request and it
    >takes a long time, let's say 5 minutes. As a result the
    HTTP connection is
    >dropped so BizTalk will retry sending the message. So you
    will have a
    >second, third, ..., request all executing the same web
    service operation.
    >If your web service is not designed correctly, this could
    lead to IIS
    >requests to be queued.
    >
    >What's the solution? Ideally, you should improve your web
    service so that
    >it executes the request in just a few seconds so you
    don't have this
    >problem. If that's not possible, then you need to change
    the default
    >timeout settings so that the HTTP connection does not
    timeout before the
    >request ends execution. To do this, you need to probably
    need to make
    >changes to the following
    >
    >Required changes
    >================
    > - on the web service machine - "Connection Timeout"
    web site property
    >for the IIS web site where your web service is installed
    (by default 120
    >seconds)
    > - on the BizTalk machine - If you are calling a web
    service from an
    >orchestration and need to increase the timeout, you can
    do so by setting a
    >context property on your outbound message in a message
    assignment shape
    >before sending.
    > MyMessage
    (SOAP.ClientConnectionTimeout) = 240; //
    >your value here
    >
    >Other things to look into
    >====================
    >The required changes above should do it. If not you can
    look further into
    >the options below.
    > - on the web service machine - <processModel
    >responseDeadlockInterval="????"> (setting per machine)
    > - on the web service machine - <httpRuntime
    executionTimeout="????"/>
    >under <system.web> (setting per application)
    > - on the web service machine - Server.ScriptTimeout
    (probably it doesn't
    >make sense. I think it's only for scritps)
    > - on the BizTalk machine that runs the host used by
    SOAP-
    ><system.net><connectionManagement><add name="*"
    maxconnection= "15"
    >(default value is 2)
    >
    >2. >> threadpool issues causing retries
    > Hopefully the changes above will eliminate all the
    unnecessary retries
    >so you won't run into threadpool issues. If you still run
    into thread pool
    >issues then what you should use multiple hosts or host
    instances and spread
    >your SOAP and HTTP requests over these multiple hosts or
    host instances.
    >
    >3. >> Is the SOAP adapter not designed to handle this
    amount of requests?
    >If so surely it cannot be considered even remotely
    scalable in an
    >enterprise messaging solution
    >It should be able to do so. It looks like a problem with
    the web service.
    >
    >--------------------
    >>>Content-Class: urn:content-classes:message
    >>>From: "Markus" <anonymous@discussions.microsoft.com>
    >>>Sender: "Markus" <anonymous@discussions.microsoft.com>
    >>>Subject: BizTalk 2004 SOAP Adapter Tuning, ThreadPool
    >>>Date: Thu, 2 Sep 2004 05:10:11 -0700
    >>>Lines: 49
    >>>Message-ID: <09c601c490e5$cb8cf660$a401280a@phx.gbl>
    >>>MIME-Version: 1.0
    >>>Content-Type: text/plain;
    >>> charset="iso-8859-1"
    >>>Content-Transfer-Encoding: 7bit
    >>>X-Newsreader: Microsoft CDO for Windows 2000
    >>>thread-index: AcSQ5cuMpntfxDpiSbKQVnHT7MClPg==
    >>>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
    >>>Newsgroups: microsoft.public.biztalk.general
    >>>Path: cpmsftngxa10.phx.gbl
    >>>Xref: cpmsftngxa10.phx.gbl
    microsoft.public.biztalk.general:19300
    >>>NNTP-Posting-Host: tk2msftngxa12.phx.gbl 10.40.1.164
    >>>X-Tomcat-NG: microsoft.public.biztalk.general
    >>>
    >>>Hi,
    >>>I am having the same problem as Conor. Does anyone have
    >>>any experience with this?
    >>>
    >>>/////////////////
    >>>
    >>>Hi,
    >>>
    >>>Can anyone point me to a Tuning guide related
    specifically
    >>>to the SOAP
    >>>Adapter and a Web Service that it calls. I'm
    experiencing
    >>>serious
    >>>scalability issues with a system that is not far off
    going
    >>>live.
    >>>
    >>>I would've assumed BizTalk can handle 500 messages
    posted
    >>>to messagebox, and
    >>>could deliver these to a Web Service via an
    Orchestration
    >>>and the SOAP
    >>>adapter in a timely and reliable fashion. However I'm
    >>>experiencing numerous
    >>>threadpool issues causing retries, queued requests in
    IIS
    >>>actually going
    >>>through successfully over an hour later, even though
    the
    >>>message was retried
    >>>right up to its retry count and written to disc via its
    >>>backup transport -
    >>>i.e. BizTalk being told that it's deliver failed, even
    >>>though the Web
    >>>Service done its work perfectly with no errors. Very
    very
    >>>confusing stuff.
    >>>
    >>>Is the SOAP adapter not designed to handle this amount
    of
    >>>requests? If so
    >>>surely it cannot be considered even remotely scalable
    in
    >>>an enterprise
    >>>messaging solution.
    >>>
    >>>Is it possible for me to increase the SOAP hosts worker
    >>>threads easily? And
    >>>should I be considering throttling IIS request handling?
    >>>
    >>>Thanks in advance,
    >>>Conor
    >>>
    >>>
    >>>.
    >>>
    >>>
    >>>
    >
    >This posting is provided "AS IS" with no warranties, and
    confers no rights.
    >
    >EBusiness Server Team
    >
    >.
    >


  • Next message: david: "creating a custom function for business rule engine"

    Relevant Pages

    • Re: An existing connection was forcibly closed by the remote host
      ... Within my web service proxy class I overrode the GetWebRequestmethod and modified it as shown below. ... HttpWebRequest request = base.GetWebRequestas ... If the size of the request message I was using is greater than the size of the packets the host could receive and the host is configured receive chunked messages then I guess I can assume when we sent a message larger than the packet size without sending it chunked their server terminated the session because it was waiting for another TCP message??? ... at System.Net.Sockets.NetworkStream.Read(Bytebuffer, Int32 offset, Int32 size) ...
      (microsoft.public.dotnet.framework.aspnet.webservices)
    • Re: four basic "non techie" type questions regarding MS DNS and windows server IIS capabilities
      ... of domain aliases to the same host running web services I ... ASP has to report something known to it from the Web Service ... It will show the server name that the web server uses; ... Not for the SAME zone -- a zone is KNOWN in DNS to be either COMPLETE ...
      (microsoft.public.windows.server.dns)
    • Re: Hosting a .NET Web Service without IIS
      ... What is an asmx web service? ... it is possible to host ASMX without IIS. ... > people host ASP.NET runtime within WinForms apps, ...
      (microsoft.public.dotnet.framework.webservices)
    • RE: error deploying web service
      ... ISP's that will host an ASP based application but who just aren't prepared ... >> Have you tried copying a minimal hello world web service to your hosting ... >> from the host from a client that can call it from your dev machine (but ... >> hoster doesn't support web services. ...
      (microsoft.public.dotnet.framework.aspnet.webservices)
    • Re: BizTalk 2004 SOAP Adapter Tuning, ThreadPool
      ... We dont have control over ... >> either the web service or the host, ... >> HTTP connection is ...
      (microsoft.public.biztalk.general)