Re: Very red CI -> Hold merges, please

[Bruce Schuchardt]

Testing on the fix for GEODE-6363 passed on overnight runs.  I could 
push a change to mask the problem and do more testing today if that's 
what folks want or I could push the fix.


On 2/7/19 4:20 PM, Alexander Murmann wrote:

Bruce, would it make sense to for now revert the suspect change to the
test? At that point we should be back to full green and we all can without
a doubt go back to our usual flow of merging to develop.

Thoughts?

On Thu, Feb 7, 2019 at 2:37 PM Kirk Lund  wrote:


Hmm, and that was another false search hit in Jira! Searching for
WANRollingUpgradeNewSenderProcessOldEvent in Jira brings up GEODE-3967
which apparently does NOT involve that test. So, maybe we found another
flaky test.

Jira search seems to not work very well.

On Thu, Feb 7, 2019 at 2:24 PM Kirk Lund  wrote:


The UpgradeTest failures on your latest commit for this PR are
WANRollingUpgradeNewSenderProcessOldEvent which seems to be a

reoccurrence

of [GEODE-3967](https://issues.apache.org/jira/browse/GEODE-3967). I
recommend having Gester take a look at that these failures. He marked
[GEODE-3967](https://issues.apache.org/jira/browse/GEODE-3967) as
resolved on Jan 9th.

On Thu, Feb 7, 2019 at 12:37 PM Jens Deppe  wrote:


No worries. I think I have a better fix now. At least the builds are
moving
again.

On Thu, Feb 7, 2019 at 12:11 PM Kirk Lund  wrote:


Sorry, go ahead and revert the commit and reopen the PR.

On Thu, Feb 7, 2019 at 11:36 AM Jens Deppe  wrote:


I was still working on a fix...

On Thu, Feb 7, 2019 at 11:31 AM Kirk Lund  wrote:


I merged it in.

On Thu, Feb 7, 2019 at 11:28 AM Kirk Lund 

wrote:

I think we should go ahead and merge in
https://github.com/apache/geode/pull/3172 since it resolves the
GfshConsoleModeUnitTest UnitTest failures.

On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag 

wrote:

FYI, I have just merged a ci timeout fix to increase the

timeout

for

geode-benchmarks to 4h. This does not influence any geode

modules.

Regards
Naba

On Thu, Feb 7, 2019 at 9:32 AM Alexander Murmann <

amurm...@apache.org

wrote:


Hi folks,

Our CI is very red since ~24 hours
<


https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK11/builds/372

.

It looks like a substantial new issue was introduced.

Can we hold off on merging new changes to the develop branch

till

this

issue is resolved?

Thank you all!

Re: Adding integrationTest src set to geode-dunit

[Kirk Lund]

Yep, I'll ping you later this afternoon to see if you're free. Thanks!

On Thu, Feb 7, 2019 at 4:11 PM Robert Houghton  wrote:

> Can I work with you on this tomorrow?
>
> On Thu, Feb 7, 2019, 15:09 Kirk Lund  wrote:
>
> > The usual geode src sets like integrationTest don't already exist in some
> > modules such as geode-dunit.
> >
> > I'm trying to write a new IntegrationTest but simply creating the
> > directories and placing a new .java file in it doesn't seem to work.
> >
> >
> >
> geode-dunit/src/integrationTest/java/org/apache/geode/test/junit/rules/DiskDirRuleIntegrationTest.java
> >
> > I've looked at geode-dunit/build.gradle and it's not clear what to add
> > there if anything. The only src sets currently in geode-dunit are:
> >
> > geode-dunit/src/distributedTest
> > geode-dunit/src/main
> > geode-dunit/src/test
> >
> > How do I add integrationTest so that it a) compiles, b) is added to my IJ
> > project, and 3) actually runs in CI and precheckin?
> >
>

Re: Adding integrationTest src set to geode-dunit

[Robert Houghton]

If i'm not responsive, it because family stuff came up. But i can
definitely do this on Monday

On Fri, Feb 8, 2019 at 9:45 AM Kirk Lund  wrote:

