gpt4 book ai didi

WSO2 ESB 未知错误代码 102511

转载 作者:行者123 更新时间:2023-12-04 04:45:55 24 4
gpt4 key购买 nike

我最近升级了WSO2 ESBWindows Server 2008 R2 上的 4.7 版并在简单地将 SOAP 请求代理到端点时遇到了下一个错误:

在处理程序处于不一致状态时接收响应 REQUEST_HEAD

ERROR_CODE : 102511  
ERROR_MESSAGE : Error in Sender
ERROR_DETAIL : Error in Sender
ERROR_EXCEPTION : null

问题是,这个错误代码没有在文档中描述,毫无异常(exception),它是什么并不明显。我能找到的最接近的代码是 SND_INVALID_STATE = 102510 并且从源代码来看,该请求似乎带有无效的 header 。但并非所有请求都失败了。相同的请求可以随机通过或失败。我已经用 fiddler 记录了所有请求并重放了它们。失败的最终可以通过,反之亦然。在此之前,我已经在本地机器(Windows 7)上部署并测试了新版本的 ESB,并且仅在冷启动时遇到此类错误。

重现它的最简单配置包括 Path Through Proxy 服务和地址端点。

代理服务配置:
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse" name="TestEP" transports="http" statistics="disable" trace="enable" startOnLoad="true">
<target endpoint="TestEP">
<outSequence>
<send/>
</outSequence>
</target>
<description/>
</proxy>

地址端点描述
<endpoint xmlns="http://ws.apache.org/ns/synapse" name="TestEP">
<address uri="http://mydomain.test/SystemServices.asmx">
<syn:suspendOnFailure>
<syn:initialDuration>0</syn:initialDuration>
<syn:progressionFactor>1.0</syn:progressionFactor>
<syn:maximumDuration>0</syn:maximumDuration>
</syn:suspendOnFailure>
</address>
</endpoint>

有没有其他人遇到过这个错误或知道如何处理它?我将不胜感激对这种情况的任何见解。

更新:
请求失败的原因似乎是
Expect: 100-continue

请求 HTTP header 中的选项。当我在 fiddler 中创建删除它的规则时,所有查询都成功了。尚不清楚 WSO2 ESB上是否有处理此类行为的方法。侧面或应该删除标题的这部分。

最佳答案

我今天在从 WSO2 ESB 4.5.1 升级到 4.7.0 时遇到了这个问题。由于 4.5.1 的另一个问题,我不得不升级,所以在 4.7.0 遇到这个问题时,我别无选择,只能解决它。

想了想,想起来4.6.0把默认传输从NHTTP切换到Passthrough,以提高性能。 4.7.0 附带了两者的配置,但默认情况下启用了 PT。配置文件位于axis2目录中:

${carbon.home}/repository/conf/axis2/

PT 配置文件是 axis2_pt.xml . NHTTP 是 axis2_nhttp.xml .您可以对它们进行比较以了解发生了哪些变化;幸运的是差异很干净。

您可以通过修改主配置文件轻松地从 PT 切换到 NHTTP:
${carbon.home}/repository/conf/carbon.xml

你有 <ConfigurationFile>下元素 <Axis2Config> .默认文件, axis2.xml似乎或多或少是 axis2_pt.xml的副本.要切换到 NHTTP,只需更改 <ConfigurationFile>${carbon.home}/repository/conf/axis2/axis2_nhttp.xml .

切换到 NHTTP 解决了我的 ESB 4.7.0 没有正确处理 100 CONTINUE 的问题。具体来说,我试图通过 ESB 使用 curl 将 PDF 上传到另一个服务。使用PT,失败;使用 NHTTP,它工作正常。我显而易见的结论是,在这种情况下,PT 简直就是马车。

从我对 PT 与 NHTTP 所做的阅读来看,从一种切换到另一种的唯一“官方”副作用是 PT 在某些情况下应该更快。然而,NHTTP 已经存在的时间更长了,因此仅仅因为经历了更多的错误修复轮次,它可能会更加可靠。我不确定这一点,因为我没有参与 WSO2 ESB 的开发,但这是一个有根据的猜测。 :)

另外,我很想对 Isuru Perera 的回答发表评论,但我没有必要的声誉,所以恐怕我不得不花两分钱关于 https://wso2.org/jira/browse/APIMANAGER-1007这里。这个问题似乎确实相关——尤其是根据我自己今天使用 curl 的经验——但不幸的是,在发表了一些最终建议避免使用 curl 的评论后,WSO2 的好心人已将该问题解决为“不是错误”,因为其他客户端“按预期工作”,从而使这成为“ curl 问题”。恕我直言,对符合 HTTP 规范的请求有破坏行为不是客户端问题,应该解决。这有效地使 PT 传输在某些情况下无法使用 - 即客户端对其如何 POST 大型机构更加智能的情况。这真的很遗憾,因为不需要解析请求正文的场景正是 PT 传输的设计目的和它应该擅长的地方!

哦,这是我在 stackoverflow 上的第一篇文章,所以如果我违反了任何房屋规则,我很抱歉;一段时间以来,我一直是被动的参与者,所以我希望我没有做错任何事情!

关于WSO2 ESB 未知错误代码 102511,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18183687/

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