BizTalk Server - HTTP Receive 500 Error - Multiple IIS App Pools needed?

Author

HTTP Receive 500 Error - Multiple IIS App Pools needed?

HablaElBiz

2007-02-01, 1:16 pm

Hello All,

Problem:

I have multiple HTTP Receive Locations in production use, but have
recently found that with adding more of them and introducing even
slight volume, my WIN2K3 SP1, BTS04 SP2 system can get into a state
where some of the Receive Locations will throw IIS Internal Server
Error messages thrown when data is submitted. I suspect that
submitting systems resubmitting is somewhat covering the issue until
the regular IIS cycle is performed.

The IIS logs show 500 errors. The Event Viewer shows nothing at
all, so it's not a BizTalk Config / subscription error / or anything
like that. I've seen and dealt wit these issues before.

The pattern is not consistent. I can have a given rloc work, then
not work, then work, etc. I can have one or two rlocs work fine and
have one that will just plain not work. Then if IIS is cycled or the
*ONE* app pool that I have been using is cycled, then it seems like
first-come-first-served up to a point, then lots of 500 errors from
there out, until the next cycle. After an IIS/App Pool cycle, rlocs
that didn't work before can start working fine (f-c-f-s).

Configuration:

I have one IIS site that has 10 (or so) virtual directories set up
within it, each pointing to the physical location of the
BTSHTTPReceive.dll that was installed with/by BTS04. Until today, all
of these virtual directories were running within one app pool.

Findings:

I have found that adding more App Pools in IIS seems to resolve the
issue (completely I'm thinking at this point after slight testing). I
can't seem to get a document to not process now that I've got more
pools in the mix.

Question:

Is there anything known or documented of an issue with the
BTSHTTPReceive.dll being hosted by multiple virtual directories
running under one app pool? Would using one app pool for multiple
*sites* work differently or better? What is the suggested config?
All the info that I can find is how to get your first HTTP rloc
operational, but nothing on how to config or keep a bunch of them
working.

Any info or insight appreciated!
- Curtis Herrick

Tao Zhang[MSFT]

2007-02-21, 7:14 pm

How many message per day that you sent to your HTTP received location?
Does the one that fail always the one that receiving the highest load?

For now, distribute them into different app pool is good idea. App Pool is
suppose to isolate the problems happened in each website: a problem happen
in one website of one pool will not affect other sites in other App Pool.

If you can give me more description on your setup and daily usage, then
that will be helpful. Also, do you have orchestration behind the HTTP
receive location? Anything wrong during message processing may cause HTTP
receive location return 500 error code too.

--------------------[vbcol=seagreen]
microsoft.public.biztalk.general,microsoft.public.biztalk.server[vbcol=seagreen]
17:00:41 GMT)[vbcol=seagreen]
NET CLR 1.1. 4322),gzip(gfe),gzip(gfe)[vbcol=seagreen
]
TK2MSFTNGHUB02.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTFEEDS01.phx.gbl!news-out.
cwix.com!newsfeed.cwix.com!newscon06.news.prodigy.net!prodigy.net!border1.nn
tp.dca.giganews.com!nntp.giganews.com!postnews.google.com!j27g2000cwj.google
groups.com!not-for-mail[vbcol=seagreen]
microsoft.public.biztalk.general:2004[vbcol=seagreen]

HablaElBiz

2007-03-05, 1:18 pm

Hi Tao,

We have quite a few HTTP rloc's, and they range from hundreds of
messages a day to thousands of messages a day. They are categorized
at this time by business system within our company.

We had this issue mostly when we were receving most of our traffic to
one server. Before we split things into pools, we (not clear what
else to do) moved some HTTP receive traffic to other servers since the
IIS 500 errors would immediately start up.

When we split things into IIS pools (one per business system - not one
per rloc... yet) things started working better.

Currently we have one web site with many virtual directories (branched
by business system at the first level within the site). Each virtual
directory is configured to use that business system's IIS app pool.

As far as which rloc would start to fail, we mixed up the traffic in
various order of arrival. It was more of a first-come-first-served
scenario. Low volume rloc's could best the high volume rloc's
depending on which type of messages showed up first. Whomever won out
seemed to stick - once one of the rloc's failed with an IIS 500, that
rloc would continue to fail with the 500 error while the others would
continue to work fine.

Each business system now has 3 or less HTTP rloc's in it, and I'm now
wondering when we'll add the next solution that will force me to start
creating sub-business-system IIS App Pools.

Does this help? Glad to give more info if needed!

Thanks,
- Curtis Herrick