> Yep, I'll ping you later this afternoon to see if you're free. Thanks!
>
> On Thu, Feb 7, 2019 at 4:11 PM Robert Houghton 
> wrote:
>
> > Can I work with you on this tomorrow?
> >
> > On Thu, Feb 7, 2019, 15:09 Kirk Lund  wrote:
> >
> > > The usual geode src sets like integrationTest don't already exist in
> some
> > > modules such as geode-dunit.
> > >
> > > I'm trying to write a new IntegrationTest but simply creating the
> > > directories and placing a new .java file in it doesn't seem to work.
> > >
> > >
> > >
> >
> geode-dunit/src/integrationTest/java/org/apache/geode/test/junit/rules/DiskDirRuleIntegrationTest.java
> > >
> > > I've looked at geode-dunit/build.gradle and it's not clear what to add
> > > there if anything. The only src sets currently in geode-dunit are:
> > >
> > > geode-dunit/src/distributedTest
> > > geode-dunit/src/main
> > > geode-dunit/src/test
> > >
> > > How do I add integrationTest so that it a) compiles, b) is added to my
> IJ
> > > project, and 3) actually runs in CI and precheckin?
> > >
> >
>

Re: Very red CI -> Hold merges, please

[Kirk Lund]

If you put quotes around "WANRollingUpgradeNewSenderProcessOldEvent" in
Jira, then the search finds no hits. Without the quotes it results in two
tickets now including the one you worked on. Jira must be searching for
partial string matches without quotes -- so some sequence of words in the
name of that test must be in your ticket. I'll be using quotes from now on.

On Thu, Feb 7, 2019 at 10:50 PM Xiaojian Zhou  wrote:

