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 (merrim...@gmail.com) 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 <ottobackwa...@gmail.com> 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 (ottobackwa...@gmail.com) > 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 (ottobackwa...@gmail.com) > 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/ > JavaVirtualMachines/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- > analytics/metron-maas-service/target/MaasIntegrationTest/ > MaasIntegrationTest-localDir-nm-0_0/usercache/ottofowler/ > appcache/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- > analytics/metron-maas-service/target/MaasIntegrationTest/ > MaasIntegrationTest-localDir-nm-0_0/usercache/ottofowler/ > appcache/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( > ConnectionState.java:197) > at org.apache.curator.ConnectionState.getZooKeeper( > ConnectionState.java:87) > at org.apache.curator.CuratorZookeeperClient.getZooKeeper( > CuratorZookeeperClient.java:115) > at org.apache.curator.framework.imps.CuratorFrameworkImpl. > performBackgroundOperation(CuratorFrameworkImpl.java:806) > at org.apache.curator.framework.imps.CuratorFrameworkImpl. > backgroundOperationsLoop(CuratorFrameworkImpl.java:792) > at org.apache.curator.framework.imps.CuratorFrameworkImpl.access$300( > CuratorFrameworkImpl.java:62) > at org.apache.curator.framework.imps.CuratorFrameworkImpl$4. > call(CuratorFrameworkImpl.java:257) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.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 (merrim...@gmail.com) > 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 <ottobackwa...@gmail.com> > wrote: > > > I think we fell off the list - sorry > > > > > > On November 3, 2016 at 12:09:02, Otto Fowler (ottobackwa...@gmail.com) > > wrote: > > > > METRON-538 > > > > Everyone is welcome to comment. > > > > > > On November 3, 2016 at 12:06:28, Ryan Merriman (merrim...@gmail.com) > > wrote: > > > > Makes sense. > > > > On Thu, Nov 3, 2016 at 11:03 AM, Otto Fowler <ottobackwa...@gmail.com> > > 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 (merrim...@gmail.com) > > > 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 <ottobackwa...@gmail.com> > > > 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 (merrim...@gmail.com) > > >> 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 <merrim...@gmail.com> > > >> 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 < > ottobackwa...@gmail.com> > > >> > wrote: > > >> > > > >> >> On Fri, Oct 28, 2016 at 3:13 PM > > >> >> <http://airmail.calendar/2016-10-28%2015:13:00%20EDT>, David Lyle > < > > >> >> dlyle65...@gmail.com> 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 (ceste...@gmail.com) > > >> wrote: > > >> >> > > >> >> What would be in the two different logging properties? > > >> >> > > >> >> On Wed, Nov 2, 2016 at 1:45 PM, Otto Fowler < > ottobackwa...@gmail.com > > > > > >> >> 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 ( > ceste...@gmail.com) > > >> >> 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 < > > >> ottobackwa...@gmail.com> > > >> >> > 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? > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> > > > >> > > > >> > > >> > > > > > > >
