[ http://jira.jboss.com/jira/browse/JBMESSAGING-1090?page=all ] Tim Fox updated JBMESSAGING-1090: --------------------------------- Fix Version/s: Unscheduled -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1090?page=all ] Tim Fox updated JBMESSAGING-1090: --------------------------------- Fix Version/s: 2.0.0 Beta (was: Unscheduled) -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1090?page=comments#action_1... ] Jay Howell commented on JBMESSAGING-1090: ----------------------------------------- Right, this was just a proposal, that I later looked at and didn't like. The goal here is to have some way of notifying or putting in some logic to do something when messages are dropped. So I agree that the exception idea may not be a good one, But I'm still not sure I would call dropping the messages and just putting an entry in the log "proper handing". Not sure what the solution is, but we need a way to inject a handler so that we can call whatever logic we need to when messages do get dropped. One more solution would be to handle it like the DLQ or the Expiry Queue. We could have an option to put messages in an Overflow Queue. Right now we move things to other queues based on the amount of time the message is a live(expiry queue), and we move it to a queue based on the amount of times that someones tried to process it(DLQ), so we could add one more thing to drop messages that exceed MaxSize to a queue. If users want them deleted, they can set the TTL for things going into that queue to 1, or if they wan to process them or do notifications, they can have a consumer do something with them. That seems to give the most flexibility is to model it after the DLQ. -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1090?page=comments#action_1... ] 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:) -- 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

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1090?page=com.atlassian.ji... ] Tim Fox commented on JBMESSAGING-1090: -------------------------------------- Behaviour for JBM 2.0 is: On max size the adress will start paging to disk so no exceptions will be thrown, unless "drop-messages-when-full" is enabled on the address, in which case messages will be dropped. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1090?page=com.atlassian.ji... ] Jeff Wilker commented on JBMESSAGING-1090: ------------------------------------------ When the "drop-messages-when-full" option is enabled, will it be possible to detect when messages are dropped? If not, then would it be possible to please reopen this Jira? The motivation behind the request is as follows. For non-durable subscribers, we would typically prefer to drop messages, rather than page, for performance reasons. Therefore, I expect the "drop-messages-when-full" setting would be useful here. However, we need to detect this situation and take the appropriate corrective action (e.g. raise a system alarm). Also, more generally, for any subscriber (durable or non-durable) we ultimately need to limit the use of physical resources, whether that be a database or file system. Therefore, at some point, messages will be dropped, with a similar requirement to detect that this has occurred. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1090?page=com.atlassian.ji... ] Tim Fox reopened JBMESSAGING-1090: ---------------------------------- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBMESSAGING-1090?page=com.atlassian.ji... ] Clebert Suconic updated JBMESSAGING-1090: ----------------------------------------- Fix Version/s: 2.0.0 (was: 2.0.0.beta4) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira