Project

General

Profile

Bug #10042

Improve support for LOG-MANAGER

Added by Alexandru Lungu about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

History

#1 Updated by Alexandru Lungu about 1 year ago

In #10000, a use of LegacyLogManager logManager = LegacyLogOps.logMgr(); was causing the thread to fail clean-up. It was because the log manager was lazily instantiated inside the clean-up phase and the context local requests ended up in a loop (requesting ConnectionManager why it was cleaned up).

I fixed that, but I observed some limitations while searching for a fix:

  • why is LegacyLogManager instantiated only for normal FWD client sessions and not for appservers? Check StandardServer.initializeClientSession.
    • please test whether LOG-MANAGER behaves differently for appserver vs normal client.
  • why is LegacyLogManager c'tor not calling the super. I think it won't properly extend the super behavior without a proper initialization. Even so, I saw system handles are rather created with StaticProxy, rather than extending HandleResource. This looks fishy to me.
    • I think this is not integrating well with the handle functionalities we have. My concern is rather that most of the SYSTEM handles are using StaticProxy for initialization, while LegacyLogManager seem to have a completely different pattern. This is prone to errors like not calling super in the c'tor.

Please use this task to ramp-up a unit test suite for this system handle and ensure it is working right.
Do static analysis to avoid requesting the LOG-MANAGER in places where it can't be instantiated. For clean-up, this was fixed in #10000.

Also available in: Atom PDF