Nigel,
Maybe it's worth adding a completely new QueueBrowser-Interface called DestinationBrowser. This would allow it to:
a) fetch current and future messages (getCurrentMessages and getFutureMessages, boolean arguments always have the potential of getting mixed up)
b) return an Iterator instead of an Enumeration
c) delete messages through the Iterator
d) return future messages in a topic as well!
e) return a Destination with getDestination, not only a Queue with getQueue.
The QueueBrowser-Interface would be soft-deprecated, i.e. only in the comment.
On 2012-07-16, at 18:39, Nigel Deakin wrote:
> Thank you Rüdiger and Nick for your comments.
>
> On 10/07/2012 11:24, Nigel Deakin wrote:
>> I refer to http://java.net/jira/browse/JMS_SPEC-44 (New API to specify delivery delay)
>>
>> We added this to the spec and javadocs quite a long time ago. I'm pleased to report that implementation work for the RI
>> is currently in progress. The implementer of this feature has been asking me how delivery delay works for topics. I
>> think this is something the spec needs to clarify. A small clarification is also needed for QueueBrowser.
>>
>> The key issue is whether the decision to add a message to a subscription (whether durable or non-durable) should be made
>> (a) when the message reaches its delivery time or (b) when the message is sent.
>>
>> Note that this is a question about deciding which subscriptions a message is added to, not about when the message would
>> actually be delivered. In both cases the message wouldn't be delivered to a consumer until the delivery time has been
>> reached.
>>
>> If we adopted (a) this would require the JMS provider to keep all messages in the server until their delivery time is
>> reached, even if there were no durable or non-durable subscriptions in existence. This might even be needed for
>> non-persistent messages. Adopting (b) does not require this and by not requiring a message to be held separately from a
>> subscription is closer to the way in which JMS providers work now. My feeling is that forcing a JMS provider to
>> implement (a) would potentially add a significant burden simply to cater for an unimportant edge case. I therefore
>> propose we adopt (b).
>
> My preference was (b)
> Rüdiger supported (a)
> Nick supported (b) (or at least didn't object to it).
>
> Any more views? I don't think there's a consensus on this yet.
>
> If a clear consensus doesn't emerge then my preference would be for me to pick one of the options (still probably b) and
> make the appropriate spec changes. However in addition I would specifically list this in an appendix of the the next
> formal draft of the spec as an unresolved issue. This gives the RI implementers something to work on, but keeps the
> issue alive whilst we seek further views and discuss this further. Having a proposal written into the spec also gives
> people something specific to read, and to object to.
>
>> Separately, I think we need to clarify the behaviour of a QueueBrowser when delivery delay is used. I think our approach
>> should be that the QueueBrowser should only return messages which are eligible to be delivered immediately. I therefore
>> propose that this be clarified to state that "a message must not be returned by a QueueBrowser before its delivery time
>> has been reached."
>
> Rüdiger disagreed, and thought that the messages returned by a QueueBrowser should include messages whose delivery time
> had not been reached.
>
> Nick, I think, supported my proposal but added that a new variant of QueueBrower was needed which would return messages
> whose delivery time had not been reached.
>
> Again, more views please. Again, a clear consensus doesn't emerge then I suggest we follow the same approach for this:
> I'll pick an option, write it in the spec and list it in the appendix as an unresolved issue.
>
> If we were to take up Nick's suggestion, what would the API look like? Currently there are two methods on Session to
> create a QueueBrowser
>
> QueueBrowser createBrowser(Queue queue)
> QueueBrowser createBrowser(Queue queue, java.lang.String messageSelector)
>
> with equivalent methods on JMSContext.
>
> We could add a third method on each:
>
> QueueBrowser createBrowser(Queue queue, java.lang.String messageSelector, boolean showFutureMessages)
>
> where the showFutureMessages parameter means the QueueBrowser should include messages whose delivery time has not yet
> been reached.
>
> Comments please? Is this a useful method, or does it simply bloat the API?
>
> Nigel
>
>
- application/pkcs7-signature attachment: smime.p7s