AMQP messages arent classed as being 'large' or not at a protocol level, but rather just messages which can be sent using 1 or more message-transfer frames as needed or appropriate to the situation. Messages can be split into multiple frames based on the servers advertised max frame size, which it can use use to govern clients behaviour, or maybe the clients own abilities/needs. The combined frame payloads on receipt then represent the complete message, whatever its size.
As I understand it, Artemis internally treats AMQP messages as 'large messages' currently if their encoded size is above the smaller of the journals configured 'journal-buffer-size' and 'journal-file-size' settings. Robbie On 7 May 2018 at 03:50, Justin Bertram <jbert...@apache.org> wrote: >> But I don't understand why a client should decide on how a message should > be treated on the server. > > Because "large" message support as originally conceived for the "core" > protocol (the foundational protocol used by Artemis) involves (at least in > part) clients *streaming* messages in chunks to the broker. The broker has > no influence on how clients send messages to the broker - whether that be > all at once or broken up into chunks which are more manageable from a > memory perspective. Therefore, it's up to the client to decide that. > > Non-core protocols (e.g. AMQP) have limited "large" message support. > > > Justin > > On Sun, May 6, 2018 at 5:58 PM, z94joma <prenumeratio...@gmail.com> wrote: > >> Hi >> >> Thanks for your answer. >> >> I find the answer a bit strange. It probably is correct though. >> >> But I don't understand why a client should decide on how a message should >> be >> treated on the server. As in my case the client can actually crash my >> consumer (As it cannot read large messages if put in large message folder.) >> >> But I will try your suggestions during the week and let everyone know. >> >> /Magnus >> >> >> >> >> >> -- >> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- >> f2341805.html >>
