The Code Whisperer

Get around the NServiceBus 1-Thread limitation

2011-11-28T16:01:00.001+02:00

You may know that NServicebus has a commercial version that has 5 threads on which it processes incoming messages. The non-commercial version has the limitation that it only has one thread on which incoming messages are processed.
Well, thanks to tasks in .Net 4.0, I've found a very cool way of overcoming this limitation...

Instead of the following usual message handler code...
public class MessageHandler : NServiceBus.IMessageHandler {

  public void Handle(MyMessageType message) {

//Code here to execute the work

...which requires the complete code that is executing the work to finish before NServiceBus can process the next message...

rather use a System.Threading.Task to execute the work, as follows:

public class MessageHandler : NServiceBus.IMessageHandler {
  public void Handle(MyMessageType message) {
Task myTask = new Task(()=> {
//Code here to execute the work
});
myTask.Start();
}
}

As soon as the task is started, the NServiceBus worker thread is immediately freed up to process the next message,

irrespective of how long the task actually takes to execute!

Happy coding!

Timeout on Web Service Calls

2011-09-02T11:19:00.001+02:00

Having a problem with your web service calls timing out?

Your WebServiceClass inherits from System.Web.Service.Protocols.WebClientProtocol.
This class is where the Timout property sits.
The default value is 100000 ms.

What you need to do is cast your WebServiceClass instance to (WebClientProtocol) and set the Timeout property. So if you wanted to set the timeout to 5 minutes:

c#:
using System.Web.Services.Protocols;
...
((WebClientProtocol)myWSClass).Timeout = 300000;
...

VB.Net
Imports System.Web.Services.Protocols
...
DirectCast(myWSClass, WebClientProtocol).Timeout = 300000
...

WCF Findings on Concurrency, InstanceContext and SessionMode

2010-08-25T09:41:00.001+02:00

I built me a little app to demo the effects of WCF InstanceContextMode, ConcurrencyMode and Sessions.

Interesting findings...
SessionMode: You define this on the ServiceContract Interface. Options are Allowed, Required, NotRequired. The default is Allowed, meaning that if you use a binding that supports sessions (seems to be all of them except BasicHttpBinding - but I still have to confirm this), a session will be established for the duration of the client proxy. When using a binding that does NOT support sessions, no Session is established; unless you go and set this to Required, in which case an exception will be thrown. Now the purpose of a Session is to establish one instance of your service class to handle all calls made to it for the duration of the Session (I assume a session ends when you dispose your client proxy). Here is a link to a very good example of why one would want to do this: http://msdn.microsoft.com/en-us/library/ms751429.aspx
The documentation states that in a Session, calls are processed in the order in which they are received. Turns out that they can be received in a different order than they were sent though...my app showed the client sending call 1, 2, 3, n...but the serviced showed the processing order being 2, 1, 3, n. Interesting.

On to InstanceContextMode: This defines how many InstanceContext objects (and therefore instances of your ServiceClass) are created by the WCF runtime.

The default InstanceContextMode is PerSession, but this only applies if you use a binding that supports Sessions. Using a binding that does NOT support sessions results in InstanceContextMode = PerCall. PerCall means a new InstanceContext (and thus a new instance of your ServiceClass) is instantiated for each call made to any operation of your service. If you set this to Single, then a single InstanceContext (and thus a single instance of your Serviceclass) is instantiated by the WCF Runtime the first time a call to an operation is made. And this single instance lives until the servicehost is disposed (though I think there is a timeout as well that controls the lifetime of this service ... no point keeping it around if it is not being called by anybody...poor soul)
ConcurrencyMode: The default is Single, and it controls whether or not multiple threads can process calls to your service. Now when the InstanceContextMode is PerCall, the ConcurrencyMode means nothing, as each call is being handled by a single instance of your ServiceClass – and that instance is disposed after servicing the call for which it was instantiated. Even so, it seems that there is a default limit (of 32) to how many calls can be in progress to a given ServiceHost in total before blocking any subsequent calls. When 32 calls are in progress, subsequent calls are blocked until one of the existing calls completes (figuring out how to change this is on my TODO list). (I read here http://weblogs.asp.net/paolopia/archive/2008/03/23/wcf-configuration-default-limits-concurrency-and-scalability.aspx that this limit is 16. I’m using a dual core machine...perhaps that is why the limit I’m encountering is double that?)
Anyway, now when a Session is established (ie, InstanceContextMode = PerSession) (though remember that this requires a binding that supports sessions), or InstanceContextMode = Single, this default ConcurrencyMode of Single has a very clear effect – only one call to the service is handled at a time. All subsequent calls are blocked until the call being processed completes.

(I was hoping to be able to use the PerformanceCounters to figure out how many calls are queued, but that seems to be a finding for another post. The ServiceModel Counter called OustandingCalls indicates the number of calls in progress, and not the number of calls that are blocked...waiting to be processed.)

Now by changing the ConcurrencyMode to Multiple, you are telling the WCF runtime to allow multiple threads to process calls made to your InstanceContext.PerSession or InstanceContext.Single service. Doing this allows multiple calls to be processed at a time by different threads, seemingly again up to the limit of 32 encountered above, at which point further calls are blocked. However, if you do this, you need to ensure that your service operations are thread safe...and that is a topic for another post...suffice to say that if you steer clear of service-level variables (and have the service operation deal only with variables declared within the operation), you’re on a good track to being threadsafe...

DOING is the best way to learn

2009-05-07T10:36:00.000+02:00

I've been wanting to build a production app using WPF but have been putting it off and off for fear of the unknown. I've been reading through books and blogs, viewing webcasts and listening to podcasts related to WPF for about a YEAR now!
Finally I came to a point of putting all the theoretical knowledge gained on the subject into practice...I rolled up my sleeves and started building my first real-life application using WPF (and Prism 2 btw) ...
...and was shocked at the number of brick walls I kept bumping into!!!
Man it felt as if I knew NOTHING! Despite the months of theoretical prepping!

But boy did I learn! In the first week of building the app I've definitely learnt a LOT more about WPF than in all the months of reading!

So a bit of advice for you who fear to tread where your brain has not yet gone before...JUST DO IT! There is no better way to learn! Don't waste too much time just reading...DOING is when you learn the most!!

Install a Windows Service WITHOUT having to use InstallUtil

2008-09-23T15:11:00.000+02:00

After much searching for this myself, I'm adding this blog in the hope of making such a search simpler for others...
Problem:
In Visual Studio, you create a Deployment project for a Windows Service project. You build and install the Deployment project. Then you go look at the list of services, and your service ain't there! You still need to run the InstallUtil utility to install the Service to the Windows Services.

Solution:
You need to add custom actions to your Deployment Project. In Visual Studio, right click on the Deployment Project, and select View --> Custom Actions. For each of the Install, Commit, Rollback and Uninstall nodes, you need to add "Primary Output from [Service Project]".
When this is done, rebuild and Install the Deployment project.

This time, the service is added to the list of Windows Services. If it still ain't there, I can only imagine that you have not added a ProjectInstaller to your Windows Service Project. (Open the designer for the [Service].vb file, right click on the design surface, and select the option to add an installer. Once this is done, each of the created components will have properties that you can set that relate to how your service deploys itself)
And if after doing all this you still don't have a service listed in the Windows Services, I really cannot help you... ;-)

Shawninator? ...and other nicknames

2007-12-03T09:35:00.000+02:00

Well this was a nickname given to me by my developer colleagues. I developed a Code Generator for use in standardising the development we do at my place of work. My colleagues loved it, and started referring to it as "The Shawninator"...this name eventually got used in referring to me whenever I came up with a cool idea in architecting a solution to a development problem...and it seems to have stuck; and I don't mind...its been my first nickname since high school...
...when I was Cyborg. My buddy Sydney Ashmead and I were totally swept away by the Top Gun wave back in '86, '87. We decided we just HAD to have call-signs...he took "Maverick" from the lead character, and I, wanting to be original, declared myself "Cyborg". We referred to each other only by these names right through high school. (Sigh!, thinking back to those days...) I even remember him mentioning how they were making a movie of me when the Jean-Claude van Damme movie (remember ?) came out...and I remember thinking how people would now not think that I was original anymore in my call-sign, and that I took it from the movie...but let the record show, my call-sign was FIRST!

In the beginning...

2007-11-17T09:23:00.000+02:00

...the Shawninator created his blog.
I have no idea yet where I'm gonna go with this, or why I really started it. I have never been any good at expressing myself anyway...verbally (and my beautiful wife will testify to that :-) ) or in the written word...but lets see...