|
Home > Archive > BizTalk Server General > January 2006 > Send Hosts per Send Port?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Send Hosts per Send Port?
|
|
| Craig Vermeer 2006-01-27, 9:28 pm |
| Hello,
Does anyone know why we can configure the BizTalk Host per Receive
Location in BizTalk 2004, but can't do the same for individual Send
Ports? When sending messages from BizTalk, you can only configure the
Send Host per adapter.
My situation is this: I have two distinct business processes running
through a single BizTalk server. One is relatively high volume but not
business critical, and the other is lower volume but very business
critical. Both use the same Send adapter, which is a custom adapter
that is basically a proxy to a .NET WebService. Maybe you can see where
this is going.
Now, the higher volume business process occasionally spikes high enough
that it causes the adapter in question to start raising "There were not
enough threads available in the thread pool..." messages from the .NET
WebRequest class, basically because the ThreadPool is starved and the
WebRequest checks to make sure that at least two threads are available
in the pool before performing its operation.
I'm updating the thread pool settings referenced here [1] to increase
the size of the Thread Pool. However, what I'd really like to do is to
isolate my two different business processes into their own hosts, so
that a spike in volume for one process won't cause failures in the
second, more critical process.
However, I can't seem to configure two different send ports using the
same adapter to go to different BizTalk Hosts. Does anyone have any
suggestions? I suppose I could create a new custom adapter that's just
like my current one, but I'd like to find a better option, if there is one.
Thanks,
Craig Vermeer
[1] http://support.microsoft.com/defaul...kb;en-us;886966
| |
| Tomas Restrepo \(MVP\) 2006-01-27, 9:28 pm |
| Hi Craig,
> Does anyone know why we can configure the BizTalk Host per Receive
> Location in BizTalk 2004, but can't do the same for individual Send Ports?
> When sending messages from BizTalk, you can only configure the Send Host
> per adapter.
It's one of those pesky assymetries in the model between send ports and
receive ports. The good news is that this has been fixed in BizTalk 2006.
>
> My situation is this: I have two distinct business processes running
> through a single BizTalk server. One is relatively high volume but not
> business critical, and the other is lower volume but very business
> critical. Both use the same Send adapter, which is a custom adapter that
> is basically a proxy to a .NET WebService. Maybe you can see where this
> is going.
>
> Now, the higher volume business process occasionally spikes high enough
> that it causes the adapter in question to start raising "There were not
> enough threads available in the thread pool..." messages from the .NET
> WebRequest class, basically because the ThreadPool is starved and the
> WebRequest checks to make sure that at least two threads are available in
> the pool before performing its operation.
>
> I'm updating the thread pool settings referenced here [1] to increase the
> size of the Thread Pool. However, what I'd really like to do is to
> isolate my two different business processes into their own hosts, so that
> a spike in volume for one process won't cause failures in the second, more
> critical process.
>
> However, I can't seem to configure two different send ports using the same
> adapter to go to different BizTalk Hosts. Does anyone have any
> suggestions? I suppose I could create a new custom adapter that's just
> like my current one, but I'd like to find a better option, if there is
> one.
One option that might alleviate the problem some might be to move it to a
third host. For example, you could have three application hosts: One running
the mission critical process, the second one running the other process, and
the third one running just the send adapter you are using. While not
perfect, it might improve things somewhat...
The second thing to do might be to review your custom adapter to make sure
it does the most efficient use of available threads. The "Writing Effective
Adapters" whitepaper [1] might help a bit in that regard.
[1]
http://msdn.microsoft.com/library/e...9818ff63dfb.asp
The third thing to do, while it might take some slight work and is a
somewhat ugly solution, might be simply to fool around with your custom
adapter. You already have it, so you could potentially make a minor change
to it and make a separate copy of it in an assembly with a different name,
change the registration in the registry and register it with biztalk using a
different adapter name/prefix. That way you could have the same code but
make it look to biztalk as if you actually had two different adapters, and
then just put them in different hosts and bind each process to one of the
copies.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| Craig Vermeer 2006-01-27, 9:28 pm |
| Thanks for the response. The 'same but not the same' adapter was an
option I was considering, so I'll probably end up going in that direction.
Tomas Restrepo (MVP) wrote:
> Hi Craig,
>
>
> It's one of those pesky assymetries in the model between send ports and
> receive ports. The good news is that this has been fixed in BizTalk 2006.
>
>
> One option that might alleviate the problem some might be to move it to a
> third host. For example, you could have three application hosts: One running
> the mission critical process, the second one running the other process, and
> the third one running just the send adapter you are using. While not
> perfect, it might improve things somewhat...
>
> The second thing to do might be to review your custom adapter to make sure
> it does the most efficient use of available threads. The "Writing Effective
> Adapters" whitepaper [1] might help a bit in that regard.
>
> [1]
> http://msdn.microsoft.com/library/e...9818ff63dfb.asp
>
> The third thing to do, while it might take some slight work and is a
> somewhat ugly solution, might be simply to fool around with your custom
> adapter. You already have it, so you could potentially make a minor change
> to it and make a separate copy of it in an assembly with a different name,
> change the registration in the registry and register it with biztalk using a
> different adapter name/prefix. That way you could have the same code but
> make it look to biztalk as if you actually had two different adapters, and
> then just put them in different hosts and bind each process to one of the
> copies.
>
| |
| Tomas Restrepo \(MVP\) 2006-01-27, 9:28 pm |
| Hi Craig,
> Thanks for the response. The 'same but not the same' adapter was an
> option I was considering, so I'll probably end up going in that direction.
One option you might want to consider in implementing it so that it's easier
to maintain would be to basically create wrap the existing adapter by two
pseudo adapter components that just implement the basic adapter interfaces
by forwarding the calls into the real adapter, and then register those. It
might save you having two codebases to maintain.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| Craig Vermeer 2006-01-27, 9:28 pm |
| Absolutely, that's a good approach. Thanks for the help!
Tomas Restrepo (MVP) wrote:
> Hi Craig,
>
>
> One option you might want to consider in implementing it so that it's easier
> to maintain would be to basically create wrap the existing adapter by two
> pseudo adapter components that just implement the basic adapter interfaces
> by forwarding the calls into the real adapter, and then register those. It
> might save you having two codebases to maintain.
>
>
|
|
|
|
|