Chris Patterson - Los Techies - Latest Comments

Re: Implementing Routing Slip with MassTransit

Guillaume Schuermans — Mon, 06 May 2013 03:30:34 -0000

I would benefit from a meaningful problem domain as well to understand
this a little better.

After a year of experimenting with mainly
NServiceBus (and a little bit of MassTransit) I am currently laying the
foundations to refactor some of our older logic to use a MessageBus.
However depending on the content of the message there will be a
different flow with some steps that are shared, others are not.

All flows are cross bounded contexts and therefor my assumption is a messagebus can be of great benefit. This courier extension seems to provide something like an ad hoc workflow control in messagehandling. Did I understand the article correctly?

Re: Implementing Routing Slip with MassTransit

Chris Patterson — Mon, 01 Apr 2013 11:58:24 -0000

It will take me a few days to write it up, but yes.

The domain is an end-user and support configurable solution where the tight coupling of services to events and reactions is not feasible due to the time required to change code/behavior. In a system with thousands of message flows, each of which can opt-in to and/or change the order of service invocation in which changes are effective immediately, it's not practical to require code changes to handle service orchestration.

All of the routing slips are built by a router, which based on the message content selects the appropriate path through the system.

Re: Implementing Routing Slip with MassTransit

udidahan — Fri, 29 Mar 2013 15:58:24 -0000

Can you give a more meaningful problem domain to illustrate this? A simple sequence can be much better handled by having one service do step 1, publish an event, which goes to another service, which does step 2 and publishes another event, going on to another service, etc.

Re: Odoyule Rules Engine for .NET

R Programmer — Sat, 26 Jan 2013 13:51:32 -0000

I downloaded the code and when I attempt to compile it, the reference for Internals.Extentions and Internals.Reflection is missing. I have been unable to locate the assembly. PLease advise.
Thanks.

Re: IDisposable, Done Right

Jonathan C Dickinson — Tue, 22 Jan 2013 03:50:48 -0000

Did you read the comment?

Firstly, if your library is being consumed by a 3rd party you can't guarantee that your best practices are being adhered to. There are bad programmers out there.
If your library is not being consumed by a 3rd party you can't guarantee that your best practices are being adhered to, especially in threaded situations. Good programmers make mistakes.Throwing an ObjectDisposedException is better than double-disposing in absolutely every situation. Rolled back that transaction twice? "Yeah, but the controlling thread was in charge of disposing that object." Try telling that to a customer who just lost millions to a bug that is easily avoided by simply not using a `bool`. At the very least it's a lot more explanatory than a FileNotFoundException in a bug report.I don't put hypothetical walls up around myself, I put up real barriers - and you are irresponsible if you don't because there is a massive difference between what you should do and what could happen.

Re: IDisposable, Done Right

kamranayub — Thu, 27 Dec 2012 12:34:03 -0000

This is important, and this is a great tip! When I pulled down the latest ActionMailer.Net library from Nuget, I started getting StackOverflowExceptions. Turns out, they didn't implement IDisposable correctly. I created a pull-request that fixes the issue, but in retrospect, I still missed some tips brought up in this article.

Thanks for sharing.

Re: IDisposable, Done Right

Shmueli Englard — Wed, 26 Dec 2012 15:38:36 -0000

What do you think of http://dave-black.blogspot.com... I've been using it as my template

Re: Odoyule Rules Engine for .NET

Jophez — Thu, 20 Dec 2012 03:14:36 -0000

any sample codes i can use? newbie here.... :)

Re: IDisposable, Done Right

Mark Lindell — Wed, 05 Dec 2012 11:49:05 -0000

That's awesome... hey, wait a minute...

Re: IDisposable, Done Right

MasaSam — Tue, 04 Dec 2012 13:40:08 -0000

Good article. Only thing I've noticed to other dispose advice articles I have read is that the sample implementation here sets the private _disposed field to true when disposing has done. Some other articles advices to set, and what I usually do, to set the field true right after it is checked in the beginning of protected Dispose method to prevent entering the disposing lines twice.

Re: IDisposable, Done Right

RaptorXP — Tue, 04 Dec 2012 10:02:58 -0000

Hmm yeah, I agree with previous comments. The suggestion in this post is only valid when you want to dispose of unmanaged resources. I can tell you that in 6 years working with .NET, I *NEVER* had to deal with unmanaged resources from .NET.

It is actually harmful to follow this recommendation if you don't have unmanaged resources because implementing a finalizer in a class automatically promotes the object to Gen 2, and you'll end up with poor GC performance.

Re: IDisposable, Done Right

Chris Patterson — Tue, 04 Dec 2012 09:26:08 -0000

If you are using any third-party library (including most of the .NET runtime, such as WCF and others) there no way you can achieve this "catch-free" system. If there is nothing the calling method can do about the exception (other than explode in a spectacular fashion) - why bother throwing the exception. Sometimes, RPC calls and the like just don't end in a happy place, and that's often just fine. Not to mention that so many people call Dispose in a catch block or finally block, without a try/catch around it, which can lead to entire application crashes.

