| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| CHANNEL STATUS(BINDING) SUBSTATE(SSLHANDSHK) |
« View previous topic :: View next topic » |
| Author |
Message
|
| MQMB&WAS |
 Posted: Tue Jul 19, 2016 7:36 pm Post subject: CHANNEL STATUS(BINDING) SUBSTATE(SSLHANDSHK) |
 |
|
Centurion
Joined: 12 Jun 2016
Posts: 130
|
Hi everyone,
need help in understating the below issue.
I'm placing msgs to remote queue on qmgr A and they are supposed to go to a local queue on qmgr B, but they are stuck on xmit queue on qmgr A.
CLUSSDR channel on qmgr A is in BINDING or RETRYING state and I'm not able to bring it to RUNNING state. (The below are the various states the channels keeps going to when I and stop and start it)
CHANNEL(TO.QMGRB.SSL) CHLTYPE(CLUSSDR) RQMNAME(QMGRB) STATUS(BINDING) SUBSTATE(RECEIVE) XMITQ(SCTQ)
or
CHANNEL(TO.QMGRB.SSL) CHLTYPE(CLUSSDR) RQMNAME(QMGRB) STATUS(BINDING) SUBSTATE(SSLHANDSHK) XMITQ(SCTQ)
or
CHANNEL(TO.QMGRB.SSL) CHLTYPE(CLUSSDR) RQMNAME(QMGRB) STATUS(RETRYING) SUBSTATE() XMITQ(SCTQ)
And I see the below logs in the AMQERR01.LOG when I try to stop and start the channel
qmgr A
1) AMQ9002: Channel 'TO.QMGRB.SSL' is starting.
2) AMQ9259: Connection timed out from host '11.xxx.xxx.x1'.
EXPLANATION:
A connection from host '11.xxx.xxx.x1' over TCP/IP timed out.
ACTION:
The select() [TIMEOUT] 360 seconds call timed out. Check to see why data was
not received in the expected time. Correct the problem. Reconnect the channel,
or wait for a retrying channel to reconnect itself.
3) AMQ9999: Channel '????' to host 'QMGRB (11.xxx.xxx.x1)' ended abnormally.
Any help is appreciated. |
|
| Back to top |
|
 |
| hughson |
| Posted: Tue Jul 19, 2016 7:59 pm Post subject: Re: CHANNEL STATUS(BINDING) SUBSTATE(SSLHANDSHK) |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| MQMB&WAS wrote: |
| CHANNEL(TO.QMGRB.SSL) CHLTYPE(CLUSSDR) RQMNAME(QMGRB) STATUS(RETRYING) SUBSTATE() XMITQ(SCTQ) |
When it's in retrying it's just waiting in between attempts.
| MQMB&WAS wrote: |
CHANNEL(TO.QMGRB.SSL) CHLTYPE(CLUSSDR) RQMNAME(QMGRB) STATUS(BINDING) SUBSTATE(RECEIVE) XMITQ(SCTQ)
or
CHANNEL(TO.QMGRB.SSL) CHLTYPE(CLUSSDR) RQMNAME(QMGRB) STATUS(BINDING) SUBSTATE(SSLHANDSHK) XMITQ(SCTQ) |
These are probably both indicating the same thing. During an SSL Handshake the channel does send and receive data, so I suspect they are both indicating that the SSL Handshake is the thing that is being slow.
| MQMB&WAS wrote: |
And I see the below logs in the AMQERR01.LOG when I try to stop and start the channel
qmgr A
1) AMQ9002: Channel 'TO.QMGRB.SSL' is starting.
2) AMQ9259: Connection timed out from host '11.xxx.xxx.x1'.
EXPLANATION:
A connection from host '11.xxx.xxx.x1' over TCP/IP timed out.
ACTION:
The select() [TIMEOUT] 360 seconds call timed out. Check to see why data was
not received in the expected time. Correct the problem. Reconnect the channel,
or wait for a retrying channel to reconnect itself.
3) AMQ9999: Channel '????' to host 'QMGRB (11.xxx.xxx.x1)' ended abnormally. |
The SSL Handshake is being so slow that it is timing out after 360 seconds (which is HBINT value + 60 seconds).
You should also take a look at the error log on QMGRB to see what it has to say about the matter. There are a number of things that can cause an SSL Handshake to slow down, the favourite guesses being something related to certificate revocation checks such as OCSP or LDAP look ups. Without knowing your setup however, we would only be guessing.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| DSPS |
| Posted: Wed Jul 20, 2016 2:22 am Post subject: SSLEV |
|
|
Apprentice
Joined: 11 Sep 2008
Posts: 44
Location: Southern England
|
Remember to set SSLEV on both queue managers, otherwise they tend not to declare in AMQERR01.LOG why they're failing to establish SSL connections.
_________________
Distributed Systems Professional Services
WebSphere and MQ Consulting and Training |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Jul 20, 2016 2:25 am Post subject: Re: SSLEV |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| DSPS wrote: |
| Remember to set SSLEV on both queue managers, otherwise they tend not to declare in AMQERR01.LOG why they're failing to establish SSL connections. |
If that's true (which I have not experienced myself) then you should report it to IBM because that is a defect. SSLEV is not meant to have any bearing on what is written to AMQERR01.LOG. It is only meant to control the creation of SSL event messages on the SYSTEM.ADMIN.CHANNEL.EVENT queue.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
