| Author |
Message
|
| santeciafardoni |
 Posted: Sun Mar 04, 2012 1:36 pm Post subject: |
 |
|
Novice
Joined: 04 Mar 2012
Posts: 13
|
Sorry Bruce,
I mean, since '90 we uses same pattern you have suggested when encountered similar problem with some API/Framework.
Is the first time that by design we are forced to use XMS ( for his async capability ) rather then JMS or Native MQ API. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sun Mar 04, 2012 1:53 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Many posts here proclaim that nothing has changed.
Do not hesitate to tell IBM that this is a completely new application functionality; and that testing has uncovered the symptoms you see.
In future posts, your first sentence should included the statement above. Please don't lead us to (or let us) believe that this application has worked in the past.
A casual reading of your OP would lead us to believe that the application was working last week, but failed mysteriously today. We can only know what you tell us. Please be precise.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| JasonE |
| Posted: Sun Mar 04, 2012 3:42 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Whats the call stack in the FDC (the bit under the box!), and sometimes you have a native call stack as well. If the trap is inside MQ code, you need to take this us with IBM - the fact you are on 7.0.1.7 will help.
Incidentally I see the first post says trap at 0 (dereferencing null) and the second at +18 - does it vary, and if so is the call stack the same when it occurs.
Note you will probably be asked to send in a trace, but if you have fdc's and dumps make sure you submit those as well.
You say you are using XMS? Do you have any client side user exits in the picture? |
|
| Back to top |
|
|
| santeciafardoni |
| Posted: Mon Mar 05, 2012 12:36 am Post subject: |
|
|
Novice
Joined: 04 Mar 2012
Posts: 13
|
Thanks Jason,
this is the backtrace:
| Code: |
---> Stack dump for the faulting thread (0x2A8C) <---
Stack Backtrace:
# ChildEBP RetAddr Param#1 Param#2 Param#3 Param#4 Fn-Loc'n : Module!Function+Offset [File Name # Line+Offset @ Address]
***StackWalk64 Warning: Module does not appear to exist. Following frames may be wrong. Error Code: 0***
00 101DF8F4 00A01710 (078E11F0 0FD8EF28 078E0F78 0FD8EDB0) 05D09CE7 :<Unknown>!<No Symbol Found>, Error Code: 126 <NLN:126>
***StackWalk64 Warning: Module does not appear to exist. Following frames may be wrong. Error Code: 0***
01 101DF92C 4DA410BD (0000016D 0FD8EDB0 078E0F78 0FD8EF28) 00A01710 :<Unknown>!<No Symbol Found>, Error Code: 126 <NLN:126>
02 101DF94C 4E406967 (0000016D 0FD8EDB0 078E0F78 0FD8EF28) 4DA410BD :<Unknown>!nmqiConsumerFunction+0xbd (FPO: [5,0,0])<NLN:487>
03 101DF994 4E407121 (0FD8ED50 101DFA54 101DF9F8 101DF9C4) 4E406967 :<Unknown>!rpqDriveConsumer+0x3c7 (FPO: [6,8,0])<NLN:487>
04 101DF9F0 4E4079D2 (00000000 101DFA54 101DFA3C 101DFA40) 4E407121 :<Unknown>!rpqProcessQueues+0x1e1 (FPO: [8,12,0])<NLN:487>
05 101DFA5C 4E407F03 (0FD91AE8 07878710 101DFA80 101DFA84) 4E4079D2 :<Unknown>!rpqDispatchThreadFn+0x3e2 (FPO: [4,14,0])<NLN:487>
06 101DFA84 4E80615B (07878710 00000000 00000000 078F1868) 4E407F03 :<Unknown>!rpqDispatchThread+0x183 (FPO: [1,3,0])<NLN:487>
07 101DFB00 729129BB (000000AF 1D344679 00000000 00000000) 4E80615B :<Unknown>!xcsSetSupportedThreadLocale+0x2fb (FPO: [1,25,4] [SEH])<NLN:487>
08 101DFB38 72912A47 (00000000 75453677 078F1868 101DFB8C) 729129BB :<Unknown>!endthreadex+0x3b<NLN:487>
09 101DFB4C 77149F42 (078F1868 6C013352 00000000 00000000) 72912A47 :<Unknown>!endthreadex+0xc7<NLN:487>
0A 101DFB8C 77149F15 (729129E1 078F1868 00000000 00000000) 77149F42 :<Unknown>!RtlInitializeExceptionChain+0x63<NLN:487>
0B 101DFBA4 00000000 (729129E1 078F1868 00000000 00000000) 77149F15 :<Unknown>!RtlInitializeExceptionChain+0x36<NLN:487>
---> Raw stack dump <---
ESP : 00 01 02 03-04 05 06 07-08 09 0A 0B-0C 0D 0E 0F ASCII 00 04 08 0C
101DF7FC: 00 00 00 00-60 f8 1d 10-14 c7 3e 66-ff 18 eb 65 ....`ø....>fÿ.ëe 00000000 101df860 663ec714 65eb18ff
101DF80C: 6c f8 1d 10-00 00 00 00-3c 05 71 02-00 00 00 00 lø......<.q..... 101df86c 00000000 0271053c 00000000
101DF81C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF82C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF83C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF84C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF85C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF86C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF87C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF88C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF89C: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF8AC: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF8BC: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF8CC: 00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00 ................ 00000000 00000000 00000000 00000000
101DF8DC: 00 00 00 00-00 00 00 00-00 00 00 00-34 f9 1d 10 ............4... 00000000 00000000 00000000 101df934
101DF8EC: 00 00 00 00-c0 20 89 07-2c f9 1d 10-10 17 a0 00 ..... ‰.,..... . 00000000 078920c0 101df92c 00a01710
101DF8FC: f0 11 8e 07-28 ef d8 0f-78 0f 8e 07-b0 ed d8 0f ..Ž.(...x.Ž..Ã.. 078e11f0 0fd8ef28 078e0f78 0fd8edb0
101DF90C: b0 21 bf 00-00 cd 5e 00-f0 fa 1d 10-9a 1e 09 66 .!....^..ú..š. f 00bf21b0 005ecd00 101dfaf0 66091e9a
101DF91C: ff ff ff ff-00 00 00 00-f0 fa 1d 10-f0 11 8e 07 ÿÿÿÿ.....ú....Ž. ffffffff 00000000 101dfaf0 078e11f0
101DF92C: 70 0f 8e 07-bd 10 a4 4d-6d 01 00 00-b0 ed d8 0f p.Ž...¤Mm....Ã.. 078e0f70 4da410bd 0000016d 0fd8edb0 |
Yes we are forced to use XMS and the issue is still alive only with one client.
Now we are building code to replicate the issue and submit to IBM, starting from XMSApps Sample. Will let you know. |
|
| Back to top |
|
|
| what? |
| Posted: Mon Mar 05, 2012 2:51 am Post subject: .NET Async XMS approach |
|
|
Newbie
Joined: 05 Mar 2012
Posts: 3
|
Hi All,
I'm on a quite similar point here. Going to choose an approach to implement a WMB client, trying to do our best we decided to put together a PoC to explore different solutions. As XMS allows asynchronous message receiving, that was looking like the best approach from the design perspective (XMS -> JMS: standards) and so we implemented an XMS client instead of a native MQ one in this PoC (.Net C#). Some difficulties arised since the beginning, that I'm trying to point out here:
1 XMS is less performing than native MQ, altough XMS has an asynchronous message receiver that I don't see on NativeMQ APIs. At least I'm not aware of such a feature in Native MQ .NET API. and I can't find a sample for this. MQ client library version in use is 7.0.1.7.
2 Neither XMS nor Native MQ implements any connection pooling facility. They just let you have multiplexing with about 10 sessions per connection. I have to write a pool to pre-create about 10 connections to have about the 100 (10 x 10) available communication slots my application will need to have at runtime. Can the 10 session per connection be set to an higher value in XMS or Native MQ ?
3 XMS Is a mature an consolidated interface on top and wrapping MQSeries API in .NET ? I can't see so many example around and I have doubts about the adoption instead of native MQ implementations.
4 If I use an async message listener, to close the session I used to receive a message (scenario here is the usual one: send a message and receive a response) I have to close the session in the async receiver. I tried to do this in the async message listener but an exception comes out saying I shoudn't do that in a message listener, altough the session.close() method is suitable to be called in a thread different from the receiver one. Confused here by this approach. Where, with an asynchronous message receiver the session.close() should be called so ? I have a workaround in my mind, but sounds "exotic".
5 I suppose the async receiver facility in XMS is built with some blocking threads in the XMS to nativeMQ wrapper. Is this the way you think it has been implemented ?
I'm sorry for the long list of considerations exposed here, but the matter is quite hard to have a clear direction on common XMS problems. My options, because of the above points are still there: XMS or MQ native, for .NET clients ? Did any of you found such issues in the past ?
Thanks.
s. |
|
| Back to top |
|
|
| JasonE |
| Posted: Mon Mar 05, 2012 5:34 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| Odd - definitely needs a pmr. Looks like something in the areas of async consume, but not enough detail in the above to pin it down at all, sorry. If you do raise a PMR, post the first 5 digits of its number in here please. |
|
| Back to top |
|
|
| santeciafardoni |
| Posted: Tue Mar 20, 2012 2:59 am Post subject: |
|
|
Novice
Joined: 04 Mar 2012
Posts: 13
|
Hi All ( and sorry for the delay ).
Jason these are the PMR's first 5 digits : 79584.
Here some little news:
We have changed approach, we are using .NET MQ Client API now and we are amazed by his tremendous performances ( 300% faster ).
Does this sounds standard ?
Last edited by santeciafardoni on Mon May 14, 2012 6:53 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 20, 2012 5:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| 4 If I use an async message listener, to close the session I used to receive a message (scenario here is the usual one: send a message and receive a response) I have to close the session in the async receiver. I tried to do this in the async message listener but an exception comes out saying I shoudn't do that in a message listener, altough the session.close() method is suitable to be called in a thread different from the receiver one. Confused here by this approach. Where, with an asynchronous message receiver the session.close() should be called so ? I have a workaround in my mind, but sounds "exotic". |
That looks fishy and not at all in accordance to JMS standards. So what are we missing here? I would expect that you close the session in the thread that created it.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| santeciafardoni |
| Posted: Tue Mar 20, 2012 6:09 am Post subject: |
|
|
Novice
Joined: 04 Mar 2012
Posts: 13
|
This is one of our first issues. If we close the Session in the same Thread that created it, the XMS MessageListener stops receiving messages.
This is one of the main reason that drive us to change approach using MQ Client. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 21, 2012 10:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| santeciafardoni wrote: |
This is one of our first issues. If we close the Session in the same Thread that created it, the XMS MessageListener stops receiving messages.
This is one of the main reason that drive us to change approach using MQ Client. |
So you need to have a Runnable model where you call the run method and only stop the session when the run method exits...
Nothing new there. Working same as in JMS. What was the need driving to the close of the session before the work is done?
Worst case scenario, you could have coordinated through a synchronized object...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| santeciafardoni |
| Posted: Wed Mar 21, 2012 10:53 am Post subject: |
|
|
Novice
Joined: 04 Mar 2012
Posts: 13
|
| fjb_saper wrote: |
So you need to have a Runnable model where you call the run method and only stop the session when the run method exits...
Nothing new there. Working same as in JMS. What was the need driving to the close of the session before the work is done?
Worst case scenario, you could have coordinated through a synchronized object...
|
You're perfectly right, but you know also that this means that all became Sync through a Runnable pattern, right ? So at this point ( and with the issue that drive me to open this topic ) we've choose to switch to MQ Client.
In any case I will give you notice when the PMR is solved. |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Thu Mar 29, 2012 8:27 pm Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
| Quote: |
1 XMS is less performing than native MQ, altough XMS has an asynchronous message receiver that I don't see on NativeMQ APIs. At least I'm not aware of such a feature in Native MQ .NET API. and I can't find a sample for this. MQ client library version in use is 7.0.1.7.
|
XMS does extra work of processing JMS headers. Hence less performing than native MQ which does not do much of header processing other than MQMD. It is expected. You are right, native MQ C# interface does not have asynchronous message receiver.
| Quote: |
2 Neither XMS nor Native MQ implements any connection pooling facility. They just let you have multiplexing with about 10 sessions per connection. I have to write a pool to pre-create about 10 connections to have about the 100 (10 x 10) available communication slots my application will need to have at runtime. Can the 10 session per connection be set to an higher value in XMS or Native MQ ?
|
My understanding (I may be wrong) is that connection pooling is not provided by clients libraries, instead it's the job of the application that uses these libraries for example WebSphere Application Server maintaining pool of connections to WebSphere MQ.
The sharing conversation value (in your words sessions per TCP connection) can be changed in the definition of SVRCONN channel that your XMS application is using. By default it's 10 and it can be changed to any value.
| Quote: |
3 XMS Is a mature an consolidated interface on top and wrapping MQSeries API in .NET ? I can't see so many example around and I have doubts about the adoption instead of native MQ implementations.
|
No that's not entirely true, it's not a wrapping over MQ Series API in .NET. Just look into Samples folder of XMS installation and you will find a number of samples demonstrating a number of features.
| Quote: |
4 If I use an async message listener, to close the session I used to receive a message (scenario here is the usual one: send a message and receive a response) I have to close the session in the async receiver. I tried to do this in the async message listener but an exception comes out saying I shoudn't do that in a message listener, altough the session.close() method is suitable to be called in a thread different from the receiver one. Confused here by this approach. Where, with an asynchronous message receiver the session.close() should be called so ? I have a workaround in my mind, but sounds "exotic".
|
Session.Close() should not be issued in the async receiver which is receiving message for that session. I would recommend you to look at the "SimpleAsyncConsumer.cs" sample. I have pasted here some relevant snippet on where a session.Close is called.
// Create consumer
consumerAsync = sessionWMQ.CreateConsumer(destination);
// Create message listener and assign it to consumer
messageListener = new MessageListener(OnMessageCallback);
consumerAsync.MessageListener = messageListener;
// Start the connection to receive messages.
connectionWMQ.Start();
// Wait 30 seconds for messages.
Console.WriteLine("Wait for messages asynchronously.");
System.Threading.Thread.Sleep(30000);
// Cleanup
consumerAsync.Close();
destination.Dispose();
sessionWMQ.Dispose();
connectionWMQ.Close();
HTH |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 30, 2012 2:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| shashikanth_in wrote: |
| You are right, native MQ C# interface does not have asynchronous message receiver. |
Weeeeellllll....
At least in MQ 7.1, one can use MQCB from the C language bindings in a C# application... |
|
| Back to top |
|
|
| santeciafardoni |
| Posted: Thu Apr 12, 2012 5:09 am Post subject: |
|
|
Novice
Joined: 04 Mar 2012
Posts: 13
|
| mqjeff wrote: |
Weeeeellllll....
At least in MQ 7.1, one can use MQCB from the C language bindings in a C# application... |
Interop in an Enterprise Application ? Just curious, what dll need to be imported to be able to use MQCB abd MQCTL ?
PS: Dont think our Architecture Team will approve that.  |
|
| Back to top |
|
|
|
|
