Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Good catch on the Jetty default. That requestHeaderSize limit comes from Jetty itself (the embedded web server Mango runs on), and Mango doesn't currently expose a mango.properties setting that maps to it. Mango exposes other web server tuning properties (web.threads.maximum, web.requests.queueSize, file upload and websocket buffer sizes, etc.), but request header size isn't wired through. A couple of options: Trim the proxy's injected headers. If your in-house proxy is adding several large headers, reducing what it injects (or moving some of that data to a request body/cookie instead) addresses the actual cause rather than working around a limit. Terminate at a reverse proxy in front of Mango. Nginx or Apache in front of Mango (see our HTTP and HTTPS Settings guide) gives you a layer where header size limits are configurable (large_client_header_buffers in nginx, for example) before the request reaches Mango's embedded Jetty server at all. This is likely your most practical fix given the limit is coming from Jetty's defaults.

@mihairosu FYI - Image issue with the forum has been fixed.

Hello @mihairosu, Single data point not publishing from MangoES to MangoEnterprise, steps to try: If other points on the same publisher are working but one specific point is not arriving on the Enterprise side, the most common cause is an XID mismatch introduced when the point was removed and re-added to the publisher. Work through these steps in order: On MangoES: Go to Publishers and open the publisher sending to MangoEnterprise Find the entry for the affected data point and note its Published Point XID (this is separate from the data point XID, it typically looks like PP_xxxxxxxx) Confirm the data point itself is healthy: add it to a Watch List and verify it is receiving fresh values from the Modbus source Confirm the data point's Logging Type is not set to Do Not Log, some publisher configurations will not forward a point that has no logged values On MangoEnterprise: Go to the Data Source that receives published data from MangoES Find the data point that is supposed to receive this value and open its configuration Look at the Point Locator, it will contain the Published Point XID it is listening for Compare this XID to the one you noted on MangoES, if they do not match, this is the cause To fix: Update the Point Locator on the MangoEnterprise data point to match the current Published Point XID from MangoES Save the data point, then disable and re-enable the data source on MangoEnterprise to force it to reconnect If the XIDs already match, also check: The data point and its data source are both enabled on MangoEnterprise The data type on the Enterprise point matches what MangoES is sending (e.g., both NUMERIC) The publisher on MangoES shows a healthy connection status with no errors The remove/re-add step almost always generates a new Published Point XID on MangoES while the Enterprise side still holds the old one, updating the Point Locator on Enterprise is usually all that is needed

@joeamiraglia Just wanted to confirm that the latest update as of a couple of days ago, was successful.

Its good to see the validation of mango is fixed.

@Jdiaz-co said in Timeout to lock table systemsettings: hello good, I'm having a problem. I'm using Mango 3.7.7 and the application crashes every so often. The error I'm getting is this: ERROR 2025-10-27T08:26:50,187 (com.serotonin.m2m2.util.timeout.TimeoutTask.run:61) - Uncaught Task Exception org.springframework.dao.CannotAcquireLockException: PreparedStatementCallback; SQL [select settingValue from systemSettings where settingName=?]; Tiempo vencido intentando trabar (lock) la tabla "SYSTEMSETTINGS" Timeout trying to lock table "SYSTEMSETTINGS"; SQL statement: select settingValue from systemSettings where settingName=? [50200-199]; nested exception is org.h2.jdbc.JdbcSQLTimeoutException: Tiempo vencido intentando trabar (lock) la tabla "SYSTEMSETTINGS" I would appreciate any help. thank you Hello, This error comes from the embedded H2 database: something is holding a lock on the SYSTEMSETTINGS table too long, so reads (like select settingValue from systemSettings…) time out and throw CannotAcquireLockException. Common causes: Another process/tool (H2 console, external SQL client) connected to the same H2 DB while Mango is running. Long-running DB operations (backups, purges, heavy writes) that keep the table locked. Short default H2 LOCK_TIMEOUT (1s) causing normal contention to show up as errors. Things to try: Make sure only Mango is connected to the H2 DB (no external tools while it’s running). Increase H2 lock timeout in env.properties/mango.properties, e.g. db.url=jdbc:h2:${ma.home}/databases/mah2;LOCK_TIMEOUT=10000 Check logs around the crash time for other FATAL/DB errors that might be the real shutdown cause. If this is a production system (not just a test setup), I strongly recommend: Migrating from H2 to MySQL (more robust under load and concurrency). Upgrading Mango to a more recent supported version if possible, to benefit from DB and stability fixes.