| Author |
Message
|
| zpat |
 Posted: Tue Jan 31, 2023 3:21 am Post subject: MQ client using Spring JMS |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
MQ client 9.2.5 using JMS Spring to connect to QM on z/os (v9.2).
I seem to recall that the default for Spring is to connect 10 times to the queue manager and all these poll once per second.
This is fairly horrendous with remote, shared QMs.
I know the "receivetimeout" controls the "polling" interval (MQGET WAIT).
What are the Spring config values to reduce the concurrent connection pool size from 10 to say 2?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| robertjaxon |
| Posted: Tue May 02, 2023 2:24 am Post subject: |
|
|
Newbie
Joined: 02 May 2023
Posts: 1
|
To reduce the concurrent connection pool size from 10 to 2, you can modify the Spring configuration file to change the following parameters:
max-concurrent-consumers: This parameter controls the maximum number of concurrent message consumers to be created for the listener container. Its default value is 10. You can change it to 2 to reduce the pool size.
concurrent-consumers: This parameter controls the initial number of concurrent message consumers to be created for the listener container. Its default value is also 10. You can set it to 2 to ensure that only 2 consumers are created initially. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 02, 2023 10:05 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks.
"Developers" seem to be taking Spring JMS boot samples from github and using them for new applications without having much knowledge of MQ.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 03, 2023 12:15 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
Thanks.
"Developers" seem to be taking Spring JMS boot samples from github and using them for new applications without having much knowledge of MQ. |
Isn't that supposed to be the new black where MQ is concerned? Abstract the need to know so "specialist" knowledge isn't needed? Asking for a friend... 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| markt |
| Posted: Wed May 03, 2023 9:38 pm Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| At least with github there's a chance the code might work. Unlike copy/paste from stackoverflow or code generation tools. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu May 04, 2023 1:30 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
| "Developers" seem to be taking Spring JMS boot samples from github and using them for new applications without having much knowledge of MQ. |
This is a common development technique. Why write code from scratch when someone else has gained the knowledge to write what you want? A downside is lack of deep understanding of all the intricacies. "Fiddle with the code until it works"
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Thu May 04, 2023 10:18 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The problem with not understanding what these samples are actually doing is when they do not work - the "developer" has little idea where to look.
I know the MQI pretty well, and vaguely understand how JMS maps to that. However I really don't know what Spring is doing and neither does the "developer" so we might have production critical applications that are not actually fully understood.
Might be a suitable approach for a college course, but not when serious amounts of real money are involved.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun May 07, 2023 4:58 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| zpat wrote: |
The problem with not understanding what these samples are actually doing is when they do not work - the "developer" has little idea where to look.
I know the MQI pretty well, and vaguely understand how JMS maps to that. However I really don't know what Spring is doing and neither does the "developer" so we might have production critical applications that are not actually fully understood.
Might be a suitable approach for a college course, but not when serious amounts of real money are involved. |
Its worse when the developer has moved on, without properly documenting the design or code, and issues crop up, or the code needs to be modified. A new developer will have a long ramp up time, which can seriously delay resolution of issues or code changes.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 08, 2023 5:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Think about what that becomes when you have Spring or Springboot + Camel in transactional mode!
And now you have every iteration of the loop opening a connection, opening the queue, doing a get, closing the queue, closing the connection.
Ain't technology wonderful? :irony: 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Mon May 08, 2023 8:13 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, that does worry me. Especially when the QM is on z/OS as the CPU costs are variable.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon May 08, 2023 5:44 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| fjb_saper wrote: |
Think about what that becomes when you have Spring or Springboot + Camel in transactional mode!
And now you have every iteration of the loop opening a connection, opening the queue, doing a get, closing the queue, closing the connection.
Ain't technology wonderful? :irony: |
Unless a MQ SME reviews the design, considerations for MQ performance and efficiency are often overlooked. That is, until in production, the app support team wonders why it can't do more than about 20 TPS or there are hundreds of MQ channel connections. We recommend volume / performance testing of new MQ apps to avoid unrealistic expectations.
_________________
Glenn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 10, 2023 12:35 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| gbaddeley wrote: |
| fjb_saper wrote: |
Think about what that becomes when you have Spring or Springboot + Camel in transactional mode!
And now you have every iteration of the loop opening a connection, opening the queue, doing a get, closing the queue, closing the connection.
Ain't technology wonderful? :irony: |
Unless a MQ SME reviews the design, considerations for MQ performance and efficiency are often overlooked. That is, until in production, the app support team wonders why it can't do more than about 20 TPS or there are hundreds of MQ channel connections. We recommend volume / performance testing of new MQ apps to avoid unrealistic expectations. |
But nowadays qmgrs have become a commodity, so instead of having the analysis done by the MQ SME, they require a qmgr in isolation with more CPU and run more clients... and as long as the business signs off on it, fat chance getting anything changed!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed May 10, 2023 4:35 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| fjb_saper wrote: |
| But nowadays qmgrs have become a commodity, so instead of having the analysis done by the MQ SME, they require a qmgr in isolation with more CPU and run more clients... and as long as the business signs off on it, fat chance getting anything changed! |
Business signoff: Where a senior manager trusts that all due diligence has been done. One month into production, all hell breaks loose due to something that was overlooked in design, coding, capacity or configuration. Performance testing was not done. Guess who gets to pick up the pieces and work long hours to investigate and remediate the issue.
_________________
Glenn |
|
| Back to top |
|
|
|
|
