accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: VFS class reloading?
Date Wed, 17 Apr 2013 01:24:34 GMT
Possibly. Being rather explicit about what we support is definitely 
good; finding out when we accidentally break something we're supposed to 
support... also a good idea. :D

I'm almost of the mindset to not really encourage people to use 0.20.205 
hadoop things anymore, maybe? I have no idea what 1.0 and 1.1 (even 0.23 
or 2.0) adoption of Hadoop in the community looks like these days.

On 04/16/2013 08:54 PM, dlmarion@comcast.net wrote:
> Likely. I just followed the directions in the README as I have not kept up with all of
the changes in 1.5. It seems that maybe we should have Jenkins build with all of the different
profile variations, or at least the ones that we use as examples in the README.
>
> ----- Original Message -----
> From: "Josh Elser" <josh.elser@gmail.com>
> To: dev@accumulo.apache.org
> Sent: Tuesday, April 16, 2013 8:49:40 PM
> Subject: Re: VFS class reloading?
>
> I wish I could tell you that it worked on my machine, but alas the
> command below did fail on a bunch of core tests via
> Accumulo*FormatTest$MRTester.
>
> Looking into it currently. Maybe someone accidentally broke
> compatibility with the old Hadoop stuff and we need to add a new
> dependency with 0.20.205.0?
>
> On 04/16/2013 08:39 PM, dlmarion@comcast.net wrote:
>> Updated my local 1.5 branch and tried to build with "mvn clean package -P assemble
-Dhadoop.version=0.20.205.0". I'm running CDH3 Update 3 locally, so that should work. A bunch
of tests failed in core with:
>>
>> Caused by: java.lang.ClassNotFoundException: org.codehaus.jackson.map.JsonMappingException
>> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>> at java.security.AccessController.doPrivileged(Native Method)
>> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>>
>>
>> Has anyone else seen this?
>>
>> -- Dave
>>
>> ----- Original Message -----
>> From: "Eric Newton" <eric.newton@gmail.com>
>> To: dev@accumulo.apache.org
>> Sent: Tuesday, April 16, 2013 7:52:09 PM
>> Subject: Re: VFS class reloading?
>>
>> We have tests for dynamic loading of classes so I'm pretty sure it works.
>>
>> John, can you repeat the failure?
>>
>> -Eric
>>
>>
>>
>> On Tue, Apr 16, 2013 at 6:50 PM, Dave Marion <dlmarion@comcast.net> wrote:
>>
>>> Looking at the code, it should work. Keith and I had several conversations
>>> about what the new classloader should do. I believe that he wanted it to
>>> behave like the old one and what I see in the code supports that. If it is
>>> not working, then I would say create a ticket for it for now. I'll try to
>>> replicate it tonight if I have time.
>>>
>>> -----Original Message-----
>>> From: Dave Marion [mailto:dlmarion@comcast.net]
>>> Sent: Tuesday, April 16, 2013 6:41 PM
>>> To: dev@accumulo.apache.org
>>> Subject: RE: VFS class reloading?
>>>
>>> The implementation changed several times, so the pre-1.5 layout may not
>>> work. In 1.5, using the bootstrap script, it should put the accumulo jars
>>> into HDFS and dynamic loading from there should occur. I'll try and test
>>> tonight if I have time.
>>>
>>> -----Original Message-----
>>> From: John Vines [mailto:vines@apache.org]
>>> Sent: Tuesday, April 16, 2013 6:30 PM
>>> To: Accumulo Dev List
>>> Subject: VFS class reloading?
>>>
>>> Maybe I missed something with the switch to the VFS classloader, but does
>>> dynamic loading out of lib/ext no longer work? I had accumulo 1.5 running,
>>> threw an iterator in there, but had to restart tserver to get the new
>>> iterator picked up. Was that an intentional change?
>>>
>>>
>


Mime
View raw message