activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gomes <e.se...@gmail.com>
Subject Re: Possible NMS Transaction bug Transaction GUID not Unique
Date Wed, 17 Aug 2011 18:49:22 GMT
Here's a link to the JIRA database:

https://issues.apache.org/jira/

You can enter a bug for the AMQNET project there.  This way you can see the
status of any work done to fix it, and you can upload code samples and other
things if necessary.  If you do upload code samples, be sure to set the
assign license rights to ASF flag.

Thanks!

On Tue, Aug 16, 2011 at 10:46 PM, spenceee <spenceee@gmail.com> wrote:

> Could you send me a link to how I could raise this as a JIRA bug?  I'm
> sorry
> but I'm not familiar with the project etc.  I also didn't want to do that
> until I was sure this was a defect, I wanted some peer review to ensure I
> didn't do something stupid.
>
> Unfortunately, this bug is difficult to reproduce in a unit test as it is
> dependent upon the transaction manager.  You need something to force .Net
> to
> enlist a transaction (as it will use PSPE and avoid it if possible) and
> then
> you need heavy multithreading to connect fast enough to reproduce the bug.
>
> But my original bug statement is very clear, if the broker ID changes on
> reboot, the queue manager should use the Guid.NewGuid() anyway.  I say this
> also because the transaction GUID is shared by all systems, not just
> ActiveMQ which could cause further problems if you are allocating a GUID
> that is not using the guaranteed globally unique algorithm.
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Possible-NMS-Transaction-bug-Transaction-GUID-not-Unique-tp3735015p3749210.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message