WSO2ESB 4.8.1 PassThroughHttpSender在出现异常时不将线程返回到工作池

Question

我认为org.apache.synapse.transport.passthru.PassThroughHttpSender是wso2esb 4.8.1中http的默认传输发件人（不确定4.9.0以后会检查它）在某些情况下不会将借用线程返回到工作池中案件。

在我看来，这是在外部序列中发生异常（而不是在直接接受传入请求的代理中）时发生的。 例如，当您使用存储和消息处理器实现存储转发模式时，就会发生这种情况。

这是我简单的WSO2ESB 4.8.1配置来重现该问题：

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://ws.apache.org/ns/synapse">
   <registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
      <parameter name="cachableDuration">15000</parameter>
   </registry>
   <import name="fileconnector"
           package="org.wso2.carbon.connector"
           status="enabled"/>
   <proxy name="ProxyTest"
          transports="http https"
          startOnLoad="true"
          trace="disable">
      <target>
         <inSequence>
            <property name="FORCE_SC_ACCEPTED"
                      value="true"
                      scope="axis2"
                      type="STRING"/>
            <log level="custom">
               <property name="text" value="store message"/>
            </log>
            <store messageStore="TestXMS"/>
            <log level="custom">
               <property name="text" value="message stored"/>
            </log>
         </inSequence>
         <outSequence/>
         <faultSequence/>
      </target>
   </proxy>
   <localEntry key="ESBInstance">Test<description/>
   </localEntry>
   <endpoint name="HTTPEndpoint">
      <http method="post" uri-template="http://localhost/index.php">
         <timeout>
            <duration>10</duration>
            <responseAction>fault</responseAction>
         </timeout>
         <suspendOnFailure>
            <errorCodes>-1</errorCodes>
            <initialDuration>0</initialDuration>
            <progressionFactor>1.0</progressionFactor>
            <maximumDuration>0</maximumDuration>
         </suspendOnFailure>
         <markForSuspension>
            <errorCodes>-1</errorCodes>
         </markForSuspension>
      </http>
   </endpoint>
   <sequence name="fault">
      <log level="full">
         <property name="MESSAGE" value="Executing default 'fault' sequence"/>
         <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
         <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
      </log>
      <drop/>
   </sequence>
   <sequence name="TestSequence">
      <log level="full">
         <property name="text" value="message recieved"/>
      </log>
      <call>
         <endpoint key="HTTPEndpoint"/>
      </call>
      <log level="full">
         <property name="text" value="message processed"/>
      </log>
   </sequence>
   <sequence name="main">
      <in>
         <log level="full"/>
         <filter source="get-property('To')" regex="http://localhost:9000.*">
            <send/>
         </filter>
      </in>
      <out>
         <send/>
      </out>
      <description>The main sequence for the message mediation</description>
   </sequence>
   <messageStore name="TestXMS"/>
   <messageProcessor class="org.apache.synapse.message.processor.impl.sampler.SamplingProcessor"
                     name="TestMP"
                     messageStore="TestXMS">
      <parameter name="interval">1000</parameter>
      <parameter name="sequence">TestSequence</parameter>
      <parameter name="concurrency">1</parameter>
      <parameter name="is.active">true</parameter>
   </messageProcessor>
</definitions>

配置端点以将请求发送到任何地方，然后仅调用TestProxy 20次或更长时间以耗尽工作线程的内部池...

收到第20个请求后，新请求将被接受并存储在存储中，但工作池将耗尽，并且不会从消息存储中重试消息。

我认为PassThroughHttpSender必须有可用的源代码...但是反编译存储库/组件/插件/synapse-nhttp-transport_2.1.2.wso2v4.jar的速度更快，并查看内部以查看问题的原因。

我们应该查看sendRequestContent方法的内部：

synchronized (msgContext)
      {
        while ((!Boolean.TRUE.equals(msgContext.getProperty("WAIT_BUILDER_IN_STREAM_COMPLETE"))) && (!Boolean.TRUE.equals(msgContext.getProperty("PASSTHRU_CONNECT_ERROR")))) {
          try
          {
            log.info("msgContext before wait");
            msgContext.wait();
            log.info("msgContext after wait");
          }
          catch (InterruptedException e)
          {
            e.printStackTrace();
          }
        }

这是进程出错的地方。 当异常发生（在另一个线程中）时，它“忘记”通知当前线程，而msgContext永远等待（实际上直到服务器重新启动）

所以我稍微修改了同一包中的另一个类-DeliveryAgent，方法为errorConnecting。 此方法用于从用于连接到目标主机的线程中捕获回调...因此，当我们捕获回调时，我们通知msgContext并通过在targetErrorHandler之后添加新的syncyize块来通知其继续...

public void errorConnecting(HttpRoute route, int errorCode, String message)
  {
    Queue<MessageContext> queue = (Queue)this.waitingMessages.get(route);
    if (queue != null)
    {
      MessageContext msgCtx = (MessageContext)queue.poll();
      if (msgCtx != null) {
        this.targetErrorHandler.handleError(msgCtx, errorCode, "Error connecting to the back end", null, ProtocolState.REQUEST_READY);
        synchronized (msgCtx)
        {
            log.info("errorConnecting: notify message context about error");
            msgCtx.setProperty("PASSTHRU_CONNECT_ERROR", Boolean.TRUE);
            msgCtx.notifyAll();
        }
      }
    }
    else
    {
      throw new IllegalStateException("Queue cannot be null for: " + route);
    }
  }

我已经做了一些测试，看起来它解决了“死”线程的问题。 但是，我不确定这是否是正确的解决方法。欢迎任何建议。

链接到反编译和修改的源文件-src.zip

Answer 1

我找出了问题的原因。 如果后端应用程序接受请求并且不向ESB回复任何内容，则会发生这种情况。 结果，连接因超时而关闭。 在这种情况下，ESB工作线程不会返回到线程池。

为了克服此问题，需要修补org.apache.synapse.transport.passthru.TargetErrorHandler java类

synchronized (mc){ 
   log.info("notify message context about error");
   mc.setProperty("PASSTHRU_CONNECT_ERROR", Boolean.TRUE); 
   mc.notifyAll(); 
}

把它放在捕获块之前。

它将适当地将消息上下文设置为有错误并通知所有等待的对象，从而使ESB可以返回线程池中的请求处理线程。 所有这些对于4.8.1都是正确的。

我已将其修补并投入生产环境，该环境在1月（2016年）每天处理数百万个请求。 自那时以来没有任何问题