Large Messages, ObjectMessage, and the JMS Bridge

[jcstaff]

Ignoring all the performance, portability, etc. issues associated with selecting an ObjectMessage versus ByteMessage -- is it a requirement of the handling of large messages by the JMSBridge that one *not* use an ObjectMessage?

(Using HornetQ 2.1.2.Final, JBoss 5.1.0.GA, and the JMS Bridge).

We are finishing up an end-to-proof of concept that involves the movement of messages between the sizes of 1K and 64K for the normal case and 1 to 10M for the extreme cases. Rate (~ 6 per minute) and thruput requirements (>1 minute) for the large and extreme cases are very low. It just has to be functional. To get things rolling, we relied on the ObjectMessage to start out and had a lot of success while deployed to a single JBoss server and MDBs. Now that we are finishing up the POC and want to operate in an environment closer to the multi-server operational environment -- we are running into issues with the JMSBridge and the handling of large messages as documented in http://community.jboss.org/message/543355#543355, HORNETQ-388.

I have read the relevant sections in the user manual, but also see a note in the JMS Streaming capability (http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/html_single/index.html#large-messages.streaming.over.jms) that the streaming of large messages only works for ByteMessage and StreamMessage. Is that restriction specific to the Streaming API -- which does not seem to be used by the JMS Bridge.

I have added a new ConnectionFactory specifically for the bridge to use, supplied the cache-large-message-client, and verified that the JMSBridge was using this factory. Nothing changed in the result.

<connection-factory name="JMSBridgeConnectionFactory">
      <connectors>
         <connector-ref connector-name="netty"/>
      </connectors>
      <entries>
         <entry name="/JMSBridgeConnectionFactory"/>
         <entry name="/XAJMSBridgeConnectionFactory"/>
      </entries>
      <min-large-message-size>1024000</min-large-message-size>
      <cache-large-message-client>true</cache-large-message-client>
   </connection-factory>

I have added the custom factory to both the source and target CF ends. I have played around with the min-large-message-size, but have not yet seen a difference (too early to tell there).

I am considering a test where our current POC object graphs are serialized into a BytesMessage. My preference would be to be able to configure the server to be able to handle up to a 10MB (1MB? 64?) in a single physical unit to get the flow complete -- were we will refactor based on lessons learned.

Thoughts on getting us over that bridge?

thanks,

jim

[jcstaff]

After some testing, review, and re-thinking. I believe I may have read the comments about setting the cache-large-message-client property on the Bridge's JMS connection factory the wrong way. Should it be turned on or off for the JMSBridge? Since the JMSBridge does not use the streaming API -- I think we want to turn off all features of efficient handling of large messages on the server and allocate enough memory and size ranges to handle our largest case.

Here is where I am so far

   * I have turned off cache-large-message-client and coldstarted everything

   * I have min-large-message-size set to the value above (1024000) as well as 10x that (10240000)

   * small messages (< 10K) are handled fine

   * breakage still occurs > 100K

   * still using an ObjectMessage

...

   * breakage seems to occur in a class that is trying to operate in a large message mode

   * the

[jcstaff]

Re-re-reading the manual put me back into the camp where cache-large-message-client should be set to true, but nothing seemed to help. The short-term solution for me here was to create a semi-deep copy of the Message within JMSBridgeImpl before it was sent. So far - so good.

Looking forward to doing this the right way...