activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Gale <paul.n.g...@gmail.com>
Subject Re: Inconsistent exception messages.
Date Fri, 30 Aug 2013 18:31:08 GMT
On Fri, Aug 30, 2013 at 11:43 AM, Gary Tully <gary.tully@gmail.com> wrote:

> 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.
>

Thanks for the clarification. I will create a Jira issue.


> 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.
>
>
True. However, STOMP clients only have ERROR frames to convey any such
information from broker.

We're taking advantage of 'sendFailIfNoSpace' in the broker's config to log
these errors on the client-side.
You're right, there is no meaningful counter measure the client can take.
It's just informative.

I suppose as an alternative a STOMP client could simultaneously subscribe
to some advisory topic(s), if the client implementation supported it. I
haven't tried to do that with ours.

Thanks,
Paul


>
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message