Can any one guess what would be maximum number of the messages can pass through the BizTalk Receive / Send Host?
I asked same question to many of my friends and every one given different answer like
Can pass “N” number of message
No Limit
Could be 10 lacks of instances
Which one is correct from your point of view? I know you are going to give me a new number. Any way let me try to answer this question also will explain you why should we consider this number? Is this really a big impact for your application?
Well, I am working for Retail application and we normally receive a 200 – 1000 messages per sec. Also we need to send each message to 10 different locations. Hence the count on average is 500*10 = 5000 message instances will send through “SendHost”.
It has been working quite well and I never faced any issue with the BizTalk SendHot. On one Friday suddenly the SendHost got Stopped and I tried a lot to start the Host but no luck. It was throwing the below error.
Job Name : MessageBox_Message_Cleanup_BizTalkMsgBoxDb
Error Description :
Arithmetic overflow error converting expression to data type int.
[SQLSTATE 22003] (Error 8115) The statement has been terminated. [SQLSTATE 01000] (Error 3621). The step failed.
This issue is due to threshold of Sendhost has crossed the Int value.
If I quickly check at the threshold of the SendHost I could find that it already reached Int value.
If you look at the Store procedures which has supported for the above job, It cleared said the data type used for nID as INT in stored procedure. But actually in table it declared as BigInt.
StoredProc Name: int_PurgeMessageZeroSumTable
CREATE PROCEDURE [dbo].[int_PurgeMessageZeroSumTable]
AS
declare @count int, @tmp int, @fUseTempTable bit,
@fContinue int,
@tnActiveTable tinyint,
@retVal int
create table #PurgeJobMsgIDs (nID int NOT NULL, uidMessageID uniqueidentifier NOT NULL)
create clustered index [CIX_PurgeJobMsgIDs] on [#PurgeJobMsgIDs] ([uidMessageID])
set @fContinue = 99
while (@fContinue >= 99)
This I have changed to BigINT as suggested by Microsoft.
I asked same question to many of my friends and every one given different answer like
Can pass “N” number of message
No Limit
Could be 10 lacks of instances
Which one is correct from your point of view? I know you are going to give me a new number. Any way let me try to answer this question also will explain you why should we consider this number? Is this really a big impact for your application?
Well, I am working for Retail application and we normally receive a 200 – 1000 messages per sec. Also we need to send each message to 10 different locations. Hence the count on average is 500*10 = 5000 message instances will send through “SendHost”.
It has been working quite well and I never faced any issue with the BizTalk SendHot. On one Friday suddenly the SendHost got Stopped and I tried a lot to start the Host but no luck. It was throwing the below error.
Job Name : MessageBox_Message_Cleanup_BizTalkMsgBoxDb
Error Description :
Arithmetic overflow error converting expression to data type int.
[SQLSTATE 22003] (Error 8115) The statement has been terminated. [SQLSTATE 01000] (Error 3621). The step failed.
This issue is due to threshold of Sendhost has crossed the Int value.
If I quickly check at the threshold of the SendHost I could find that it already reached Int value.
If you look at the Store procedures which has supported for the above job, It cleared said the data type used for nID as INT in stored procedure. But actually in table it declared as BigInt.
StoredProc Name: int_PurgeMessageZeroSumTable
CREATE PROCEDURE [dbo].[int_PurgeMessageZeroSumTable]
AS
declare @count int, @tmp int, @fUseTempTable bit,
@fContinue int,
@tnActiveTable tinyint,
@retVal int
create table #PurgeJobMsgIDs (nID int NOT NULL, uidMessageID uniqueidentifier NOT NULL)
create clustered index [CIX_PurgeJobMsgIDs] on [#PurgeJobMsgIDs] ([uidMessageID])
set @fContinue = 99
while (@fContinue >= 99)
This I have changed to BigINT as suggested by Microsoft.
Thanks a lot for the tip of using BigInt..
ReplyDeleteIt helped us resolve a major performance issue..