Hi all.

Here is a question posed to me by one of my developers here at work and the
answer is not immediately obvious.  Maybe someone has seen this behaviour
before and has some recommendations...

*****
With respect to the “Submit” adapter in the SubmitDirect sample in BizTa
lk
Server 2004 SDK, when we submit a request message to BizTalk and wait for th
e
response via the SubmitSyncMessage() method, the related Service Instance
entries in the Health and Activity Tracking (HAT) Operations (with Service
Name equal to “<Isolated Adapter>”) will always show in the query result
s
with Status equal to “Dehydrated” and Pending Job equal to “None”, a
nd do not
disappear from the list. Viewing Message Flow in any of these entries shows
Microsoft.BizTalk.DefaultPipelines.XMLTransmit as Service Name. The
“Submit”adapter is running in an IIS worker process and we are closing t
he
Microsoft.Samples.BizTalk.Adapters.TransportProxyUtils.BizTalkMessaging
object after each call. We noticed that the same thing happens with the
sample’s SubmitRequest project and that it does not happen with the
SubmitMessage() method call used in the submission of one-way messages. We
have to explicitly terminate these service instances to remove them from the
query results. Why does this happen? Does this kind of behavior with the
adapter represent any potential issue?
*****

[ Post a follow-up to this message ]

Ben,

> Here is a question posed to me by one of my developers here at work and
> the
> answer is not immediately obvious.  Maybe someone has seen this behaviour
> before and has some recommendations...
>
> *****
> With respect to the "Submit" adapter in the SubmitDirect sample in BizTalk
> Server 2004 SDK, when we submit a request message to BizTalk and wait for
> the
> response via the SubmitSyncMessage() method, the related Service Instance
> entries in the Health and Activity Tracking (HAT) Operations (with Service
> Name equal to "<Isolated Adapter>") will always show in the query results
> with Status equal to "Dehydrated" and Pending Job equal to "None", and do
> not
> disappear from the list. Viewing Message Flow in any of these entries
> shows
> Microsoft.BizTalk.DefaultPipelines.XMLTransmit as Service Name. The
> "Submit"adapter is running in an IIS worker process and we are closing the
> Microsoft.Samples.BizTalk.Adapters.TransportProxyUtils.BizTalkMessaging
> object after each call. We noticed that the same thing happens with the
> sample's SubmitRequest project and that it does not happen with the
> SubmitMessage() method call used in the submission of one-way messages. We
> have to explicitly terminate these service instances to remove them from
> the
> query results. Why does this happen? Does this kind of behavior with the
> adapter represent any potential issue?
> *****

I haven't used the SubmitDirect sample adapter much, but I've looked at the
code, and I do have some experience writing similar adapters (I wrote a
transactional direct submit for one of our customers).

From your description, I believe your problem is you're creating and
destroying the adapter each time you want to send a message. Looking through
the code, the adapter was not designed for that. Instead, you create the
initial instance and send all messages through it (yes, you should be able
to submit two messages concurrently from different threads through the same
instance).

The problem here is that calling MessagingAPI.Close() will actually release
the adapter, so the next call will try to reinitialize it, and that is slow.
Also, you'll quickly get into trouble under load, I think, because the
possibility of a race condition probably exists.

I'd try using a single instance and see if that actually helps!


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]