jboss-esb fs-listener jbm 消息队列溢出

发布于 2024-08-23 08:45:27 字数 2795 浏览 3 评论 0原文

我们有一个 jboss esb 服务器,它以预定的方式(预定频率为 20 秒)从文件系统读取文件,并将它们转换为 esb 消息,然后解析该消息。

ESB 服务器上还配置了一些其他提供者/侦听器 (jms) 和服务。当其中一项服务出现错误时,就会影响上述过程。文件系统提供程序(网关)工作正常,但接收网关消息的 jms 侦听器无法工作,并且 jbm 队列(jbm_msg Oracle DB 表)中积累了大量消息。

问题是,当我的服务器重新启动时,jbm 队列中的消息在 esb 中解析仅 20 秒,这是 fs-provider 的计划频率,不再处理消息,CPU 使用率上升到 100% 并保持在那里。我们相信 fs-providers 会以某种方式中断 jms-provider。

有没有我们遗漏的配置。

这是我们拥有的配置文件: jboss-esb.xml

<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
 <providers>  
  <fs-provider name="SitaIstProvider">
   <fs-bus busid="gw_sita_ist" >
    <fs-message-filter
     directory="/ikarussita/IST/IN"
     input-suffix=".RCV"
     work-suffix=".lck"
     post-delete="false"
     post-directory="/ikarussita/IST/OK"
     post-suffix=".ok"
     error-delete="false"
     error-directory="/ikarussita/IST/ERR"
     error-suffix=".err"/>
   </fs-bus>
  </fs-provider>

  <jms-provider name="SitaESBQueue" connection-factory="ConnectionFactory">
   <jms-bus busid="esb_sita_queue">
    <jms-message-filter dest-type="QUEUE" dest-name="queue/esb_sita_queue"/>
         </jms-bus>
  </jms-provider>  
 </providers>

 <services>
  <service category="SITA" name="SITA_IST" description="SITA Daemon For ISTCOXH">  
   <listeners>
    <fs-listener name="Sita_Ist_Gateway" busidref="gw_sita_ist" is-gateway="true" schedule-frequency="20" />
    <jms-listener name="Jms_Sita_EsbAware" busidref="esb_sita_queue" />
   </listeners>

   <actions mep="OneWay">
             <action name="parse_msg" class="com.celebi.integration.action.sita.inbound.SitaHandler" process="parseMessage" />
    <action name="send_ikarus" class="com.celebi.integration.action.ikarus.outbound.fis.FlightJmsSender" />
   </actions>
  </service>
 </services>
</jbossesb>

jbm-queue-

<?xml version="1.0" encoding="UTF-8"?>
<server>
    <mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=esb_sita_queue"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
     </mbean>
<server>

service.xmlDeployment.xml

<jbossesb-deployment>
<depends>jboss.messaging.destination:service=Queue,name=esb_sita_queue</depends>
</jbossesb-deployment>

感谢

We have a jboss esb server which is reading files from the file system in a scheduled way (schedule frequency of 20sec) and convert them into the esb message then we parse the message.

There are some other providers/listeners (jms) and services configured on the esb servers. When there is an error in one of the services it effects the above process. File system provider (gateway) is working fine but the jms-listener who takes the gateway messages are not working and lots of messages are accumulated in the jbm queue (jbm_msg Oracle DB table).

Here is the problem, when my server is restarted messages in the jbm-queue is parsed in the esb for just 20 seconds which is the scheduled frequency of fs-provider, never process messages again and cpu usage goes up to 100% and stays there. We believe somehow fs-providers interrupts the jms-provider.

Is there any configuration we have been missing out.

Here are the configuration files that we have:
jboss-esb.xml

<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
 <providers>  
  <fs-provider name="SitaIstProvider">
   <fs-bus busid="gw_sita_ist" >
    <fs-message-filter
     directory="/ikarussita/IST/IN"
     input-suffix=".RCV"
     work-suffix=".lck"
     post-delete="false"
     post-directory="/ikarussita/IST/OK"
     post-suffix=".ok"
     error-delete="false"
     error-directory="/ikarussita/IST/ERR"
     error-suffix=".err"/>
   </fs-bus>
  </fs-provider>

  <jms-provider name="SitaESBQueue" connection-factory="ConnectionFactory">
   <jms-bus busid="esb_sita_queue">
    <jms-message-filter dest-type="QUEUE" dest-name="queue/esb_sita_queue"/>
         </jms-bus>
  </jms-provider>  
 </providers>

 <services>
  <service category="SITA" name="SITA_IST" description="SITA Daemon For ISTCOXH">  
   <listeners>
    <fs-listener name="Sita_Ist_Gateway" busidref="gw_sita_ist" is-gateway="true" schedule-frequency="20" />
    <jms-listener name="Jms_Sita_EsbAware" busidref="esb_sita_queue" />
   </listeners>

   <actions mep="OneWay">
             <action name="parse_msg" class="com.celebi.integration.action.sita.inbound.SitaHandler" process="parseMessage" />
    <action name="send_ikarus" class="com.celebi.integration.action.ikarus.outbound.fis.FlightJmsSender" />
   </actions>
  </service>
 </services>
</jbossesb>

jbm-queue-service.xml

<?xml version="1.0" encoding="UTF-8"?>
<server>
    <mbean code="org.jboss.jms.server.destination.QueueService"
      name="jboss.messaging.destination:service=Queue,name=esb_sita_queue"
      xmbean-dd="xmdesc/Queue-xmbean.xml">
      <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
      <depends>jboss.messaging:service=PostOffice</depends>
     </mbean>
<server>

deployment.xml

<jbossesb-deployment>
<depends>jboss.messaging.destination:service=Queue,name=esb_sita_queue</depends>
</jbossesb-deployment>

Thanx

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

愛放△進行李 2024-08-30 08:45:27

将服务拆分为 2 个独立的服务,一个处理 JMS 队列,另一个处理文件轮询器。指定相同的操作管道。这样您就可以获得相同的功能,但不会出现线程问题。还可以在侦听器上使用 max-threads attr 来指定读取线程的数量。

Split the service into 2 separate services, one handling the JMS queue, the other the file poller. Specify the same action pipeline. That way you get the same functionality but without the threading issue. Also use max-threads attr on the listener to specify the number of reading threads.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文