| Author |
Message
|
| mobidzid |
 Posted: Wed Jun 21, 2023 12:41 am Post subject: Orphaned CONN - CHANNEL can't start |
 |
|
Newbie
Joined: 21 Jun 2023
Posts: 3
|
Hi,
We have three channel instances we can't start due to 'AMQ9514E: Channel 'xxx' is in use.' error. That seems to be caused by existing CONNs - we can find them with 'dis CONN(*) where (CHANNEL eq 'xxx')' command. Unfortunately we can't stop those CONNs due to 'AMQ8461I: Connection identifier not found.' error. The PIDs listed in those CONNs are not to be found in the operating system. Looks like something killed the runmqchl processes in a way that MQ didn't notice. BTW: all three orphaned CONNs have exactly the same UOWSTDA/UOWSTTI - and it matches the timestamp of related XMITQs.
Now, the question is: how to get rid of those orphaned CONNs to be able to start the channels again?
MQ9.1 running on RedHat 7.9 in Azure... |
|
| Back to top |
|
 |
| hughson |
| Posted: Wed Jun 21, 2023 1:57 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
Do the orphaned channels show up in DISPLAY CHSTATUS? If yes, does using a STOP CHANNEL MODE(FORCE) before trying the START CHANNEL have any effect?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mobidzid |
| Posted: Wed Jun 21, 2023 2:01 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2023
Posts: 3
|
| hughson wrote: |
| Do the orphaned channels show up in DISPLAY CHSTATUS? |
No. Or, rather, now they do, as STOPPED.
| Quote: |
| If yes, does using a STOP CHANNEL MODE(FORCE) before trying the START CHANNEL have any effect? |
We tried to stop channels with both FORCE and TERMINATE, it takes longer than usually and they go to STOPPED status, but the zombie CONNs are still there.
BTW: when trying to start these channels they hang on status INITIALIZING. Related process 'runmqchl' is started but dies promptly and AMQ9514E is logged.
As a workaround we created new channels but re-used the original XMITQs (to get the messages sent) and it worked. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Jun 21, 2023 2:14 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1916
Location: Bay of Plenty, New Zealand
|
I would assume that next time the queue manager is cycled the orphans will be gone and your can return to the original channels. That's a weird one for sure. You might consider opening a case with IBM so they could improve the detection of such a situation.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| mobidzid |
| Posted: Wed Jun 21, 2023 2:30 am Post subject: |
|
|
Newbie
Joined: 21 Jun 2023
Posts: 3
|
Yeah, we also think restarting should help. But we can't do that just like that, not in production.
We did open a ticket at IBM already. So far the message is 'sorry, no clue', but no final statement yet. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jun 21, 2023 3:57 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
What does display conn show? eg. dis conn(62EA73022517D1E1) all
If there are any incomplete UOW, it may eventually lead to "log rollback" or "log full" errors.
If stopping the conns does not work, restarting the queue manager may be the only means of resolving this issue.
_________________
Glenn |
|
| Back to top |
|
|
|
|
