配置端点以充当工作人员和订阅者

发布于 2024-08-08 21:30:45 字数 789 浏览 2 评论 0原文

是否可以将端点配置为充当从分发者检索作业并订阅某种消息的工作人员?

我有以下场景(适应销售术语)

*)中央部门不时发布新价格清单。必须通知所有工人。这意味着,工作人员应该订阅此事件。

*) 当新订单到达中央时,它会将其发送到分销商,分销商将其发送到下一个空闲工作人员进行处理。这意味着,必须将工作人员配置为从分发者接收消息。 我使用以下配置:

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

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

当我仅将其配置为工作人员或仅作为订阅者时,一切都会按预期工作,但当我将其配置为两者时则不然。

我发现一条消息到达中央的输入队列时,返回地址是分发器的地址而不是工作器地址,并且在这种情况下发布器无法识别订阅者。 有什么想法吗?提前致谢。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

时光瘦了 2024-08-15 21:30:45

IFAIK 不应该以这种方式使用工人。我认为正确的方法是让您的中央订阅价格,当“NewOrderMessage”到达时,用所需的价格(可能仅是该特定订单中产品的价格)丰富该数据,并向输入发送新的 ProcessOrderRequest分配器的队列。

另一种方法是让发送订单请求的流程将价格包含在订单请求中。

这有什么意义吗?

/安德烈亚斯

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

沧笙踏歌 2024-08-15 21:30:45

分配器背后的工作人员是指如何扩展单个逻辑订阅者,而不是如何处理多个逻辑订阅者。关键是,工作人员池中只有一个工作人员应该收到给定的消息,在这种情况下,您希望所有工作人员对发布者来说都是一样的 - 这就是给出分发者地址的原因。

如果您有多个想要横向扩展的逻辑订阅者,请为每个订阅者提供自己的分配器。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文