> WANRollingUpgradeNewSenderProcessOldEvent is not related with GEODE-3967.
> I wonder why search guided us to GEODE-3967.
>
> Regards
> Gester
>
> On Thu, Feb 7, 2019 at 8:34 PM Owen Nichols  wrote:
>
> > Pipeline is back to green now.  Thank you to everyone who stepped up to
> > get things back on track.
> >
> > If you had PR checks fail this week, please re-trigger them (by making an
> > empty commit).
> >
> > > On Feb 7, 2019, at 4:20 PM, Alexander Murmann 
> > wrote:
> > >
> > > Bruce, would it make sense to for now revert the suspect change to the
> > > test? At that point we should be back to full green and we all can
> > without
> > > a doubt go back to our usual flow of merging to develop.
> > >
> > > Thoughts?
> > >
> > > On Thu, Feb 7, 2019 at 2:37 PM Kirk Lund  wrote:
> > >
> > >> Hmm, and that was another false search hit in Jira! Searching for
> > >> WANRollingUpgradeNewSenderProcessOldEvent in Jira brings up GEODE-3967
> > >> which apparently does NOT involve that test. So, maybe we found
> another
> > >> flaky test.
> > >>
> > >> Jira search seems to not work very well.
> > >>
> > >> On Thu, Feb 7, 2019 at 2:24 PM Kirk Lund  wrote:
> > >>
> > >>> The UpgradeTest failures on your latest commit for this PR are
> > >>> WANRollingUpgradeNewSenderProcessOldEvent which seems to be a
> > >> reoccurrence
> > >>> of [GEODE-3967](https://issues.apache.org/jira/browse/GEODE-3967). I
> > >>> recommend having Gester take a look at that these failures. He marked
> > >>> [GEODE-3967](https://issues.apache.org/jira/browse/GEODE-3967) as
> > >>> resolved on Jan 9th.
> > >>>
> > >>> On Thu, Feb 7, 2019 at 12:37 PM Jens Deppe 
> wrote:
> > >>>
> >  No worries. I think I have a better fix now. At least the builds are
> >  moving
> >  again.
> > 
> >  On Thu, Feb 7, 2019 at 12:11 PM Kirk Lund  wrote:
> > 
> > > Sorry, go ahead and revert the commit and reopen the PR.
> > >
> > > On Thu, Feb 7, 2019 at 11:36 AM Jens Deppe 
> > wrote:
> > >
> > >> I was still working on a fix...
> > >>
> > >> On Thu, Feb 7, 2019 at 11:31 AM Kirk Lund 
> wrote:
> > >>
> > >>> I merged it in.
> > >>>
> > >>> On Thu, Feb 7, 2019 at 11:28 AM Kirk Lund 
> > >> wrote:
> > >>>
> >  I think we should go ahead and merge in
> >  https://github.com/apache/geode/pull/3172 since it resolves the
> >  GfshConsoleModeUnitTest UnitTest failures.
> > 
> >  On Thu, Feb 7, 2019 at 9:57 AM Nabarun Nag 
> >  wrote:
> > 
> > > FYI, I have just merged a ci timeout fix to increase the
> > >> timeout
> >  for
> > > geode-benchmarks to 4h. This does not influence any geode
> >  modules.
> > >
> > > Regards
> > > Naba
> > >
> > > On Thu, Feb 7, 2019 at 9:32 AM Alexander Murmann <
> > > amurm...@apache.org
> > >>>
> > > wrote:
> > >
> > >> Hi folks,
> > >>
> > >> Our CI is very red since ~24 hours
> > >> <
> > >>
> > >
> > >>>
> > >>
> > >
> > 
> > >>
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK11/builds/372
> > >>> .
> > >> It looks like a substantial new issue was introduced.
> > >>
> > >> Can we hold off on merging new changes to the develop branch
> >  till
> > >> this
> > >> issue is resolved?
> > >>
> > >> Thank you all!
> > >>
> > >
> > 
> > >>>
> > >>
> > >
> > 
> > >>>
> > >>
> >
> >
>

[DISCUSS] Static analysis of statics

[Dan Smith]

Hi devs,

We've expressed interest in getting rid of singletons and allowing multiple
copies of cache to run in the same JVM.

I'd like to get a handle on what static state we have. As a first step I'd
like to introduce a few annotations and some static analysis to find all of
our mutable static fields.

I intend to add a PMD rule to look for mutable static state, and some new
annotations to the fields we have right now to indicate what we want to do
with them.

More details are in this PR -  https://github.com/apache/geode/pull/3178

Are people ok with adding these additional annotations? You will see static
fields be marked with things like @MakeNotStatic or @MakeImmutable until we
get them all cleaned up.

-Dan

Re: [Proposal] Adding Micrometer to Apache Geode

[Dale Emery]

I have submitted a new PR https://github.com/apache/geode/pull/3180 
, superseding the original one.

I invite your review.

Cheers,
Dale

—
Dale Emery
dem...@pivotal.io

> On Feb 4, 2019, at 9:10 AM, Kirk Lund  wrote:
> 
> +1 to add Micrometer in the described way and I'll add my approval to the
> PR as well
> 
> On Fri, Feb 1, 2019 at 4:16 PM Dale Emery  wrote:
> 
>> Hello all,
>> 
>> I've created a PR to add Micrometer to Geode:
>> https://github.com/apache/geode/pull/3153
>> 
>> I invite your review.
>> 
>> The Micrometer system includes a rich suite of Meter types for
>> instrumenting code, and several styles of meter registries for
>> maintaining the meters.  It also includes (as separate jars) additional
>> registry types for publishing metrics to a variety of external
>> monitoring systems (e.g. Prometheus, JMX, and Influx).
>> 
>> See http://micrometer.io/ for details about Micrometer,
>> 
>> This PR adds a Micrometer-based metrics system to Geode.
>> 
>> On startup, Geode configures a "primary" meter registry. Developers use
>> the primary registry to create meters (gauges, counters, timers, and
>> others) to instrument Geode and client code.
>> 
>> Internally, the meter registry is a "composite" registry, which allows
>> attaching any number of "downstream" registries. Each downstream
>> registry will typically publish the metrics to an external monitoring
>> system, or provide an endpoint where an external monitoring system can
>> "scrape" the metrics.
>> 
>> In Geode, when a meter is added or removed from the primary registry,
>> the primary registry adds or removes a corresponding meter in each
>> downstream registry.  When a meter in the primary registry is updated
>> (e.g. incremented), the primary registry forwards each operation to the
>> corresponding meter in each downstream registry.
>> 
>> A MetricsCollector provides access to the primary registry, and includes
>> methods for adding and removing downstream registries.
>> 
>> The MetricsCollector itself is currently available via a method on
>> InternalDistributedSystem.  Eventually we plan to  make the
>> MetricsCollector available through DistributedSystem, or some other
>> non-internal class or interface.
>> 
>> The key components of this change are:
>> - MetricsCollector (interface) allows access to the primary registry,
>>  and allows adding and removing downstream registries.
>> - CompositeMetricsCollector is the concrete implementation of
>>  MetricsCollector, and creates the internal composite registry.
>> - InternalDistributedSystem creates the MetricsCollector and makes it
>>  available via a new getMetricsCollector() method.
>> - The Micrometer system for instrumenting and maintaining metrics (added
>>  to Geode as a dependency).
>> 
>> Cheers,
>> Dale
>> 
>>> On Jan 15, 2019, at 9:37 AM, Mark Hanson  wrote:
>>> 
>>> Hello All,
>>> 
>>> I would like to propose that we incorporate Micrometer into Geode to
>> allow us to collect statistics and make them more easily available to
>> external services should someone chose to implement support for that.
>>> 
>>> In some basic testing, it does not appear to have a significant impact
>> on performance to hook this in. I think that in the long run it will really
>> improve the visibility of the systems stats in real-time… This will also
>> allow some extensibility for people who want to hook into their tracking
>> infrastructure, such as New Relic or Data Dog, though we are not putting
>> that in.
>>> 
>>> 
>>> What do people think?
>>> 
>>> Thanks,
>>> Mark
>>> 
>>> 
>> 
>> 

geode-junit and geode-dunit classpath problems

[Kirk Lund]

We have a src/main class called UseJacksonForJsonPathRule which uses
classes from this dependency in geode-junit/build.gradle:

  compile('com.jayway.jsonpath:json-path')

I'm trying to write a unit test in src/test called
UseJacksonForJsonPathRuleTest but it fails with the following
NoClassDefFoundErrors. These are the same classes used by any test using
UseJacksonForJsonPathRule. geode-dunit's
DistributedUseJacksonForJsonPathRule extends UseJacksonForJsonPathRule and
we have one test in geode-core that uses the distributed version of the
rule and it passes without NoClassDefFoundErrors.

Anyone know why or what needs to change in geode-junit/build.gradle?

Also, I seem to keep hitting this ever since we exploded geode-junit and
geode-dunit. It's as if the classpaths aren't really correct for
geode-junit and geode-dunit, such that when I start writing unit tests or
integration tests within those two modules, they just don't work unless I
move the test to geode-core -- that's the only module in which I can
actually run these back filled unit tests. Given that it seems to be a
systemic problem with geode-junit and geode-dunit, can we do something to
fix this systemically instead of every single time I write a new test?

java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/ObjectMapper

at
com.jayway.jsonpath.spi.json.JacksonJsonProvider.(JacksonJsonProvider.java:32)
at
org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule$1.(UseJacksonForJsonPathRule.java:65)
at
org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule.before(UseJacksonForJsonPathRule.java:63)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource.access$000(SerializableExternalResource.java:24)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:36)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.ClassNotFoundException:
com.fasterxml.jackson.databind.ObjectMapper
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 20 more


java.lang.NoClassDefFoundError: Could not initialize class
com.jayway.jsonpath.spi.json.JacksonJsonProvider

at
org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule$1.(UseJacksonForJsonPathRule.java:65)
at
org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule.before(UseJacksonForJsonPathRule.java:63)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource.access$000(SerializableExternalResource.java:24)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:36)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)

