WSO2 ESB 未知错误代码 102511 [英] WSO2 ESB unknown error code 102511

问题描述

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

I have recently upgraded WSO2 ESB to version 4.7 on the Windows Server 2008 R2 and encountered the next error while simply proxying SOAP request to an endpoint:

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

Receiving response while the handler is in an inconsistent state REQUEST_HEAD

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

问题是，该错误代码未在文档中描述，并且无一例外，不清楚是什么原因造成的.我能找到的最接近的代码是 SND_INVALID_STATE = 102510 并且从源代码来看，该请求似乎带有无效的标头.但并非所有请求都失败了.同一个请求可以随机通过或失败.我已经用 fiddler 记录了所有请求并重播了它们.失败的最终可以通过，反之亦然.在此之前，我已经在本地机器(Windows 7)上部署并测试了新版本的 ESB，并且仅在冷启动时遇到了此类错误.

Thing is, that this error code is not described in the documentation and without an exception it is not obvious what to make of it. The closest code I could find was SND_INVALID_STATE = 102510 and judging from the source code it seems that the request comes with invalid headers. But not all requests are getting failed. The same request can pass or fail randomly. I've recorder all requests with fiddler and replayed them. The one that has failed can eventually pass and vice versa. Before that I've deployed and tested new version of ESB on my local machine (Windows 7) and encountered such error only on the cold start.

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

The simplest configuration to reproduce it consists of Path Through Proxy service and an address endpoint.

代理服务配置:

<?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>

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

Has anyone else experienced this error or knows how to deal with it? I will be grateful for any insight on the situation.

更新:
请求失败的原因似乎是

An update:
It seems the reason why requests are failing is

Expect: 100-continue

请求 HTTP 标头中的选项.当我在提琴手中创建一个规则来删除它时，所有的查询都成功了.目前还不清楚是否有办法在 WSO2 ESB 端处理这种行为，或者是否应该删除这部分标头.

option in the request HTTP header. When I created a rule to remove it in fiddler, all queries went successfully. It is still not clear whether there is a way to deal with such behavior on WSO2 ESB side or should this part of the header be removed.

推荐答案

我今天从 WSO2 ESB 4.5.1 升级到 4.7.0 时遇到了这个问题.我在 4.5.1 中遇到了另一个问题，因此我不得不升级，所以在遇到 4.7.0 的这个问题时，我别无选择，只能解决它.

I encountered this problem today when upgrading from WSO2 ESB 4.5.1 to 4.7.0. I had another problem with 4.5.1 that I had to upgrade because of, so upon encountering this problem with 4.7.0, I had no choice but to solve it.

想了一会儿，我想起了在 4.6.0 中默认传输从 NHTTP 切换到 Passthrough 以提高性能.4.7.0 附带了两者的配置，但默认启用 PT.配置文件在axis2目录中:

After thinking for some time, I remembered that the default transport was switched from NHTTP to Passthrough in 4.6.0 to increase performance. 4.7.0 ships with configurations for both, but with PT enabled by default. The config files are in the axis2 directory:

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

PT 配置文件是 axis2_pt.xml.NHTTP 是 axis2_nhttp.xml.您可以区分它们以了解发生了什么变化；幸运的是，差异非常干净.

The PT config file is axis2_pt.xml. The NHTTP one is axis2_nhttp.xml. You can diff them to get an idea of what changes; the diff is luckily pretty clean.

您可以通过修改主配置文件轻松地从 PT 切换到 NHTTP:

You can easily switch from PT to NHTTP by modifying the main config file:

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

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

There you have the <ConfigurationFile> element under <Axis2Config>. The default file, axis2.xml seems to be more or less a copy of axis2_pt.xml. To switch to NHTTP, just change the <ConfigurationFile> to ${carbon.home}/repository/conf/axis2/axis2_nhttp.xml.

切换到 NHTTP 解决了我的 ESB 4.7.0 无法正确处理 100 CONTINUE 的问题.具体来说，我试图通过 ESB 使用 curl 将 PDF 上传到另一个服务.使用PT，失败；使用 NHTTP，它工作得很好.我的明显结论是，在这种情况下，PT 简直是个错误.

Switching to NHTTP solved my problem of ESB 4.7.0 not dealing with 100 CONTINUE correctly. Specifically, I was trying to upload a PDF using curl through the ESB to another service. Using PT, it failed; using NHTTP, it worked fine. My obvious conclusion is that PT is simply buggy in this scenario.

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

From the reading that I have done about PT vs NHTTP, the only "official" side-effect of switching from one to the other is that PT should be faster in certain scenarios. However, NHTTP has been around for longer and is therefore likely to be a bit more solid simply by virtue of having gone through more bugfixing rounds. I don't know this for sure as I'm not involved with the development of WSO2 ESB, but it's an educated guess. :)

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

Also I'd love to comment on Isuru Perera's answer, but I don't have the necessary reputation so I'm afraid I have to put my two cents regarding https://wso2.org/jira/browse/APIMANAGER-1007 here. This issue does indeed seem related - especially based on my own experience with curl today - but unfortunately the kind folks at WSO2 have resolved the issue as "Not a bug" after a number of comments that ultimately recommended avoiding the use of curl because other clients "work as expected," thus rendering this a "curl issue." IMHO having broken behaviour with HTTP-spec-compliant requests is not a client issue and should be resolved. This effectively renders the PT transport unusable in certain scenarios - i.e. ones where the client is a little bit more intelligent about how it POSTs large bodies. This is really a shame, because scenarios where the request body does not need to be parsed are precisely what the PT transport was designed for and where it should excel!

哦，这是我在 stackoverflow 上的第一篇文章，如果我违反了任何家规，我深表歉意；一段时间以来我一直是一个被动的参与者，所以我希望我没有做错什么！

Oh and this is my first post on stackoverflow so I'm sorry if I've broken any house rules; I've been a passive participant for some time so I'm hoping I didn't do anything too wrong!

这篇关于WSO2 ESB 未知错误代码 102511的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！