ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » MQ client using Spring JMS

Post new topic  Reply to topic
 MQ client using Spring JMS « View previous topic :: View next topic » 
Author Message
zpat
PostPosted: Tue Jan 31, 2023 3:21 am    Post subject: MQ client using Spring JMS Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
robertjaxon
PostPosted: Tue May 02, 2023 2:24 am    Post subject: Reply with quote

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
View user's profile Send private message
zpat
PostPosted: Tue May 02, 2023 10:05 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
exerk
PostPosted: Wed May 03, 2023 12:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
markt
PostPosted: Wed May 03, 2023 9:38 pm    Post subject: Reply with quote

Knight

Joined: 14 May 2002
Posts: 502

At least with github there's a chance the code might work. Unlike copy/paste from stackoverflow or code generation tools.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Thu May 04, 2023 1:30 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
zpat
PostPosted: Thu May 04, 2023 10:18 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
gbaddeley
PostPosted: Sun May 07, 2023 4:58 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
fjb_saper
PostPosted: Mon May 08, 2023 5:11 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
zpat
PostPosted: Mon May 08, 2023 8:13 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
gbaddeley
PostPosted: Mon May 08, 2023 5:44 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
fjb_saper
PostPosted: Wed May 10, 2023 12:35 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Wed May 10, 2023 4:35 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Java / JMS » MQ client using Spring JMS
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.