| Author |
Message
|
| pavavenu |
 Posted: Tue Aug 08, 2023 2:42 am Post subject: Automatic client reconnection is not compatible with client |
 |
|
Newbie
Joined: 11 Jun 2015
Posts: 3
|
Hi All,
MQ client (CD 9.1) connecting to QMGR with version 9.2.0.8 . There were few changes from MQ client as well ( MQ client version - CD version 9.1 to 9.2 ), Springboot 2.7 and started noticing high channel usage .
When we raised PMR , The team suggested that
"Automatic client reconnection is not compatible with client and suggestion was "You should be able to achieve the behavior seen at 9.1.2.0 by disabling automatic client reconnection at level 9.2.4.0."
client don't want to disable this feature ( AutoReconnect ) and expecting us to provide a version which works for both Client reconnection logic with channel sharing ( current value of MQ client channel is set - SHARECNV - 10 )
Earlier the version of MQ client 9010200 did worked for them . I'm not sure if I fully understand what they meant . Can someone guide me here ?
Thanks !! |
|
| Back to top |
|
 |
| hughson |
| Posted: Tue Aug 08, 2023 9:02 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
Makes no sense to me. If it worked at an earlier version, it should work at the newer version. Suggest you go back to the person who said it and ask them what they meant.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| pavavenu |
| Posted: Mon Sep 04, 2023 7:00 am Post subject: |
|
|
Newbie
Joined: 11 Jun 2015
Posts: 3
|
| hughson wrote: |
Makes no sense to me. If it worked at an earlier version, it should work at the newer version. Suggest you go back to the person who said it and ask them what they meant.
Cheers,
Morag |
Thanks Morag , I checked with PMR with the following query and their answer was "Automatic client reconnection is not compatible with client applications sharing channel instances for MQ versions above 9.1 ( up to the latest version )" and they are asking for RFE ( request for enhancement ) if MQ wants to support both .
Even I don't agree with IBM on this statement , we have other clients with MQ 9.2 with both functionality ( reconnection logic + share channel ( SHARECNV=2)
and working as expected.
The PMR which I raised for high channel usage post installation of MQ 9.2 and MQ 9.3 client . with MQ version 9.1.2.0 is working as expected
client has the following jars
mq-jms-spring-boot-started-2.1.2.jar
com.ibm.mq.allclient-9.1.2.0 jar
spring-boot.2.7.4.jar
spring-core-5.3.23.jar
spring-jms-5.3.23.jar
connects to MQ server with 9.2.0.8
sharecnv =10
when client tests with MQ 9.2 - high channel usage is seen ( 1900+ connections ( max instance =2000)
when client reverts to MQ 9.1 - Normal channel usage ( 1000-1200 connections ) |
|
| Back to top |
|
|
| AntBeardsmore |
| Posted: Wed Sep 06, 2023 2:42 am Post subject: |
|
|
Newbie
Joined: 05 Sep 2023
Posts: 3
|
Hi Pavavenu
I think there has been a bit of miscommunication here. Just to be completely clear, Automatic Reconnection and SHARECNV(>1) are absolutely still supported, there is no question of being 'not compatible'.
However, there have been (JMS specific) changes in recent client and QM levels in this area which have led to your initial issue. The topic is a bit complicated, but the key points are reasonably well covered here in the doc page 'Sharing a TCP/IP connection in IBM MQ classes for JMS' (afraid I can't link URL as a new user here !!!)
As you are probably aware one JMSConnection or Context can relate to multiple MQ Connection handles (typically 2, maybe more if discrete sessions are used within the application logic). In older releases, MQ used to allocate these MQ connections 'arbitrarily' to TCP connections (within SHARECNV constraints).
Over the years since client reconnect was introduced we have discovered several situations in which this approach causes problems - for example disconnecting more Connections/Sessions than actually needed during a failover. To prevent these problems, reconnectable JMSConnections (and all associated JMSSessions) are now always allocated to their own discrete TCP connections. By default, non reconnectable clients continue to share sockets, though this can be tuned as described in the link above.
As you have seen, this will typically result in a higher number of channel instances than in older releases - although it was never guaranteed that connection sharing would 'fill' every conversation to the maximum SHARECNV value. It may therefore be necessary to increase MAXINST/MAXINSTC if these were set to 'conservative' levels. There is typically very little downside to increased channel instances and reduced socket sharing (if anything MQ throughput is likely to be slightly improved).
Because of the functional problems sharing sockets between reconnectable JMS connections can introduce, I think we would be resistant to relaxing this restriction in the general case - however, if these clients are actually only exploiting reconnect for HA failover (RECONNECT_QMGR) I think there would be scope for relaxing this and would support an 'Idea' (RFE). Whether this would be seen as a high priority would probably depend on whether we have many customers who see real issues with increasing the number of TCP connections instead in this situation.
I hope this makes more sense of the initial response you received. (And thanks for highlighting Morag - after many years lurking it's finally forced me to register for an ID here!).
Regards
Anthony
IBM MQ Development |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Sep 06, 2023 8:19 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
|
| Back to top |
|
|
| AntBeardsmore |
| Posted: Thu Sep 07, 2023 2:05 am Post subject: |
|
|
Newbie
Joined: 05 Sep 2023
Posts: 3
|
| That's the one (and now I'm past my first two posts, I believe I may be able to include it myself next time!) |
|
| Back to top |
|
|
| pavavenu |
| Posted: Sat Sep 09, 2023 6:28 am Post subject: |
|
|
Newbie
Joined: 11 Jun 2015
Posts: 3
|
Thank you AntBeardsmore and Morag for the suggestion and the link provided. I was waiting for PMR update ( after uploading the trace file again )
PMR suggestion is unchanged  they still say that both functionalities don't work together . it's still a debate I guess
My suggestion to the client was revert to working version as of now and hold it till we migrate our MQ to version 9.3 . |
|
| Back to top |
|
|
| AntBeardsmore |
| Posted: Sun Sep 10, 2023 11:51 pm Post subject: |
|
|
Newbie
Joined: 05 Sep 2023
Posts: 3
|
Hi Pavavenu - I think there is just some confusion over use of the word 'compatible' (I had also taken a look at the relevant ticket before my original reply).
Combining the two options is definitely supported. However the resulting behaviour you might be expecting (sharing sockets across unrelated JMSConnections/sessions) is not possible ('compatible') with the newer client and server levels for the reasons explained. |
|
| Back to top |
|
|
| exad3545 |
| Posted: Sat Oct 28, 2023 11:09 pm Post subject: |
|
|
Newbie
Joined: 28 Oct 2023
Posts: 3
|
In essence, both Automatic Reconnection and SHARECNV (>1) are still fully compatible and supported. Recent changes in JMS have led to an increase in TCP connections, but this is aimed at improving reliability. There's potential for reconsidering this based on user feedback for clients primarily using reconnect for failover.
EDIT by EXERK: Unrelated url removed. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Oct 29, 2023 2:30 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
| exad3545 wrote: |
In essence, both Automatic Reconnection and SHARECNV (>1) are still fully compatible and supported. Recent changes in JMS have led to an increase in TCP connections, but this is aimed at improving reliability. There's potential for reconsidering this based on user feedback for clients primarily using reconnect for failover.
EDIT by EXERK: Unrelated url removed. |
EXERK: This user made their first 3 posts in 6 minutes. They did not ask any questions or make any useful contribution. Intelligent troll?
_________________
Glenn |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 31, 2023 3:00 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gbaddeley wrote: |
| exad3545 wrote: |
In essence, both Automatic Reconnection and SHARECNV (>1) are still fully compatible and supported. Recent changes in JMS have led to an increase in TCP connections, but this is aimed at improving reliability. There's potential for reconsidering this based on user feedback for clients primarily using reconnect for failover.
EDIT by EXERK: Unrelated url removed. |
EXERK: This user made their first 3 posts in 6 minutes. They did not ask any questions or make any useful contribution. Intelligent troll? |
Potentially, which is why I am keeping a close eye on them... 
_________________
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 |
|
|
| petroben |
| Posted: Sat Nov 04, 2023 2:41 am Post subject: |
|
|
Newbie
Joined: 04 Nov 2023
Posts: 2
|
It sounds like you're dealing with compatibility and functionality issues between your MQ client version 9.2 and the QMGR version 9.2.0.8, specifically related to automatic client reconnection and channel sharing.
<Spam URL removed>
The suggestion from the team is to disable automatic client reconnection in your MQ client version 9.2.4.0 to achieve behavior similar to version 9.1.2.0, which may help with the channel usage issue. However, you mentioned that the client does not want to disable this feature.
<Spam URL removed>
To provide a version that works for both client reconnection logic and channel sharing, you may need to explore MQ client versions and configurations that are compatible with both your client's requirements and the QMGR's capabilities. This might involve trying different MQ client versions or configurations to find a suitable balance between the features your client needs and compatibility with the QMGR.
Brooke
Consulting with IBM MQ support or your MQ administrator for more specific guidance on finding a compatible configuration for your specific use case is advisable.
Last edited by petroben on Wed Feb 28, 2024 12:45 am; edited 3 times in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 04, 2023 6:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| petroben wrote: |
It sounds like you're dealing with compatibility and functionality issues between your MQ client version 9.2 and the QMGR version 9.2.0.8, specifically related to automatic client reconnection and channel sharing.
The suggestion from the team is to disable automatic client reconnection in your MQ client version 9.2.4.0 to achieve behavior similar to version 9.1.2.0, which may help with the channel usage issue. However, you mentioned that the client does not want to disable this feature.
To provide a version that works for both client reconnection logic and channel sharing, you may need to explore MQ client versions and configurations that are compatible with both your client's requirements and the QMGR's capabilities. This might involve trying different MQ client versions or configurations to find a suitable balance between the features your client needs and compatibility with the QMGR.
Consulting with IBM MQ support or your MQ administrator for more specific guidance on finding a compatible configuration for your specific use case is advisable. |
READS LIKE AI-GENERATED
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Nov 07, 2023 2:17 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| READS LIKE AI-GENERATED |
Yes, petroben made their first 2 posts at exactly the same time and they just seemed to paraphrase previous posts in the threads. Let me guess that their next post will have some strange link in it.
_________________
Glenn |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Dec 24, 2023 12:58 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand
|
| gbaddeley wrote: |
| bruce2359 wrote: |
| READS LIKE AI-GENERATED |
Yes, petroben made their first 2 posts at exactly the same time and they just seemed to paraphrase previous posts in the threads. Let me guess that their next post will have some strange link in it. |
In fact, instead they went back and edited their reply above and ADDED two links.
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
