Hi Anne
So, I have sorted the MOD FW rules using my proprietary ruleset and comodo so Im happy the false flags have stopped. I did extensive debugging over a frustrating week with SP Page builder to understand why Joomla 4 core works fine with a highly constrained stack running Plesk, Centos on AWS, etc yet SP Page builder continues to cycle/log out and hold me up due to not been able to do anything with it in a reasonable timeframe.
The blackbox debugging on the processing patterns shows SP Page builder on a very constrained server running hot on short term threads/processes, which do NOT resolve, they get cycled into medium and long term threads which is indicative of a memory leak from the point of internal object like a text block, image gallery, etc. The thread just cycles (very slowly) and new threads are created building the load. This will not be noticable on a robust server with plenty of juice but kills my own where I had to restart it on a number of occassions. This is a software bug which I think from the MySQL latency correlations to be originating in timeouts with the DB and poor handling of saves most likely using SQL inserts/updates and not stored procedures or functions which are lighter. Whilst tightly coupled, the need for proper backend handling needs to be reviewed and corrected for constrained resource access for SP Page builder, or minimum system resources required set out by Joomshaper.
Whilst you are at it, there is evidence of poor timeout handling with cache where a larger save like an image gallery is cached first, but if the server is constrained, this will time out and 'may' save before the exception handling logs the user out of the internal object saving until it is completed.
Joomshaper Devs should revise their caching and backend process workflows for better handling so that resource constrained users dont have to spend days doing hours of actual work.
Best Regards
John
