| [paho-dev] DEFAULT_MAX_INFLIGHT? |
| Hi, I was doing some testing with the Paho java client library and when I sent a lot of messages (especially at QoS 1 which requires an ack) I started getting exceptions thrown for REASON_CODE_MAX_INFLIGHT. It looks like the default is hardcoded to be 10 here: My shallow understanding of how the client works is that if you have a persistent message, it’s stored (in memory or disk) but it also seems to be checking this limit first, which seems to mean that the maximum number of stored/buffered messages is 10, no matter what persistent backing store you are using? I could hack the client library code to fix that limit, but it still seems very low to me. The use case is a device where the network might be down for minutes or hours at a time, and the client persistence feature is great and all, but that’s really not much of a buffer. I feel like that’s actually a bug. I could patch the code, but maybe it should be configurable? Or removed entirely if you’re using file based persistence? Should I file a bug and submit a patch? |