The maven -q flag takes care of that right? On Fri, Nov 4, 2016 at 9:39 AM, Otto Fowler <[email protected]> wrote:
> Ryan, > > Are you looking at the maven logging levels as well? The plugins etc ( > the shading output for example )? > > > On November 4, 2016 at 10:21:19, Otto Fowler ([email protected]) > wrote: > > I’m guessing that if you add a duplicate appender it just replaces the one > that is there of that type > > > On November 4, 2016 at 10:14:08, Ryan Merriman ([email protected]) > wrote: > > Haha I wrote something that does the exact same thing. I added a couple > extra methods to set log levels for other logging frameworks (Log4j2 and > Java logging). Good to know, I will just add on to that. > > On Fri, Nov 4, 2016 at 9:05 AM, Otto Fowler <[email protected]> > wrote: > >> Hey Ryan, >> >> Take a look at the UnitTestHelper in test utils. It has methods for >> changing the logger verbosity. Even if it is not what we do, it is >> interesting. I just stubbled on it. >> >> >> >> On November 3, 2016 at 13:56:51, Otto Fowler ([email protected]) >> wrote: >> >> We are going to need a separate jira or set for sweeping the code for >> compile warnings maybe. >> >> >> On November 3, 2016 at 13:50:59, Otto Fowler ([email protected]) >> wrote: >> >> https://github.com/ottobackwards/incubator-metron.git >> branch METRON-538 >> >> If you end up wanting to send me over PR’s. >> >> 1 commit so far, I was able to get rid of the curator exceptions: >> >> Running org.apache.metron.maas.service.MaasIntegrationTest >> Found endpoints: dummy:1.0 @ http://10.0.0.99:1500 serving: >> apply=echo >> Cleaning up... >> Killing 2189 from 2189 ttys000 0:01.19 /Library/Java/JavaVirtualMachi >> nes/jdk1.8.0_31.jdk/Contents/Home/bin/java >> org.apache.metron.maas.service.runner.Runner >> -ci 2 -zq 127.0.0.1:52505 -zr /maas/config -s dummy_rest.sh -n dummy -hn >> 10.0.0.99 -v 1.0 >> Killing 2192 from 2192 ttys000 0:00.01 /bin/bash >> /Users/ottofowler/src/apache/forks/incubator-metron/metron-a >> nalytics/metron-maas-service/target/MaasIntegrationTest/Maas >> IntegrationTest-localDir-nm-0_0/usercache/ottofowler/appcach >> e/application_1478189460460_0001/container_1478189460460_ >> 0001_01_000002/dummy_rest.sh >> Killing 2236 from 2236 ttys000 0:00.00 /bin/bash >> /Users/ottofowler/src/apache/forks/incubator-metron/metron-a >> nalytics/metron-maas-service/target/MaasIntegrationTest/Maas >> IntegrationTest-localDir-nm-0_0/usercache/ottofowler/appcach >> e/application_1478189460460_0001/container_1478189460460_ >> 0001_01_000002/dummy_rest.sh >> 2016-11-03 12:11:20,839 ERROR [Thread[Thread-256,5,main]] >> delegation.AbstractDelegationTokenSecretManager >> (AbstractDelegationTokenSecretManager.java:run(659)) - >> ExpiredTokenRemover received java.lang.InterruptedException: sleep >> interrupted >> 2016-11-03 12:11:20,956 ERROR [Thread[Thread-236,5,main]] >> delegation.AbstractDelegationTokenSecretManager >> (AbstractDelegationTokenSecretManager.java:run(659)) - >> ExpiredTokenRemover received java.lang.InterruptedException: sleep >> interrupted >> 2016-11-03 12:11:36,277 ERROR [Curator-Framework-0] >> curator.ConnectionState (ConnectionState.java:checkTimeouts(200)) - >> Connection timed out for connection string (127.0.0.1:52505) and timeout >> (15000) / elapsed (15421) >> org.apache.curator.CuratorConnectionLossException: KeeperErrorCode = >> ConnectionLoss >> at org.apache.curator.ConnectionState.checkTimeouts(ConnectionS >> tate.java:197) >> at org.apache.curator.ConnectionState.getZooKeeper(ConnectionSt >> ate.java:87) >> at org.apache.curator.CuratorZookeeperClient.getZooKeeper(Curat >> orZookeeperClient.java:115) >> at org.apache.curator.framework.imps.CuratorFrameworkImpl.perfo >> rmBackgroundOperation(CuratorFrameworkImpl.java:806) >> at org.apache.curator.framework.imps.CuratorFrameworkImpl.backg >> roundOperationsLoop(CuratorFrameworkImpl.java:792) >> at org.apache.curator.framework.imps.CuratorFrameworkImpl.acces >> s$300(CuratorFrameworkImpl.java:62) >> at org.apache.curator.framework.imps.CuratorFrameworkImpl$4.cal >> l(CuratorFrameworkImpl.java:257) >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool >> Executor.java:1142) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo >> lExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> >> etc etc >> >> I am just going to make a pass through these types and see if there is a >> common shutdown order problem ( maas does not use the integration component >> runner so shutdown order is not specified, so it may be ‘special’ ). >> >> >> >> On November 3, 2016 at 12:30:46, Ryan Merriman ([email protected]) >> wrote: >> >> Here is the Jira for log levels: >> https://issues.apache.org/jira/browse/METRON-541 >> >> On Thu, Nov 3, 2016 at 11:13 AM, Otto Fowler <[email protected]> >> wrote: >> >> > I think we fell off the list - sorry >> > >> > >> > On November 3, 2016 at 12:09:02, Otto Fowler ([email protected]) >> > wrote: >> > >> > METRON-538 >> > >> > Everyone is welcome to comment. >> > >> > >> > On November 3, 2016 at 12:06:28, Ryan Merriman ([email protected]) >> > wrote: >> > >> > Makes sense. >> > >> > On Thu, Nov 3, 2016 at 11:03 AM, Otto Fowler <[email protected]> >> > wrote: >> > >> > > I think we should have two jiras, two pr’s. >> > > I’ll create one for the shutdown issues. >> > > >> > > >> > > >> > > On November 3, 2016 at 12:02:53, Ryan Merriman ([email protected]) >> > > wrote: >> > > >> > > Yeah let's do it in parallel. You can start with the shutdown issues >> and >> > > I'll work on making the log levels configurable. Let's go ahead and >> > > proceed with 2 log configurations and see how it goes. If you get done >> > > first, just submit a PR and I'll add to it. >> > > >> > > Thanks Otto. I can't wait to get this fixed. >> > > >> > > On Thu, Nov 3, 2016 at 10:57 AM, Otto Fowler <[email protected] >> > >> > > wrote: >> > > >> > >> I have not. I was going to start looking at shutdown while waiting >> for >> > >> consensus on 1 v 2 log configurations. >> > >> How do you want to proceed? We can do it together. >> > >> >> > >> >> > >> On November 3, 2016 at 11:43:24, Ryan Merriman ([email protected]) >> > >> wrote: >> > >> >> > >> Otto, have you started on any of this yet? Was thinking I would start >> > with >> > >> getting the log levels consistent and dig into the shutdown issues. >> Then >> > >> we can iterate from there. >> > >> >> > >> Ryan >> > >> >> > >> On Wed, Nov 2, 2016 at 1:29 PM, Ryan Merriman <[email protected]> >> > >> wrote: >> > >> >> > >> > I vote for 1 logging configuration (ERROR only). Why do we want >> > >> different >> > >> > logging in Travis vs local? If you are working on a specific >> component >> > >> and >> > >> > need more verbose logging, temporarily change the log level to INFO >> > for >> > >> > that component. If we get the logging in shape this will be easy to >> > do. >> > >> > >> > >> > On Wed, Nov 2, 2016 at 1:18 PM, Otto Fowler < >> [email protected]> >> > >> > wrote: >> > >> > >> > >> >> On Fri, Oct 28, 2016 at 3:13 PM >> > >> >> <http://airmail.calendar/2016-10-28%2015:13:00%20EDT>, David >> Lyle < >> > >> >> [email protected]> wrote: >> > >> >> >> > >> >> > I think you noticed the main problem with turning logging off >> > >> entirely. >> > >> >> > >> > >> >> > I'd be inclined to have two files: one which defaults to INFO >> and >> > >> >> another >> > >> >> > that defaults to ERROR for Travis. We can give a >> > >> >> -Dlog4j.configuration=file:log4j.config.set.to.ERROR.only >> > >> >> > for travis, which I think Otto suggested. >> > >> >> >> > >> >> So - >> > >> >> * one jira to fix the component shutdowns ( I’ll take a stab >> unless >> > you >> > >> >> are >> > >> >> already on it ) >> > >> >> * one jira to have travis run with a second configuration ( be it >> > >> >> literally >> > >> >> a second file or something else ) set to error only >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> On November 2, 2016 at 13:51:28, Casey Stella ([email protected] >> ) >> > >> wrote: >> > >> >> >> > >> >> What would be in the two different logging properties? >> > >> >> >> > >> >> On Wed, Nov 2, 2016 at 1:45 PM, Otto Fowler < >> [email protected] >> > > >> > >> >> wrote: >> > >> >> >> > >> >> > What about having two logging configurations? One just for >> travis, >> > >> and >> > >> >> > one pretty much what there is now ( the teardown stuff still >> has to >> > >> be >> > >> >> > sorted out ). Maybe Travis can be scripted to put the right >> logging >> > >> >> > properties files in place? >> > >> >> > >> > >> >> > >> > >> >> > On November 2, 2016 at 12:42:09, Casey Stella ( >> [email protected]) >> > >> >> wrote: >> > >> >> > >> > >> >> > I haven't seen a JIRA about this yet. IMHO, I think a good >> > first-pass >> > >> >> > would be: >> > >> >> > * We have a lot of ERROR level logging that happens because >> during >> > >> >> teardown >> > >> >> > of the in memory components that could be fixed by tearing down >> > >> >> components >> > >> >> > in the right order (possibly). >> > >> >> > * Teardown in some of our integration tests don't seem to get >> > called >> > >> if >> > >> >> the >> > >> >> > tests fail, this causes cascading errors to happen ( the next >> test >> > >> won't >> > >> >> > start because it can't start the components), so ensuring >> teardown >> > >> >> happens >> > >> >> > in a finally block would be good >> > >> >> > * If there are chatty components that are inappropriately >> logging, >> > we >> > >> >> can >> > >> >> > adjust the logging level on a per-package basis. Tender balance >> > >> between >> > >> >> > suppressing valuable output and chattiness would ahve to be made >> > (and >> > >> >> > probably discussed as part of a JIRA). >> > >> >> > >> > >> >> > In retrospect, after considering this after the previous >> discussion >> > >> on >> > >> >> the >> > >> >> > dev list, I would not be in favor of logging to a file. It is >> > >> important >> > >> >> to >> > >> >> > see those logs on the travis output to help with quick-debugging >> > help >> > >> >> and >> > >> >> > we'd be setting ourselves up to be non-standard as well. I'd >> rather >> > >> see >> > >> >> a >> > >> >> > more directed and surgical effort. >> > >> >> > >> > >> >> > That's just my $0.02, though. I'd welcome a JIRA (or multiple >> > JIRAs) >> > >> to >> > >> >> > tackle logging. >> > >> >> > >> > >> >> > On Wed, Nov 2, 2016 at 12:33 PM, Otto Fowler < >> > >> [email protected]> >> > >> >> > wrote: >> > >> >> > >> > >> >> > > Did a jira for this actually get created? I would be willing >> to >> > >> help >> > >> >> work >> > >> >> > > on getting the logs setup for what they need to be for travis >> and >> > >> for >> > >> >> > > local. Did we settle on an approach? Is there work ongoing >> that >> > >> could >> > >> >> use >> > >> >> > > some dev or testing help? >> > >> >> > > >> > >> >> > >> > >> >> > >> > >> >> >> > >> > >> > >> > >> > >> >> > >> >> > > >> > >> >> >
