Category nameļ¼šBizTalk 2009

Getting rid of : WCF-Custom" raised an error message. Details "System.Data.SqlClient.SqlException: Timeout expired

December 22, 2010 / Comments Off on Getting rid of : WCF-Custom" raised an error message. Details "System.Data.SqlClient.SqlException: Timeout expired

I had a nice setup in my BizTalk environment. I had 4 receive locations polling for data (in the same table) and it all boiled down to execute a stored procedure with different parameters. I used the WCF adapter with SQL bindings for that.
For some obscure reason, I would get timeouts in the eventlog. Below is a screenshot of the receive port setup I had. Only one is shown but I had four of them.

Some important things to notice:

  • PolledDataAvailablestatement, is not used cause Pollwhiledatatfound = false. But you still have to put stuff in there to make things work.
  • Execute a specific sproc, with the number of records you want to receive as a parameter.
  • UseAmbientTransaction, no, no,no, had too many problems in the past when using msdtc and receive locations (locks and stuff) so this is a NO.
  • ReceiveTimeout is set to 10 minutes. This is a bit long but i never touched that value, it’s the default.

To make things a little bit more clear, The stored procedure I used looks looked like this :

 CREATE PROCEDURE [dbo].[Get_TeVertalen_Berichten]
(
 @MaximumAantal INT = NULL
)
AS
BEGIN
 EXEC [dbo].[Get_Berichten_Internal]
  @MaximumAantalInternal = @MaximumAantal,
  @OudeBerichtStatus = ‘TeVertalen’,
  @NieuweBerichtStatus = ‘VertalenGestart’,
  @Richting  = ‘Ingaand’  
END

And here is the code of Get_Berichten_Internal:

CREATE PROCEDURE [dbo].[Get_Berichten_Internal]
(
 @MaximumAantalInternal INT = 15,
 @OudeBerichtStatus  VARCHAR(200),
 @NieuweBerichtStatus VARCHAR(200),
 @Richting    VARCHAR(20) 
)
AS
BEGIN
 BEGIN TRY
  — Declare variables
  DECLARE @AFFECTED_KEYS TABLE
  (
   BerichtID NUMERIC(18, 0)
  )
  DECLARE @AFFECTED_ROWS INT
   — Some sets needed
  SET NOCOUNT ON
  — Perform the update statement and capture all the keys
  UPDATE
   TOP (@MaximumAantalInternal) dbo.tb_Bericht
  SET  
   BerichtStatus = @NieuweBerichtStatus
  OUTPUT
   INSERTED.BerichtID
  INTO
   @AFFECTED_KEYS
  WHERE
   BerichtStatus = @OudeBerichtStatus
  AND
   ExternBerichtTypeID IS NOT NULL
  AND
   InternBerichtTypeID IS NOT NULL
  AND
   Richting = @Richting
  — DO STUFF WITH THE AFFECTED KEYS
  <– SNIP–>
 END TRY
END

Now everything looks good and in the query analyzer everything was working blazingly fast. But I started to see the following message in the eventlog every 10 minutes (hmm that’s the receive timeout).  And sometimes several (four to be exactly) of them within a very short period of time.

Event Type: Warning
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5740
Date:  14-12-2010
Time:  10:47:07
User:  N/A
Computer: BA34T
Description:
The adapter “WCF-Custom” raised an error message. Details “System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
   at Microsoft.ServiceModel.Channels.Common.Design.AdapterAsyncResult.End()
   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterInputChannel.EndTryReceive(IAsyncResult result, Message& message)
   at System.ServiceModel.Dispatcher.InputChannelBinder.EndTryReceive(IAsyncResult result, RequestContext& requestContext)
   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.EndTryReceive(IAsyncResult result, RequestContext& requestContext)”.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

And once this message started to appear, stuff went downhill from there on. I could see in the profiler that stored procedures were taking ages, and even simple updates of a single record would take thirty seconds or so. Lock-Time-outs and deadlocks were occuring on a very regular basis. Even though the receive locations werent receiving any data. So nothing was received and I still got may daily portion of errors/warnings/suspended stuff in BizTalk because of this.
So basically it looked like I was having some kind of locking problem even if no work was done by the second stored procedure. But the second procedure did an update (even when there was nothing to update) and maybe that triggered the nasty behaviour.

