[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1090) Add appropriate Exception handling when hitting MaxSize

[Jay Howell (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-1090?page=comments#action_12395353 ] 
            
Jay Howell commented on JBMESSAGING-1090:
-----------------------------------------

Sorry to Correct, The current functionality is 

Queue - exception is thrown with a descriptive message when the message is put on the queue.

Topic - Message is dropped due to the implementation of the Topic.  That is the only case where we actually just drop the message.

The current functionality works, but I see the following problems with it...

1.  Hard to execute custom logic when you hit MaxSize
a.  When an exception is thrown for a Queue add and the max hits, a very generic jms exception is thrown.  There's little way to know what the problem is without having to parse the exception message..
b.  when an exception is thrown for a Topic, since each subscription is a queue, the way that it happens gives no way to find out that you hit max size in any of the subscriber queues

2.  I'm not sure hitting max size represents an exception after thinking about it.  IMO:  Hitting max size is a rule, not an exception state.

3.  Using an exception for max size will possibly make users embed some part of their business flow into an exception logic.  For instance if they want to send a mail or put the message in another queue, they will have to embed that business flow whereever they have logic to put something on a queue.  This would lead to spreading logic in a lot of different places.

For these reasons, it seems that some cross cutting solution needs to be done.  I can only think of the two already listed(make an overflow queue, add a place where we could put a point cut for aop).

The question that I have is for a topic.  Since each subscriber queue will get the Max size, if I have 100 subscriptions, will that mean if we
1. use the overflow, we will put a message in the overflow for each subscription(there will be 100 of them)
2. use the overflow, would we need to keep track of the subscriptions that didn't get it and the ones that did?
2.  use the aop, we will call the pointcut 100 times.

I'm sure these are some of the difficulties that this design has also raised in the past.

Jay:)

> Add appropriate Exception handling when hitting MaxSize
> -------------------------------------------------------
>
>                 Key: JBMESSAGING-1090
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1090
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.GA
>            Reporter: Jay Howell
>         Assigned To: Jay Howell
>            Priority: Minor
>             Fix For: 2.0.0 Beta
>
>
> When using MaxSize for a queue and topic the following behaviors exist
> Queue - When a queue hits MaxSize, the delivery returned in Channel Support is null.  This triggers a very generic JMSException to be thrown by looking at the delivery and seeing if it's null in the ServerConnectionEndpoint.
> Topic - When a subscription hits the MaxSize(defined in the topic), the delivery returned will be null, but no check is done and no JMSException is thrown in the ServerConnectionEndpoint.
> What this means is that anyone who wants to put hooks in to gather the messages dropped can't.  Either because the exception is too generic or because one is not thrown at all.
> I would purpose that we put proper exception handling down in the ChannelSupport where MaxSize is checked for both queues and subscriptions.  
> We would need to Change the The two methods in channel support for send and sendInternal to throw a JMSException.  Then we throw a checked Exception in ChannelSupport for MaxSize violations(make a new exception derived from MessagingJMSException).  
> Adding proper exception handling to these would allow users to add aspects and notifications when messages are dropped due to MaxSize.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira