| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| .NET: AccessViolationException with concurrent put |
« View previous topic :: View next topic » |
| Author |
Message
|
| gsccs |
 Posted: Tue Jul 19, 2011 7:14 am Post subject: .NET: AccessViolationException with concurrent put |
 |
|
Newbie
Joined: 19 Jul 2011
Posts: 2
|
Hi,
we're facing a multi-threading issue with the .NET client library, fix pack v7.0.1.5, on a WinXP machine:
When putting messages onto a queue concurrently, after some time we get the following exception:
| Code: |
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at IBM.WMQ.MQCommonServices.xtr_fnc_entryFn(UInt32* pCtl, UInt32 component, UInt32 module)
at IBM.WMQ.MQCommonServices.TraceEntry(String objectId, UInt32 component, UInt32 method, Object[] parameters)
at IBM.WMQ.CommonServices.TraceEntry(String objectId, UInt32 component, UInt32 method, Object[] parameters)
at IBM.WMQ.MQBase.TrEntry(UInt32 method, Object[] parms)
at IBM.WMQ.MQPutMessageOptions.ClearInvalidFields(Int32 Version)
at IBM.WMQ.MQPutMessageOptions..ctor() |
We also get the same exception through a different path:
| Code: |
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at IBM.WMQ.MQCommonServices.xtr_fnc_entryFn(UInt32* pCtl, UInt32 component, UInt32 module)
at IBM.WMQ.MQCommonServices.TraceEntry(String objectId, UInt32 component, UInt32 method, Object[] parameters)
at IBM.WMQ.CommonServices.TraceEntry(String objectId, UInt32 component, UInt32 method, Object[] parameters)
at IBM.WMQ.MQBase.TrEntry(UInt32 method, Object[] parms)
at IBM.WMQ.MQMessageDescriptor.ClearInvalidFields(Int32 Version)
at IBM.WMQ.MQMessageDescriptor..ctor()
at IBM.WMQ.MQMessage..ctor() |
We use the following connect options:
| Code: |
private readonly Hashtable connectionProperties = new Hashtable
{
{ MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT },
{ MQC.CONNECT_OPTIONS_PROPERTY, MQC.MQCNO_HANDLE_SHARE_BLOCK }
}; |
According to the documentation, these options should allow reusing the same queue handle from multpile threads concurrently.
Also, we intermittently see the following exception:
| Code: |
System.ArgumentException: Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count)
at IBM.WMQ.MQDestination.Put(MQMessage message, MQPutMessageOptions pmo) |
That one is usually accompanied by lots of RC 2009 errors.
All of the above events leave a message in the Windows event log, as well as in AMQERR01.LOG:
| Code: |
Internal error on call to SSL function on channel 'CL2001'.
An error indicating a software problem was returned from a function which is used to provide SSL support. The error code returned was '3'. The function call was 'gsk_secure_soc_read'. The channel is 'CL2001'; in some cases its name cannot be determined and so is shown as '????'. The channel did not start. |
This points to some problem with SSL (which we're bound to use), but the return code just means "An internal error has occurred." Same message is logged in AMQERR01.LOG . Also, the code is run as a Windows service, where we couldn't get the SSL support to work back in version v5.3. Maybe there's a connection here.
Unfortunately, I couldn't so far reliably reproduce the issue via some simple test code. It only shows in our full-scale application.
Does anyone have an idea what could be causing this, or how to work around it in some way (except for single-threading the whole thing)? I'm really stuck here given the variety of issues and the lack of detailed error information.
Many thanks,
Georg |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jul 19, 2011 1:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
You are using a client channel with WMQ 7.0.1.5
What is the value of sharecnv on the SVRCONN channel?
What happens if you set it to 1?
Also are you using syncpoint?
Hope this helps some 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gsccs |
| Posted: Wed Jul 20, 2011 12:59 am Post subject: |
|
|
Newbie
Joined: 19 Jul 2011
Posts: 2
|
I assume you're referring to the
| Code: |
| MQEnvironment.SharingConversations |
property, which defaults to 10.
Setting this to 1 doesn't help the issue, unfortunately.
I'll probably just fall back to synchronize the puts myself, despite the obvious performance implications. I'm a bit disappointed though by the complexity of getting this seemingly simple use case to work.
Thanks |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jul 20, 2011 11:07 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| gsccs wrote: |
I assume you're referring to the
| Code: |
| MQEnvironment.SharingConversations |
property, which defaults to 10.
Setting this to 1 doesn't help the issue, unfortunately.
I'll probably just fall back to synchronize the puts myself, despite the obvious performance implications. I'm a bit disappointed though by the complexity of getting this seemingly simple use case to work.
Thanks |
Don't share the handles between threads.
Have each thread carry its own conversation.
Don't open and close the queue for each put.
The performance implication should be minimum
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Jul 20, 2011 1:46 pm Post subject: Re: .NET: AccessViolationException with concurrent put |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| gsccs wrote: |
| According to the documentation, these options should allow reusing the same queue handle from multpile threads concurrently. |
I think you are correct, since an HObj (object handle) is usable only on the HConn where it was created, and your use of MQCNO_HANDLE_SHARE_BLOCK should tell MQ to serialize your calls for the same HConn.
I am not sure how this principle transfers to the .NET classes, however.
I am going on an educated guess, but I think you are concurrently using the same MQPutMessageOptions and MQMessageDescriptor objects on separate threads. I don't think that is allowed.
fjb_saper's advice is good, IMHO. Keep everything related to each MQ connection private within its own thread. Separate HConns can be used concurrently, with no serialization, which might be what you want, depending on your app design of course.
Hope this helps |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
