when publish message with confirm, confirm ack wait long time will lead create channel spent long time ?

[CrackerGit]

[michaelklishin]

I will convert this issue to a GitHub discussion. Currently GitHub will automatically close and lock the issue even though your question will be transferred and responded to elsewhere. This is to let you know that we do not intend to ignore this but this is how the current GitHub conversion mechanism makes it seem for the users :(

[michaelklishin]

I do not really understand the question, nor have we any executable evidence or metrics data. Publisher confirms don't have any effect on how long it takes to open a channel. It's a separate step (a network round trip). I don't see how this is generally
relevant given that channels are meant to be long-lived.

Channels with confirms enabled do a bit more work. Confirm notifications all the way from the source (queue replicas) to channel and back to the client are all done asynchronously, so their overhead is not going to be drastic.

[CrackerGit]

I think so too, but the phenomenon is very strange, I found by recording methods perform time-consuming when creating the channel took around 30 s in AmqpChannel $BlockingRpContinaution. GetReply (the rabbitmq Java client).This is the same time that I set the confirm ack to sleep, and this does not affect the creation of channels in the rest of the Connection, so I have eliminated the machine resource issue.I wonder if there is a possibility that when a Channel is created in a connection there is a lock that depends on some state of an existing Channel.
Use AMQP Client 5.4.3, Rabbit MQ Server 3.7.6, Erlang 9.3

[CrackerGit]

maybe this is rabbit mq java client issue, when confirm not reply , connection can't read message from stream.