You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@drill.apache.org by Chris Westin <ch...@gmail.com> on 2015/09/16 02:20:55 UTC
Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
I just rebased, and twice in a row I've gotten wedged running
org.apache.drill.jdbc.ITTestShadedJar
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Daniel Barclay <db...@maprtech.com>.
> The level complexity of the build process to get a test to correctly test
> the right thing means jumping through a bunch of hoops to clear the
> classpath and then use a special classloader.
Hey, do we know if using a Maven integration test would make testing
the JDBC-all Jar file easier?
Presumably, integration testing supports having different dependencies
and classpaths for server that's started and stopped once vs. the set
of client tests.
If that's accurate, then, when we start moving some tests to be
Maven integration tests, maybe this JDBC-all Jar test could be simplified
a lot.
Daniel
Jacques Nadeau wrote:
> Ah, you're focused on testing from within the IDE?
>
> The level complexity of the build process to get a test to correctly test
> the right thing means jumping through a bunch of hoops to clear the
> classpath and then use a special classloader. I can't imagine that you
> could get it to run correctly in an ide. For example, Eclipse is very
> sloppy about keeping classpaths perfect versus what is declared in the pom
> file.
>
> The parameter you're looking for is generated by the ant plugin simply
> because that appears the way to get the value into an environment variable
> so that the inner classloader can load the drillbit for the test.
>
> The test: loads a drillbit in one classloader using the alternative
> classpath provided by the app.class.path variable. This is taken from what
> would have typically been the jvm level classpath. We then clear the jvm
> classpath to only include the test class, Junit and hamcrest. After the
> drillbit is initialized and we've run one query, we then add the jdbc all
> jar to the system classloader and open a connection to the drillbit and
> execute a query. The test is designed specifically to confirm that the
> requisite classes are correctly included in jdbc-all and that it will run
> correctly. The test can't run without the shaded jar being generated and I
> can't imagine any of the of the ides have good enough understanding of the
> various maven plugins and options used that they would correctly work. Even
> if you found some changes that made the test execute in and ide, I can't
> imagine that it would correctly manage all the classpath stuff.
> On Sep 15, 2015 9:37 PM, "Chris Westin" <ch...@gmail.com> wrote:
>
>> Variability: for me so far 2 out of 2 times.
>>
>> No stack trace, but as above, when I try to reproduce it in an IDE
>> "This seems to be because the test is getting an ExceptionInInitializer in
>> DrillbitClassLoader because the app.class.path property isn't set (and then
>> the resulting String.length() on its value throws an NPE)."
>>
>> I don't see app.class.path set anywhere in any pom.xml (so it's not getting
>> set when I copy the surefire arguments into the IDE's launch configuration
>> for the test, either).
>>
>>
>> On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
>> wrote:
>>
>>> It was tested on a clean machine a number of times. Any thoughts on the
>>> variability? Can you provide stack trace?
>>> On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
>>>
>>>> Yes, I see this issue too.
>>>>
>>>>> On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
>>>> wrote:
>>>>>
>>>>> This seems to be because the test is getting an
>> ExceptionInInitializer
>>> in
>>>>> DrillbitClassLoader because the app.class.path property isn't set
>> (and
>>>> then
>>>>> the resulting String.length() on its value throws an NPE).
>>>>>
>>>>> Bueller?
>>>>>
>>>>> On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
>> chriswestin42@gmail.com
>>>>
>>>>> wrote:
>>>>>
>>>>>> I just rebased, and twice in a row I've gotten wedged running
>>>>>> org.apache.drill.jdbc.ITTestShadedJar
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
--
Daniel Barclay
MapR Technologies
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Jacques Nadeau <ja...@dremio.com>.
Do you see the antrun running in the maven log before the failsafe plugin?
On Sep 17, 2015 12:49 PM, "Chris Westin" <ch...@gmail.com> wrote:
> I upgraded to maven 3.3.3 (from 3.2.3). I checked effective pom, and it's
> antrun 1.7. However, the unit tests still get wedged in the same place.
>
> On Wed, Sep 16, 2015 at 8:05 AM, Jacques Nadeau <ja...@dremio.com>
> wrote:
>
> > You can run a remote debugging session. However, given what you're
> > describing, it sounds very much like an issue with the build rather than
> an
> > issue with the Drill code or test. (Although a better error message would
> > be nice for the situation where the app.class.path is missing.) As such,
> > you would most likely need to debug the maven code to find out why the
> > directive described below is failing.
> >
> > It seems like, on your system, maven-antrun-plugin isn't working
> correctly.
> > The use of it in this module is very simple: generate a complete
> classpath
> > and then put that classpath in an environment variable. In the plugin
> > definition we're assigning the app.class.path variable the value of the
> > value that the antrun plugin generated for the value of
> > maven.test.classpath. (Note that you can't use this directly as this is
> > something that is created by the antrun plugin and isn't generally
> > available as a property inside of maven.) The code is here:
> >
> > https://github.com/apache/drill/blob/master/exec/jdbc-all/pom.xml#L215
> >
> > My guess is that your maven has a slightly different version of ant
> plugin
> > that isn't handling this correctly. If that is the case, we can fix this
> by
> > specifying a managed version of the antrun plugin. I'm on Maven 3.3.3 so
> > when I run 'mvn help:effective-pom' and find the antrun plugin I see:
> >
> > <plugin>
> > <artifactId>maven-antrun-plugin</artifactId>
> > <version>1.7</version>
> > </plugin>
> >
> > Can you confirm what you see? If you add <version>1.7</version> directly
> > after line 215, does that resolve the issue?
> >
> >
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Wed, Sep 16, 2015 at 6:17 AM, Chris Westin <ch...@gmail.com>
> > wrote:
> >
> > > I only tried to run it from the IDE after it failed in mvn install (in
> > > order to figure out why it's failing). Great, so if it can't work in
> the
> > > IDE, how do we figure out why it's failing?
> > > On Sep 16, 2015 5:37 AM, "Jacques Nadeau" <ja...@dremio.com> wrote:
> > >
> > > > Ah, you're focused on testing from within the IDE?
> > > >
> > > > The level complexity of the build process to get a test to correctly
> > test
> > > > the right thing means jumping through a bunch of hoops to clear the
> > > > classpath and then use a special classloader. I can't imagine that
> you
> > > > could get it to run correctly in an ide. For example, Eclipse is very
> > > > sloppy about keeping classpaths perfect versus what is declared in
> the
> > > pom
> > > > file.
> > > >
> > > > The parameter you're looking for is generated by the ant plugin
> simply
> > > > because that appears the way to get the value into an environment
> > > variable
> > > > so that the inner classloader can load the drillbit for the test.
> > > >
> > > > The test: loads a drillbit in one classloader using the alternative
> > > > classpath provided by the app.class.path variable. This is taken from
> > > what
> > > > would have typically been the jvm level classpath. We then clear the
> > jvm
> > > > classpath to only include the test class, Junit and hamcrest. After
> > the
> > > > drillbit is initialized and we've run one query, we then add the
> jdbc
> > > all
> > > > jar to the system classloader and open a connection to the drillbit
> and
> > > > execute a query. The test is designed specifically to confirm that
> the
> > > > requisite classes are correctly included in jdbc-all and that it will
> > run
> > > > correctly. The test can't run without the shaded jar being generated
> > and
> > > I
> > > > can't imagine any of the of the ides have good enough understanding
> of
> > > the
> > > > various maven plugins and options used that they would correctly
> work.
> > > Even
> > > > if you found some changes that made the test execute in and ide, I
> > can't
> > > > imagine that it would correctly manage all the classpath stuff.
> > > > On Sep 15, 2015 9:37 PM, "Chris Westin" <ch...@gmail.com>
> > wrote:
> > > >
> > > > > Variability: for me so far 2 out of 2 times.
> > > > >
> > > > > No stack trace, but as above, when I try to reproduce it in an IDE
> > > > > "This seems to be because the test is getting an
> > ExceptionInInitializer
> > > > in
> > > > > DrillbitClassLoader because the app.class.path property isn't set
> > (and
> > > > then
> > > > > the resulting String.length() on its value throws an NPE)."
> > > > >
> > > > > I don't see app.class.path set anywhere in any pom.xml (so it's not
> > > > getting
> > > > > set when I copy the surefire arguments into the IDE's launch
> > > > configuration
> > > > > for the test, either).
> > > > >
> > > > >
> > > > > On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <
> jacques@dremio.com>
> > > > > wrote:
> > > > >
> > > > > > It was tested on a clean machine a number of times. Any thoughts
> on
> > > the
> > > > > > variability? Can you provide stack trace?
> > > > > > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <skatkam@maprtech.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Yes, I see this issue too.
> > > > > > >
> > > > > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <
> > > chriswestin42@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > This seems to be because the test is getting an
> > > > > ExceptionInInitializer
> > > > > > in
> > > > > > > > DrillbitClassLoader because the app.class.path property isn't
> > set
> > > > > (and
> > > > > > > then
> > > > > > > > the resulting String.length() on its value throws an NPE).
> > > > > > > >
> > > > > > > > Bueller?
> > > > > > > >
> > > > > > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> > > > > chriswestin42@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> I just rebased, and twice in a row I've gotten wedged
> running
> > > > > > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Chris Westin <ch...@gmail.com>.
I upgraded to maven 3.3.3 (from 3.2.3). I checked effective pom, and it's
antrun 1.7. However, the unit tests still get wedged in the same place.
On Wed, Sep 16, 2015 at 8:05 AM, Jacques Nadeau <ja...@dremio.com> wrote:
> You can run a remote debugging session. However, given what you're
> describing, it sounds very much like an issue with the build rather than an
> issue with the Drill code or test. (Although a better error message would
> be nice for the situation where the app.class.path is missing.) As such,
> you would most likely need to debug the maven code to find out why the
> directive described below is failing.
>
> It seems like, on your system, maven-antrun-plugin isn't working correctly.
> The use of it in this module is very simple: generate a complete classpath
> and then put that classpath in an environment variable. In the plugin
> definition we're assigning the app.class.path variable the value of the
> value that the antrun plugin generated for the value of
> maven.test.classpath. (Note that you can't use this directly as this is
> something that is created by the antrun plugin and isn't generally
> available as a property inside of maven.) The code is here:
>
> https://github.com/apache/drill/blob/master/exec/jdbc-all/pom.xml#L215
>
> My guess is that your maven has a slightly different version of ant plugin
> that isn't handling this correctly. If that is the case, we can fix this by
> specifying a managed version of the antrun plugin. I'm on Maven 3.3.3 so
> when I run 'mvn help:effective-pom' and find the antrun plugin I see:
>
> <plugin>
> <artifactId>maven-antrun-plugin</artifactId>
> <version>1.7</version>
> </plugin>
>
> Can you confirm what you see? If you add <version>1.7</version> directly
> after line 215, does that resolve the issue?
>
>
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Wed, Sep 16, 2015 at 6:17 AM, Chris Westin <ch...@gmail.com>
> wrote:
>
> > I only tried to run it from the IDE after it failed in mvn install (in
> > order to figure out why it's failing). Great, so if it can't work in the
> > IDE, how do we figure out why it's failing?
> > On Sep 16, 2015 5:37 AM, "Jacques Nadeau" <ja...@dremio.com> wrote:
> >
> > > Ah, you're focused on testing from within the IDE?
> > >
> > > The level complexity of the build process to get a test to correctly
> test
> > > the right thing means jumping through a bunch of hoops to clear the
> > > classpath and then use a special classloader. I can't imagine that you
> > > could get it to run correctly in an ide. For example, Eclipse is very
> > > sloppy about keeping classpaths perfect versus what is declared in the
> > pom
> > > file.
> > >
> > > The parameter you're looking for is generated by the ant plugin simply
> > > because that appears the way to get the value into an environment
> > variable
> > > so that the inner classloader can load the drillbit for the test.
> > >
> > > The test: loads a drillbit in one classloader using the alternative
> > > classpath provided by the app.class.path variable. This is taken from
> > what
> > > would have typically been the jvm level classpath. We then clear the
> jvm
> > > classpath to only include the test class, Junit and hamcrest. After
> the
> > > drillbit is initialized and we've run one query, we then add the jdbc
> > all
> > > jar to the system classloader and open a connection to the drillbit and
> > > execute a query. The test is designed specifically to confirm that the
> > > requisite classes are correctly included in jdbc-all and that it will
> run
> > > correctly. The test can't run without the shaded jar being generated
> and
> > I
> > > can't imagine any of the of the ides have good enough understanding of
> > the
> > > various maven plugins and options used that they would correctly work.
> > Even
> > > if you found some changes that made the test execute in and ide, I
> can't
> > > imagine that it would correctly manage all the classpath stuff.
> > > On Sep 15, 2015 9:37 PM, "Chris Westin" <ch...@gmail.com>
> wrote:
> > >
> > > > Variability: for me so far 2 out of 2 times.
> > > >
> > > > No stack trace, but as above, when I try to reproduce it in an IDE
> > > > "This seems to be because the test is getting an
> ExceptionInInitializer
> > > in
> > > > DrillbitClassLoader because the app.class.path property isn't set
> (and
> > > then
> > > > the resulting String.length() on its value throws an NPE)."
> > > >
> > > > I don't see app.class.path set anywhere in any pom.xml (so it's not
> > > getting
> > > > set when I copy the surefire arguments into the IDE's launch
> > > configuration
> > > > for the test, either).
> > > >
> > > >
> > > > On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
> > > > wrote:
> > > >
> > > > > It was tested on a clean machine a number of times. Any thoughts on
> > the
> > > > > variability? Can you provide stack trace?
> > > > > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com>
> > > wrote:
> > > > >
> > > > > > Yes, I see this issue too.
> > > > > >
> > > > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <
> > chriswestin42@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > This seems to be because the test is getting an
> > > > ExceptionInInitializer
> > > > > in
> > > > > > > DrillbitClassLoader because the app.class.path property isn't
> set
> > > > (and
> > > > > > then
> > > > > > > the resulting String.length() on its value throws an NPE).
> > > > > > >
> > > > > > > Bueller?
> > > > > > >
> > > > > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> > > > chriswestin42@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> I just rebased, and twice in a row I've gotten wedged running
> > > > > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Jacques Nadeau <ja...@dremio.com>.
You can run a remote debugging session. However, given what you're
describing, it sounds very much like an issue with the build rather than an
issue with the Drill code or test. (Although a better error message would
be nice for the situation where the app.class.path is missing.) As such,
you would most likely need to debug the maven code to find out why the
directive described below is failing.
It seems like, on your system, maven-antrun-plugin isn't working correctly.
The use of it in this module is very simple: generate a complete classpath
and then put that classpath in an environment variable. In the plugin
definition we're assigning the app.class.path variable the value of the
value that the antrun plugin generated for the value of
maven.test.classpath. (Note that you can't use this directly as this is
something that is created by the antrun plugin and isn't generally
available as a property inside of maven.) The code is here:
https://github.com/apache/drill/blob/master/exec/jdbc-all/pom.xml#L215
My guess is that your maven has a slightly different version of ant plugin
that isn't handling this correctly. If that is the case, we can fix this by
specifying a managed version of the antrun plugin. I'm on Maven 3.3.3 so
when I run 'mvn help:effective-pom' and find the antrun plugin I see:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
</plugin>
Can you confirm what you see? If you add <version>1.7</version> directly
after line 215, does that resolve the issue?
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Wed, Sep 16, 2015 at 6:17 AM, Chris Westin <ch...@gmail.com>
wrote:
> I only tried to run it from the IDE after it failed in mvn install (in
> order to figure out why it's failing). Great, so if it can't work in the
> IDE, how do we figure out why it's failing?
> On Sep 16, 2015 5:37 AM, "Jacques Nadeau" <ja...@dremio.com> wrote:
>
> > Ah, you're focused on testing from within the IDE?
> >
> > The level complexity of the build process to get a test to correctly test
> > the right thing means jumping through a bunch of hoops to clear the
> > classpath and then use a special classloader. I can't imagine that you
> > could get it to run correctly in an ide. For example, Eclipse is very
> > sloppy about keeping classpaths perfect versus what is declared in the
> pom
> > file.
> >
> > The parameter you're looking for is generated by the ant plugin simply
> > because that appears the way to get the value into an environment
> variable
> > so that the inner classloader can load the drillbit for the test.
> >
> > The test: loads a drillbit in one classloader using the alternative
> > classpath provided by the app.class.path variable. This is taken from
> what
> > would have typically been the jvm level classpath. We then clear the jvm
> > classpath to only include the test class, Junit and hamcrest. After the
> > drillbit is initialized and we've run one query, we then add the jdbc
> all
> > jar to the system classloader and open a connection to the drillbit and
> > execute a query. The test is designed specifically to confirm that the
> > requisite classes are correctly included in jdbc-all and that it will run
> > correctly. The test can't run without the shaded jar being generated and
> I
> > can't imagine any of the of the ides have good enough understanding of
> the
> > various maven plugins and options used that they would correctly work.
> Even
> > if you found some changes that made the test execute in and ide, I can't
> > imagine that it would correctly manage all the classpath stuff.
> > On Sep 15, 2015 9:37 PM, "Chris Westin" <ch...@gmail.com> wrote:
> >
> > > Variability: for me so far 2 out of 2 times.
> > >
> > > No stack trace, but as above, when I try to reproduce it in an IDE
> > > "This seems to be because the test is getting an ExceptionInInitializer
> > in
> > > DrillbitClassLoader because the app.class.path property isn't set (and
> > then
> > > the resulting String.length() on its value throws an NPE)."
> > >
> > > I don't see app.class.path set anywhere in any pom.xml (so it's not
> > getting
> > > set when I copy the surefire arguments into the IDE's launch
> > configuration
> > > for the test, either).
> > >
> > >
> > > On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
> > > wrote:
> > >
> > > > It was tested on a clean machine a number of times. Any thoughts on
> the
> > > > variability? Can you provide stack trace?
> > > > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com>
> > wrote:
> > > >
> > > > > Yes, I see this issue too.
> > > > >
> > > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <
> chriswestin42@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > > This seems to be because the test is getting an
> > > ExceptionInInitializer
> > > > in
> > > > > > DrillbitClassLoader because the app.class.path property isn't set
> > > (and
> > > > > then
> > > > > > the resulting String.length() on its value throws an NPE).
> > > > > >
> > > > > > Bueller?
> > > > > >
> > > > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> > > chriswestin42@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> I just rebased, and twice in a row I've gotten wedged running
> > > > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > > > >>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Chris Westin <ch...@gmail.com>.
I only tried to run it from the IDE after it failed in mvn install (in
order to figure out why it's failing). Great, so if it can't work in the
IDE, how do we figure out why it's failing?
On Sep 16, 2015 5:37 AM, "Jacques Nadeau" <ja...@dremio.com> wrote:
> Ah, you're focused on testing from within the IDE?
>
> The level complexity of the build process to get a test to correctly test
> the right thing means jumping through a bunch of hoops to clear the
> classpath and then use a special classloader. I can't imagine that you
> could get it to run correctly in an ide. For example, Eclipse is very
> sloppy about keeping classpaths perfect versus what is declared in the pom
> file.
>
> The parameter you're looking for is generated by the ant plugin simply
> because that appears the way to get the value into an environment variable
> so that the inner classloader can load the drillbit for the test.
>
> The test: loads a drillbit in one classloader using the alternative
> classpath provided by the app.class.path variable. This is taken from what
> would have typically been the jvm level classpath. We then clear the jvm
> classpath to only include the test class, Junit and hamcrest. After the
> drillbit is initialized and we've run one query, we then add the jdbc all
> jar to the system classloader and open a connection to the drillbit and
> execute a query. The test is designed specifically to confirm that the
> requisite classes are correctly included in jdbc-all and that it will run
> correctly. The test can't run without the shaded jar being generated and I
> can't imagine any of the of the ides have good enough understanding of the
> various maven plugins and options used that they would correctly work. Even
> if you found some changes that made the test execute in and ide, I can't
> imagine that it would correctly manage all the classpath stuff.
> On Sep 15, 2015 9:37 PM, "Chris Westin" <ch...@gmail.com> wrote:
>
> > Variability: for me so far 2 out of 2 times.
> >
> > No stack trace, but as above, when I try to reproduce it in an IDE
> > "This seems to be because the test is getting an ExceptionInInitializer
> in
> > DrillbitClassLoader because the app.class.path property isn't set (and
> then
> > the resulting String.length() on its value throws an NPE)."
> >
> > I don't see app.class.path set anywhere in any pom.xml (so it's not
> getting
> > set when I copy the surefire arguments into the IDE's launch
> configuration
> > for the test, either).
> >
> >
> > On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
> > wrote:
> >
> > > It was tested on a clean machine a number of times. Any thoughts on the
> > > variability? Can you provide stack trace?
> > > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com>
> wrote:
> > >
> > > > Yes, I see this issue too.
> > > >
> > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <chriswestin42@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > This seems to be because the test is getting an
> > ExceptionInInitializer
> > > in
> > > > > DrillbitClassLoader because the app.class.path property isn't set
> > (and
> > > > then
> > > > > the resulting String.length() on its value throws an NPE).
> > > > >
> > > > > Bueller?
> > > > >
> > > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> > chriswestin42@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> I just rebased, and twice in a row I've gotten wedged running
> > > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Jacques Nadeau <ja...@dremio.com>.
Ah, you're focused on testing from within the IDE?
The level complexity of the build process to get a test to correctly test
the right thing means jumping through a bunch of hoops to clear the
classpath and then use a special classloader. I can't imagine that you
could get it to run correctly in an ide. For example, Eclipse is very
sloppy about keeping classpaths perfect versus what is declared in the pom
file.
The parameter you're looking for is generated by the ant plugin simply
because that appears the way to get the value into an environment variable
so that the inner classloader can load the drillbit for the test.
The test: loads a drillbit in one classloader using the alternative
classpath provided by the app.class.path variable. This is taken from what
would have typically been the jvm level classpath. We then clear the jvm
classpath to only include the test class, Junit and hamcrest. After the
drillbit is initialized and we've run one query, we then add the jdbc all
jar to the system classloader and open a connection to the drillbit and
execute a query. The test is designed specifically to confirm that the
requisite classes are correctly included in jdbc-all and that it will run
correctly. The test can't run without the shaded jar being generated and I
can't imagine any of the of the ides have good enough understanding of the
various maven plugins and options used that they would correctly work. Even
if you found some changes that made the test execute in and ide, I can't
imagine that it would correctly manage all the classpath stuff.
On Sep 15, 2015 9:37 PM, "Chris Westin" <ch...@gmail.com> wrote:
> Variability: for me so far 2 out of 2 times.
>
> No stack trace, but as above, when I try to reproduce it in an IDE
> "This seems to be because the test is getting an ExceptionInInitializer in
> DrillbitClassLoader because the app.class.path property isn't set (and then
> the resulting String.length() on its value throws an NPE)."
>
> I don't see app.class.path set anywhere in any pom.xml (so it's not getting
> set when I copy the surefire arguments into the IDE's launch configuration
> for the test, either).
>
>
> On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
> wrote:
>
> > It was tested on a clean machine a number of times. Any thoughts on the
> > variability? Can you provide stack trace?
> > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
> >
> > > Yes, I see this issue too.
> > >
> > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
> > > wrote:
> > > >
> > > > This seems to be because the test is getting an
> ExceptionInInitializer
> > in
> > > > DrillbitClassLoader because the app.class.path property isn't set
> (and
> > > then
> > > > the resulting String.length() on its value throws an NPE).
> > > >
> > > > Bueller?
> > > >
> > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> chriswestin42@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> I just rebased, and twice in a row I've gotten wedged running
> > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Daniel Barclay <db...@maprtech.com>.
Chris Westin wrote:
> Variability: for me so far 2 out of 2 times.
>
> No stack trace, but as above, when I try to reproduce it in an IDE
> "This seems to be because the test is getting an ExceptionInInitializer in
> DrillbitClassLoader because the app.class.path property isn't set (and then
> the resulting String.length() on its value throws an NPE)."
Yes, I just ran into that today too, trying to run it in an IDE (Eclipse).
>
> I don't see app.class.path set anywhere in any pom.xml (so it's not getting
> set when I copy the surefire arguments into the IDE's launch configuration
> for the test, either).
It does seem to be set by something in the JDBC-all POM file, but not
directly--there's some embedded Ant script getting the value from
somewhere else.)
Daniel
>
>
> On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com> wrote:
>
>> It was tested on a clean machine a number of times. Any thoughts on the
>> variability? Can you provide stack trace?
>> On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
>>
>>> Yes, I see this issue too.
>>>
>>>> On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
>>> wrote:
>>>>
>>>> This seems to be because the test is getting an ExceptionInInitializer
>> in
>>>> DrillbitClassLoader because the app.class.path property isn't set (and
>>> then
>>>> the resulting String.length() on its value throws an NPE).
>>>>
>>>> Bueller?
>>>>
>>>> On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <chriswestin42@gmail.com
>>>
>>>> wrote:
>>>>
>>>>> I just rebased, and twice in a row I've gotten wedged running
>>>>> org.apache.drill.jdbc.ITTestShadedJar
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
--
Daniel Barclay
MapR Technologies
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Jacques Nadeau <ja...@dremio.com>.
Aman, your issue is different. Derby starts up on a particular port. If you
have something else running on that port (including a paused version of a
previous run) then the test would fail. Are you sure you don't have
anything running on that port?
On Sep 15, 2015 10:25 PM, "Aman Sinha" <as...@maprtech.com> wrote:
> Here's a different issue I encountered running unit tests on a clean master
> branch on my Mac:
>
> Running org.apache.drill.exec.store.jdbc.TestJdbcPlugin
> ...
> ...
> Tue Sep 15 20:01:36 PDT 2015 : Could not listen on port 20000 on host
> 127.0.0.1:
> java.net.BindException: Address already in use
>
> It has to do with starting up derby:
>
> storage-jdbc asinha$ cat derby.log
>
> Tue Sep 15 22:13:01 PDT 2015 : Apache Derby Network Server - 10.11.1.1 -
> (1616546) started and ready to accept connections on port 1527
> Tue Sep 15 22:13:01 PDT 2015 : Could not listen on port 20000 on host
> 127.0.0.1:
> java.net.BindException: Address already in use
> An exception was thrown during network server startup.
> DRDA_ListenPort.S:Could not listen on port 20000 on host 127.0.0.1:
> java.net.BindException: Address already in use
>
>
> On Tue, Sep 15, 2015 at 9:37 PM, Chris Westin <ch...@gmail.com>
> wrote:
>
> > Variability: for me so far 2 out of 2 times.
> >
> > No stack trace, but as above, when I try to reproduce it in an IDE
> > "This seems to be because the test is getting an ExceptionInInitializer
> in
> > DrillbitClassLoader because the app.class.path property isn't set (and
> then
> > the resulting String.length() on its value throws an NPE)."
> >
> > I don't see app.class.path set anywhere in any pom.xml (so it's not
> getting
> > set when I copy the surefire arguments into the IDE's launch
> configuration
> > for the test, either).
> >
> >
> > On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
> > wrote:
> >
> > > It was tested on a clean machine a number of times. Any thoughts on the
> > > variability? Can you provide stack trace?
> > > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com>
> wrote:
> > >
> > > > Yes, I see this issue too.
> > > >
> > > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <chriswestin42@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > This seems to be because the test is getting an
> > ExceptionInInitializer
> > > in
> > > > > DrillbitClassLoader because the app.class.path property isn't set
> > (and
> > > > then
> > > > > the resulting String.length() on its value throws an NPE).
> > > > >
> > > > > Bueller?
> > > > >
> > > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> > chriswestin42@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> I just rebased, and twice in a row I've gotten wedged running
> > > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Daniel Barclay <db...@maprtech.com>.
Aman Sinha wrote:
> Here's a different issue I encountered running unit tests on a clean master
> branch on my Mac:
>
> Running org.apache.drill.exec.store.jdbc.TestJdbcPlugin
But that's the JDBC storage plug-in, not the Drill JDBC driver and
its tests.
Daniel
> ...
> ...
> Tue Sep 15 20:01:36 PDT 2015 : Could not listen on port 20000 on host
> 127.0.0.1:
> java.net.BindException: Address already in use
>
> It has to do with starting up derby:
>
> storage-jdbc asinha$ cat derby.log
>
> Tue Sep 15 22:13:01 PDT 2015 : Apache Derby Network Server - 10.11.1.1 -
> (1616546) started and ready to accept connections on port 1527
> Tue Sep 15 22:13:01 PDT 2015 : Could not listen on port 20000 on host
> 127.0.0.1:
> java.net.BindException: Address already in use
> An exception was thrown during network server startup.
> DRDA_ListenPort.S:Could not listen on port 20000 on host 127.0.0.1:
> java.net.BindException: Address already in use
>
>
> On Tue, Sep 15, 2015 at 9:37 PM, Chris Westin <ch...@gmail.com>
> wrote:
>
>> Variability: for me so far 2 out of 2 times.
>>
>> No stack trace, but as above, when I try to reproduce it in an IDE
>> "This seems to be because the test is getting an ExceptionInInitializer in
>> DrillbitClassLoader because the app.class.path property isn't set (and then
>> the resulting String.length() on its value throws an NPE)."
>>
>> I don't see app.class.path set anywhere in any pom.xml (so it's not getting
>> set when I copy the surefire arguments into the IDE's launch configuration
>> for the test, either).
>>
>>
>> On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
>> wrote:
>>
>>> It was tested on a clean machine a number of times. Any thoughts on the
>>> variability? Can you provide stack trace?
>>> On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
>>>
>>>> Yes, I see this issue too.
>>>>
>>>>> On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
>>>> wrote:
>>>>>
>>>>> This seems to be because the test is getting an
>> ExceptionInInitializer
>>> in
>>>>> DrillbitClassLoader because the app.class.path property isn't set
>> (and
>>>> then
>>>>> the resulting String.length() on its value throws an NPE).
>>>>>
>>>>> Bueller?
>>>>>
>>>>> On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
>> chriswestin42@gmail.com
>>>>
>>>>> wrote:
>>>>>
>>>>>> I just rebased, and twice in a row I've gotten wedged running
>>>>>> org.apache.drill.jdbc.ITTestShadedJar
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
--
Daniel Barclay
MapR Technologies
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Aman Sinha <as...@maprtech.com>.
Here's a different issue I encountered running unit tests on a clean master
branch on my Mac:
Running org.apache.drill.exec.store.jdbc.TestJdbcPlugin
...
...
Tue Sep 15 20:01:36 PDT 2015 : Could not listen on port 20000 on host
127.0.0.1:
java.net.BindException: Address already in use
It has to do with starting up derby:
storage-jdbc asinha$ cat derby.log
Tue Sep 15 22:13:01 PDT 2015 : Apache Derby Network Server - 10.11.1.1 -
(1616546) started and ready to accept connections on port 1527
Tue Sep 15 22:13:01 PDT 2015 : Could not listen on port 20000 on host
127.0.0.1:
java.net.BindException: Address already in use
An exception was thrown during network server startup.
DRDA_ListenPort.S:Could not listen on port 20000 on host 127.0.0.1:
java.net.BindException: Address already in use
On Tue, Sep 15, 2015 at 9:37 PM, Chris Westin <ch...@gmail.com>
wrote:
> Variability: for me so far 2 out of 2 times.
>
> No stack trace, but as above, when I try to reproduce it in an IDE
> "This seems to be because the test is getting an ExceptionInInitializer in
> DrillbitClassLoader because the app.class.path property isn't set (and then
> the resulting String.length() on its value throws an NPE)."
>
> I don't see app.class.path set anywhere in any pom.xml (so it's not getting
> set when I copy the surefire arguments into the IDE's launch configuration
> for the test, either).
>
>
> On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com>
> wrote:
>
> > It was tested on a clean machine a number of times. Any thoughts on the
> > variability? Can you provide stack trace?
> > On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
> >
> > > Yes, I see this issue too.
> > >
> > > > On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
> > > wrote:
> > > >
> > > > This seems to be because the test is getting an
> ExceptionInInitializer
> > in
> > > > DrillbitClassLoader because the app.class.path property isn't set
> (and
> > > then
> > > > the resulting String.length() on its value throws an NPE).
> > > >
> > > > Bueller?
> > > >
> > > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <
> chriswestin42@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> I just rebased, and twice in a row I've gotten wedged running
> > > >> org.apache.drill.jdbc.ITTestShadedJar
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Chris Westin <ch...@gmail.com>.
Variability: for me so far 2 out of 2 times.
No stack trace, but as above, when I try to reproduce it in an IDE
"This seems to be because the test is getting an ExceptionInInitializer in
DrillbitClassLoader because the app.class.path property isn't set (and then
the resulting String.length() on its value throws an NPE)."
I don't see app.class.path set anywhere in any pom.xml (so it's not getting
set when I copy the surefire arguments into the IDE's launch configuration
for the test, either).
On Tue, Sep 15, 2015 at 9:09 PM, Jacques Nadeau <ja...@dremio.com> wrote:
> It was tested on a clean machine a number of times. Any thoughts on the
> variability? Can you provide stack trace?
> On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
>
> > Yes, I see this issue too.
> >
> > > On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
> > wrote:
> > >
> > > This seems to be because the test is getting an ExceptionInInitializer
> in
> > > DrillbitClassLoader because the app.class.path property isn't set (and
> > then
> > > the resulting String.length() on its value throws an NPE).
> > >
> > > Bueller?
> > >
> > > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <chriswestin42@gmail.com
> >
> > > wrote:
> > >
> > >> I just rebased, and twice in a row I've gotten wedged running
> > >> org.apache.drill.jdbc.ITTestShadedJar
> > >>
> > >>
> > >>
> >
> >
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Jacques Nadeau <ja...@dremio.com>.
It was tested on a clean machine a number of times. Any thoughts on the
variability? Can you provide stack trace?
On Sep 15, 2015 6:28 PM, "Sudheesh Katkam" <sk...@maprtech.com> wrote:
> Yes, I see this issue too.
>
> > On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com>
> wrote:
> >
> > This seems to be because the test is getting an ExceptionInInitializer in
> > DrillbitClassLoader because the app.class.path property isn't set (and
> then
> > the resulting String.length() on its value throws an NPE).
> >
> > Bueller?
> >
> > On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <ch...@gmail.com>
> > wrote:
> >
> >> I just rebased, and twice in a row I've gotten wedged running
> >> org.apache.drill.jdbc.ITTestShadedJar
> >>
> >>
> >>
>
>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Sudheesh Katkam <sk...@maprtech.com>.
Yes, I see this issue too.
> On Sep 15, 2015, at 5:53 PM, Chris Westin <ch...@gmail.com> wrote:
>
> This seems to be because the test is getting an ExceptionInInitializer in
> DrillbitClassLoader because the app.class.path property isn't set (and then
> the resulting String.length() on its value throws an NPE).
>
> Bueller?
>
> On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <ch...@gmail.com>
> wrote:
>
>> I just rebased, and twice in a row I've gotten wedged running
>> org.apache.drill.jdbc.ITTestShadedJar
>>
>>
>>
Re: Is anyone having issues with the jdbc unit tests (ITTestShadedJar)?
Posted by Chris Westin <ch...@gmail.com>.
This seems to be because the test is getting an ExceptionInInitializer in
DrillbitClassLoader because the app.class.path property isn't set (and then
the resulting String.length() on its value throws an NPE).
Bueller?
On Tue, Sep 15, 2015 at 5:20 PM, Chris Westin <ch...@gmail.com>
wrote:
> I just rebased, and twice in a row I've gotten wedged running
> org.apache.drill.jdbc.ITTestShadedJar
>
>
>