Throttling state

Use the following steps to access the performance counters.

On the Desktop, click Start, point to Programs, point to Administrative Tools, and then click Performance.

In the Performance dialog box, click Add.

In the Add Counters dialog box, from the Performance object drop-down list, select from the available BizTalk:Message Agent performance counters, and then click Add.

In the Add Counters dialog box, do one of the following:

After selecting the counters, click Add and then click Close.

For each Host instance,the throttlings state are shown with « Message delivery throttling state » and « Message publishing throttling state »

When there is no throttling, their values are 0. But when they got throttlhing state, their value could be 1 to 11

Here is their definition :

Message delivery throttling state A flag indicating whether the system is throttling message delivery (affecting XLANG message processing and outbound transports).

  • 0: Not throttling
  • 1: Throttling due to imbalanced message delivery rate (input rate exceeds output rate)
  • 3: Throttling due to high in-process message count
  • 4: Throttling due to process memory pressure
  • 5: Throttling due to system memory pressure
  • 9: Throttling due to high thread count
  • 10: Throttling due to user override on delivery
Message publishing throttling state A flag indicating whether the system is throttling message publishing (affecting XLANG message processing and inbound transports).

  • 0: Not throttling
  • 2: Throttling due to imbalanced message publishing rate (input rate exceeds output rate)
  • 4: Throttling due to process memory pressure
  • 5: Throttling due to system memory pressure
  • 6: Throttling due to database growth
  • 8: Throttling due to high session count
  • 9: Throttling due to high thread count
  • 11: Throttling due to user override on publishing

For fixing throttling, start by readung this link http://msdn.microsoft.com/en-us/library/aa559893(BTS.10).aspx

Then I wish you luck

Handle deadlock in polling Scenarii

Situation

In some scenarii, you must poll a datatable and you use WCF-SQL. This polling must update a column for  rows which are red. Due to the polling frequency you might encounter deadlock.

Consequence there is no more activity in your BizTalk Server, and you can loose some newly data which are never inserted

So you need to know if you have deadlock, here is the query that retrieve all status’ queries.

SELECT P.spid, P.ecid, P.status, P.loginame, P.hostname, P.blocked AS blk, D.name as dbname, P.cmd, P.request_id, T.text FROM sys.sysprocesses P CROSS APPLY sys.dm_exec_sql_text(P.sql_handle) T LEFT JOIN sys.sysdatabases D ON D.dbid = P.dbid

If you find suspended, then you’ve got DeadLock

The problem come from the fact that you try to insert new data while you try to update with biztalk already existing data.

Workaround

You must specify a deadlock victim. Most of time, we declare BizTalk as deadlock victim. Indeed, BizTalk have a frequence polling, if it can’t read this time, it could read the next time. But it’s just a general case.

To set a deadlock victim, in your SQL sentence you have to specify the deadlock priority. there are three levels

LOW

Specifies that the current session will be the deadlock victim if it is involved in a deadlock and other sessions involved in the deadlock chain have deadlock priority set to either NORMAL or HIGH or to an integer value greater than -5. The current session will not be the deadlock victim if the other sessions have deadlock priority set to an integer value less than -5. It also specifies that the current session is eligible to be the deadlock victim if another session has set deadlock priority set to LOW or to an integer value equal to -5.

NORMAL

Specifies that the current session will be the deadlock victim if other sessions involved in the deadlock chain have deadlock priority set to HIGH or to an integer value greater than 0, but will not be the deadlock victim if the other sessions have deadlock priority set to LOW or to an integer value less than 0. It also specifies that the current session is eligible to be the deadlock victim if another other session has set deadlock priority to NORMAL or to an integer value equal to 0. NORMAL is the default priority.

HIGH

Specifies that the current session will be the deadlock victim if other sessions involved in the deadlock chain have deadlock priority set to an integer value greater than 5, or is eligible to be the deadlock victim if another session has also set deadlock priority to HIGH or to an integer value equal to 5.

Source MSDN

For my problem, BizTalk will have a low deadlock priority and the program which insert data the hight deadlock priority. We never loose data again

Azure : BizTalk Service will come soon

Hi everybody, Mick’s Breeze announce a great thing on his blog. Azure will sooner have BizTalk as an application service. Its name simply BizTalk Service. For the moment only customer who joined the preview programs can use it. I hope they deliver it as soon as possible :

biztalk service

What can we do with this service,  Mick said :

  •  a RESTful endpoint
  •  one or more transforms
  •  a RESTful exit point (or it could be a request , response)

For more information please click here

Manually purge DTA

Hi everyone, on development and validation server, I frequently got space disk issue due to DTA log size.

