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? > >> >> > > > >> >> > > >> >> > > >> >> > >> > > >> > > >> > >> > > >
