Connection exception occurred, but Pushy still used it about pushy HOT 2 CLOSED

I'm sure you've been busy, just sending again for visbility.
@jchambers

from pushy.

It sounds like everything here is working as intended. To address your questions directly:

It seems that after encountering the IOException…, the other requests should be sent by other connections rather than nioEventLoopGroup-25-1. But Pushy still used nioEventLoopGroup-25-1(Http2Exception$StreamException, ClosedChannelException).

An exception on a channel is generally not fatal. All kinds of exceptions can occur that apply only to a single stream (and thus only a single notification), and closing a connection after every exception would lead to expensive and unnecessary cycling of channels. This is, as near as I can tell, working as intended.

There is another strange phenomenon where nioEventLoopGroup-25-1 handleConnectionRemoved, and then nioEventLoopGroup-25-3 starts receiving responses.

That seems normal to me, but perhaps I don't understand the concern. If I understand the implication correctly, I think you're saying that for a single channel, it appears that the channel is removed from the pool before it begins processing responses. If that's the case, that can certainly happen because the channel pool is using one event loop while the channel itself is using another to process traffic to and from the APNs server. Since they're on different threads, there's no guarantee as to the order in which events from thread A and thread B will be interleaved.

All "handleConnectionRemoved"s were found in nioEventLoopGroup-xx-1. Is it designed in this way?

Yes. Channel pools use a single event loop to make sure pool-related events are processed in order.

Additionally, I have configured 4 connections, but the other 2 threads are rarely being used. Is this normal?

Without knowing specifically how threads are getting mapped to connections in your specific scenario, I don't know, but I don't think that's necessarily unexpected. I don't think Netty guarantees that channels will be evenly distributed across threads in an event loop group, so it may be that multiple channels are getting assigned to the same thread.

In all, none of this sounds alarming or like anything is behaving incorrectly. I don't think there's any action to be taken, and so I'll close this issue for now.

from pushy.