So, if your developpers don’t want to configure all biztalk jobs, or you forget to configure those job on validation stage please follow the next instructions :

  • Stop all BizTalk Host Instance
  • Stop IIS Server
  • Stop SSO service
  • Connect to BizTalk SQL server with SQL Server Management Studio (Run ssms)
  • In Object explorer go to BizTalkDtaDb
  • Execute Stored procedure dtasp_PurgeAllCompletedTrackingData
  • After execution, I recommend to shrink the database
  • Now check the Database size, and you’ll see that it’s empty 🙂

 

For more information please go on http://msdn.microsoft.com/en-us/library/aa561918.aspx

(Message 4035) BACKUP LOG cannot be performed because there is no current database backup

Hi everyone, last time I got a disk space issue, after purging some data and backup, I tried to run the biztalk jobs. But the DTA backup job  failed with this error

Executed as user: xxx. Processed 3233 pages for database ‘BizTalkDTADb’, file ‘BizTalkDTADb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 3233 pages in 0.400 seconds (63.133 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 2 pages for database ‘BizTalkMgmtDb’, file ‘BizTalkMgmtDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 2 pages in 0.008 seconds (1.342 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 13829 pages for database ‘BizTalkMsgBoxDb’, file ‘BizTalkMsgBoxDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 13829 pages in 1.118 seconds (96.631 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 1 pages for database ‘BizTalkRuleEngineDb’, file ‘BizTalkRuleEngineDb_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG successfully processed 1 pages in 0.022 seconds (0.044 MB/sec). [SQLSTATE 01000] (Message 3014) Processed 1 pages for database ‘SSODB’, file ‘SSODB_log’ on file 1. [SQLSTATE 01000] (Message 4035) BACKUP LOG cannot be performed because there is no current database backup. [SQLSTATE 42000] (Error 4214) BACKUP LOG is terminating abnormally. [SQLSTATE 42000] (Error 3013) BACKUP LOG successfully processed 1 pages in 0.018 seconds (0.271 MB/sec). [SQLSTATE 01000] (Error 3014). The step failed.

To summarize, the job could not find the full backup which is the reference for one day (but  does exist on disks).

Fortunately, it appends on test environnement. So I decide to clear all Backup and force the job to create a new full one. Here is the process:

  • First delete all biztalk Backup
  • Connect Sql server management studio, to  the BizTalk management Database
  • Execute the stored procedure [dbo].[sp_ForceFullBackup]
  • Next re-run the job, a newly ful backup is created

This workaround is effective, but in production environnement, you must keep an eye on the backup disk and prevent any empty space to avoid this problem.

How to handle Zombie

I’m glad to present the first release of BizTalk Zombie Management. You can find it at http://btszombiemanagement.codeplex.com/

What is BizTalk Zombie Management ?

This is a codeplex project. It proposes a solution to process zombie message after their zombified state. It’s a windows service that need to be install on each BizTalk machine.
When a zombie is raised, the service catch it and retrieve back the message. Next the message is published for a BizTalk adapter.

Here is the process flow :

When use BizTalk Zombie Management ?

A zombie message is a message that was routed to a running orchestration from the messagebox and was « in flight » when the orchestration ended. An « in flight » message is a message that has been routed to a service instance and so is in a messagebox queue destined for the service instance. Since the message can no longer be consumed by the subscribing orchestration instance, the message is suspended and marked with a ServiceInstance/State value of « Suspended (Non-resumable) ».

A zombie service instance is an instance of an orchestration which has completed while a message that was routed to the orchestration instance from the messagebox was still « in flight ». Since the orchestration instance has ended, it cannot consume the « in flight » messages and so is suspended and marked with a ServiceInstance/State value of « Suspended (Non-resumable) ».

The occurrence of zombies typically falls into one of the following categories:

Terminate control messages – The orchestration engine allows the use of control messages to cancel all currently running work in a specific orchestration instance. Since the control message immediately halts the running orchestration, zombie instances are not unexpected. A number of Human Workflow related designs tend to use this mechanism as well as some other designs.

Parallel listen receives – In this scenario the service instance waits for 1 of n messages and when it receives certain messages it does some work and terminates. If messages are received on a parallel branch just as the service instance is terminating, zombies are created.

Sequential convoys with non-deterministic endpoints – In this scenario, a master orchestration schedule is designed to handle all messages of a certain type in order to meet some type of system design requirement. These design requirements may include ordered delivery, resource dispenser, and batching. For this scenario, the tendency is to define a while loop surrounding a listen with one branch having a receive and the other having a delay shape followed by some construct which sets some variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered. Non-deterministic endpoints like this are prone to generating zombies.

(source : MSDN)

The service cover all case which generate zombie. Warning, this service does not prevent Zombie generation. It only provide a way to avoid loosing data

How does it work ?

BizTalk Zombie Management is C# service which keep an eye on BizTalk WMI table. When a zombie occur a special BizTalk event is generated and catched for processing.

For more information go to the documentation page :  http://btszombiemanagement.codeplex.com/documentation