Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of gary.tully@gmail.com
 designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ5znhv_psbvgfqzngtVNTFH=4Kv-TOkAJocRZh9gEosz6zN-g@mail.gmail.com>
References: 
 <CAJ5znhv_psbvgfqzngtVNTFH=4Kv-TOkAJocRZh9gEosz6zN-g@mail.gmail.com>
Date: Fri, 30 Aug 2013 16:43:27 +0100
Message-ID: 
 <CAH+vQmMzD8Zi6R71e1wKvTpp27KMhXRmssN2HT3_mxHAMd5YRw@mail.gmail.com>
Subject: Re: Inconsistent exception messages.
From: Gary Tully <gary.tully@gmail.com>
To: "users@activemq.apache.org" <users@activemq.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

please open a jira issue to track this, they should be more
consistent, in all cases where ResourceAllocationException is thrown
the send is being rejected.
The detail should be confined to the server side logging really, the
client can't reasonably interpret the message in any sensible way,
unless it is forwarded to a sys admin.


On 28 August 2013 17:39, Paul Gale <paul.n.gale@gmail.com> wrote:
> ActiveMQ 5.8.0 on RHEL 6.1 connecting w/STOMP 1.2.
>
> I have noticed that the exception messages that can be returned via an
> ERROR frame can vary in format for the same exception type depending on
> where in the source it originated.
>
> In my STOMP client I parse out the message header of the ERROR frame using
> a regex. A lot of variability can be handled by making the regex case
> insensitive. However, there is a definite refactoring opportunity for the
> ActiveMQ source to make the creation and format of these messages more
> consistent.
>
> I searched for all occurrences of ResourceAllocationException and based on
> that I came up with the following messages that could be returned to the
> client via an ERROR frame. I have seen a number of them appear already
> through experimentation. For clarity I simplified the message strings,
> taken from the source, by removing the '+' symbols and some variable names.
>
>
> The following suffer from inconsistent use of parentheses and inconsistent
> casing:
>
> 'Temp Store is Full (getTempUsage().getPercentUsage()% of
> systemUsage.getTempUsage().getLimit()). Stopping producer
> (message.getProducerId()) to prevent flooding
> getActiveMQDestination().getQualifiedName().'
> 'Persistent store is Full, getStoreUsageHighWaterMark()% of
> systemUsage.getStoreUsage().getLimit(). Stopping producer
> (message.getProducerId()) to prevent flooding
> getActiveMQDestination().getQualifiedName().'
>
>
> The following suffer from inconsistent phrasing, inconsistent use of
> parentheses and inconsistent casing:
>
> 'Usage Manager Memory Limit reached. Producer (getProducerId()) stopped to
> prevent flooding getQualifiedName().'
> 'Usage Manager Memory Usage limit reached. Stopping producer
> (getProducerId()) to prevent flooding getQualifiedName().'
> 'Usage Manager Memory Limit reached. Stopping producer
> (timeout.message.getProducerId()) to prevent flooding
> getActiveMQDestination().getQualifiedName().'
> 'Usage Manager memory limit (memoryUsage.getLimit()) reached. Rejecting
> send for producer (message.getProducerId()) to prevent flooding
> getActiveMQDestination().getQualifiedName().'
>
> Can this be cleaned up in the broker codebase?
>
> BTW, what is the difference in meaning (and associated consequences)
> between 'stopping a producer', 'producer stopped' and 'rejecting send for
> producer'? I don't have enough context for each calling location to know.
> Intuitively they all sound roughly the same to me.
>
> What exceptions, other than ResourceAllocationException, are possible
> candidates for appearing in an ERROR frame?
>
> Thanks,
> Paul


-- 
http://redhat.com
http://blog.garytully.com