In one of our internal web app's developement, we were executing an console applications with certain arguments synchronously and were trying to display the results in the front-end.

When we activate the process I can see the process getting kicked-off in the task manager and it never exits, after a time period (IIS timeout setting), the web app times out.

At the end we figured out, the reason is due to an dead lock condition between the parent process (w3wp) and the child process(console app).

Synchronous read operations introduce a dependency between the caller reading from the StandardOutput stream and the child process writing to that stream. These dependencies can result in deadlock conditions. When the caller reads from the redirected stream of a child process, it is dependent on the child. The caller waits on the read operation until the child writes to the stream or closes the stream. When the child process writes enough data to fill its redirected stream, it is dependent on the parent. The child process waits on the next write operation until the parent reads from the full stream or closes the stream. The deadlock condition results when the caller and child process wait on each other to complete an operation, and neither can proceed.

Solution is really simple, look at the code snippet below.

// Start the child process.
Process p = new Process();
// Redirect the output stream of the child process.
p.StartInfo.UseShellExecute = false;
p.StartInfo.RedirectStandardOutput = true;
p.StartInfo.FileName = "Write500Lines.exe";
p.Start();
// Do not wait for the child process to exit before
// reading to the end of its redirected stream.
// p.WaitForExit();
// Read the output stream first and then wait.
string output = p.StandardOutput.ReadToEnd();
p.WaitForExit();

BTW, most of explanation is from MSDN, but it took me a while to figure out.

Labels: .NET

One of the feature I anticipated in SQL 2005 management studio was some kind of Intellisense when you type the queries. But, surprisingly there was no support for it.

Red Gate software came with a very cleaner solution, a single application which supports SQL intellisense on QueryAnalyser, Enterprise manager, Management Studio, VS 2003, VS 2005, UltraEdit and Editplus2.

My favorite feature is SQL Snippet, similar to VS 2005 code snippet concept. Just type
“SSF” on the query analyser, which translates to “SELECT * FROM “ awesome. You can add your own snippets, this will definitely make life easier for some developers/DBA's.

Labels: blagging

We all know the problems we had with gotdotnet and people tend to move their open source projects to SourceForge. Here is the reply from Microsoft towards open source community CodePlex.

As I mentioned in my previous post Microsoft launched a new portal to know about the people, insights, and analysis from the Microsoft Open Source Software Lab.

It clearly shows Microsoft positive approach towards open source community, big applause for the guys over there who made it happen.

I already contacted James Newkirk to bring my SQL Service Broker Management studio 2005 project into open source community, since CodePlex is in BETA now, you cannot add projects directly.

Labels: blagging

The orchestration engine persists the entire state of a running orchestration instance at various points, so that the instance can later be completely restored in memory.

The state includes
1. The internal state of the engine, including its current progress.
2. The state of any .NET components that maintain state information and are being used by the orchestration.
3. Message and variable values.

Persistence Points
The orchestration engine saves the state of a running orchestration instance at various points. If it needs to rehydrate the orchestration instance, start up from a controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration instance from the last persistence point, as though nothing else had occurred. For example, if a message is received but there is an unexpected shutdown before state can be saved, the engine will not record that it has received the message, and will receive it again upon restarting. The engine will save the state in the following circumstances:

1. The end of a transactional scope is reached.
The engine saves state at the end of a transactional scope so that the point at which the orchestration should resume is defined unambiguously, and so that compensation can be carried out correctly if necessary.

The orchestration will continue to run from the end of the scope if persistence was successful; otherwise, the appropriate exception handler will be invoked.

If the scope is transactional and atomic, the engine will save state within that scope.

If the scope is transactional and long-running, the engine will generate a new transaction and persist the complete state of the runtime.

2.A debugging breakpoint is reached.

3. A message is sent. The only exception to this is when a message is sent from within an atomic transaction scope.

4. The orchestration starts another orchestration asynchronously, as with the Start Orchestration shape.

5. The orchestration instance is suspended.

