MSMQ Messaging
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
Edited By Malcolm on 1270847999
Diogenes of Sinope: "It is not that I am mad, it is only that my head is different from yours."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
-
thibodeaux
- Posts: 8121
- Joined: Thu May 20, 2004 7:32 pm
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.
Speaking of orchestration, I would recommend NOT using Windows Workflow Foundation.
-
thibodeaux
- Posts: 8121
- Joined: Thu May 20, 2004 7:32 pm
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.
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.
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.
Sounds like it's slick once it's up & running, though.
Diogenes of Sinope: "It is not that I am mad, it is only that my head is different from yours."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
-
thibodeaux
- Posts: 8121
- Joined: Thu May 20, 2004 7:32 pm
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.thibodeaux wrote:Speaking of orchestration, I would recommend NOT using Windows Workflow Foundation.
Diogenes of Sinope: "It is not that I am mad, it is only that my head is different from yours."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
-
thibodeaux
- Posts: 8121
- Joined: Thu May 20, 2004 7:32 pm
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.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.
Diogenes of Sinope: "It is not that I am mad, it is only that my head is different from yours."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."
Arnold Judas Rimmer, BSC, SSC: "Better dead than smeg."