views:

240

answers:

2

Is it possible to configure an endpoint to act as a worker retrieving jobs from a distributor AND subscribe to some kind of messages?

I have the following scenario ( adapted to sale terminology)

*) a central department publishes every now and then a list of the new prices. All workers have to be notified. That means, a worker should subscribe to this event.

*) when a new order arrives at the central, it sends it to the distributor, which send it to the next idle worker to be processed. That means, a worker have to be configured to receive messages from the distributor. I use the following configuration:

 <MsmqTransportConfig
    InputQueue="worker"
    ErrorQueue="error"
    NumberOfWorkerThreads="2"
    MaxRetries="5"
  />

  <UnicastBusConfig
    DistributorControlAddress="distributorControlBus"
    DistributorDataAddress="distributorDataBus" >    
    <MessageEndpointMappings>
      <add Messages="Events" Endpoint="messagebus" />
    </MessageEndpointMappings>
  </UnicastBusConfig>

When I configure it only as a worker or only as a subscriber everything works as expected, but not when I configure it as both.

I discovered that a message arrives at the input queue of the central with the address of the distributor as return address instead of worker address, and the publisher recognize no subscriber in this case. Any ideas? Thanks in advance.

+1  A: 

Workers are not supposed to be used in that way IFAIK. I think the way to go would be to have your central subscribe to the prices and when a "NewOrderMessage" arrives enrich that data with the required prices (perhaps only prices for the products in that particular order) and send a new ProcessOrderRequest to the input queue of the distributor.

Another way would be to have the process that sends the order request to include the prices in the order request.

Does that make any sense?

/Andreas

Andreas Öhlund
That’s how I am doing it right now. The price list is attached to the order message. My intent was to strip down the messages and spare bandwidth.If this doesn’t work I may consider sending the timestamp of the current price list and letting the worker requests it from central using Bus.Reply(), But this also means I have to persist the messages somehow until the answer arrives.
Mouk
Any other ways? The data we require is extremely heavy and cannot be transferred over the wire
theGecko
TheGecko, we're looking at bundling in a data bus for transmitting larger quantities of data.
Udi Dahan
+1  A: 

Workers behind a distributor is how you scale out a single logical subscriber, not how you handle multiple logical subscribers. The point is that only a single worker out of the pool of workers should get a given message, in which case, you want all workers to look the same to the publisher - which is why the address of the distributor is given.

If you have multiple logical subscribers that you want to scale out, give each one of them their own distributor.

Udi Dahan
I think I understand the concept of workers now. When a worker publishes a message all subscriber to the distributor endpoint should be notified. Makes sense.
Mouk
Surely multiple distributors each with its own workers would still only allow broadcast messages to be received by the distributor and not the workers?
theGecko
theGecko, when a worker publishes a message, it sets the return address of that message to be the address of its distributor, such that to subscribers they appear as the distributor. Hope that answers your question.
Udi Dahan