1.0.1 work fine with some patches but heap protection or queue managment needed in some

[poulch74]

situations. for example when wifi performance is poor (it happens sometimes then about 30 wifi ap around me) i see in debug output about 100-150 elements in queue. it eats all heap, i see errors OUTBOUND_PUB_TOO_BIG and some next allocation fails with exception and reboot... about patches - i return back _destroyClient but replace delete -> close and patch ESPayncTCPwith issue "onAck hander not firing #160".

[wladwnt]

Have probably the same issue. Do you mean you:

1. patch ESPAsyncTCP with "set _tx_unacked_len to zero in void AsyncClient::_connected"?
2. You call _destroyClient() in PangolinMQTT::_onDisconnect, and in _destroyClient() you close PANGO:TCP, so your code is:

`void PangolinMQTT::_destroyClient(){
if(PANGO::TCP) {
PANGO::TCP->onDisconnect([this](void* obj, AsyncClient* c) { }); // prevent recursion
delete PANGO::TCP; // causes a recurse!
PANGO::TCP=nullptr;
}
}

void PangolinMQTT::_hpDespatch(mb m){ if(_cbMessage) _cbMessage(m.topic.c_str(), m.payload, m.plen, m.qos, m.retain, m.dup); }

void PangolinMQTT::_onDisconnect(int8_t r) {
#if PANGO_DEBUG > 0
PANGO_PRINT1("ON DISCONNECT FH=%u r=%d\n",PANGO::_HAL_getFreeHeap(),r);
#endif
_connected=false;
PANGO::_clearQ(&PANGO::TXQ);
PANGO::_clearFragments();
PANGO::_nPollTicks=PANGO::_nSrvTicks=0;
if(PANGO::TCP){
_destroyClient();
if(_cbDisconnect) _cbDisconnect(r);
}
} `

[wladwnt]

Does it make sense to check in application if PANGO::TXQ.size() is too high, then prevent new publish() ...

[poulch74]

1. yes
2. no. in 1.0.1 PANGO::TCP reused so delete replaced with close()
   TXQ.size can be for example 10 but huge payload.. so i check GetFreeHeap and if it about 10000 - block publish.

[HamzaHajeir]

You can check H4AsyncMQTT, as it relies of a solid TCP client that Phil built its bases.

[poulch74]

I prefer clean PangolinMQTT without H4 dep… (the best solution for me PangolinMqtt+ EspAsyncTCP+ EspAsyncWebServer with websocket support) but in fact now in my current project I use  https://github.com/bertmelis/espMqttClient  

Вторник, 1 августа 2023, 22:43 +03:00 от Hamza Hajeir ***@***.***>:     You can check H4AsyncMQTT , as it relies of a solid TCP client that Phil built its bases. — Reply to this email directly, view it on GitHub , or unsubscribe . You are receiving this because you authored the thread. Message ID: <philbowles/PangolinMQTT/issues/33/1660971595 @ github . com>

    -- Павел Чаузов Отправлено из Почты Mail.ru  

[proddy]

I prefer clean PangolinMQTT without H4 dep… (the best solution for me PangolinMqtt+ EspAsyncTCP+ EspAsyncWebServer with websocket support) but in fact now in my current project I use  https://github.com/bertmelis/espMqttClient  

same here. It has a smaller footprint which is critical to my project.

[HamzaHajeir]

I see your preferences, however the only extra dependency is H4 scheduler, which is critical for the solid TCP functioning beside the whole stack. For ESP32 the TLS is achievable. But for ESP8266 we need some memory management preventing OOM, which is critical for large projects, it should be soon to implement such. We will keep it close to ESP8266, but for the 32 it is so reliable. For a product I work on, we use ESP32-S3 with 2MB PSRAM! However one can run a complete H4Plugins stack by a PlatformIO project "[H4Plugins_Env](https://github.com/hamzahajeir/h4plugins_env)", with an option to test for ESP8266. The environment enables to run any sketch across the stack.

…

On Wed, Aug 2, 2023, 10:09 Proddy ***@***.***> wrote: I prefer clean PangolinMQTT without H4 dep… (the best solution for me PangolinMqtt+ EspAsyncTCP+ EspAsyncWebServer with websocket support) but in fact now in my current project I use https://github.com/bertmelis/espMqttClient same here. It has a smaller footprint which is critical to my project. — Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH3O7J6NHKF3NZ3VKU564ADXTH4KRANCNFSM4XLZIBBQ> . You are receiving this because you commented.Message ID: ***@***.***>