Page 1 of 1
Posted: Fri Apr 09, 2010 3:45 pm
by Malcolm
Anyone fucked around with this?
Posted: Fri Apr 09, 2010 5:15 pm
by thibodeaux
Yep, we use it all the time.
Posted: Fri Apr 09, 2010 5:19 pm
by Malcolm
How's it performing? We're about to rip out our entire middle layer & do our service orchestration with it, and 95% of the dev team has zero experience with it. The dude in charge of it is definitely in the majority & will need massive support from the minority.
Edited By Malcolm on 1270847999
Posted: Fri Apr 09, 2010 8:33 pm
by thibodeaux
Seems to do OK. We run massive amounts of small messages through it. What kind of performance do you need? I don't know how much orchestration you think it does. They way we use it, it's pretty much just a queue. Any orchestration is done by our code.
Speaking of orchestration, I would recommend NOT using Windows Workflow Foundation.
Posted: Fri Apr 09, 2010 8:41 pm
by thibodeaux
I should add that while I've worked with MSMQ for nigh on 10 years now, I haven't touched any of the code that actually talks to the queue. One of our devs wrote a wrapper for that, and we just use the wrapper. We have a pretty neat service architecture. I'll give a thumbnail sketch.
Let's say you want a new thing that queries Amazon's API: you give it a UPC and it gives you back something like the title. But you're going to have a bazillion of these searches and you can't slam 'em all at Amazon at once because they throttle you. So you're going to queue them. Here's what we do.
1. Create your MSMQ
2. Write your code that talks to Amazon, and have it called by a function that implements some interface that we've defined. The inputs come in via a generic dictionary, ditto the outputs.
3. Now you configure your service by associating that code from step 2 with the queue in step 1. We've got a database for this. Your code will now run as a Windows NT Service on our "cloud" on as many servers, with as many threads, as you specify (remember, throttling is important, so sometimes you only define a few threads).
That's it. Any code that wants to send work to this new service just calls into our wrapper class with the dictionary of inputs, plus the database row ID from step 3, and a message automatically goes into the msmq. We also have the message go into a database for retrying, logging, etc.
We can also have arbitrary database query results become messages into the queue, which is really cool for running things on a schedule.
Posted: Sat Apr 10, 2010 4:02 pm
by Malcolm
The worrisome part is that the dude who's in charge of this endeavour is slightly dimmer than a supermassive black hole. I anticipate the orchestration being a complete clusterfuck. & he's also going to have to deal with writing the lock manager.
Sounds like it's slick once it's up & running, though.
Posted: Sat Apr 10, 2010 6:46 pm
by thibodeaux
Works for us. YMMV.
Keep in mind that we wrote all that stuff ourselves. MSMQ is just for queueing up the messages.
Edited By thibodeaux on 1270939621
Posted: Mon Apr 12, 2010 11:05 am
by Malcolm
thibodeaux wrote:Speaking of orchestration, I would recommend NOT using Windows Workflow Foundation.
That's the initial plan, from what I hear. How do I convince them otherwise? I either need some authoritative document or some form of example for proof.
Posted: Mon Apr 12, 2010 1:38 pm
by thibodeaux
I got nothin but my own experience. It's just...painful to use. And I don't see the upside. Perhaps your architect can explain the upside for you.
Posted: Mon Apr 12, 2010 2:33 pm
by Malcolm
thibodeaux wrote:I got nothin but my own experience. It's just...painful to use. And I don't see the upside. Perhaps your architect can explain the upside for you.
Yeah, reading up on all that right now. Our architect is an incompetent fuckwit who probably couldn't even do up velcro-strap shoes. The .Net folk up here are nervous to say the least.