| Author |
Message
|
| nize |
 Posted: Wed May 26, 2010 1:19 am Post subject: SHARECONVALLOWED for XMS |
 |
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed May 26, 2010 2:01 am Post subject: Re: SHARECONVALLOWED for XMS |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Nice try but I would strongly advise against its casual usage. This option will impact performance. Think that you would want to share a connection on MDB instances? I think not. Remember that all messages are single threaded through a connection. So if the connection is busy you wait. Not the wanted effect is it?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nize |
| Posted: Wed May 26, 2010 11:13 pm Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Thanks for the warning. The reason that we are looking at consolidating multiple connections on a single channel instance is for the situations where we have a higher number of users of the portal than the number of connections in the connection pool.
So, as far as I can see it we only have two options when the number of concurrent requests are greater than the maximum number of channel instances:
1. using binding connection between Java/C# application and WMQ (i.e. not using SVRCONN at all)
2. sharing the same channel instance (i.e. TCP session) for multiple user requests by using SHARECONVALLOWED
Option 2 could be used together with "connection pooling".
Do you see any other option?
Still I wonder whether option 2 is available for XMS? |
|
| Back to top |
|
|
| mvic |
| Posted: Thu May 27, 2010 1:57 am Post subject: Re: SHARECONVALLOWED for XMS |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| fjb_saper wrote: |
| Remember that all messages are single threaded through a connection. So if the connection is busy you wait. Not the wanted effect is it? |
The first sentence at the OP's URL is
"Multiple instances of an MQI channel can be made to share a single TCP/IP connection"
So it is true that multiple MQ client connections can use a single TCP/IP network connection. This was new in V7.
Re. performance, if each MDB is getting 100 messages per hour, then running a few of those on one TCP/IP connection seems an ok thing - to me. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu May 27, 2010 5:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Re. performance, if each MDB is getting 100 messages per hour, then running a few of those on one TCP/IP connection seems an ok thing - to me. |
100 messages per second may be a point where performance becomes a consideration.
_________________
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 |
|
|
| fjb_saper |
| Posted: Thu May 27, 2010 11:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
In my opinion, sharing a connection becomes a function of your volume, throughput and SLA. There may be very valid reasons for doing so. However one should not assume that just because you can, you should.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Tue Jun 01, 2010 7:01 pm Post subject: Re: SHARECONVALLOWED for XMS |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
Yes.
Look at XMSC_WMQ_SHARE_CONV_ALLOWED property in documentation.
HTH.
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 01, 2010 7:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What you should look at is the V7 option to limit the total number of instances of a particular channel.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nize |
| Posted: Wed Jun 09, 2010 11:46 am Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
| Quote: |
| Look at XMSC_WMQ_SHARE_CONV_ALLOWED property in documentation. |
Thanks! This is what I looked for initially.
| Quote: |
| What you should look at is the V7 option to limit the total number of instances of a particular channel. |
Yes, I have found the new options MAXINST and MAXINSTC in the perspective of protecting the WMQ server.
Since you had comments on using XMSC_WMQ_SHARE_CONV_ALLOWED, would you be able to recommend a pattern for implementing a requester agent (in a request/reply message exchange pattern) using XMS without using too many channel instances?
Scenario:
user portal <-> requester agent <-> XMS <-> WMQ client <-> WMQ <-> JMS <-> provider agent
Say that the requester agent would have 150 concurrent requests, how would the correlation of the responses to the requests be implemented in the requester agent? Say that we have a limitation of 30 channel instances on WMQ for the SVRCONN channel. In other words, would we use a single (or a few) message listeners invoking the onMessage method, or would we use a synchronous pattern using the receive method? In case we would use the Message Listener interface, how would we perform the correlation? How would we deal with threading? Assume that the user requires a response time of 10 seconds. Where would the request context be stored while waiting for the response?
Could you refer to any pattern or (even better) a sample? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 09, 2010 9:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| nize wrote: |
Since you had comments on using XMSC_WMQ_SHARE_CONV_ALLOWED, would you be able to recommend a pattern for implementing a requester agent (in a request/reply message exchange pattern) using XMS without using too many channel instances?
Scenario:
user portal <-> requester agent <-> XMS <-> WMQ client <-> WMQ <-> JMS <-> provider agent
Say that the requester agent would have 150 concurrent requests, how would the correlation of the responses to the requests be implemented in the requester agent? Say that we have a limitation of 30 channel instances on WMQ for the SVRCONN channel. In other words, would we use a single (or a few) message listeners invoking the onMessage method, or would we use a synchronous pattern using the receive method? In case we would use the Message Listener interface, how would we perform the correlation? How would we deal with threading? Assume that the user requires a response time of 10 seconds. Where would the request context be stored while waiting for the response?
Could you refer to any pattern or (even better) a sample? |
This is a tall order... At 150 concurrent requests and a 10 second SLA that gives you normally:
- an average of 15 requests per second
- a max channels for the application of 300 (leave some room to grow)
- a synchronous pattern with receive(long waittime)
- depending on business need a temporary dynamic reply queue with message expiry...
If going for reduced number of connections i.e. 30 max you'd need
- pooling of resources i.e. connections
- an asynchronous callback
- no dynamic but a fixed reply queue
- an MDB consuming all messages without distinction and imperatively using less than 29 instances (otherwise all 30 connections are used up and no connections left for the requests...) Personally I'd think that a single instance would be sufficient.
- an application mechanism (with DB persistency?) that would allow you to match the request to the async response when received, across threads.
Each application instance would require it's own reply to queue or else you need to be able to go also across app instances... (The object would need to fire an event to a listener when updated with the response?)
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nize |
| Posted: Wed Jun 09, 2010 11:57 pm Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
| Quote: |
| a max channels for the application of 300 (leave some room to grow) |
Which is the maximum number of channel instances for a QM instance?
Would it be reasonable with 300 channel instances for a QM instance in respect to memory management and such? I believe that the default limitation is 100? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jun 10, 2010 12:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| nize wrote: |
| Quote: |
| a max channels for the application of 300 (leave some room to grow) |
Which is the maximum number of channel instances for a QM instance?
Would it be reasonable with 300 channel instances for a QM instance in respect to memory management and such? I believe that the default limitation is 100? |
You have to adjust to what your needs are. This is what the channels stanza is for.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| nize |
| Posted: Thu Jun 10, 2010 11:12 pm Post subject: |
|
|
Voyager
Joined: 02 Sep 2009
Posts: 90
|
Yes, I guess thats true.  I tried to find an method to help me predict the amount of memory required per SVRCONN channel instance, but I failed. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Jun 11, 2010 1:34 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| nize wrote: |
| Yes, I guess thats true. I tried to find an method to help me predict the amount of memory required per SVRCONN channel instance, but I failed. |
Predicting is difficult. Measuring / monitoring a test workload is easier. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 11, 2010 4:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| nize wrote: |
| I tried to find an method to help me predict the amount of memory required per SVRCONN channel instance, but I failed. |
Look in the Performance Report Support Packs. They give a baseline for the amount of memory any SVRCONN channel will use. But if one channel is sending 100 byte messages and another is sending 100 MB messages, they will be using different amounts of memory. Which is why there is no answer other than "It depends." to the question of how much memory a channel uses.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
