[
https://issues.apache.org/jira/browse/ARTEMIS-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465060#comment-15465060
]
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_r77524869
--- 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 --
What do you mean by silently fail? If the client chooses an appropriate
QoS level (or protocol equivilent) it'll never get an ack and thus as far
as the client is concerned the broker never received it.
On Mon, Sep 5, 2016 at 2:49 PM, clebertsuconic <notificati...@github.com>
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_r77524662>
> :
>
> > @@ -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;
>
> there is no way to tell the producers on these protocols that the message
> failed. Keep coming would endup on a drop and the producer may thing it
was
> sent ok. It would be a message loss without communicating the failure to
> the producer.
>
> Is it possible to configure it to go from PAGING to DROP once the disk
> limit is reached?
>
> you can already configure global-max-size to DROP.
>
> I *strongly* advise against silently fail. (I have a strong opinion on
> this subject). I won't silently fail a message send on purpose here.
>
> —
> 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#r77524662>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AAOCy2c6jvpra-IFJzF4wUJTfzmGqJqhks5qnB3PgaJpZM4J0MjB>
> .
>
> 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)