6. The system shuts down under controlled conditions. Note that this does not include abnormal termination; in that case, when the engine next runs, it will resume the orchestration instance from the last persistence point that occurred before the shutdown.

7. The engine determines that the instance should be dehydrated.

8.The orchestration instance is finished.

Serialization
All object instances that your orchestraion refers to directly or indirectly (as through other objects) must be serializable for your orchestration state to be persisted. There are two exceptions:

1. You can have a nonserializable object declared inside an atomic transaction. You can do this because atomic scopes do not contain persistence points.
2. System.Xml.XmlDocument is not a serializable class; it is handled as a special case and can be used anywhere.

Caution In order for a .NET object to be persisted, it must be marked as serializable.

COM Objects
COM objects cannot be persisted using standard .NET serialization procedures. If you want to call a COM object outside of an atomic transaction, you must wrap the COM object in a .NET object that is .NET serializable and knows how to persist and restore the state of the COM object.

Labels: BIZTALK

Microsoft opened a new blog site port25.technet.com to bring the people, insights, and analysis from the Microsoft Open Source Software Lab.

Labels: blagging

Do you think you can use BTSDeploy on a remote BiztalkMgmtDb database server?

I thought it will after looking at its parameter list, it takes a database server name and managment database name and an XML port configuration file as arguments. So, it sounded very normal for me to take it for granted we can IMPORT/EXPORT stuff into remote Biztalk server (or groups) using the BTSDEPLOY command.

Example:
BTSDEPLOY EXPORT SERVER=ACCD12WS229 DATABASE=BiztalkMgmtDb BINDING=c:\ports.xml UNBOUNDPORTS

We architected everything based on this assumption.The idea of our project is to control multiple biztalk environments (groups) from a single web application. The project I'm working on is relatively of big scale where we have around 10 different Biztalk server groups each with 4 Biztalk servers + all those additional SQL servers, Clusters blau, blau.

As a developer I was working on my workstation specifying my local workstation name as server and BiztalkMgmtDb as database parameter. For quite long time we didn't hit any problems. Once in a while we connected to some other developer boxes remotely to do some testing and everything worked seamlessly. (Yes! it worked seamlessly connecting to a remote biztalk server).

Hang on before you start cursing, why is this post then?!! All our problems started when we deployed our solution into the module testing environment. Suddenly we saw this error comming up

Access Denied. Microsoft.Adapter..WSE.dll

There are so many attributes which can go wrong and produce this error, some of them we considered.
1. It's a ASP.NET web applicaiton, so some of the credentials may not be correct. (We used application pool running under specified Biztalk account).
2. You are accessing a remote Biztalk Database server, where some SSO bits involved. So, again some credentials may not be correct.
3. There could be some problem in MSDTC between the ASP.NET server and reomote DB server

etc,etc...we can think of so many attributes because of the distributed nature of Biztalk itself and thing what we were trying to achive.

Luckily, this error popped up on one of the developer box as well, where he was using one of our inbuild custom adapters. Then we came to a conclusion, this problem occurs only for biztalk servers(groups) where some custom adapters are deployed (BTW, WSE adapter is also an addon adapter on top of Biztalk base build).

If you deploy the same adapter in the main server** and run the command against a remote server, it IMPORTED/EXPORTED successfully. Wow! so what's going on underneath the scene.

Here you go. Thanks to Microsoft folks Angus foreman and his upline MS staff at Redmond for making us understand what going on beneath the scene.

When you EXPORT configuration from BiztalkMgmtDb, the result set comes as a big blob data to the main Biztalk Server** in an encrypted form. Then the main server** parse the result with the help of adapters deployed in the main server**, from where it gets all the design time parameters of the adapters from the registry and generates the output port configuration xml file. If the adapters are not present in the main server** but the data is present in the blob then there is a mismatch and BTSDEPLOY throws Access denied error. We wouldn't have found out this error or the functionality behind if there were no custom adapters.

Then, we did some work around to fix the problem, using web services and stuff. Huh! this post is already to long.

**(from where the BTSDEPLOY command is executed)

Labels: BIZTALK