From: fluca1978 at infinito.it (Luca Ferrari) Date: Mon, 26 Jul 2010 12:00:04 +0200 Subject: [Pljava-dev] pljava error logging levels In-Reply-To: <910AD504-DD44-40EC-9592-426A84F5FA05@greenplum.com> References: <3F082C5B-116B-4CB7-9755-B3D306B8C942@greenplum.com> <201007211505.50676.fluca1978@infinito.it> <910AD504-DD44-40EC-9592-426A84F5FA05@greenplum.com> Message-ID: <201007261200.05370.fluca1978@infinito.it> Maybe now I get the point: 1) Session calls ELogHandler.init() that initializes the parameters, including the logging level; 2) the Java logging framework does not call publish if the logging level is not adeguate, and therefore changes in the log/client_min_messages are not seen. In this situation there are three solutions I guess: 1) each time a logging is successful (i.e., publish has been called), we need to reconfigure the log level of the handler. The problem with this is that we risk to get unlogged messages for a while, until one pass the publish method. 2) once a new handler is created it must self update its value of the log level. The problem with this is that if the handler is kept for a while, the changes are not seen. 3) create a thread that, once a while, reloads the log level and set it into the current log level, but this causes a lot of threads (one per handler) 4) keep a map of all created handlers and update them each time a new one is created. The problem is that the thread will execute when the control is on the java space, due to the locking mechanism of the backend, and therefore it will update the handlers with a little lag once a java call is made. This should not represent a big problem, because before a java call is made there is no need to change the java logging setting. I attach a patch also for this solution mixed with the number 2. Any comments? Luca -------------- next part -------------- A non-text attachment was scrubbed... Name: eloghandler.thread.patch Type: text/x-patch Size: 10671 bytes Desc: not available URL: