OK, good to know. Thanks. Well, it's a worst-case scenario, and we just would like to be prepared in case such situations arise.
Chopping up the message ourselves could be an option, but if it still could be handled without any application side processing (and along with automatic resume in case of disconnections and network problems), we wouldn't have to make any special code of our own for handling these cases. Best regards, Tor Rune Skoglund, [email protected] Den 27. feb. 2014 20:52, skrev Rob Godfrey: > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
