You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by spenceee <sp...@gmail.com> on 2011/08/11 07:50:57 UTC
Possible NMS Transaction bug Transaction GUID not Unique
G'day, first time poster, apologies if I'm in the wrong forum.
I think I have found a defect in the NMS 1.5.0 API regarding the allocation
of a Resource Manager GUID in the NetTxConnection class. This is sent to
the MS DTC as a unique identifier for the resource manager. I've read the
source code for this class and it is derived from the BrokerInfo.BrokerID
from the connection. According to MSDN the ID needs to be:
resourceManagerIdentifier
A unique identifier for a resource manager, which should persist across
resource manager failure or reboot.
If I understand correctly, each new connection to the broker will get a new
value for BrokerID. Therefore I can see little value in deriving the GUID
from the broker info. I think it would make more sense for
NetTxConnection.ResourceManagerGUID to set the value internally to
Guid.NewGuid(); and then return this value.
internal resourceManagerGuid = Guid.NewGuid; //Guaranteed* unique
and threadsafe.
internal Guid ResourceManagerGuid
{
get
{
return resourceManagerGuid;
}
}
The only reason I can see for receiving this error is if somehow the same
brokerID is returned. I am using 4 threads to make connections with to the
broker concurrently on 4 separate Active MQ connection objects.
I've santised the error I've received if it's helpful.
Error : 2011/19/12 04:19:44 xxx: Source: System.Transactions
Message: A resource manager with the same identifier is already registered
with the specified transaction coordinator. (Exception from HRESULT:
0x8004D102)Stack: at
System.Transactions.Oletx.IDtcProxyShimFactory.CreateResourceManager(Guid
resourceManagerIdentifier, IntPtr managedIdentifier, IResourceManagerShim&
resourceManagerShim)
at
System.Transactions.Oletx.OletxResourceManager.get_ResourceManagerShim()
at System.Transactions.Oletx.OletxResourceManager.Reenlist(Int32
prepareInfoLength, Byte[] prepareInfo, IEnlistmentNotificationInternal
enlistmentNotification)
at
System.Transactions.Oletx.OletxTransactionManager.ReenlistTransaction(Guid
resourceManagerIdentifier, Byte[] recoveryInformation,
IEnlistmentNotificationInternal enlistmentNotification)
at System.Transactions.TransactionManager.Reenlist(Guid
resourceManagerIdentifier, Byte[] recoveryInformation,
IEnlistmentNotification enlistmentNotification)
at Apache.NMS.ActiveMQ.TransactionContext.InitializeDtcTxContext()
at
Apache.NMS.ActiveMQ.NetTxConnection.CreateAtiveMQSession(AcknowledgementMode
ackMode)
at Apache.NMS.ActiveMQ.Connection.CreateSession(AcknowledgementMode
sessionAcknowledgementMode)
at xxx.TimeoutRead(Int32 timeOut, Boolean commit)
--
View this message in context: http://activemq.2283324.n4.nabble.com/Possible-NMS-Transaction-bug-Transaction-GUID-not-Unique-tp3735015p3735015.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Possible NMS Transaction bug Transaction GUID not Unique
Posted by "e.semog" <e....@gmail.com>.
[Cross-posting to the forum in case you aren't subscribed to the
dev@activemq.apache.org mailing list]
Thanks for the info on this issue. Would you be able to enter a JIRA item
for this, along with any unit test code that exposes the problem? Having
unit tests helps us ensure we have fixed the problem and guards against any
future regressions.
Best,
Jim
--
View this message in context: http://activemq.2283324.n4.nabble.com/Possible-NMS-Transaction-bug-Transaction-GUID-not-Unique-tp3735015p3740525.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Possible NMS Transaction bug Transaction GUID not Unique
Posted by Jim Gomes <e....@gmail.com>.
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 <sp...@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.
>
Re: Possible NMS Transaction bug Transaction GUID not Unique
Posted by spenceee <sp...@gmail.com>.
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.
Re: Possible NMS Transaction bug Transaction GUID not Unique
Posted by Jim Gomes <e....@gmail.com>.
Thanks for the info on this issue. Would you be able to enter a JIRA item
for this, along with any unit test code that exposes the problem? Having
unit tests helps us ensure we have fixed the problem and guards against any
future regressions.
Best,
Jim
On Wed, Aug 10, 2011 at 10:50 PM, spenceee <sp...@gmail.com> wrote:
> G'day, first time poster, apologies if I'm in the wrong forum.
>
> I think I have found a defect in the NMS 1.5.0 API regarding the allocation
> of a Resource Manager GUID in the NetTxConnection class. This is sent to
> the MS DTC as a unique identifier for the resource manager. I've read the
> source code for this class and it is derived from the BrokerInfo.BrokerID
> from the connection. According to MSDN the ID needs to be:
>
> resourceManagerIdentifier
> A unique identifier for a resource manager, which should persist across
> resource manager failure or reboot.
>
> If I understand correctly, each new connection to the broker will get a new
> value for BrokerID. Therefore I can see little value in deriving the GUID
> from the broker info. I think it would make more sense for
> NetTxConnection.ResourceManagerGUID to set the value internally to
> Guid.NewGuid(); and then return this value.
>
> internal resourceManagerGuid = Guid.NewGuid; //Guaranteed* unique
> and threadsafe.
> internal Guid ResourceManagerGuid
> {
> get
> {
> return resourceManagerGuid;
> }
> }
>
> The only reason I can see for receiving this error is if somehow the same
> brokerID is returned. I am using 4 threads to make connections with to the
> broker concurrently on 4 separate Active MQ connection objects.
>
> I've santised the error I've received if it's helpful.
>
> Error : 2011/19/12 04:19:44 xxx: Source: System.Transactions
> Message: A resource manager with the same identifier is already registered
> with the specified transaction coordinator. (Exception from HRESULT:
> 0x8004D102)Stack: at
> System.Transactions.Oletx.IDtcProxyShimFactory.CreateResourceManager(Guid
> resourceManagerIdentifier, IntPtr managedIdentifier, IResourceManagerShim&
> resourceManagerShim)
> at
> System.Transactions.Oletx.OletxResourceManager.get_ResourceManagerShim()
> at System.Transactions.Oletx.OletxResourceManager.Reenlist(Int32
> prepareInfoLength, Byte[] prepareInfo, IEnlistmentNotificationInternal
> enlistmentNotification)
> at
> System.Transactions.Oletx.OletxTransactionManager.ReenlistTransaction(Guid
> resourceManagerIdentifier, Byte[] recoveryInformation,
> IEnlistmentNotificationInternal enlistmentNotification)
> at System.Transactions.TransactionManager.Reenlist(Guid
> resourceManagerIdentifier, Byte[] recoveryInformation,
> IEnlistmentNotification enlistmentNotification)
> at Apache.NMS.ActiveMQ.TransactionContext.InitializeDtcTxContext()
> at
>
> Apache.NMS.ActiveMQ.NetTxConnection.CreateAtiveMQSession(AcknowledgementMode
> ackMode)
> at Apache.NMS.ActiveMQ.Connection.CreateSession(AcknowledgementMode
> sessionAcknowledgementMode)
> at xxx.TimeoutRead(Int32 timeOut, Boolean commit)
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Possible-NMS-Transaction-bug-Transaction-GUID-not-Unique-tp3735015p3735015.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>