Usage of browserPage.getPayloadProcessor() prevents GCing BrowserPage and PayloadProcessor objects

[webfirmframework]

PayloadProcessor is required to use in websocket listener implementation class (class annotated by @WebListener). But, usage of PayloadProcessor returned by browserPage.getPayloadProcessor() method leads not to GC BrowserPage and PayloadProcessor object. This may lead to an out of memory issue. This bug is produced in Java 13.

[webfirmframework]

The bug was due to the cyclic dependency of PayloadProcessor, BrowserPage and ThreadLocal instance. GC issue is fixed by declaring ThreadLocal class as static but using a ThreadLocal class is not recommended to use with PayloadProcessor and it may make other bugs when multiple threads are used to update UI anywhere in the app. So browserPage.getPayloadProcessor is deprecated since 3.0.11, instead use browserPage.newPayloadProcessor() to create a PayloadProcessor object. Same instance of PayloadProcessor should not be used under multiple threads, create separate object for each thread. More specifically multiple threads should not access same PayloadProcessor object at a time and the data (bytes) passing to PayloadProcessor must be in its original sequential order.

Quick fix for now is:

Instead of using PayloadProcessor payloadProcessor = browserPage.getPayloadProcessor();
use PayloadProcessor payloadProcessor = new PayloadProcessor(browserPage);

Since 3.0.11 we can use:

PayloadProcessor payloadProcessor = browserPage.newPayloadProcessor();