So I finally got around to doing this. I've made changes on a per
destination basis only for now and have attached the patch to the JIRA.
Also, can you please comment on
https://issues.apache.org/activemq/browse/AMQ-2659 AMQ-2659 ? I've proposed
a small code change for that. Should be a quick
Ok, I have to finish some work first but I'll see how much I can get done
after that. I'm not too familiar with the classes you mentioned but I'll
see what I can figure out.
In principle, I can wait till 5.4 but I'll see what I can do.
There is no problem with AMQ RA, it's just that we have o
If you are in the thick of it and can propose a patch that would be great.
A new boolean option on ActiveMQPolicy would be the best way to introduce
the configuration on a destination basis (set in
org.apache.activemq.broker.region.policy.PolicyEntry.configure(Broker,
SystemUsage, QueueSubscription
I would point out that another JIRA that I've opened (
https://issues.apache.org/activemq/browse/AMQ-2652 AMQ-2652 ), illustrates a
deadlock (hang) which is triggered precisely by the prefetch extension of
transacted consumers (see JIRA for details). So while trying to avoid one
potential hang, t
Fair point. From the perspective of the ResourceAdapter where there are
explicit expectations this makes good sense. The prefetch should be written
in stone.
>From a regular transacted consumers perspective, where the prefetch is
largely hidden, avoiding a hang for large transactions is good becau
I don't really get this. If you extend the prefetchSize to more than what it
was configured to be by the maxMessages parameter in the
Connection.createConnectionConsumer() call, you are violating the JMS spec.
The maxMessages parameter is defined as "the maximum number of messages that
can be as
The prefetch extension in the transacted case is necessary for the case
where a transacted consumer wants to consumer more than prefetch messages in
a single transaction. Without the extension, the broker would see a full
prefetch and not dispatch any more and a receive could block.
On 15 March 20
JIRA AMQ-2651 opened.
I would be happy to provide a patch but as I stated in my original post, I
don't fully understand the need for prefetchExtension in the case of a
transacted, asynchronous (prefetchSize > 0) consumer. If somebody could
explain it, that would perhaps give me the required know
sorry its taking us a while to respond - generally raising a jira with a junit
test case is the best way to go. I know its more effort - but each issue does
take us a while to verify and then fix. Patches are always very welcome too!
On 15 Mar 2010, at 20:02, rodos77 wrote:
>
> Any responses to
Any responses to this or the other 2 issues I posted ? I think these are
pretty serious issues. If I'm correct, this makes AMQ non compliant to the
JMS Spec.
I've gone through the trouble of designing a test for each issue so it
should be very easy to verify the problem. Do I need to open some
Hi,
I've searched the forum and JIRA and have noticed that the prefetchExtension
in PrefetchSubscription has caused grief before. However, I think there
still a problem.
First, I understand the purpose of the prefetchExtension for the case when
prefetchSize = 0. It allows messages to be dispat
11 matches
Mail list logo