I started a discusiion on MSDN to see if anybody could help : <<See here>>

 But eventually i cghanged something to make this behaviour go away. The idea was only to perform the update when there was stuff to update. So i changed the first procedure to :

CREATE PROCEDURE [dbo].[Get_TeVertalen_Berichten]
(
   @MaximumAantal INT = NULL
)
AS
BEGIN
 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
 DECLARE @Aantal int
 SELECT
  @Aantal=count(*)
 FROM
  dbo.tb_Bericht WITH (NOLOCK)
 WHERE
  BerichtStatus = ‘TeVertalen’
 AND
  ExternBerichtTypeID IS NOT NULL
 AND
  InternBerichtTypeID IS NOT NULL
 AND
  Richting = ‘Ingaand’
 IF @Aantal > 0
 BEGIN
  EXEC [dbo].[Get_Berichten_Internal]
    @MaximumAantalInternal = @MaximumAantal,
    @OudeBerichtStatus  = ‘TeVertalen’,
    @NieuweBerichtStatus = ‘VertalenGestart’,
    @Richting    = ‘Ingaand’  
 END 
END

 And by first checking if there was any work to do and only then do an update, I got rid of the deadlocks and the errors in the eventlog.
I really don’t know why this solved it, but my guess is there is some bug in the WCF adapters, that go wrong if you start a transaction but return no data.

Everything is running smooth now and I hope this post will help somebody experiencing the same problems.

No longer Copy Local That Biztalk Reference !!!!!!!

January 25, 2010 / Comments Off on No longer Copy Local That Biztalk Reference !!!!!!!

On monday 19 january I gave a presentation to the dutch BizTalk User Group (BTUG) about he BizTalk Best Practices. The Best Practices are a set of components, a loosly coupled architecture and a software factory that supports the components and the architecture.

The presentation went very well and for sure I had to demo something. And while i was demoing i had a lot of trouble with the references. Normally i don’t have these problems during a demo cause then i build the complete solution in about half an hour. (including deployment & stuff). But this time I had only 10 minutes to demo, so i had set up some stuff (and tested) in pre set up projects….

But then i got red circles everywhere in my orchestrations. This was cause by the problem described excellent in this post : “Copy Local That BizTalk Reference” by Pim Waaijenberg.

Then today I read my rss feeds in BlogLines (great web based reader) feeds and there I saw this post : Hotfix for BizTalk 2009 and Visual Studio 2008 issues released.

So it seems my demo came just a few days too early…(or this fix was a few days too late !).

Anyway it seems the problemis solved.

 [edit]

I saw my BizTalk Collegue Jean Paul Smit already blogged about this. He was not able to sit through the whole BTUG meeting so i don’t know if he saw me with this problem. He has a nice entry about it explaing what is solved. Have a read of his post here : http://bloggingabout.net/blogs/jpsmit/archive/2010/01/25/hotfix-for-biztalk-server-2009-development-environment.aspx

Ugly….. Xsd Import causes DummyVar warnings during compile time in BizTalk *UGLY*

September 8, 2009 / Comments Off on Ugly….. Xsd Import causes DummyVar warnings during compile time in BizTalk *UGLY*

I am busy creating a BizTalk Software factory for BizTalk 2009.

So instead of going through all kinds of repeatable steps,

  1. enter data,
  2. do some more stuff,
  3. add pesky references
  4. do more stuff,
  5. add a map,
  6. add another map,
  7. add an orchestration,
  8. Start from step 2 again

I have those steps nicely put into a wizard. You enter data once and a complete orchestration with maps is generated. Very nice indeed.
Everything works fine but you have to look very carefully into all kind of compile errors.
So during compilation of my testproject I saw some very ugly warnings….

Warning cs0169: The field BlaBlaBla__DummyVar0 is never used.
Warning cs0169: The field BlaBlaBla__DummyVar1 is never used.
Warning cs0169: The field BlaBlaBla__DummyVar2 is never used.
Warning cs0169: The field BlaBlaBla__DummyVar3 is never used.
Warning cs0169: The field BlaBlaBla__DummyVar4 is never used.

I was curious about this Warning and didn’t know if it was caused by my software Factory or was just default behaviour.
So I started to investigate. And the results are pretty UGLY

You will get one of those DummyVar warning for every schema that is included in your current Schema !

Microsoft this is plain UGLY….

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta