The reason I am looking for clarification is because it reacts differently for me between version 2.0.0.GA and 2.2.5.Final.
I did not have to alter my <journal-buffer-size> from the default for a 600K message on version 2.2.5.Final.
However, I did have to increase it for even a 420K message in 2.0.0.GA.
Anybody have any recommendations?
I'm not sure how it would work on 2.0.0.GA...
I would use large messages.. If you are using clustering however, I would go to the latest Branch or wait the next public release.
You need to increase the Journal buffer size as you mentioned, and the size of the journal to be bigger than your file.
Can you clearify one two more things.
I am confused by the large messges support.
The example, documentation, and discussions I read all seem to refer to streaming the received message which make use of some features that I do not believe to be JMS standards.
ie. message.setObjectProperty("JMS_HQ_InputStream", InputStream)...
This is great, however, I wanted to avoid them for now.
In my testing though, I was able to send and receive a 2MB Text Message using standard JMS calls.
The hornetq trace logging showed that it appeared to be receiving the message via large-message support and in chunks. - nice
1.) Besides memory considerations - is there any reason that the large-message support ( ie. setting <min-large-message-size> to default 100K ) should not be used even for large TextMessages using standard JMS receive calls?
In which case, the default <journal-buffer-size> would be fine. I would just have to be concerned with the <address-settings.max-size-bytes> value correct?
2.) Is the chunking of large messages also used during the send from a client?
In my tests the send of 2Mb TextMessage takes a long time, however, the receive is quick.
LargeMessage is used any time a message is bigger than min_large_message_size definition at the connection-factory.
You can use these properties to force large messages, but the message will be sent in chunks and stored outside of the journal whenever the size is more than minLargeMessageSize (defaulted at 100 KiB)