Messaging Update

Seems more multithreading was the culprit.

with on thread one:
lock (dictionary) { dictionary.Add("bum", "a homeless person");}

and seven seconds later on another thread:
lock (dictionary) { if (dictionary.Contains("bum")) C.Out("defined"); }

... Contains returned false!

FTW??

... or was it IIS.

*** UPDATE Sept 16 ***

It was IIS. After adding tons of logging and tracking thread IDs, app domain IDs and process IDs, it was apparent that IIS would load up more than 1 either app domain or process for the app.

The long term solution was to house the app in a windows service that communicated over WCF. It was a quick refactor and opens the door for using WCF to push to clients. The new question is, does WCF hold threads? Or can you have 100,000 seldomly active clients for, say, a chat application?

Don't Give Up on Messaging

Today at work the dreaded words were uttered: "Well if it's not working by the end of the day lets just go for the pull every 1 second solution."

After implementing all of the long running processes to a pub/sub model, it was not pleasant to hear that. I wasn't going to just give up on that much energy poured into the current (and best) approach.

After adding tons of logging and hammering the server to see where the leaks sprung up, I cornered the culprit. If you are pulling from MSMQ ad nauseum, and you are in a multithreaded environment, you need to protect yourself from the thread unsafe methods "Send" and "Receive" on your MSMQ object - usually done by creating the MSMQ object for just long enough to do 1 operation.

The place where this was being done was not a multithreaded scenario, so I got rid of the creation and disposal of the MSMQ object between receives.

That did it.

The other lesson here is to be careful when you do have a multithreaded app pulling from MSMQ. You may see same messages go missing. I know there are other MSMQ features that guarantee delivery, etc, but I expect this integrity out-of-the-box.

Alt.NET Canada

Too bad I had to miss this due to work. Here is Greg Young's Domain Driven Design presentation:

Project Management and Command/Query Separation

Just like we have issues mixing command and query when writing software, we run into similar issues when it comes to project management.

Say you have a project manager that is very technical. You would think that you could do no better. But alas, you will have bottlenecked his potential by requiring him to service the "queries" he has to provide for management (such as status reports, etc).

In the opposite corner, you can have a non-technical PM giving "commands" to the developers without the proper knowledge of the consequences of his actions.

Even in the well balanced scenario, you can overload a PM with a week or more worth of "queries"... or ask for too much direction.

So, can you scale your PM? If the role is clearly defined and we have a separation of command and query, yes you can.

Thoughts?

DDD and the Too Many Aggregate Roots Design Smell

This usually comes about from forcing a DDD solution where one would really needs a simple forms over data type app with ORM thrown in for speed.

Don't even bother with TDD for the most part.

Thoughts?