Which sucks at 2am in a production 24x7 system. Plan for failure, and deal with it in the code so you can sleep at night.

Re: IDisposable, Done Right

Chris Patterson — Tue, 04 Dec 2012 09:22:46 -0000

If multiple threads are sharing a disposable resource, a parent or other thread should be responsible for disposing of it once the consuming threads have exited. Otherwise, a thread could dispose of something that another thread might still be using.

Re: IDisposable, Done Right

Chris Patterson — Tue, 04 Dec 2012 09:18:10 -0000

Both classes have their own private _disposed, so no problem there.

Re: IDisposable, Done Right

fflams — Tue, 04 Dec 2012 06:03:58 -0000

This is a good article for beginner developpers, however you should check your example.
When explaining how a derived class should override the Dispose(bool) method, you have it set the _disposed falg to true before calling the base.Dispose, that will result in the base class not doing its dispose job and simply setting object references to null....

Re: IDisposable, Done Right

jer0enh — Tue, 04 Dec 2012 04:13:47 -0000

(I meant to say skim through part II of the article which offers some simple advice that greatly simplifies the implementation of IDisposable resources)

Re: IDisposable, Done Right

jer0enh — Tue, 04 Dec 2012 04:08:02 -0000

Of course it is, I'm not arguing with that. We need deterministic disposal and obviously in some cases the full dispose pattern as you describe it is warranted. However, implementing this full pattern by default on every class that implements IDisposable hurts readability and as others also have said, a Finalizer is almost never needed and can actually introduce other (performance) issues. Please at least skim through the article on codeproject I linked to, it's well worth a read.

Re: IDisposable, Done Right

Steve Walsh — Tue, 04 Dec 2012 02:32:02 -0000

Good observation (I hope!). The scary thing is that I know quite a few devs who would write that sort of code and make that sort of comments...

Re: IDisposable, Done Right

Evil Exception — Mon, 03 Dec 2012 22:05:23 -0000

Swallowing exceptions in the dispose method or finalizer is arguably more dangerous than having the application crash since it can leave your application in an undefined state. I dis-recommend against the advice given in this article. An exception should be an exception and therefore you should do all in your power for preventing Exceptions in the first place and if one is detected, build in the right control flow for preventing that exception from ever happening. Ideally, your application should have no catch blocks.

Re: IDisposable, Done Right

Sergey — Mon, 03 Dec 2012 17:16:39 -0000

This is scary, I pity people working with you... Continue writing vague, performance-hitting and hard-to-read code. And conveying it with such vanity...

Re: IDisposable, Done Right

Tec Goblin — Mon, 03 Dec 2012 16:24:32 -0000

"I can't believe you are seriously suggesting that someone write LESS code." I try to understand if this is sarcasm or not.

Re: IDisposable, Done Right

Chris Patterson — Mon, 03 Dec 2012 15:02:23 -0000

DisposableClass and SubDisposableClass both have their own _disposed flag, so it should be fine. Glad you enjoyed the article - be sure to read all the comments as well!

Re: IDisposable, Done Right

Corey — Mon, 03 Dec 2012 14:30:59 -0000

Awesome article, details all the potential pitfalls of implementing IDisposable. I noticed a smallmistake and I wanted to point it out in case someone accidentally incorporates it in their project:SubDisposableClass.Dispose sets _disposed to true before calling the baseclass implementation of Dispose. This will result in the cleanup logic in the base class neverbeing executed (since _disposed will already be set to true).

Re: IDisposable, Done Right

Jonathan C Dickinson — Mon, 03 Dec 2012 13:24:18 -0000

I agree with peterritchie. Only implement the finalizer if you directly control unmanaged resources (which you should **NEVER EVER** be directly controlling anyway, see SafeHandle (http://msdn.microsoft.com/en-u... ), or obscure scenarios like temporary files.

The reason it is important is because of the finalizer queue (http://msdn.microsoft.com/en-u... ). The GC needs to iterate over this thing every time it does a pass. Filling it up with junk that doesn't need to be there isn't a good idea.However, you should always provide Dispose(bool) as your inheritors might find they need a finalizer (you don't need one because you know that you should be using SafeHandle).

Your code is also susceptible to a race condition, you could be double-disposed in threaded scenarios. Considering that the thread-safe code is shorter it makes more sense to always do it that way.

Basically, you are looking for this: https://gist.github.com/419687...

Edit: Note that in .Net even if you are not using threads there is the 'virtual thread' that the GC imposes (the GC can interrupt your code wherever it pleases), even if there wasn't a finalizer thread. This means that if you don't use the interlocked route you are susceptible to double-dispose.

Re: IDisposable, Done Right

Hmmm — Sun, 02 Dec 2012 12:07:20 -0000

I think you might have been lured by a troll. AstroArch, as in Astronaut Architect? I think AstroArch is having a joke of it. Kind of funny, IMO, assuming it is a joke.