For completeness... the Java Broker would hold a single image in memory and and on disk (no matter how many queues the message went to)... though it probably wouldn't be able to allocate a mesage that was over 4Gb as it would attempt to allocate a single byte array of that size - and Java is limitted to 4Gb there because it uses signed 32-bit integers for array access. We've never had anyone try to use such large messages, and I must admit I'm curious as to why you would want to bundle up all your data into a single message rather than chunking it into smaller units.
-- Rob On 27 February 2014 20:36, Ted Ross <[email protected]> wrote: > Speaking for the C++ broker: > > If the messages are transient (i.e. not durable), the enqueued messages > will all be a reference to a single in-memory instance of the message > content. Don't use durability for these cases, they will be individually > stored on disk (requiring 4TB of journal space). > > -Ted > > > On 02/27/2014 02:23 PM, Tor Rune Skoglund wrote: > >> Hi, >> >> when sending large messages (say, 4GB) from a server to a group of >> receivers (say, 1000 of them) where each of them have their own queue on >> the server side, will the server side broker queues "refer" to the same >> payload (in memory/on disk), or will the payload get duplicated on each >> queue? >> >> Best regards, >> Tor Rune Skoglund, [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
