Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

此内容没有您所选择的语言版本。

17.2. Producer flow control

HornetQ also can limit the amount of data sent from a client to a server to prevent the server being overwhelmed.

17.2.1. Window based flow control
复制链接

In a similar way to consumer window based flow control, HornetQ producers, by default, can only send messages to an address as long as they have sufficient credits to do so. The amount of credits required to send a message is given by the size of the message.
As producers run low on credits they request more from the server. When the server sends them more credits they can send more messages.
The amount of credits a producer requests in one go is known as the window size.
The window size therefore determines the amount of bytes that can be in-flight at any one time before more need to be requested; this prevents the remoting connection from getting overloaded.

17.2.1.1. Using Core API
复制链接

If the HornetQ core API is being used, window size can be set via the ClientSessionFactory.setProducerWindowSize(int producerWindowSize) method.

17.2.1.2. Using JMS
复制链接

If JNDI is used to look up the connection factory, the producer window size can be configured in JBOSS_DIST/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-jms.xml: 
<connection-factory name="NettyConnectionFactory">
   <connectors>
     <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="/ConnectionFactory"/>       
   </entries>
   <producer-window-size>10</producer-window-size>
</connection-factory>
Copy to Clipboard Toggle word wrap
If the connection factory is directly instantiated, the producer window size can be set via the HornetQConnectionFactory.setProducerWindowSize(int producerWindowSize) method.

17.2.1.3. Blocking producer window based flow control
复制链接

Normally the server will always give the same number of credits as has been requested. However, it is also possible to set a maximum size on any address. This then blocks how many credits can be sent to the address so that its memory cannot be exceeded.
For example, if there is a JMS queue called "myqueue", the maximum memory size could be set to 10 MB, and the server will control the number of credits sent to any producers which are sending any messages to myqueue. This means that the total messages in the queue never exceeds 10 MB.
When the address gets full, producers will block on the client side until more space frees up on the address; that is, until messages are consumed from the queue thus freeing up space for more messages to be sent. This is called blocking producer flow control.
To configure an address with a maximum size and tell the server that you want to block producers for this address if it becomes full, you need to define an AddressSettings (Section 23.3, “Configuring Queues Through Address Settings”) block for the address and specify max-size-bytes and address-full-policy
The address block applies to all queues registered to that address. That is, the total memory for all queues bound to that address will not exceed max-size-bytes. In the case of JMS topics this means the total memory of all subscriptions in the topic will not exceed max-size-bytes.
Here is an example: 
<address-settings>
   <address-setting match="jms.queue.exampleQueue">            
      <max-size-bytes>100000</max-size-bytes>
      <address-full-policy>PAGE</address-full-policy>   
   </address-setting>
</address-settings>
Copy to Clipboard Toggle word wrap
The above example would set the max size of the JMS queue "exampleQueue" to be 100,000 bytes and would block any producers sending to that address to prevent that max size being exceeded.
Note the policy must be set to BLOCK to enable blocking producer flow control.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat