You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Alan Conway <ac...@redhat.com> on 2014/01/22 22:38:06 UTC

Finding available channels on a pn_connection_t

I'm trying to solve a problem for HA on the Qpid C++ broker. I need to figure out, for a given connection, will an attempt to open another channel at the other end exceed the channel-max for this connection?

To do that I figure I need to know the number of currently open channels (easy) and the negotiated channel-max for the connection. How can I find that?

Based on a novice reading of transport.c, it looks like the channel-max field of the open performative is ignored. Am I reading this wrong? If not, what is proton assuming - that it can always open 64k channels on any connection? This would violate the limit imposed by the Qpid C++ broker and client of 32k channels (I don't know why they impose that limit but they do.)

Any pointers much appreciated!
Alan.

Re: Finding available channels on a pn_connection_t

Posted by Rafael Schloming <rh...@alum.mit.edu>.
Hi Alan,

I think you're correct. I don't think there is any attempt to limit the
number of channels used. I'll add some API to make the max number of
channels available.

--Rafael

On Wed, Jan 22, 2014 at 4:38 PM, Alan Conway <ac...@redhat.com> wrote:

> I'm trying to solve a problem for HA on the Qpid C++ broker. I need to
> figure out, for a given connection, will an attempt to open another channel
> at the other end exceed the channel-max for this connection?
>
> To do that I figure I need to know the number of currently open channels
> (easy) and the negotiated channel-max for the connection. How can I find
> that?
>
> Based on a novice reading of transport.c, it looks like the channel-max
> field of the open performative is ignored. Am I reading this wrong? If not,
> what is proton assuming - that it can always open 64k channels on any
> connection? This would violate the limit imposed by the Qpid C++ broker and
> client of 32k channels (I don't know why they impose that limit but they
> do.)
>
> Any pointers much appreciated!
> Alan.
>