Re: geode-junit and geode-dunit classpath problems

[Kirk Lund]

Alright, this one is figured out! I think most of these issues are other
3rd party dependencies that aren't in geode-junit or geode-dunit because
the tests that run and require those dependencies are over in geode-core. I
believe I can handle this sort of thing one at a time... 

On Fri, Feb 8, 2019 at 2:01 PM Kirk Lund  wrote:

> We have a src/main class called UseJacksonForJsonPathRule which uses
> classes from this dependency in geode-junit/build.gradle:
>
>   compile('com.jayway.jsonpath:json-path')
>
> I'm trying to write a unit test in src/test called
> UseJacksonForJsonPathRuleTest but it fails with the following
> NoClassDefFoundErrors. These are the same classes used by any test using
> UseJacksonForJsonPathRule. geode-dunit's
> DistributedUseJacksonForJsonPathRule extends UseJacksonForJsonPathRule and
> we have one test in geode-core that uses the distributed version of the
> rule and it passes without NoClassDefFoundErrors.
>
> Anyone know why or what needs to change in geode-junit/build.gradle?
>
> Also, I seem to keep hitting this ever since we exploded geode-junit and
> geode-dunit. It's as if the classpaths aren't really correct for
> geode-junit and geode-dunit, such that when I start writing unit tests or
> integration tests within those two modules, they just don't work unless I
> move the test to geode-core -- that's the only module in which I can
> actually run these back filled unit tests. Given that it seems to be a
> systemic problem with geode-junit and geode-dunit, can we do something to
> fix this systemically instead of every single time I write a new test?
>
> java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/ObjectMapper
>
> at
> com.jayway.jsonpath.spi.json.JacksonJsonProvider.(JacksonJsonProvider.java:32)
> at
> org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule$1.(UseJacksonForJsonPathRule.java:65)
> at
> org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule.before(UseJacksonForJsonPathRule.java:63)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource.access$000(SerializableExternalResource.java:24)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:36)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.ClassNotFoundException:
> com.fasterxml.jackson.databind.ObjectMapper
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
>
>
> java.lang.NoClassDefFoundError: Could not initialize class
> com.jayway.jsonpath.spi.json.JacksonJsonProvider
>
> at
> org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule$1.(UseJacksonForJsonPathRule.java:65)
> at
> org.apache.geode.test.junit.rules.UseJacksonForJsonPathRule.before(UseJacksonForJsonPathRule.java:63)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource.access$000(SerializableExternalResource.java:24)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:36)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)