gpt4 book ai didi

mule - 请求-回复范围与请求-响应交换模式

转载 作者:行者123 更新时间:2023-12-01 12:35:38 25 4
gpt4 key购买 nike

我正在尝试了解 request-reply scope 的用例什么时候这比 request-response exchange pattern 更受欢迎? ?,特别是如果底层传输是 JMS,我猜测使用交换模式或范围将从流的角度在内部和功能上做完全相同的事情。

在维护关联 ID 和 replyTo 属性详细信息方面使用请求-回复范围会出现一些麻烦 herehere ,如果使用请求-响应交换模式,是否会存在同样的挑战? (我猜是的,有人可以确认一下吗)

基本上什么时候在请求-响应交换模式上使用请求-回复

更新我的问题以进一步探究请求-回复范围的行为。

在接受的答案中提到的第一个用例中试验请求-回复范围的使用。

用例 1

The endpoint itself does not support request-reponse and still you want to simulate synchronicity

我创建了如下所示的流程,我也在没有消息属性转换器的情况下对此进行了测试(相同的行为)

Request-reply use case

实际的行为是请求永远等待,即使在文件成功写入之后,回复也永远不会进入出站 VM

我的流程代码如下

<flow name="request-replyflowtest">
<http:listener config-ref="Orders_HTTP_Listener_Configuration" path="/rr" doc:name="request-reply-test"/>
<set-payload value="Hello world" doc:name="Set Payload"/>
<message-properties-transformer overwrite="true" doc:name="Message Properties" >
<add-message-property key="MULE_REPLYTO" value="vm://back"/>
<add-message-property key="MULE_CORRELATION_ID" value="#[java.util.UUID.randomUUID().toString()]"/>
</message-properties-transformer>
<request-reply doc:name="Request-Reply">
<file:outbound-endpoint path="C:\Users\sudarshan.sreenivasan\Desktop" outputPattern="hello.txt" responseTimeout="10000" doc:name="File"/>
<vm:inbound-endpoint exchange-pattern="one-way" path="back" doc:name="VM"/>
</request-reply>
<logger message="response not written out" level="INFO" doc:name="Logger"/>
<set-payload value="This is from a different flow" doc:name="Set Payload"/>
</flow>

最佳答案

在大多数情况下,基本上你应该使用请求-响应,除了以下情况:

  • 端点本身不支持请求-响应,但你仍然想模拟同步
  • 你想向一种传输方式发送请求并期望在不同的传输方式上得到响应,即:发送到 jms 期望在 amqp 中得到响应
  • 您想向一个连接器发送请求并期望在另一个连接器上得到响应,即:发送到 jms 连接器 a 期望响应 jms 连接器 b

关于mule - 请求-回复范围与请求-响应交换模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/30115829/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com