[
https://issues.apache.org/jira/browse/ARTEMIS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465083#comment-15465083
]
ASF GitHub Bot commented on ARTEMIS-581:
----------------------------------------
Github user mtaylor commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/749#discussion_r77526654
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ServerSessionImpl.java
---
@@ -1249,6 +1256,14 @@ public RoutingStatus send(final ServerMessage
message, final boolean direct) thr
@Override
public RoutingStatus send(final ServerMessage message, final boolean
direct, boolean noAutoCreateQueue) throws Exception {
+
+ // If the protocol doesn't support flow control, we have no choice
other than fail the communication
+ if (!this.getRemotingConnection().isSupportsFlowControl() &&
pagingManager.isDiskFull()) {
+ ActiveMQIOErrorException exception =
ActiveMQMessageBundle.BUNDLE.diskBeyondLimit();
+ this.getRemotingConnection().fail(exception);
+ throw exception;
--- End diff --
When I say QoS I mean the QoS sent by the client. In the MQTT case, if you
send a message with QoS1 to the broker, the broker must ack it, otherwise
the client assumes that the message was never received then retries at some
later date. So it's not a silent fail. The client never thinks the broker
got the message.
With AMQP, STOMP and OpenWire. It's a little harder than just blocking
using flow control, there's no way (at least that I know of) to revoke
credits once they've been allocated in AMQP and CORE. This means clients
are able to continue sending potentially causing an OOM.
On Mon, Sep 5, 2016 at 3:00 PM, clebertsuconic <[email protected]>
wrote:
> In artemis-server/src/main/java/org/apache/activemq/artemis/
> core/server/impl/ServerSessionImpl.java
> <https://github.com/apache/activemq-artemis/pull/749#discussion_r77526135>
> :
>
> > @@ -1249,6 +1256,14 @@ public RoutingStatus send(final ServerMessage
message, final boolean direct) thr
> >
> > @Override
> > public RoutingStatus send(final ServerMessage message, final
boolean direct, boolean noAutoCreateQueue) throws Exception {
> > +
> > + // If the protocol doesn't support flow control, we have no
choice other than fail the communication
> > + if (!this.getRemotingConnection().isSupportsFlowControl() &&
pagingManager.isDiskFull()) {
> > + ActiveMQIOErrorException exception =
ActiveMQMessageBundle.BUNDLE.diskBeyondLimit();
> > + this.getRemotingConnection().fail(exception);
> > + throw exception;
>
> Failng the send here would endup the STOMP or MQTT producer to believe the
> message was sent.
>
> if you want that level of QOS set global-max-size to something meaninful
> and configure it to DROP.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
>
<https://github.com/apache/activemq-artemis/pull/749/files/f84d9d105901253d079ec8dd42b888f15f356354#r77526135>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AAOCy9VkkrKDq5uWaBYyXKvTfgU4K6qTks5qnCBsgaJpZM4J0MjB>
> .
>
> Add setting to control global disk usage
> -----------------------------------------
>
> Key: ARTEMIS-581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-581
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Affects Versions: 1.3.0
> Reporter: Lionel Cons
> Assignee: clebert suconic
> Priority: Blocker
> Fix For: 1.5.0
>
>
> AFAIK, there is no way to prevent Artemis from using too much space on the
> disk (with paged messages).
> Disk space, just like memory space, is limited and Artemis should detect when
> it is about to use too much space and act accordingly (i.e. DROP, FAIL...).
> ActiveMQ 5.x does allow controlling disk usage via its {{storeUsage}} and
> {{tempUsage}} settings in {{systemUsage}}.
> Could Artemis also use a global disk setting to limit its disk usage?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
