Hide Forgot
Created attachment 835224 [details] default datasource Description of problem: There is WARN with exceptios in log when stoppinng the portal. I'm attaching stacktraces (for both default datasource and "real" database datasource)
Created attachment 835227 [details] database datasource
Vlasta, does it happens all the time, or just sometimes? I tried to reproduce it on my machine, and I've been unable to reproduce this. At most, I get a different exception when the there has been some inactivity between the boot and the shutdown ("Cannot close the session as it hasn't been opened first"). While I could experimenting moving the shutdown logic to something that would hopefully happen before, I would still be unable to test, as I cannot reproduce.
As discussed on IRC: steps to reproduce: 1. unzip clean DR1 and start it. 2. open localhost:8080/portal and set root password 3. log in as a root 4. go to page management and add a test page 5. stop the portal
I've verified that the exceptions from attachments are no longer present in CR01. I've noticed that there is another exception in log when the there has been some inactivity between the boot and the shutdown ("Cannot close the session as it hasn't been opened first"). I've discussed it with Juraci on IRC that there can occur such a warning in log. Juraci can you add an explanation? Thanks.
The WSRP component requires a fresh list of consumers during shutdown, in order to cleanly stop. Before GTNPORTAL-3281, this routine was effectively not being called, and in fixing that exposed the behavior of this BZ. Basically, what is happening is that we don't have a chance to use the database when the container is shutting down, so, a clean stop of WSRP is not always possible. This is not critical though (specially considering that, before GTNPORTAL-3281, it wasn't done at all), but we still want to try to stop cleanly. When the DB is stopped when we try to reach it, the mentioned WARN message occurs. The exception on the logs were removed, but the WARN couldn't be so, as it's logged by an internal component, of which WSRP has no control.