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，从源代码来看，请求似乎带有无效的标头。但并非所有请求都会失败。相同的请求可以随机通过或失败。我已经用提琴手记录了所有请求，然后重播了它们。失败的最终可以通过，反之亦然。在此之前，我已经在本地计算机（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.

最简单的复制配置它由代理路径服务和地址端点组成。

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标头中的b
$ b

选项。当我创建一个规则以在提琴手中将其删除时，所有查询均成功进行。尚不清楚是否有办法解决 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

在< Axis2Config> 下有< ConfigurationFile> 元素。默认文件 axis2.xml 似乎或多或少是 axis2_pt.xml 的副本。要切换到NHTTP，只需将< ConfigurationFile> 更改为 $ {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的问题。具体来说，我试图使用curl通过ESB将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 vs 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，因为其他客户，他们将该问题解决为不是bug 按预期工作，因此这是一个卷曲问题。恕我直言，符合HTTP规范的请求的行为不规范不是客户端问题，应该解决。这有效地使PT传输在某些情况下无法使用-即在某些情况下客户端对其如何过帐大型主体更加了解。这实在令人遗憾，因为不需要解析请求主体的场景正是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屋！