Re: CS MS Logging Level
to get back with my findings so far, The method I mentioned will work be it not that we have an explicit mention of log4j configuration in our web.xml. It states that 'log4j-cloud.xml' should be searched on the classpath. I deleted the extraneous file(s) from the hyperv plugin. This seems to solve the problem. There are several other ways of loading the configuration file in cloudstack. I haven't begun to consider consolidating them as this is a multi process system and it does make sense. Point of attention, though. Daan On Thu, Jan 8, 2015 at 3:41 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: It seems I had thrown away another log4j conf to get this working:( I did a clean checkout and my trick isn't working anymore. keep you posted On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Great - thanks, Daan! On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I got around looking at this (under peer pressure @SBP;) There is a property to maven jetty plugin: systemProperties systemProperty namelog4j.configuration/name value${project.build.directory}/log4j.xml/value !-- or something like this -- /systemProperty /systemProperties doing some final test before checking in. Not sure what changed but in jetty and when. It seems to pick the first or last on the class path or the lowest or highest hashed one without this set. dunno Daan On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Anshul, The hyperv log4j configuration should not be used at all. On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar anshul.gang...@citrix.com wrote: Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan
Re: CS MS Logging Level
Awesome - thanks again, Daan! On Fri, Jan 9, 2015 at 2:36 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: to get back with my findings so far, The method I mentioned will work be it not that we have an explicit mention of log4j configuration in our web.xml. It states that 'log4j-cloud.xml' should be searched on the classpath. I deleted the extraneous file(s) from the hyperv plugin. This seems to solve the problem. There are several other ways of loading the configuration file in cloudstack. I haven't begun to consider consolidating them as this is a multi process system and it does make sense. Point of attention, though. Daan On Thu, Jan 8, 2015 at 3:41 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: It seems I had thrown away another log4j conf to get this working:( I did a clean checkout and my trick isn't working anymore. keep you posted On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Great - thanks, Daan! On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I got around looking at this (under peer pressure @SBP;) There is a property to maven jetty plugin: systemProperties systemProperty namelog4j.configuration/name value${project.build.directory}/log4j.xml/value !-- or something like this -- /systemProperty /systemProperties doing some final test before checking in. Not sure what changed but in jetty and when. It seems to pick the first or last on the class path or the lowest or highest hashed one without this set. dunno Daan On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Anshul, The hyperv log4j configuration should not be used at all. On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar anshul.gang...@citrix.com wrote: Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: CS MS Logging Level
It seems I had thrown away another log4j conf to get this working:( I did a clean checkout and my trick isn't working anymore. keep you posted On Thu, Jan 8, 2015 at 3:21 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Great - thanks, Daan! On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I got around looking at this (under peer pressure @SBP;) There is a property to maven jetty plugin: systemProperties systemProperty namelog4j.configuration/name value${project.build.directory}/log4j.xml/value !-- or something like this -- /systemProperty /systemProperties doing some final test before checking in. Not sure what changed but in jetty and when. It seems to pick the first or last on the class path or the lowest or highest hashed one without this set. dunno Daan On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Anshul, The hyperv log4j configuration should not be used at all. On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar anshul.gang...@citrix.com wrote: Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan
Re: CS MS Logging Level
Great - thanks, Daan! On Thu, Jan 8, 2015 at 7:17 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: I got around looking at this (under peer pressure @SBP;) There is a property to maven jetty plugin: systemProperties systemProperty namelog4j.configuration/name value${project.build.directory}/log4j.xml/value !-- or something like this -- /systemProperty /systemProperties doing some final test before checking in. Not sure what changed but in jetty and when. It seems to pick the first or last on the class path or the lowest or highest hashed one without this set. dunno Daan On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Anshul, The hyperv log4j configuration should not be used at all. On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar anshul.gang...@citrix.com wrote: Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: CS MS Logging Level
I got around looking at this (under peer pressure @SBP;) There is a property to maven jetty plugin: systemProperties systemProperty namelog4j.configuration/name value${project.build.directory}/log4j.xml/value !-- or something like this -- /systemProperty /systemProperties doing some final test before checking in. Not sure what changed but in jetty and when. It seems to pick the first or last on the class path or the lowest or highest hashed one without this set. dunno Daan On Wed, Dec 31, 2014 at 2:40 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Anshul, The hyperv log4j configuration should not be used at all. On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar anshul.gang...@citrix.com wrote: Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- Daan
Re: CS MS Logging Level
Anshul, The hyperv log4j configuration should not be used at all. On Wed, Dec 31, 2014 at 6:55 AM, Anshul Gangwar anshul.gang...@citrix.com wrote: Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan
Re: CS MS Logging Level
Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan
Re: CS MS Logging Level
No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
RE: CS MS Logging Level
Daan, I am not seeing extraneous logs on my dev setup other than thread which is cleaning up expired async-jobs. You can safely change CONSOLE appender's threshold to INFO in hyperv plugin if you think that is causing the problem. We will not lose much info which we want to show to user by this change. And in any case it will be available in vmops.log. CONSOLE appender's threshold is set to TRACE since the start of plugin. -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Tuesday, December 30, 2014 11:10 PM To: dev@cloudstack.apache.org Subject: Re: CS MS Logging Level No, vmops.log does not seem to be getting spammed...just the console. On Tue, Dec 30, 2014 at 1:44 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Mike, It doesn't spew to vmops.log anymore, right? It seems that the new jetty version interprets all the log4j/classpath differently and the one from the hyperv plugin takes precedence. I have been looking for a solution but haven't found one yet. On Mon, Dec 29, 2014 at 10:02 PM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™* -- Daan -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
CS MS Logging Level
Hi, Does anyone know if the logging level or something like that changed on the management server in 4.6? It seems like it's spewing out tons of information to the console these days. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*