the fix can be seen in the linked subversion commits tab of the issue:
https://issues.apache.org/activemq/browse/AMQ-2100?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
click on the modified files links to see the diffs.
2009/2/10 bonnyr :
>
> Gary,
>
> Agreed about the
Rob,
Like in a sliding window protocol, an acknowledged message acks all before
it (by the same consumer).
I guess I'm assuming either one consumer per session on the consuming client
side or some way to
track this on a per session basis in case there are multiple consumers.
Cheers,
Bonny
raj
just for clarification - do you mean all messages delivered to the the
MessageConsumer would be acked on WINDOW_ACK instead of Session wide ?
On 10 Feb 2009, at 23:42, bonnyr wrote:
Rob,
Can I hijack this issue and bring back an issue I have filed in Jira
and is
assigned to you (AMQ-19
Rob,
Can I hijack this issue and bring back an issue I have filed in Jira and is
assigned to you (AMQ-1916) and
that is the issue of a new ack mode (I called it WINDOW_ACK) that is a mix
between CLIENT_ACK and
INDIV_ACK in that the acknowledgement is related to the message but unlike
in CLIENT_A
Gary,
Agreed about the test case - my familiarity with the AMQ test suite is not
that good (excuses, excuses :) ) so what I tried to do, unsuccessfully, was
to play with the ConsumerTool without much luck
on my dev machine which is a WinXP running on a Centrino Duo, and which is
different from ou
> However, wouldn't static analysis of the code be sufficient in this case?
> The code segment above is the only thing that is not protected by
> synchronization, whilst
> every other use of this collection is.
>
Static analysis can identify the problem and the fix, but it doesn't
protect the cha
Bonnie,
in CLIENT_ACK, the list is used on close to deal with duplicate
suppression, these messages will
get redelivered so they need to be removed from audit that tracks
their receipt. That logic is at fault.
Cheers,
Gary.
2009/2/9 bonnyr :
>
> Gary,
>
> Why would the collection be used in CLIEN
didn't see a jira - so created one:
https://issues.apache.org/activemq/browse/AMQ-2100
On 9 Feb 2009, at 23:14, bonnyr wrote:
Gary,
Why would the collection be used in CLIENT_ACK mode then?
In our application we've got to work in this mode since there's a
processing
chain
that may take
Bonny - agreed - looks like that bit of code has never been
synchronized - will add a fix ...
cheers,
Rob
Rob Davies
http://fusesource.com
http://rajdavies.blogspot.com/
On 9 Feb 2009, at 23:14, bonnyr wrote:
Gary,
Why would the collection be used in CLIENT_ACK mode then?
In our applic
Gary,
Why would the collection be used in CLIENT_ACK mode then?
In our application we've got to work in this mode since there's a processing
chain
that may take a while between delivery of the message and its ack, so
chaging this
mode is not possible for our use case.
We're aware of the fact
> I'm not quite able to cause this to happen in a simple test case. Perhaps
> this is to do with some
> thread timing/scheduling issues in the simple test case vs our application.
>
Yea, that is fairly typical.
> However, are you in a
> position to explain what the deliveredMessage collection is u
Gary,
I'm not quite able to cause this to happen in a simple test case. Perhaps
this is to do with some
thread timing/scheduling issues in the simple test case vs our application.
However, are you in a
position to explain what the deliveredMessage collection is used for? Is it
not used in all co
Hi Bonny,
that looks like a bug indeed, should be easy to replicate in a Junit
tests case I think. Could you raise a jira issue for this and if you
have some tests code that demonstrates, please include it.
for more info see: http://activemq.apache.org/contributing.html
Thanks,
Gary.
2009/2/6 bo
13 matches
Mail list logo
