The behaviour is going to be dependent on how your components are actually configured, so it's hard to say specifics without more detail on how e.g your router and broker are actually configured to work together with the clients.
Senders have no ability to control credit, it is granted by the receiver end of a link such that the sending end of the link can transfer messages across to it. For example in a simple client-broker usage, the broker will grant credit to a sender allow messages to be produced onto its queues/topics, and a consuming client will grant credit to the broker to receive messages from its queue/topic, but the two message flows are independent, the sender client doesn't see credit from the receiver client, they each transfer messages independently to/from the broker. When you have the router in between the broker and producer/consumer clients, then what happens will depend on how things have been set up to operate, e.g whether you are using routing links through to the broker, or if the router is message-routing messages to the broker. See http://qpid.apache.org/releases/qpid-dispatch-1.12.0/user-guide/index.html#how-routers-route-messages-qdr for an overview of these. That will influence where credit is effectively being granted to/from and how messages flow between components. E.g with message routing the router itself is then granting credit to senders, and itself being granted credit from the broker, but it doesn't take responsibility for accepting/other the messages, that would still happen end to end between the client and broker and vice versa. Robbie On Fri, 10 Jul 2020 at 16:03, tomt <tt...@netapp.com> wrote: > > Thanks for the fast response. I spent a good part of the afternoon looking > into the whole flow control system to understand better given what you had > asked. > > I am using the Python client as my receivers and the C++ API as my senders > who each synchronously send on their own threads as fast as possible. > > I dug a little deeper and found the Python client starts off receivers with > 10 credits as the default since I have not taken credits into account for > anything I've done so far. I am having an assumption here that increasing > the number will increase my throughput, but I think I still lack some > general understanding here. > > If I have multiple receivers subscribed to a given topic and they each have > some X amount of credits, how does the sender account for this when sending? > Some receivers could be slower in replenishing credits than others and the > sender only sends to the topic and has no idea how many receivers there are. > After further looking at the examples and AMQP 1.0 spec, it doesn't seem > like I have much ability at all to control credits from the sender side at > all. Do you have anything I can look at to learn more about the flow > control feature? > > Thanks > > > > -- > Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
