I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

I have a few questions regarding the setup.

1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

Thanks,
Jim

Hi Jim,

1. The truncated CONNAME does look rather suspicious. Do you see the same truncation when you display the channel using a PCF based tool such as MQ Explorer (or MO71)? i.e. is the truncation at the presentation layer, or is that truly what the CONNAME is? You could also look at another view of the same data by issuing the following command:-

   DISPLAY CLUSQMGR(QC90) CHANNEL CONNAME

   The fact that the channel is running successfully does suggest only a display issue, unless the nameserver is able to resolve that hostname with or without the svc.cluster.local bit on the end! The port number of 1414 is redundant of course.

2. It is quite normal and expected to only define one CLUSRCVR channel into each queue manager in a cluster and then to see every member of the cluster connect to that queue manager using that CLUSRCVR channel name. Generic receivers (as they are called) were a best practice long before cluster channels came along. Perhaps you are more familiar with the concept used by SVRCONN channels? You make one definition and then multiple client applications can come along and connect using that one channel name. Same is true for RCVR channels, and also for CLUSRCVR channels. One definition and multiple running instances (channel statuses). This is why channel status has helpful attributes such as RQMNAME and CONNAME to show which running instance you are looking at.

3. I'm not a K8S expect so will leave your third question to someone who is, to answer.

Cheers,
Morag

I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

I have a few questions regarding the setup.

1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

Thanks,
Jim

Hi Jim,

1. The truncated CONNAME does look rather suspicious. Do you see the same truncation when you display the channel using a PCF based tool such as MQ Explorer (or MO71)? i.e. is the truncation at the presentation layer, or is that truly what the CONNAME is? You could also look at another view of the same data by issuing the following command:-

   DISPLAY CLUSQMGR(QC90) CHANNEL CONNAME

   The fact that the channel is running successfully does suggest only a display issue, unless the nameserver is able to resolve that hostname with or without the svc.cluster.local bit on the end! The port number of 1414 is redundant of course.

2. It is quite normal and expected to only define one CLUSRCVR channel into each queue manager in a cluster and then to see every member of the cluster connect to that queue manager using that CLUSRCVR channel name. Generic receivers (as they are called) were a best practice long before cluster channels came along. Perhaps you are more familiar with the concept used by SVRCONN channels? You make one definition and then multiple client applications can come along and connect using that one channel name. Same is true for RCVR channels, and also for CLUSRCVR channels. One definition and multiple running instances (channel statuses). This is why channel status has helpful attributes such as RQMNAME and CONNAME to show which running instance you are looking at.

3. I'm not a K8S expect so will leave your third question to someone who is, to answer.

Cheers,
Morag

I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

I have a few questions regarding the setup.

1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

Thanks,
Jim

I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

I have a few questions regarding the setup.

1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

Thanks,
Jim

I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

I have a few questions regarding the setup.

1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

Thanks,
Jim

I'm creating Helm charts to deploy a 3-node uniform cluster into our Kubernetes environment.  There are two repos in the cluster (QC90 & QC91).  The third member (QC92) is not a repo.  This appears to be working correctly in that when I run "dis chstatus(psinv*)" on each member I see all the expected sender and receiver channels there with status of RUNNING. 

I have a few questions regarding the setup.

1) When I run "dis chl(psinv*) conname" to display the connection names I see this.  Note the CONNAME value for the first sender channel is truncated.  Is this normal?  I know from the qm.ini file the CONNAME value I'm supplying has the full length, same as the others.


2) For the two receiver channels I see the same channel name (PSINV_QC90) is used.  Is that correct?  I'm using this command to define these:

3) (Perhaps more of a K8s question) Since I'm doing this in a Kubernetes environment should I deploy a Service for each MQ server instance in the Statefulset?  I currently have a single Service for the three.

Thanks,
Jim