Resolution:
Yes, it can have.

For flow control to work, the global parameter must be enabled, there  must be active consumers on the
flow-controled destination, and the  server is blocking the producer's send call by delaying the producer's
send response. So it is only after the message is put in the  destination that the flow control can occur
(but delaying the response to the producer, which effectively block the send call from the  application perspective).
If you start other producers, they will follow  the same pattern, put a message and then if above the flow control
threshold, be blocked. As you can see, flow control value is not an  absolute limit, but instead a threshold.

So we may need to combine flow control and maxbytes if you want to  limit the amount of data in the destination.

Now, keep in mind that flow control is, as described earlier, causing  the producer's send method to block. But there
are situations where the  EMS client API is not waiting for a confirmation from the server, namely when sending
NON_PERSISTENT messages, or when using a transaction. If each send would wait for a server's response,
performance would degrade and defeat the point of using non persistent messages for instance. So  the EMS client
API is maintaining some counters (both in term of number of messages sent and size) when the server has the global
flow control parameter enabled. When reaching those threshold (either number of size of messages sent), the client is
actually waiting for a response from  the server. It allows the client and server to exercise the flow control even in
situations where the client is normally not waiting for any response from the server following a send.

With all the above, it is easy to understand that a destination can have  pending messages above the flow control threshold.
Probably that the you want to use maxbytes  instead (or in combination with) flow control.

Can a queue have a pending message size more than flow control threshold set?