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.
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?