RE: BizTalk 2004 SOAP Adapter Tuning, ThreadPool
From: Markus (anonymous_at_discussions.microsoft.com)
Date: 09/06/04
- Previous message: Tareq Mohamed: "Do u need single click deployment for your biztalk projects, I"m h"
- In reply to: Adrian Hamza[MSFT]: "RE: BizTalk 2004 SOAP Adapter Tuning, ThreadPool"
- Next in thread: Matt Milner: "Re: BizTalk 2004 SOAP Adapter Tuning, ThreadPool"
- Reply: Matt Milner: "Re: BizTalk 2004 SOAP Adapter Tuning, ThreadPool"
- Messages sorted by: [ date ] [ thread ]
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
>
>.
>
- Previous message: Tareq Mohamed: "Do u need single click deployment for your biztalk projects, I"m h"
- In reply to: Adrian Hamza[MSFT]: "RE: BizTalk 2004 SOAP Adapter Tuning, ThreadPool"
- Next in thread: Matt Milner: "Re: BizTalk 2004 SOAP Adapter Tuning, ThreadPool"
- Reply: Matt Milner: "Re: BizTalk 2004 SOAP Adapter Tuning, ThreadPool"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|