General MSMQ and C# question

  • Thread starter Thread starter Claudia
  • Start date Start date
C

Claudia

Hi all...

I'm working on a project that uses MSMQ as its core for inter-process
communication. At the moment there is a single process that listens for
inbound TCP-based messages on a socket, and when something is received it
gets packaged up and sent to an MSMQ queue for further processing.

The process on the listening end of this queue will process the message and
either (a) send a response to the originator, or, (b) send an "internal"
message to another process for further work.

(a) is achieved by sending to a general "outbound" MSMQ queue which then
responds via TCP to the originator of the message.
(b) is achieved by sending the message onto the relevant queue for the
process to do the further work...
(I hope i haven't lost anyone by now! ;) )

Now, if I have, say, 40 processors, that means 40 queues (plus the general
"outbound" queue). The single TCP-listener process will have a hashtable of
40 MessageQueue objects, each ready to send to the appropriate worker
process.

Each worker process will listen to its own queue and send to the general
"outbound" queue.

For inter-process communications, each worker process has a hashtable of 39
MessageQueue objects, each ready to send to any of the other worker
processes...

I'm not sure if this is the best way of doing this... any suggestions???

Thanks!
Claudia
 
Claudia,
From your description it isn't entirely clear why you feel you need such a
complicated (and potentially resource-intensive) setup. Wouldn't it be
possible to have a single MessageQueue and use something like - for example
-- the Message label to tell the processor which process it is destined for?
Then you could have a sort of "broker" class that would read the message
label and based on a simple switch statement, send it on to the respective
class to handle that specific processing.

if each message is derived from an Interface that has a generic "Execute"
method, all you would need to do is read out the payload and deserialize it
to an instance of the Interface and call the method...

Just my 2 cents.
Peter
 
Why do you have a TCP listener? It seems to be unnecessary over head. One
approach is to configure the Queue with remote access and send the messages
directly to the queue. Since the queue already implements message
confirmation, you can eliminate that part of your application that is
responsible for notification.

Configure the queue with triggers so that messages that need to be forwarded
on internally are automatically forwarded or handled by the queue framework.
The thing is, you've built a lot of functionality into your applications
that are already robustly implemented in the queue framework.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
 
http://www.apress.com/book/supplementDownload.html?bID=10003&sID=3050

Check the Chapter 8 example.


You could do 1 queue, or maybe 2. Put not >2.

You need to just label each messgae with a machine name.

.....

\firstlevelqueue
\secondlevelqueue

Send your initial messages to firstlevelqueue.
Create an object like

public class MyObject
private int m_processorNumber;
public int ProcessorNumber{ get { return this.m_processorNumber;} }
public MyObject (int processorNumber)
{ this.m_processorNumber = processorNumber; }

And then you can put an instance of MyObject into the BODY of the Q message.

....

Then you write a Windows Service, which is your "Poller" (aka, polls the
firstlevelqueue every X seconds)

You write your businesslogic to handle your if/else.

The reason I advocate 2 queues...is that it is a little easier ....when you
read the messages from the Q.. and you have to cast them as MyObject.

Check the sample in that zip download (top of this email).

You may have to rewrite it a little if you have 1.1, but you can do this.

I think the example has public class Document....where this would become
your MyObject.


...

I think a different N queue for every N processor you have .... is a bad
design.
(aka, 40 processors = 40 queues....)



Alvin Bruney - ASP.NET MVP said:
Why do you have a TCP listener? It seems to be unnecessary over head. One
approach is to configure the Queue with remote access and send the
messages
directly to the queue. Since the queue already implements message
confirmation, you can eliminate that part of your application that is
responsible for notification.

Configure the queue with triggers so that messages that need to be
forwarded
on internally are automatically forwarded or handled by the queue
framework.
The thing is, you've built a lot of functionality into your applications
that are already robustly implemented in the queue framework.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



Claudia said:
Hi all...

I'm working on a project that uses MSMQ as its core for inter-process
communication. At the moment there is a single process that listens for
inbound TCP-based messages on a socket, and when something is received it
gets packaged up and sent to an MSMQ queue for further processing.

The process on the listening end of this queue will process the message and
either (a) send a response to the originator, or, (b) send an "internal"
message to another process for further work.

(a) is achieved by sending to a general "outbound" MSMQ queue which then
responds via TCP to the originator of the message.
(b) is achieved by sending the message onto the relevant queue for the
process to do the further work...
(I hope i haven't lost anyone by now! ;) )

Now, if I have, say, 40 processors, that means 40 queues (plus the
general
"outbound" queue). The single TCP-listener process will have a hashtable of
40 MessageQueue objects, each ready to send to the appropriate worker
process.

Each worker process will listen to its own queue and send to the general
"outbound" queue.

For inter-process communications, each worker process has a hashtable of 39
MessageQueue objects, each ready to send to any of the other worker
processes...

I'm not sure if this is the best way of doing this... any suggestions???

Thanks!
Claudia
Click to expand...
Click to expand...
 
Back
Top