[jira] Commented: (HADOOP-2249) [hbase] Add means of getting the timestamps for all cell versions: e.g. long [] getVersions(row, column)
[ https://issues.apache.org/jira/browse/HADOOP-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547389 ] Bryan Duxbury commented on HADOOP-2249: --- I was hoping for a method that would give you all of the timestamps for a row, not per row and column. You'd want to able to do this so that you could know what different versions of a particular entity you have in HBase. As such, basically all I'm looking for is: long[] getRowTimestamps(Text row) > [hbase] Add means of getting the timestamps for all cell versions: e.g. long > [] getVersions(row, column) > > > Key: HADOOP-2249 > URL: https://issues.apache.org/jira/browse/HADOOP-2249 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: stack >Priority: Minor > Fix For: 0.16.0 > > > Should be means of asking hbase for list of all the timestamps associated > with a particular cell. The brute force way would be adding a getVersions > method but perhaps we can come up w/ something more elegant than this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547383 ] Hadoop QA commented on HADOOP-2314: --- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370690/block.patch against trunk revision r600019. @author +1. The patch does not contain any @author tags. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs +1. The patch does not introduce any new Findbugs warnings. core tests +1. The patch passed core unit tests. contrib tests +1. The patch passed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1226/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1226/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1226/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1226/console This message is automatically generated. > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug > Components: dfs >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2326) Add a Random backoff for the initial block report sent to the Name node
[ https://issues.apache.org/jira/browse/HADOOP-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dhruba borthakur updated HADOOP-2326: - Attachment: (was: asyncRPC-4.patch) > Add a Random backoff for the initial block report sent to the Name node > --- > > Key: HADOOP-2326 > URL: https://issues.apache.org/jira/browse/HADOOP-2326 > Project: Hadoop > Issue Type: Improvement > Components: dfs >Reporter: Sanjay Radia >Assignee: Sanjay Radia > Fix For: 0.16.0 > > > Startup time can be improved if the initial block reports are spread randomly > over small period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2326) Add a Random backoff for the initial block report sent to the Name node
[ https://issues.apache.org/jira/browse/HADOOP-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dhruba borthakur updated HADOOP-2326: - Comment: was deleted > Add a Random backoff for the initial block report sent to the Name node > --- > > Key: HADOOP-2326 > URL: https://issues.apache.org/jira/browse/HADOOP-2326 > Project: Hadoop > Issue Type: Improvement > Components: dfs >Reporter: Sanjay Radia >Assignee: Sanjay Radia > Fix For: 0.16.0 > > > Startup time can be improved if the initial block reports are spread randomly > over small period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-1841) IPC server should write repsonses asynchronously
[ https://issues.apache.org/jira/browse/HADOOP-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dhruba borthakur updated HADOOP-1841: - Attachment: asyncRPC-4.patch This patch is in response to Doug's comments that we need to show improvement in performance in the face of slow clients. This patch has a unit test that creates a server with one handler thread. One thread makes an RPC and stops processing the response. Another thread then issues another RPC and it completes successfully even though the first thread has not yet consumed the RPC response. This test passes successfully with this patch whereas it fails with trunk. Please let me know is it addresses your concerns. If so, then the only remaining thing to make this patch committable is to demonstrate that it does not degrade performance for sort runs. > IPC server should write repsonses asynchronously > > > Key: HADOOP-1841 > URL: https://issues.apache.org/jira/browse/HADOOP-1841 > Project: Hadoop > Issue Type: Improvement > Components: ipc >Reporter: Doug Cutting >Assignee: dhruba borthakur > Attachments: asyncRPC-2.patch, asyncRPC-4.patch, asyncRPC.patch, > asyncRPC.patch > > > Hadoop's IPC Server currently writes responses from request handler threads > using blocking writes. Performance and scalability might be improved if > responses were written asynchronously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2326) Add a Random backoff for the initial block report sent to the Name node
[ https://issues.apache.org/jira/browse/HADOOP-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dhruba borthakur updated HADOOP-2326: - Attachment: asyncRPC-4.patch This patch is in response to Doug's comments that we need to show improvement in performance in the face of slow clients. This patch has a unit test that creates a server with one handler thread. One thread makes an RPC and stops processing the response. Another thread then issues another RPC and it completes successfully even though the first thread has not yet consumed the RPC response. This test passes successfully with this patch whereas it fails with trunk. Please let me know is it addresses your concerns. If so, then the only remaining thing to make this patch committable is to demonstrate that it does not degrade performance for sort runs. > Add a Random backoff for the initial block report sent to the Name node > --- > > Key: HADOOP-2326 > URL: https://issues.apache.org/jira/browse/HADOOP-2326 > Project: Hadoop > Issue Type: Improvement > Components: dfs >Reporter: Sanjay Radia >Assignee: Sanjay Radia > Fix For: 0.16.0 > > Attachments: asyncRPC-4.patch > > > Startup time can be improved if the initial block reports are spread randomly > over small period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Deleted: (HADOOP-1828) [Hbase Shell] Switch Command for sub-shell
[
https://issues.apache.org/jira/browse/HADOOP-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Yoon deleted HADOOP-1828:
> [Hbase Shell] Switch Command for sub-shell
> --
>
> Key: HADOOP-1828
> URL: https://issues.apache.org/jira/browse/HADOOP-1828
> Project: Hadoop
> Issue Type: Improvement
> Environment: All environments
>Reporter: Edward Yoon
>Priority: Minor
>
> This is a swtich command patch for the future implementation of sub-shell.
> {code}
> HBase > altools;
> Hbase altools, 0.0.1 version
> Type 'help;' for Hbase altools usage.
> HBase.Altools > help;
> Type 'help ;' to see command-specific usage.
> * Global commands.
> FSHadoop FsShell operations.
> EXIT Exit shell
> SHOW List all tables.
> CLEAR Clear the screen.
> DESCRIBE Describe a table's columnfamilies.
> * Altools Commands.
> Projection ...
> HBase.Altools > exit;
> HBase > exit;
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
A tracing framework for Hadoop
Hi, We're grad students at UC Berkeley working on a project to instrument Hadoop using an open-source path-based tracing framework called X- Trace (www.x-trace.net/wiki). X-Trace captures causal dependencies between events in addition to timings, letting developers analyze not just performance but also context and dependencies for various events. We have created a web-based trace analysis UI that shows performance of different IPC calls, DFS operations, and phases of a MapReduce job. The goal is to let users easily spot the origin of unusual behavior in a running system at a centralized location. We believe that this kind of tracing can be used for performance tuning and debugging in both development and production environments. We'd like to get feedback on our work and suggestions on what trace analyses would be useful to Hadoop developers and users. Some of the reports we currently generate include machine utilization over time, relative performance of different tasks, and performance of DFS operations. You can see an example set of reports at http://www.cs.berkeley.edu/~matei/xtrace_sample_task.html (this is a trace of a Nutch indexing job). You can also read our project journal at http://radlab.cs.berkeley.edu/wiki/Projects/Monitoring_Hadoop_through_Tracing . We've already spotted some interesting issues, like map tasks and DFS reads/writes that are an order of magnitude slower than the average, and we are investigating possible causes for them. Most importantly, the UI lets a user easily see where the system is spending time and reason about how to tune it, and provides much more information than the progress data in the JobTracker UI. As a Hadoop developer, what kinds of questions do you want answered about running jobs that are hard to obtain just from process logs? Once we've had a discussion on features for a trace analysis UI, we would like to contribute our work into the Hadoop codebase. We will create a JIRA issue and patch adding this functionality. We're also interested in seeing if we can integrate X-Trace logging more tightly with the current Apache logging in Hadoop. Finally, we are currently experimenting on relatively small (<50 nodes) clusters here at Berkeley, but we would really like to try tracing some large (>1000 node) clusters. If there is someone interested in evaluating performance on such a cluster, we would be very happy to talk about how to set up X-Trace and provide you with a patch. Thanks, Andy Konwinski and Matei Zaharia
[jira] Assigned: (HADOOP-2225) Joining Three or More Tables
[ https://issues.apache.org/jira/browse/HADOOP-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Yoon reassigned HADOOP-2225: --- Assignee: Edward Yoon > Joining Three or More Tables > > > Key: HADOOP-2225 > URL: https://issues.apache.org/jira/browse/HADOOP-2225 > Project: Hadoop > Issue Type: Sub-task >Reporter: Edward Yoon >Assignee: Edward Yoon > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2240) Truncate for hbase
[ https://issues.apache.org/jira/browse/HADOOP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Yoon updated HADOOP-2240: Fix Version/s: 0.16.0 Affects Version/s: 0.15.0 Status: Patch Available (was: In Progress) submitting. > Truncate for hbase > -- > > Key: HADOOP-2240 > URL: https://issues.apache.org/jira/browse/HADOOP-2240 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: Billy Pearson >Assignee: Edward Yoon >Priority: Minor > Fix For: 0.16.0 > > Attachments: 2240.patch > > > Would be nice to have a way to truncate the tables from the shell. With out > doing a drop and create your self. Maybe the truncate could issue the drop > and create command for you based off the layout in the the table before the > truncate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2229) Provide a simple login implementation
[ https://issues.apache.org/jira/browse/HADOOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547376 ] Hadoop QA commented on HADOOP-2229: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370727/ugi5.patch against trunk revision r600019. @author +1. The patch does not contain any @author tags. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs -1. The patch appears to introduce 3 new Findbugs warnings. core tests -1. The patch failed core unit tests. contrib tests -1. The patch failed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1225/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1225/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1225/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1225/console This message is automatically generated. > Provide a simple login implementation > - > > Key: HADOOP-2229 > URL: https://issues.apache.org/jira/browse/HADOOP-2229 > Project: Hadoop > Issue Type: New Feature >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: ugi.patch, ugi1.patch, ugi2.patch, ugi3.patch, > ugi4.patch, ugi5.patch > > > Give a simple implementation of HADOOP-1701.Hadoop clients are assumed to > be started within a Unix-like network which provides user and group > management. This implementation read user information from the OS and send > them to the NameNode in plaintexts through RPC (see also HADOOP-2184). > NameNode trusts all information given and uses them for permission checking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2240) Truncate for hbase
[
https://issues.apache.org/jira/browse/HADOOP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Yoon updated HADOOP-2240:
Attachment: 2240.patch
- Truncate table is used to clean all data from a table.
SYNTAX: TRUNCATE TABLE table_name;
{code}
hql > insert into test (a,b) values ('aa','bb') where row='row1';
1 row inserted successfully. (0.41 sec)
hql > truncate table test;
'test' is successfully truncated.
hql > select * from test;
0 row(s) in set. (1.16 sec)
hql > exit;
{code}
- We need to get away from functionalities and focus on the internal algorithm
issues. I'll make these issues.
- i didn't make the test case becuase it already exists. (It just steps of
creating drop repeats.)
> Truncate for hbase
> --
>
> Key: HADOOP-2240
> URL: https://issues.apache.org/jira/browse/HADOOP-2240
> Project: Hadoop
> Issue Type: New Feature
> Components: contrib/hbase
>Reporter: Billy Pearson
>Assignee: Edward Yoon
>Priority: Minor
> Attachments: 2240.patch
>
>
> Would be nice to have a way to truncate the tables from the shell. With out
> doing a drop and create your self. Maybe the truncate could issue the drop
> and create command for you based off the layout in the the table before the
> truncate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2326) Add a Random backoff for the initial block report sent to the Name node
[ https://issues.apache.org/jira/browse/HADOOP-2326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547374 ] dhruba borthakur commented on HADOOP-2326: -- And it would be nice if the backoff period is somehow dependent on either namenode load and/or cluster size. > Add a Random backoff for the initial block report sent to the Name node > --- > > Key: HADOOP-2326 > URL: https://issues.apache.org/jira/browse/HADOOP-2326 > Project: Hadoop > Issue Type: Improvement > Components: dfs >Reporter: Sanjay Radia >Assignee: Sanjay Radia > Fix For: 0.16.0 > > > Startup time can be improved if the initial block reports are spread randomly > over small period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: hard link count for a file
Hi Raghu, Can you pl explain what curFile and backupFile refer to in this context? Are you referring to the block data file and the metafile? Thanks, dhruba -Original Message- From: Raghu Angadi [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 4:05 PM To: hadoop-dev@lucene.apache.org Subject: Re: hard link count for a file I am back to writing this code as part of periodic block verification. Another approach I am thinking of is to check curFile.lastModified() and backupFile.lastModified(). As long as these two are different, we could assume they are different files. This is simpler than trying to lock the files. Raghu. Raghu Angadi wrote: > > Thanks Nigel. > > Another hack I can think of is, if DataNode is not finalized we can try > to lock current/subdir.../blk_id and previous/subdir../blk_id. If second > lock fails, we can assume they are the same. > > Raghu. > > Nigel Daley wrote: >> Raghu, >> >> LGPL not allowed in distro: >> http://people.apache.org/~cliffs/3party.html >> >> Nige >> >> On Nov 6, 2007, at 11:32 PM, Raghu Angadi wrote: >> >
[jira] Work started: (HADOOP-2240) Truncate for hbase
[ https://issues.apache.org/jira/browse/HADOOP-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HADOOP-2240 started by Edward Yoon. > Truncate for hbase > -- > > Key: HADOOP-2240 > URL: https://issues.apache.org/jira/browse/HADOOP-2240 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: Billy Pearson >Assignee: Edward Yoon >Priority: Minor > > Would be nice to have a way to truncate the tables from the shell. With out > doing a drop and create your self. Maybe the truncate could issue the drop > and create command for you based off the layout in the the table before the > truncate. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547370 ] Hadoop QA commented on HADOOP-2288: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370725/2288_20071130c.patch against trunk revision r600019. @author +1. The patch does not contain any @author tags. javadoc -1. The javadoc tool appears to have generated messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs -1. The patch appears to introduce 1 new Findbugs warnings. core tests -1. The patch failed core unit tests. contrib tests -1. The patch failed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1224/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1224/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1224/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1224/console This message is automatically generated. > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130c.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2297) [Hbase Shell] System.exit() Handling in Jar command
[ https://issues.apache.org/jira/browse/HADOOP-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547369 ] Edward Yoon commented on HADOOP-2297: - Oh, Thanks michael! I'll try to do it. > [Hbase Shell] System.exit() Handling in Jar command > --- > > Key: HADOOP-2297 > URL: https://issues.apache.org/jira/browse/HADOOP-2297 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: Edward Yoon >Assignee: Edward Yoon > Fix For: 0.16.0 > > Attachments: 2297_v02.patch, 2297_v03.patch, Capture.java > > > I'd like to block the exitVM by System.exit(). > Shell should terminate by "quit" command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2323) JobTracker.close() prints stack traces for exceptions that are not errors
[
https://issues.apache.org/jira/browse/HADOOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547362
]
Hadoop QA commented on HADOOP-2323:
---
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12370714/patch.txt
against trunk revision r599951.
@author +1. The patch does not contain any @author tags.
javadoc +1. The javadoc tool did not generate any warning messages.
javac +1. The applied patch does not generate any new compiler warnings.
findbugs +1. The patch does not introduce any new Findbugs warnings.
core tests +1. The patch passed core unit tests.
contrib tests +1. The patch passed contrib unit tests.
Test results:
http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1223/testReport/
Findbugs warnings:
http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1223/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results:
http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1223/artifact/trunk/build/test/checkstyle-errors.html
Console output:
http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1223/console
This message is automatically generated.
> JobTracker.close() prints stack traces for exceptions that are not errors
> -
>
> Key: HADOOP-2323
> URL: https://issues.apache.org/jira/browse/HADOOP-2323
> Project: Hadoop
> Issue Type: Bug
> Components: mapred
>Affects Versions: 0.16.0
>Reporter: Jim Kellerman
>Assignee: Jim Kellerman
> Fix For: 0.16.0
>
> Attachments: patch.txt
>
>
> JobTracker.close() prints a stack trace for an interrupted exception even
> though it was the method that interrupted the thread that threw the
> exception. For example:
> {code}
> this.expireTrackers.stopTracker();
> try {
> this.expireTrackersThread.interrupt();
> this.expireTrackersThread.join();
> } catch (InterruptedException ex) {
> ex.printStackTrace();
> }
> {code}
> Well of course it is going to catch an InterruptedException after it just
> interrupted the thread!
> This is *not* an error and should *not* be dumped to the logs!
> In other circumstances, catching InterruptedException is entirely
> appropriate. Just not in close where you've told the thread to shutdown and
> then interrupted it to ensure it does!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2229) Provide a simple login implementation
[ https://issues.apache.org/jira/browse/HADOOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-2229: -- Status: Patch Available (was: Open) > Provide a simple login implementation > - > > Key: HADOOP-2229 > URL: https://issues.apache.org/jira/browse/HADOOP-2229 > Project: Hadoop > Issue Type: New Feature >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: ugi.patch, ugi1.patch, ugi2.patch, ugi3.patch, > ugi4.patch, ugi5.patch > > > Give a simple implementation of HADOOP-1701.Hadoop clients are assumed to > be started within a Unix-like network which provides user and group > management. This implementation read user information from the OS and send > them to the NameNode in plaintexts through RPC (see also HADOOP-2184). > NameNode trusts all information given and uses them for permission checking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2229) Provide a simple login implementation
[ https://issues.apache.org/jira/browse/HADOOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-2229: -- Attachment: ugi5.patch This patch incorporates Sanjay's comments. > Provide a simple login implementation > - > > Key: HADOOP-2229 > URL: https://issues.apache.org/jira/browse/HADOOP-2229 > Project: Hadoop > Issue Type: New Feature >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: ugi.patch, ugi1.patch, ugi2.patch, ugi3.patch, > ugi4.patch, ugi5.patch > > > Give a simple implementation of HADOOP-1701.Hadoop clients are assumed to > be started within a Unix-like network which provides user and group > management. This implementation read user information from the OS and send > them to the NameNode in plaintexts through RPC (see also HADOOP-2184). > NameNode trusts all information given and uses them for permission checking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Attachment: 2288_20071130c.patch > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130c.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Attachment: (was: 2288_20071130b.patch) > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130c.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Status: Patch Available (was: Open) > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130c.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2326) Add a Random backoff for the initial block report sent to the Name node
Add a Random backoff for the initial block report sent to the Name node --- Key: HADOOP-2326 URL: https://issues.apache.org/jira/browse/HADOOP-2326 Project: Hadoop Issue Type: Improvement Components: dfs Reporter: Sanjay Radia Assignee: Sanjay Radia Fix For: 0.16.0 Startup time can be improved if the initial block reports are spread randomly over small period of time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2229) Provide a simple login implementation
[ https://issues.apache.org/jira/browse/HADOOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547350 ] Sanjay Radia commented on HADOOP-2229: -- In writeFields, please write the kind of authentication technology (something like "STRING_UGI") to distinguish it from other authentication info such as tickets. readFields, it should raise an exception if the the string does not match. (This may be moot if we go to JAAS and GSS, as it probably has its own way of taking care of this, but at least it would be consistent for now). The javadocs comments for some of the public methods are not in the conventional javadoc style. > Provide a simple login implementation > - > > Key: HADOOP-2229 > URL: https://issues.apache.org/jira/browse/HADOOP-2229 > Project: Hadoop > Issue Type: New Feature >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: ugi.patch, ugi1.patch, ugi2.patch, ugi3.patch, ugi4.patch > > > Give a simple implementation of HADOOP-1701.Hadoop clients are assumed to > be started within a Unix-like network which provides user and group > management. This implementation read user information from the OS and send > them to the NameNode in plaintexts through RPC (see also HADOOP-2184). > NameNode trusts all information given and uses them for permission checking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2315) [hbase] REST servlet doesn't treat / characters in row key correctly
[ https://issues.apache.org/jira/browse/HADOOP-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2315: -- Attachment: fix-urlencode-keys.patch This patch resolves the problem. > [hbase] REST servlet doesn't treat / characters in row key correctly > > > Key: HADOOP-2315 > URL: https://issues.apache.org/jira/browse/HADOOP-2315 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Trivial > Attachments: fix-urlencode-keys.patch > > > Using row keys like "com.site.www/:http" currently doesn't work. We've > tracked it down to the use of request.getPathInfo() instead of > request.getRequestURI() in Dispatcher.getPathSegments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-496) Expose HDFS as a WebDAV store
[ https://issues.apache.org/jira/browse/HADOOP-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anurag Sharma updated HADOOP-496: - Attachment: fuse-j-patch.zip fuse-j-hadoopfs-0.zip hi, Attachments include the following: - fuse-j-hadoop package - fuse-j patch. -thanks > Expose HDFS as a WebDAV store > - > > Key: HADOOP-496 > URL: https://issues.apache.org/jira/browse/HADOOP-496 > Project: Hadoop > Issue Type: New Feature > Components: dfs >Reporter: Michel Tourn >Assignee: Enis Soztutar > Attachments: fuse-j-hadoopfs-0.zip, fuse-j-patch.zip, > hadoop-496-3.patch, hadoop-496-4.patch, hadoop-496-spool-cleanup.patch, > hadoop-webdav.zip, jetty-slide.xml, lib.webdav.tar.gz, screenshot-1.jpg, > slideusers.properties, webdav_wip1.patch, webdav_wip2.patch > > > WebDAV stands for Distributed Authoring and Versioning. It is a set of > extensions to the HTTP protocol that lets users collaboratively edit and > manage files on a remote web server. It is often considered as a replacement > for NFS or SAMBA > HDFS (Hadoop Distributed File System) needs a friendly file system interface. > DFSShell commands are unfamiliar. Instead it is more convenient for Hadoop > users to use a mountable network drive. A friendly interface to HDFS will be > used both for casual browsing of data and for bulk import/export. > The FUSE provider for HDFS is already available ( > http://issues.apache.org/jira/browse/HADOOP-17 ) but it had scalability > problems. WebDAV is a popular alternative. > The typical licensing terms for WebDAV tools are also attractive: > GPL for Linux client tools that Hadoop would not redistribute anyway. > More importantly, Apache Project/Apache license for Java tools and for server > components. > This allows for a tighter integration with the HDFS code base. > There are some interesting Apache projects that support WebDAV. > But these are probably too heavyweight for the needs of Hadoop: > Tomcat servlet: > http://tomcat.apache.org/tomcat-4.1-doc/catalina/docs/api/org/apache/catalina/servlets/WebdavServlet.html > Slide: http://jakarta.apache.org/slide/ > Being HTTP-based and "backwards-compatible" with Web Browser clients, the > WebDAV server protocol could even be piggy-backed on the existing Web UI > ports of the Hadoop name node / data nodes. WebDAV can be hosted as (Jetty) > servlets. This minimizes server code bloat and this avoids additional network > traffic between HDFS and the WebDAV server. > General Clients (read-only): > Any web browser > Linux Clients: > Mountable GPL davfs2 http://dav.sourceforge.net/ > FTP-like GPL Cadaver http://www.webdav.org/cadaver/ > Server Protocol compliance tests: > http://www.webdav.org/neon/litmus/ > A goal is for Hadoop HDFS to pass this test (minus support for Properties) > Pure Java clients: > DAV Explorer Apache lic. http://www.ics.uci.edu/~webdav/ > WebDAV also makes it convenient to add advanced features in an incremental > fashion: > file locking, access control lists, hard links, symbolic links. > New WebDAV standards get accepted and more or less featured WebDAV clients > exist. > core http://www.webdav.org/specs/rfc2518.html > ACLs http://www.webdav.org/specs/rfc3744.html > redirects "soft links" http://greenbytes.de/tech/webdav/rfc4437.html > BIND "hard links" http://www.webdav.org/bind/ > quota http://tools.ietf.org/html/rfc4331 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2229) Provide a simple login implementation
[ https://issues.apache.org/jira/browse/HADOOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547347 ] Doug Cutting commented on HADOOP-2229: -- +1 This looks good to me. > Provide a simple login implementation > - > > Key: HADOOP-2229 > URL: https://issues.apache.org/jira/browse/HADOOP-2229 > Project: Hadoop > Issue Type: New Feature >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: ugi.patch, ugi1.patch, ugi2.patch, ugi3.patch, ugi4.patch > > > Give a simple implementation of HADOOP-1701.Hadoop clients are assumed to > be started within a Unix-like network which provides user and group > management. This implementation read user information from the OS and send > them to the NameNode in plaintexts through RPC (see also HADOOP-2184). > NameNode trusts all information given and uses them for permission checking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2325) Require Java 6 for release 0.16.
Require Java 6 for release 0.16. Key: HADOOP-2325 URL: https://issues.apache.org/jira/browse/HADOOP-2325 Project: Hadoop Issue Type: Improvement Components: build Reporter: Doug Cutting Fix For: 0.16.0 We should require Java 6 for release 0.16. Java 6 is now available for OS/X. Hadoop performs much better on Java 6. And, finally, there are features of Java 6 (like 'df') that would be nice to use. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-496) Expose HDFS as a WebDAV store
[ https://issues.apache.org/jira/browse/HADOOP-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547345 ] Anurag Sharma commented on HADOOP-496: -- hi, We revived the old fuse-hadoop project (a FUSE-J based plugin that lets you mount Hadoop-FS). We have tried this on a small cluster (10 nodes) and basic functionality works (mount, ls, cat,cp, mkdir, rm, mv, ...). The main changes include some bug fixes to FUSE-J and changing the previous fuse-hadoop implementation to enforce write-once. We found the FUSE framework to be straightforward and simple. We have seen several mentions of using FUSE with Hadoop, so if there is a better place to post these files, please let me know. Attachments to follow... -thanks > Expose HDFS as a WebDAV store > - > > Key: HADOOP-496 > URL: https://issues.apache.org/jira/browse/HADOOP-496 > Project: Hadoop > Issue Type: New Feature > Components: dfs >Reporter: Michel Tourn >Assignee: Enis Soztutar > Attachments: hadoop-496-3.patch, hadoop-496-4.patch, > hadoop-496-spool-cleanup.patch, hadoop-webdav.zip, jetty-slide.xml, > lib.webdav.tar.gz, screenshot-1.jpg, slideusers.properties, > webdav_wip1.patch, webdav_wip2.patch > > > WebDAV stands for Distributed Authoring and Versioning. It is a set of > extensions to the HTTP protocol that lets users collaboratively edit and > manage files on a remote web server. It is often considered as a replacement > for NFS or SAMBA > HDFS (Hadoop Distributed File System) needs a friendly file system interface. > DFSShell commands are unfamiliar. Instead it is more convenient for Hadoop > users to use a mountable network drive. A friendly interface to HDFS will be > used both for casual browsing of data and for bulk import/export. > The FUSE provider for HDFS is already available ( > http://issues.apache.org/jira/browse/HADOOP-17 ) but it had scalability > problems. WebDAV is a popular alternative. > The typical licensing terms for WebDAV tools are also attractive: > GPL for Linux client tools that Hadoop would not redistribute anyway. > More importantly, Apache Project/Apache license for Java tools and for server > components. > This allows for a tighter integration with the HDFS code base. > There are some interesting Apache projects that support WebDAV. > But these are probably too heavyweight for the needs of Hadoop: > Tomcat servlet: > http://tomcat.apache.org/tomcat-4.1-doc/catalina/docs/api/org/apache/catalina/servlets/WebdavServlet.html > Slide: http://jakarta.apache.org/slide/ > Being HTTP-based and "backwards-compatible" with Web Browser clients, the > WebDAV server protocol could even be piggy-backed on the existing Web UI > ports of the Hadoop name node / data nodes. WebDAV can be hosted as (Jetty) > servlets. This minimizes server code bloat and this avoids additional network > traffic between HDFS and the WebDAV server. > General Clients (read-only): > Any web browser > Linux Clients: > Mountable GPL davfs2 http://dav.sourceforge.net/ > FTP-like GPL Cadaver http://www.webdav.org/cadaver/ > Server Protocol compliance tests: > http://www.webdav.org/neon/litmus/ > A goal is for Hadoop HDFS to pass this test (minus support for Properties) > Pure Java clients: > DAV Explorer Apache lic. http://www.ics.uci.edu/~webdav/ > WebDAV also makes it convenient to add advanced features in an incremental > fashion: > file locking, access control lists, hard links, symbolic links. > New WebDAV standards get accepted and more or less featured WebDAV clients > exist. > core http://www.webdav.org/specs/rfc2518.html > ACLs http://www.webdav.org/specs/rfc3744.html > redirects "soft links" http://greenbytes.de/tech/webdav/rfc4437.html > BIND "hard links" http://www.webdav.org/bind/ > quota http://tools.ietf.org/html/rfc4331 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[ https://issues.apache.org/jira/browse/HADOOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-2322: -- Fix Version/s: 0.16.0 > [hbase] getRow(row, TS) client interface not properly connected > --- > > Key: HADOOP-2322 > URL: https://issues.apache.org/jira/browse/HADOOP-2322 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Minor > Fix For: 0.16.0 > > Attachments: ts-regionserver.patch > > > There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) > calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[ https://issues.apache.org/jira/browse/HADOOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-2322: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed (The was passed by hudson when it was originally added mistakenly to hadoop-2224). Resolving. > [hbase] getRow(row, TS) client interface not properly connected > --- > > Key: HADOOP-2322 > URL: https://issues.apache.org/jira/browse/HADOOP-2322 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Minor > Attachments: ts-regionserver.patch > > > There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) > calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: hard link count for a file
I am back to writing this code as part of periodic block verification. Another approach I am thinking of is to check curFile.lastModified() and backupFile.lastModified(). As long as these two are different, we could assume they are different files. This is simpler than trying to lock the files. Raghu. Raghu Angadi wrote: Thanks Nigel. Another hack I can think of is, if DataNode is not finalized we can try to lock current/subdir.../blk_id and previous/subdir../blk_id. If second lock fails, we can assume they are the same. Raghu. Nigel Daley wrote: Raghu, LGPL not allowed in distro: http://people.apache.org/~cliffs/3party.html Nige On Nov 6, 2007, at 11:32 PM, Raghu Angadi wrote:
[jira] Commented: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547343 ] Doug Cutting commented on HADOOP-2288: -- +1 This looks good to me. > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130b.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[ https://issues.apache.org/jira/browse/HADOOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547342 ] Hadoop QA commented on HADOOP-2322: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370706/ts-regionserver.patch against trunk revision r599951. @author +1. The patch does not contain any @author tags. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs +1. The patch does not introduce any new Findbugs warnings. core tests -1. The patch failed core unit tests. contrib tests +1. The patch passed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1222/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1222/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1222/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1222/console This message is automatically generated. > [hbase] getRow(row, TS) client interface not properly connected > --- > > Key: HADOOP-2322 > URL: https://issues.apache.org/jira/browse/HADOOP-2322 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Minor > Attachments: ts-regionserver.patch > > > There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) > calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2297) [Hbase Shell] System.exit() Handling in Jar command
[ https://issues.apache.org/jira/browse/HADOOP-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Bieniosek updated HADOOP-2297: -- Attachment: Capture.java Hey Edward, I think I figured out how to suppress System.exit and capture stdout/stderr. Here, System.exit throws a SecurityException, which can be caught above. In this case, I catch in Thread.UncaughtExceptionHandler since I am running misbehaved threads. I also wrote a class that captures stdout/stderr. Since java only lets me set one printStream to capture stdout per jvm, I have to check Thread.currentThread, and then decide where to write the captured output. I am hoping to incorporate some of this code into my custom jetty server that submits hadoop jobs. > [Hbase Shell] System.exit() Handling in Jar command > --- > > Key: HADOOP-2297 > URL: https://issues.apache.org/jira/browse/HADOOP-2297 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: Edward Yoon >Assignee: Edward Yoon > Fix For: 0.16.0 > > Attachments: 2297_v02.patch, 2297_v03.patch, Capture.java > > > I'd like to block the exitVM by System.exit(). > Shell should terminate by "quit" command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2323) JobTracker.close() prints stack traces for exceptions that are not errors
[
https://issues.apache.org/jira/browse/HADOOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Kellerman updated HADOOP-2323:
--
Status: Patch Available (was: Open)
> JobTracker.close() prints stack traces for exceptions that are not errors
> -
>
> Key: HADOOP-2323
> URL: https://issues.apache.org/jira/browse/HADOOP-2323
> Project: Hadoop
> Issue Type: Bug
> Components: mapred
>Affects Versions: 0.16.0
>Reporter: Jim Kellerman
>Assignee: Jim Kellerman
> Fix For: 0.16.0
>
> Attachments: patch.txt
>
>
> JobTracker.close() prints a stack trace for an interrupted exception even
> though it was the method that interrupted the thread that threw the
> exception. For example:
> {code}
> this.expireTrackers.stopTracker();
> try {
> this.expireTrackersThread.interrupt();
> this.expireTrackersThread.join();
> } catch (InterruptedException ex) {
> ex.printStackTrace();
> }
> {code}
> Well of course it is going to catch an InterruptedException after it just
> interrupted the thread!
> This is *not* an error and should *not* be dumped to the logs!
> In other circumstances, catching InterruptedException is entirely
> appropriate. Just not in close where you've told the thread to shutdown and
> then interrupted it to ensure it does!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2323) JobTracker.close() prints stack traces for exceptions that are not errors
[
https://issues.apache.org/jira/browse/HADOOP-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Kellerman updated HADOOP-2323:
--
Attachment: patch.txt
> JobTracker.close() prints stack traces for exceptions that are not errors
> -
>
> Key: HADOOP-2323
> URL: https://issues.apache.org/jira/browse/HADOOP-2323
> Project: Hadoop
> Issue Type: Bug
> Components: mapred
>Affects Versions: 0.16.0
>Reporter: Jim Kellerman
>Assignee: Jim Kellerman
> Fix For: 0.16.0
>
> Attachments: patch.txt
>
>
> JobTracker.close() prints a stack trace for an interrupted exception even
> though it was the method that interrupted the thread that threw the
> exception. For example:
> {code}
> this.expireTrackers.stopTracker();
> try {
> this.expireTrackersThread.interrupt();
> this.expireTrackersThread.join();
> } catch (InterruptedException ex) {
> ex.printStackTrace();
> }
> {code}
> Well of course it is going to catch an InterruptedException after it just
> interrupted the thread!
> This is *not* an error and should *not* be dumped to the logs!
> In other circumstances, catching InterruptedException is entirely
> appropriate. Just not in close where you've told the thread to shutdown and
> then interrupted it to ensure it does!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-1841) IPC server should write repsonses asynchronously
[ https://issues.apache.org/jira/browse/HADOOP-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547337 ] Koji Noguchi commented on HADOOP-1841: -- Just wanted to note that we had couple of occasions when one user 1) Started many dfsclients on a single node 2) Load on that client node became too high that its rpc read speed slowed down significantly 3) Namenode became unresponsive Rebooting that client node brought back the namenode. I'm hoping this patch would solve such cases. > IPC server should write repsonses asynchronously > > > Key: HADOOP-1841 > URL: https://issues.apache.org/jira/browse/HADOOP-1841 > Project: Hadoop > Issue Type: Improvement > Components: ipc >Reporter: Doug Cutting >Assignee: dhruba borthakur > Attachments: asyncRPC-2.patch, asyncRPC.patch, asyncRPC.patch > > > Hadoop's IPC Server currently writes responses from request handler threads > using blocking writes. Performance and scalability might be improved if > responses were written asynchronously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2185) Server ports: to roll or not to roll.
[ https://issues.apache.org/jira/browse/HADOOP-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547336 ] dhruba borthakur commented on HADOOP-2185: -- +1 code looks good. > Server ports: to roll or not to roll. > - > > Key: HADOOP-2185 > URL: https://issues.apache.org/jira/browse/HADOOP-2185 > Project: Hadoop > Issue Type: Improvement > Components: conf, dfs, mapred >Affects Versions: 0.15.0 >Reporter: Konstantin Shvachko >Assignee: Konstantin Shvachko > Fix For: 0.16.0 > > Attachments: FixedPorts.patch, FixedPorts2.patch > > > Looked at the issues related to port rolling. My impression is that port > rolling is required only for the unit tests to run. > Even the name-node port should roll there, which we don't have now, in order > to be able to start 2 cluster for testing say dist cp. > For real clusters on the contrary port rolling is not desired and some times > even prohibited. > So we should have a way of to ban port rolling. My proposition is to > # use ephemeral port 0 if port rolling is desired > # if a specific port is specified then port rolling should not happen at all, > meaning that a > server is either able or not able to start on that particular port. > The desired port is specified via configuration parameters. > - Name-node: fs.default.name = host:port > - Data-node: dfs.datanode.port > - Job-tracker: mapred.job.tracker = host:port > - Task-tracker: mapred.task.tracker.report.bindAddress = host > Task-tracker currently does not have an option to specify port, it always > uses the ephemeral port 0, > and therefore I propose to add one. > - Secondary node does not need a port to listen on. > For info servers we have two sets of config variables *.info.bindAddress and > *.info.port > except for the task tracker, which calls them *.http.bindAddress and > *.http.port instead of "info". > With respect to the info servers I propose to completely eliminate the port > parameters, and form > *.info.bindAddress = host:port > Info servers should do the same thing, namely start or fail on the specified > port if it is not 0, > and start on any free port if it is ephemeral. > For the task-tracker I would rename tasktracker.http.bindAddress to > mapred.task.tracker.info.bindAddress > For the data-node the info dfs.datanode.info.bindAddress should be included > into the default config. > Is there a reason why it is not there? > This is the summary of proposed changes: > || Server || current name = value || proposed name = value || > | NameNode | fs.default.name = host:port | same | > | | dfs.info.bindAddress = host | dfs.http.bindAddress = host:port | > | DataNode | dfs.datanode.bindAddress = host | dfs.datanode.bindAddress = > host:port | > | | dfs.datanode.port = port | eliminate | > | | dfs.datanode.info.bindAddress = host | dfs.datanode.http.bindAddress = > host:port | > | | dfs.datanode.info.port = port | eliminate | > | JobTracker | mapred.job.tracker = host:port | same | > | | mapred.job.tracker.info.bindAddress = host | > mapred.job.tracker.http.bindAddress = host:port | > | | mapred.job.tracker.info.port = port | eliminate | > | TaskTracker | mapred.task.tracker.report.bindAddress = host | > mapred.task.tracker.report.bindAddress = host:port | > | | tasktracker.http.bindAddress = host | > mapred.task.tracker.http.bindAddress = host:port | > | | tasktracker.http.port = port | eliminate | > | SecondaryNameNode | dfs.secondary.info.bindAddress = host | > dfs.secondary.http.bindAddress = host:port | > | | dfs.secondary.info.port = port | eliminate | > Do we also want to set some uniform naming convention for the configuration > variables? > Like having hdfs instead of dfs, or info instead of http, or systematically > using either datanode > or data.node would make that look better in my opinion. > So these are all +*api*+ changes. I would +*really*+ like some feedback on > this, especially from > people who deal with configuration issues on practice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-1841) IPC server should write repsonses asynchronously
[ https://issues.apache.org/jira/browse/HADOOP-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547335 ] dhruba borthakur commented on HADOOP-1841: -- As expected, this patch does not decrease the performance of the namenode. But I agree with owen that we should determine that it does not affect sort performance too. > IPC server should write repsonses asynchronously > > > Key: HADOOP-1841 > URL: https://issues.apache.org/jira/browse/HADOOP-1841 > Project: Hadoop > Issue Type: Improvement > Components: ipc >Reporter: Doug Cutting >Assignee: dhruba borthakur > Attachments: asyncRPC-2.patch, asyncRPC.patch, asyncRPC.patch > > > Hadoop's IPC Server currently writes responses from request handler threads > using blocking writes. Performance and scalability might be improved if > responses were written asynchronously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Attachment: 2288_20071130b.patch 2288_20071130b.patch: In FileSystem, the original create(Path f, boolean overwrite, ...) is no longer abstract. It call the new create(Path f, FsPermission permission, boolean overwrite, ...) by default. Similar thing is done for mkdirs. > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130b.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Attachment: (was: 2288_20071130.patch) > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2229) Provide a simple login implementation
[ https://issues.apache.org/jira/browse/HADOOP-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-2229: -- Attachment: ugi4.patch Ok, now the proposal for umask to remove umask from both UGI and UnixUGI. Instead FSPermission (defined in HADOOP-2288) is going to provide get/set umask methods. The approach is that rather than getting a user's umask from UNIX, umask is going to be read from hadoop configuration. If it is not set in the configuration, it is set to a default value 0022. This new patch reflects the proposed change. > Provide a simple login implementation > - > > Key: HADOOP-2229 > URL: https://issues.apache.org/jira/browse/HADOOP-2229 > Project: Hadoop > Issue Type: New Feature >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: ugi.patch, ugi1.patch, ugi2.patch, ugi3.patch, ugi4.patch > > > Give a simple implementation of HADOOP-1701.Hadoop clients are assumed to > be started within a Unix-like network which provides user and group > management. This implementation read user information from the OS and send > them to the NameNode in plaintexts through RPC (see also HADOOP-2184). > NameNode trusts all information given and uses them for permission checking. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HADOOP-2303) [hbase] patch-build test failures (#1194, #1193, #1192)
[
https://issues.apache.org/jira/browse/HADOOP-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Kellerman resolved HADOOP-2303.
---
Resolution: Duplicate
This issue will be addressed by HADOOP-2324
> [hbase] patch-build test failures (#1194, #1193, #1192)
> ---
>
> Key: HADOOP-2303
> URL: https://issues.apache.org/jira/browse/HADOOP-2303
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
>Reporter: stack
>Priority: Minor
>
> TestRegionServerExit failes in #1194 like this:
> {code}
> ...
> [junit] 2007-11-29 00:20:53,775 INFO [RegionServer:0]
> org.apache.hadoop.hbase.HRegionServer.run(HRegionServer.java:816): aborting
> server at: 140.211.11.75:61555
> [junit] 2007-11-29 00:20:53,791 INFO [RegionServer:2]
> org.apache.hadoop.hbase.HRegionServer.run(HRegionServer.java:809): On abort,
> closed hlog
> [junit] 2007-11-29 00:20:53,791 INFO [RegionServer:2]
> org.apache.hadoop.hbase.HRegionServer.run(HRegionServer.java:816): aborting
> server at: 140.211.11.75:61754
> [junit] 2007-11-29 00:20:53,801 INFO [HMaster]
> org.apache.hadoop.hbase.HLog.splitLog(HLog.java:205): log file splitting
> completed for /hbase/log_140.211.11.75_1196295616136_61556
> [junit] 2007-11-29 00:20:53,801 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,801 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,802 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,802 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,802 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,802 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,802 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,803 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,803 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,803 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,803 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,803 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,804 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,804 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,804 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 14
[jira] Created: (HADOOP-2324) [hbase] Fix assertion failures in TestTableMapReduce
[hbase] Fix assertion failures in TestTableMapReduce Key: HADOOP-2324 URL: https://issues.apache.org/jira/browse/HADOOP-2324 Project: Hadoop Issue Type: Bug Components: contrib/hbase Affects Versions: 0.16.0 Reporter: Jim Kellerman Assignee: Jim Kellerman Fix For: 0.16.0 TestTableMapReduce consists of two tests: a very simple one that verifies that it is working, and a larger test that verifies that it works when the table consists of multiple regions. There are two failure modes: 1) an assertion failure in the verify method 2) the test times out because something does not shut down cleanly. to figure out what is causing these failures, the first step will be to do copious logging in the test. Once the root cause is determined, we can address it. Unfortunately, some of the testing will have to be done via Hudson, because that is the only environment in which it fails. We routinely test under Windows, Fedora Core 6, MacOsX, and Ubuntu. Windows and Ubuntu have both single and dual processor configurations. FC6 and MacOS run on dual core machines. Only Hudson seems crippled enough to demonstrate these problems. (A good thing since they are real problems) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-2314: -- Status: Patch Available (was: Open) Raghu, yes, this is the real fix for HADOOP-2256. Dhruba, thanks a million for you help with the testing. :-) > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug > Components: dfs >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dhruba borthakur updated HADOOP-2314: - Component/s: dfs > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug > Components: dfs >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547322 ] dhruba borthakur commented on HADOOP-2314: -- This fix works great. +1 > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug > Components: dfs >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2303) [hbase] patch-build test failures (#1194, #1193, #1192)
[
https://issues.apache.org/jira/browse/HADOOP-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547318
]
Jim Kellerman commented on HADOOP-2303:
---
TestRegionServerExit fails in #1194 should now be fixed.
#1193 fails in TestTableMapReduce because following assertion fails:
{code}
junit.framework.AssertionFailedError
at
org.apache.hadoop.hbase.mapred.TestTableMapReduce.verify(TestTableMapReduce.java:389)
at
org.apache.hadoop.hbase.mapred.TestTableMapReduce.localTestSingleRegionTable(TestTableMapReduce.java:270)
{code}
in build #1217 it failed from another assertion error:
{code}
junit.framework.AssertionFailedError
at
org.apache.hadoop.hbase.mapred.TestTableMapReduce.verify(TestTableMapReduce.java:389)
at
org.apache.hadoop.hbase.mapred.TestTableMapReduce.localTestMultiRegionTable(TestTableMapReduce.java:322)
{code}
The exceptions:
{code}
[junit] 2007-11-30 04:23:11,357 ERROR [expireTrackers]
org.apache.hadoop.mapred.JobTracker$ExpireTrackers.run(JobTracker.java:308):
Tracker Expiry Thread got exception: java.lang.InterruptedException: sleep
interrupted
[junit] at java.lang.Thread.sleep(Native Method)
[junit] at
org.apache.hadoop.mapred.JobTracker$ExpireTrackers.run(JobTracker.java:263)
[junit] at java.lang.Thread.run(Thread.java:595)
[junit] 2007-11-30 04:23:11,358 WARN [Task Commit Thread]
org.apache.hadoop.mapred.JobTracker$TaskCommitQueue.run(JobTracker.java:2017):
Task Commit Thread exiting, got interrupted: java.lang.InterruptedException
[junit] at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1815)
[junit] at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1850)
[junit] at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:359)
[junit] at
org.apache.hadoop.mapred.JobTracker$TaskCommitQueue.run(JobTracker.java:1919)
{code}
are red herrings because of the the way JobTracker shuts down. (See HADOOP-2323)
> [hbase] patch-build test failures (#1194, #1193, #1192)
> ---
>
> Key: HADOOP-2303
> URL: https://issues.apache.org/jira/browse/HADOOP-2303
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
>Reporter: stack
>Priority: Minor
>
> TestRegionServerExit failes in #1194 like this:
> {code}
> ...
> [junit] 2007-11-29 00:20:53,775 INFO [RegionServer:0]
> org.apache.hadoop.hbase.HRegionServer.run(HRegionServer.java:816): aborting
> server at: 140.211.11.75:61555
> [junit] 2007-11-29 00:20:53,791 INFO [RegionServer:2]
> org.apache.hadoop.hbase.HRegionServer.run(HRegionServer.java:809): On abort,
> closed hlog
> [junit] 2007-11-29 00:20:53,791 INFO [RegionServer:2]
> org.apache.hadoop.hbase.HRegionServer.run(HRegionServer.java:816): aborting
> server at: 140.211.11.75:61754
> [junit] 2007-11-29 00:20:53,801 INFO [HMaster]
> org.apache.hadoop.hbase.HLog.splitLog(HLog.java:205): log file splitting
> completed for /hbase/log_140.211.11.75_1196295616136_61556
> [junit] 2007-11-29 00:20:53,801 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,801 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,802 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,802 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,802 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29 00:20:53,802 INFO [HMaster]
> org.apache.hadoop.hbase.HMaster$ProcessServerShutdown.process(HMaster.java:1999):
> process shutdown of server 140.211.11.75:61556: logSplit: true, rootChecked:
> false, rootRescanned: false, numberOfMetaRegions: 1,
> onlineMetaRegions.size(): 1
> [junit] 2007-11-29 00:20:53,802 DEBUG [HMaster]
> org.apache.hadoop.hbase.HMaster.run(HMaster.java:1068): Main processing loop:
> ProcessServerShutdown of 140.211.11.75:61556
> [junit] 2007-11-29
[jira] Created: (HADOOP-2323) JobTracker.close() prints stack traces for exceptions that are not errors
JobTracker.close() prints stack traces for exceptions that are not errors
-
Key: HADOOP-2323
URL: https://issues.apache.org/jira/browse/HADOOP-2323
Project: Hadoop
Issue Type: Bug
Components: mapred
Affects Versions: 0.16.0
Reporter: Jim Kellerman
Assignee: Jim Kellerman
Fix For: 0.16.0
JobTracker.close() prints a stack trace for an interrupted exception even
though it was the method that interrupted the thread that threw the exception.
For example:
{code}
this.expireTrackers.stopTracker();
try {
this.expireTrackersThread.interrupt();
this.expireTrackersThread.join();
} catch (InterruptedException ex) {
ex.printStackTrace();
}
{code}
Well of course it is going to catch an InterruptedException after it just
interrupted the thread!
This is *not* an error and should *not* be dumped to the logs!
In other circumstances, catching InterruptedException is entirely appropriate.
Just not in close where you've told the thread to shutdown and then interrupted
it to ensure it does!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547313 ] Hadoop QA commented on HADOOP-2224: --- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370699/ts-regionserver.patch against trunk revision r599951. @author +1. The patch does not contain any @author tags. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs +1. The patch does not introduce any new Findbugs warnings. core tests +1. The patch passed core unit tests. contrib tests +1. The patch passed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1221/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1221/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1221/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1221/console This message is automatically generated. > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2278) Streaming: better conrol over input splits
[ https://issues.apache.org/jira/browse/HADOOP-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547312 ] arkady borkovsky commented on HADOOP-2278: -- Some split conditions are hard to catch by a fixed patter. A very important split condition is "key switch" -- (need to be fiels as a separate issue?) Quite often, the mapper input is grouped by key and the mapper is actually a reducer. Therefore, it expects that all the values for given key go to the same task. Currently, the split happens between any two records, so "key runs" are usually broken at split boundaries. The work around is to have infinite split size -- which creates bad granularity. > Streaming: better conrol over input splits > -- > > Key: HADOOP-2278 > URL: https://issues.apache.org/jira/browse/HADOOP-2278 > Project: Hadoop > Issue Type: Improvement > Components: contrib/streaming >Reporter: arkady borkovsky > > In steaming, the map command usually expect to receive it's input > uninterpreted -- just as it is stored in DFS. > However, the split (the beginning and the end of the portion of data that > goes to a single map task) is often important and is not "any line break". > Often the input consists of multi-line docments -- e.g. in XML. > There should be a way to specify a pattern that separates logical records. > Existing "Streaming XML record reader" kind of provides this functionality. > However, it is accepted that "Streaming XML" is a hack and needs to be > replaced -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[ https://issues.apache.org/jira/browse/HADOOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2322: -- Status: Patch Available (was: Open) > [hbase] getRow(row, TS) client interface not properly connected > --- > > Key: HADOOP-2322 > URL: https://issues.apache.org/jira/browse/HADOOP-2322 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Minor > Attachments: ts-regionserver.patch > > > There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) > calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2224: -- Attachment: (was: ts-regionserver.patch) > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury resolved HADOOP-2224. --- Resolution: Fixed > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2224: -- Status: Open (was: Patch Available) Decided to open a new issue for the fix instead of reopening the existing one. See HADOOP-2322 > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[ https://issues.apache.org/jira/browse/HADOOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury reassigned HADOOP-2322: - Assignee: Bryan Duxbury > [hbase] getRow(row, TS) client interface not properly connected > --- > > Key: HADOOP-2322 > URL: https://issues.apache.org/jira/browse/HADOOP-2322 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Minor > Attachments: ts-regionserver.patch > > > There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) > calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[hbase] getRow(row, TS) client interface not properly connected --- Key: HADOOP-2322 URL: https://issues.apache.org/jira/browse/HADOOP-2322 Project: Hadoop Issue Type: Bug Components: contrib/hbase Reporter: Bryan Duxbury Priority: Minor Attachments: ts-regionserver.patch There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2321) Streaming: better support for command lines or streaming command
Streaming: better support for command lines or streaming command Key: HADOOP-2321 URL: https://issues.apache.org/jira/browse/HADOOP-2321 Project: Hadoop Issue Type: Improvement Components: contrib/streaming Reporter: arkady borkovsky Quite often, the command line for streaming mapper or reducer needs to use one or two levels of quotes. This make it inconvenient or impossible to pass the commands in the streaming command line. It would be good to have streaming take its specification from a file -- especially as longer streaming commands are not typed in, but are either run from files (shell scripts) or generated by other processors. The current work around is to separate files for the mapper command, for the reducer command, and for the streaming command itself. This works, but is inconvenient and quite error-prone. Having just one file with all three would be good. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2322) [hbase] getRow(row, TS) client interface not properly connected
[ https://issues.apache.org/jira/browse/HADOOP-2322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2322: -- Attachment: ts-regionserver.patch This patch resolves the problem. > [hbase] getRow(row, TS) client interface not properly connected > --- > > Key: HADOOP-2322 > URL: https://issues.apache.org/jira/browse/HADOOP-2322 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Minor > Attachments: ts-regionserver.patch > > > There was a bug in the patch for HADOOP-2224 that was causing getRow(row, ts) > calls to always return the most recent cells. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2224: -- Status: Patch Available (was: Reopened) > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch, > ts-regionserver.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2224: -- Attachment: ts-regionserver.patch This patch adds the correct overloaded getRow call to HRegionServer.java. > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch, > ts-regionserver.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547292 ] bryanduxbury edited comment on HADOOP-2224 at 11/30/07 1:17 PM: - The HRegionServer class had a broken implementation of the new method. was (Author: bryanduxbury): The HRegionServer class had a broken implementation of the new class. > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury reopened HADOOP-2224: --- The HRegionServer class had a broken implementation of the new class. > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547287 ] dhruba borthakur commented on HADOOP-2314: -- I am testing this right now. > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-1792) df command doesn't exist under windows
[ https://issues.apache.org/jira/browse/HADOOP-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547282 ] Olivier Dagenais commented on HADOOP-1792: -- I got this problem too: It appears DF is being used to compute available disk space before creating files. While Java does not appears to have support for this (see [bug 4057701|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4057701]), it does appear that another Apache project (sort of) does: [org.apache.commons.FileSystemUtils.freeSpaceKb|http://commons.apache.org/io/api-release/org/apache/commons/io/FileSystemUtils.html#freeSpaceKb(java.lang.String)] ...at least it wouldn't require that Hadoop users on Windows install Cygwin. > df command doesn't exist under windows > -- > > Key: HADOOP-1792 > URL: https://issues.apache.org/jira/browse/HADOOP-1792 > Project: Hadoop > Issue Type: Bug > Components: fs >Affects Versions: 0.14.0 >Reporter: Benjamin Francisoud > > My code use to work with previous version of hadoop, I upgraded to 0.14 and > now: > java.io.IOException: CreateProcess: df -k "C:\Documents and > Settings\Benjamin\Local Settings\Temp\test14906test\mapredLocal" error=2 > at java.lang.ProcessImpl.create(Native Method) > at java.lang.ProcessImpl.(Unknown Source) > at java.lang.ProcessImpl.start(Unknown Source) > at java.lang.ProcessBuilder.start(Unknown Source) > at java.lang.Runtime.exec(Unknown Source) > at java.lang.Runtime.exec(Unknown Source) > at org.apache.hadoop.fs.DF.doDF(DF.java:60) > at org.apache.hadoop.fs.DF.(DF.java:53) > at > org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.confChanged(LocalDirAllocator.java:198) > at > org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathForWrite(LocalDirAllocator.java:235) > at > org.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:124) > at > org.apache.hadoop.mapred.MapOutputFile.getSpillFileForWrite(MapOutputFile.java:88) > at > org.apache.hadoop.mapred.MapTask$MapOutputBuffer.sortAndSpillToDisk(MapTask.java:373) > at > org.apache.hadoop.mapred.MapTask$MapOutputBuffer.flush(MapTask.java:593) > at org.apache.hadoop.mapred.MapTask.run(MapTask.java:190) > at > org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:137) > at > org.apache.hadoop.mapred.LocalJobRunner.submitJob(LocalJobRunner.java:283) > at org.apache.hadoop.mapred.JobClient.submitJob(JobClient.java:397) > ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HADOOP-2320) [hbase] Committed TestGet2 is managled (breaks build).
[ https://issues.apache.org/jira/browse/HADOOP-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HADOOP-2320. --- Resolution: Fixed Fix Version/s: 0.16.0 Committed. > [hbase] Committed TestGet2 is managled (breaks build). > -- > > Key: HADOOP-2320 > URL: https://issues.apache.org/jira/browse/HADOOP-2320 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: stack > Fix For: 0.16.0 > > Attachments: tg2.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2320) [hbase] Committed TestGet2 is managled (breaks build).
[hbase] Committed TestGet2 is managled (breaks build). -- Key: HADOOP-2320 URL: https://issues.apache.org/jira/browse/HADOOP-2320 Project: Hadoop Issue Type: Bug Components: contrib/hbase Reporter: stack Attachments: tg2.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2320) [hbase] Committed TestGet2 is managled (breaks build).
[ https://issues.apache.org/jira/browse/HADOOP-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-2320: -- Attachment: tg2.patch Add license. Removed doubled instance of class. > [hbase] Committed TestGet2 is managled (breaks build). > -- > > Key: HADOOP-2320 > URL: https://issues.apache.org/jira/browse/HADOOP-2320 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: stack > Attachments: tg2.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2311) [hbase] Could not complete hdfs write out to flush file forcing regionserver restart
[
https://issues.apache.org/jira/browse/HADOOP-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HADOOP-2311:
--
Attachment: delete-logging.patch
Log all deletes.
> [hbase] Could not complete hdfs write out to flush file forcing regionserver
> restart
>
>
> Key: HADOOP-2311
> URL: https://issues.apache.org/jira/browse/HADOOP-2311
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
>Reporter: stack
>Priority: Minor
> Attachments: delete-logging.patch
>
>
> I've spent some time looking into this issue but there are not enough clues
> in the logs to tell where the problem is. Here's what I know.
> Two region servers went down last night, a minute apart, during Paul Saab's
> 6hr run inserting 300million rows into hbase. The regionservers went down to
> force rerun of hlog and avoid possible data loss after a failure writing
> memory flushes to hdfs.
> Here is the lead up to the failed flush:
> ...
> 2007-11-28 22:40:02,231 INFO hbase.HRegionServer - MSG_REGION_OPEN :
> regionname: postlog,img149/4699/133lm0.jpg,1196318393738, startKey:
> , tableDesc: {name: postlog, families:
> {cookie:={name: cookie, max versions: 1, compression: NONE, in memory: false,
> max length: 2147483647, bloom filter: none}, ip:={name: ip, max versions: 1,
> compression: NONE, in memory: false, max length: 2147483647, bloom filter:
> none}}}
> 2007-11-28 22:40:02,242 DEBUG hbase.HStore - starting 1703405830/cookie (no
> reconstruction log)
> 2007-11-28 22:40:02,741 DEBUG hbase.HStore - maximum sequence id for hstore
> 1703405830/cookie is 29077708
> 2007-11-28 22:40:03,094 DEBUG hbase.HStore - starting 1703405830/ip (no
> reconstruction log)
> 2007-11-28 22:40:03,852 DEBUG hbase.HStore - maximum sequence id for hstore
> 1703405830/ip is 29077708
> 2007-11-28 22:40:04,138 DEBUG hbase.HRegion - Next sequence id for region
> postlog,img149/4699/133lm0.jpg,1196318393738 is 29077709
> 2007-11-28 22:40:04,141 INFO hbase.HRegion - region
> postlog,img149/4699/133lm0.jpg,1196318393738 available
> 2007-11-28 22:40:04,141 DEBUG hbase.HLog - changing sequence number from
> 21357623 to 29077709
> 2007-11-28 22:40:04,141 INFO hbase.HRegionServer - MSG_REGION_OPEN :
> regionname: postlog,img149/7512/dscnlightenedfi3.jpg,1196318393739,
> startKey: , tableDesc: {name: postlog,
> families: {cookie:={name: cookie, max versions: 1, compression: NONE, in
> memory: false, max length: 2147483647, bloom filter: none}, ip:={name: ip,
> max versions: 1, compression: NONE, in memory: false, max length: 2147483647,
> bloom filter: none}}}
> 2007-11-28 22:40:04,145 DEBUG hbase.HStore - starting 376748222/cookie (no
> reconstruction log)
> 2007-11-28 22:40:04,223 DEBUG hbase.HStore - maximum sequence id for hstore
> 376748222/cookie is 29077708
> 2007-11-28 22:40:04,277 DEBUG hbase.HStore - starting 376748222/ip (no
> reconstruction log)
> 2007-11-28 22:40:04,353 DEBUG hbase.HStore - maximum sequence id for hstore
> 376748222/ip is 29077708
> 2007-11-28 22:40:04,699 DEBUG hbase.HRegion - Next sequence id for region
> postlog,img149/7512/dscnlightenedfi3.jpg,1196318393739 is 29077709
> 2007-11-28 22:40:04,701 INFO hbase.HRegion - region
> postlog,img149/7512/dscnlightenedfi3.jpg,1196318393739 available
> 2007-11-28 22:40:34,427 DEBUG hbase.HRegionServer - flushing region
> postlog,img143/1310/yashrk3.jpg,1196317258704
> 2007-11-28 22:40:34,428 DEBUG hbase.HRegion - Not flushing cache for region
> postlog,img143/1310/yashrk3.jpg,1196317258704: snapshotMemcaches() determined
> that there was nothing to do
> 2007-11-28 22:40:55,745 DEBUG hbase.HRegionServer - flushing region
> postlog,img142/8773/1001417zc4.jpg,1196317258703
> 2007-11-28 22:40:55,745 DEBUG hbase.HRegion - Not flushing cache for region
> postlog,img142/8773/1001417zc4.jpg,1196317258703: snapshotMemcaches()
> determined that there was nothing to do
> 2007-11-28 22:41:04,144 DEBUG hbase.HRegionServer - flushing region
> postlog,img149/4699/133lm0.jpg,1196318393738
> 2007-11-28 22:41:04,144 DEBUG hbase.HRegion - Started memcache flush for
> region postlog,img149/4699/133lm0.jpg,1196318393738. Size 74.7k
> 2007-11-28 22:41:04,764 DEBUG hbase.HStore - Added
> 1703405830/ip/610047924323344967 with sequence id 29081563 and size 53.8k
> 2007-11-28 22:41:04,902 DEBUG hbase.HStore - Added
> 1703405830/cookie/3147798053949544972 with sequence id 29081563 and size 41.3k
> 2007-11-28 22:41:04,902 DEBUG hbase.HRegion - Finished memcache flush for
> region postlog,img149/4699/133lm0.jpg,1196318393738 in 758ms,
> sequenceid=29081563
> 2007-11-28 22:41:04,902 DEBUG hbase.HStore - compaction for HStore
> postlog,img149/4699/133lm0.jpg,1196318393738/ip needed.
> 2007-11-28 22:41:04,903 DEBUG hbase.H
[jira] Commented: (HADOOP-2068) [hbase] RESTful interface
[ https://issues.apache.org/jira/browse/HADOOP-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547268 ] stack commented on HADOOP-2068: --- Thanks for the patch Bryan. > [hbase] RESTful interface > - > > Key: HADOOP-2068 > URL: https://issues.apache.org/jira/browse/HADOOP-2068 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: stack >Assignee: Bryan Duxbury >Priority: Minor > Fix For: 0.16.0 > > Attachments: rest-11-27-07-v2.patch, rest-11-27-07.3.patc, > rest-11-27-07.patch, rest-11-28-07.2.patch, rest-11-28-07.3.patch, > rest-11-28-07.patch, rest.patch > > > A RESTful interface would be one means of making hbase accessible to clients > that are not java. It might look something like the below: > + An HTTP GET of http://MASTER:PORT/ outputs the master's attributes: online > meta regions, list of tables, etc.: i.e. what you see now when you go to > http://MASTER:PORT/master.jsp. > + An HTTP GET of http://MASTER:PORT/TABLENAME: 200 if tables exists and > HTableDescription (mimetype: text/plain or text/xml) or 401 if no such table. > HTTP DELETE would drop the table. HTTP PUT would add one. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW: 200 if row exists and 401 > if not. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNFAMILY: > HColumnDescriptor (mimetype: text/plain or text/xml) or 401 if no such table. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/: 200 and latest > version (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE > would delete the cell. HTTP PUT would add a new version. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/TIMESTAMP: 200 > (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE would > remove. HTTP PUT would put this record. > + Browser originally goes against master but master then redirects to the > hosting region server to serve, update, delete, etc. the addressed cell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2068) [hbase] RESTful interface
[ https://issues.apache.org/jira/browse/HADOOP-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-2068: -- Resolution: Fixed Fix Version/s: 0.16.0 Status: Resolved (was: Patch Available) Committed (Failed tests were unrelated to this patch which doesn't add any new tests and is code that doesn't run at unit test time). Resolving. > [hbase] RESTful interface > - > > Key: HADOOP-2068 > URL: https://issues.apache.org/jira/browse/HADOOP-2068 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: stack >Assignee: Bryan Duxbury >Priority: Minor > Fix For: 0.16.0 > > Attachments: rest-11-27-07-v2.patch, rest-11-27-07.3.patc, > rest-11-27-07.patch, rest-11-28-07.2.patch, rest-11-28-07.3.patch, > rest-11-28-07.patch, rest.patch > > > A RESTful interface would be one means of making hbase accessible to clients > that are not java. It might look something like the below: > + An HTTP GET of http://MASTER:PORT/ outputs the master's attributes: online > meta regions, list of tables, etc.: i.e. what you see now when you go to > http://MASTER:PORT/master.jsp. > + An HTTP GET of http://MASTER:PORT/TABLENAME: 200 if tables exists and > HTableDescription (mimetype: text/plain or text/xml) or 401 if no such table. > HTTP DELETE would drop the table. HTTP PUT would add one. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW: 200 if row exists and 401 > if not. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNFAMILY: > HColumnDescriptor (mimetype: text/plain or text/xml) or 401 if no such table. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/: 200 and latest > version (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE > would delete the cell. HTTP PUT would add a new version. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/TIMESTAMP: 200 > (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE would > remove. HTTP PUT would put this record. > + Browser originally goes against master but master then redirects to the > hosting region server to serve, update, delete, etc. the addressed cell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2068) [hbase] RESTful interface
[ https://issues.apache.org/jira/browse/HADOOP-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547263 ] Hadoop QA commented on HADOOP-2068: --- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370483/rest-11-28-07.3.patch against trunk revision r599879. @author +1. The patch does not contain any @author tags. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs +1. The patch does not introduce any new Findbugs warnings. core tests +1. The patch passed core unit tests. contrib tests -1. The patch failed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1220/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1220/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1220/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1220/console This message is automatically generated. > [hbase] RESTful interface > - > > Key: HADOOP-2068 > URL: https://issues.apache.org/jira/browse/HADOOP-2068 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: stack >Assignee: Bryan Duxbury >Priority: Minor > Attachments: rest-11-27-07-v2.patch, rest-11-27-07.3.patc, > rest-11-27-07.patch, rest-11-28-07.2.patch, rest-11-28-07.3.patch, > rest-11-28-07.patch, rest.patch > > > A RESTful interface would be one means of making hbase accessible to clients > that are not java. It might look something like the below: > + An HTTP GET of http://MASTER:PORT/ outputs the master's attributes: online > meta regions, list of tables, etc.: i.e. what you see now when you go to > http://MASTER:PORT/master.jsp. > + An HTTP GET of http://MASTER:PORT/TABLENAME: 200 if tables exists and > HTableDescription (mimetype: text/plain or text/xml) or 401 if no such table. > HTTP DELETE would drop the table. HTTP PUT would add one. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW: 200 if row exists and 401 > if not. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNFAMILY: > HColumnDescriptor (mimetype: text/plain or text/xml) or 401 if no such table. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/: 200 and latest > version (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE > would delete the cell. HTTP PUT would add a new version. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/TIMESTAMP: 200 > (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE would > remove. HTTP PUT would put this record. > + Browser originally goes against master but master then redirects to the > hosting region server to serve, update, delete, etc. the addressed cell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2298) ant target without source and docs
[ https://issues.apache.org/jira/browse/HADOOP-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547258 ] Doug Cutting commented on HADOOP-2298: -- We could provide an ant target that builds a binary tarball, but still release the compound tarball. Folks could then run the binary-only target from within a release if they want to build a binary-only tarball. Might that suffice? Producing only a single file per release simplifies things. But we don't want users to have to recompile releases, and writing a binary-only tarball target that doesn't recompile might be tricky. I don't yet have a strong sense about the best way to proceed... > ant target without source and docs > --- > > Key: HADOOP-2298 > URL: https://issues.apache.org/jira/browse/HADOOP-2298 > Project: Hadoop > Issue Type: Improvement > Components: build >Reporter: Gautam Kowshik > > Can we have an ant target or a -D option to build the hadoop tar without the > source and documentation? This brings down the tar size from 11.5 MB to 5.6 > MB. This would speed up distribution. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2319) Build both 32 and 64 bit native libraries when compiling with a 64 bit JVM
Build both 32 and 64 bit native libraries when compiling with a 64 bit JVM -- Key: HADOOP-2319 URL: https://issues.apache.org/jira/browse/HADOOP-2319 Project: Hadoop Issue Type: Improvement Components: build Reporter: Nigel Daley Priority: Minor When a 32 bit JVM is used to build Hadoop, the 32 bit native libraries are build (providing -Dcompile.native=true is present). Likewise, a 64 bit JVM automatically builds a 64 bit native library. It would be helpful if a 64 bit JVM built both 32 and 64 bit native libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547255 ] Raghu Angadi commented on HADOOP-2314: -- Does this fix the problem seen in HADOOP-2256? > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2318) All C++ builds should use the autoconf tools
All C++ builds should use the autoconf tools Key: HADOOP-2318 URL: https://issues.apache.org/jira/browse/HADOOP-2318 Project: Hadoop Issue Type: Improvement Components: build Reporter: Nigel Daley Priority: Minor Currently we have -Dcompile.native and -Dcompile.c++ build flags. In addition, builds for pipes and libhadoop use autoconf tools, but libhdfs does not, nor does 64bit libhdfs compile work. All these builds should use autoconf tools, support 64bit compilation, and should occur when a single flag is present (-Dcompile.c++ seems like the better choice). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HADOOP-2068) [hbase] RESTful interface
[ https://issues.apache.org/jira/browse/HADOOP-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury reassigned HADOOP-2068: - Assignee: Bryan Duxbury > [hbase] RESTful interface > - > > Key: HADOOP-2068 > URL: https://issues.apache.org/jira/browse/HADOOP-2068 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: stack >Assignee: Bryan Duxbury >Priority: Minor > Attachments: rest-11-27-07-v2.patch, rest-11-27-07.3.patc, > rest-11-27-07.patch, rest-11-28-07.2.patch, rest-11-28-07.3.patch, > rest-11-28-07.patch, rest.patch > > > A RESTful interface would be one means of making hbase accessible to clients > that are not java. It might look something like the below: > + An HTTP GET of http://MASTER:PORT/ outputs the master's attributes: online > meta regions, list of tables, etc.: i.e. what you see now when you go to > http://MASTER:PORT/master.jsp. > + An HTTP GET of http://MASTER:PORT/TABLENAME: 200 if tables exists and > HTableDescription (mimetype: text/plain or text/xml) or 401 if no such table. > HTTP DELETE would drop the table. HTTP PUT would add one. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW: 200 if row exists and 401 > if not. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNFAMILY: > HColumnDescriptor (mimetype: text/plain or text/xml) or 401 if no such table. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/: 200 and latest > version (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE > would delete the cell. HTTP PUT would add a new version. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/TIMESTAMP: 200 > (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE would > remove. HTTP PUT would put this record. > + Browser originally goes against master but master then redirects to the > hosting region server to serve, update, delete, etc. the addressed cell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2315) [hbase] REST servlet doesn't treat / characters in row key correctly
[ https://issues.apache.org/jira/browse/HADOOP-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2315: -- Priority: Trivial (was: Major) > [hbase] REST servlet doesn't treat / characters in row key correctly > > > Key: HADOOP-2315 > URL: https://issues.apache.org/jira/browse/HADOOP-2315 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury >Priority: Trivial > > Using row keys like "com.site.www/:http" currently doesn't work. We've > tracked it down to the use of request.getPathInfo() instead of > request.getRequestURI() in Dispatcher.getPathSegments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HADOOP-2109) [hbase] TestRegionServerExit failures in patch build #1004, #1003, #991, and #971
[ https://issues.apache.org/jira/browse/HADOOP-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Kellerman resolved HADOOP-2109. --- Resolution: Fixed This test hasn't failed in a while. Resolving issue. Should it start failing again, we'll open a new issue. > [hbase] TestRegionServerExit failures in patch build #1004, #1003, #991, and > #971 > - > > Key: HADOOP-2109 > URL: https://issues.apache.org/jira/browse/HADOOP-2109 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Affects Versions: 0.16.0 >Reporter: stack > Fix For: 0.16.0 > > Attachments: patch.txt, patch.txt, patch.txt, patch.txt, patch.txt > > > Figure why the failures. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2316) [hbase] Run REST servlet outside of master
[
https://issues.apache.org/jira/browse/HADOOP-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury updated HADOOP-2316:
--
Priority: Minor (was: Major)
> [hbase] Run REST servlet outside of master
> --
>
> Key: HADOOP-2316
> URL: https://issues.apache.org/jira/browse/HADOOP-2316
> Project: Hadoop
> Issue Type: New Feature
> Components: contrib/hbase
>Reporter: Bryan Duxbury
>Assignee: Bryan Duxbury
>Priority: Minor
>
> In order to support desired deployment strategy, we need to be able to run
> the REST servlet independently of the master info server. We should add an
> new option to the bin/hbase command ("rest"?) that optionally takes a port
> and bind address and starts the servlet outside of any other project.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2317) [hbase] Support multipart/related instead of xml input/output
[hbase] Support multipart/related instead of xml input/output - Key: HADOOP-2317 URL: https://issues.apache.org/jira/browse/HADOOP-2317 Project: Hadoop Issue Type: New Feature Components: contrib/hbase Reporter: Bryan Duxbury Assignee: Bryan Duxbury Priority: Trivial XML is bulky and slow, but the only way currently supported for multi-column gets/puts/etc. We should add support for multipart/related encoded entity bodies since that will be all binary and presumably faster and more compact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HADOOP-2316) [hbase] Run REST servlet outside of master
[
https://issues.apache.org/jira/browse/HADOOP-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Duxbury reassigned HADOOP-2316:
-
Assignee: Bryan Duxbury
> [hbase] Run REST servlet outside of master
> --
>
> Key: HADOOP-2316
> URL: https://issues.apache.org/jira/browse/HADOOP-2316
> Project: Hadoop
> Issue Type: New Feature
> Components: contrib/hbase
>Reporter: Bryan Duxbury
>Assignee: Bryan Duxbury
>
> In order to support desired deployment strategy, we need to be able to run
> the REST servlet independently of the master info server. We should add an
> new option to the bin/hbase command ("rest"?) that optionally takes a port
> and bind address and starts the servlet outside of any other project.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2316) [hbase] Run REST servlet outside of master
[hbase] Run REST servlet outside of master
--
Key: HADOOP-2316
URL: https://issues.apache.org/jira/browse/HADOOP-2316
Project: Hadoop
Issue Type: New Feature
Components: contrib/hbase
Reporter: Bryan Duxbury
In order to support desired deployment strategy, we need to be able to run the
REST servlet independently of the master info server. We should add an new
option to the bin/hbase command ("rest"?) that optionally takes a port and bind
address and starts the servlet outside of any other project.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-2314: -- Attachment: block.patch Here is a patch for fixing the problem. I've run this for 50 times in a row and havenot see any timeout. > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2315) [hbase] REST servlet doesn't treat / characters in row key correctly
[hbase] REST servlet doesn't treat / characters in row key correctly Key: HADOOP-2315 URL: https://issues.apache.org/jira/browse/HADOOP-2315 Project: Hadoop Issue Type: Bug Components: contrib/hbase Reporter: Bryan Duxbury Using row keys like "com.site.www/:http" currently doesn't work. We've tracked it down to the use of request.getPathInfo() instead of request.getRequestURI() in Dispatcher.getPathSegments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Attachment: 2288_20071130.patch 2288_20071130.patch: Change applyMask(...) to applyUMask(...) since it is useful to HADOOP-2229. > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > Attachments: 2288_20071130.patch > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HADOOP-2315) [hbase] REST servlet doesn't treat / characters in row key correctly
[ https://issues.apache.org/jira/browse/HADOOP-2315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury reassigned HADOOP-2315: - Assignee: Bryan Duxbury > [hbase] REST servlet doesn't treat / characters in row key correctly > > > Key: HADOOP-2315 > URL: https://issues.apache.org/jira/browse/HADOOP-2315 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Reporter: Bryan Duxbury >Assignee: Bryan Duxbury > > Using row keys like "com.site.www/:http" currently doesn't work. We've > tracked it down to the use of request.getPathInfo() instead of > request.getRequestURI() in Dispatcher.getPathSegments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
[ https://issues.apache.org/jira/browse/HADOOP-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hairong Kuang updated HADOOP-2314: -- Fix Version/s: (was: 0.15.2) 0.16.0 > TestBlockReplacement occasionally get into an infinite loop > --- > > Key: HADOOP-2314 > URL: https://issues.apache.org/jira/browse/HADOOP-2314 > Project: Hadoop > Issue Type: Bug >Affects Versions: 0.15.1 >Reporter: Hairong Kuang >Assignee: Hairong Kuang > Fix For: 0.16.0 > > Attachments: block.patch > > > It turns out that in the case that tests an invalid deletion hint, either the > newNode or source may be choosen to be deleted as an exessive replica since > both of the nodes are on the same rack. The test assumes that only newNode > will be deleted and wait for its deletion. This causes an infinite loop when > source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (HADOOP-2314) TestBlockReplacement occasionally get into an infinite loop
TestBlockReplacement occasionally get into an infinite loop --- Key: HADOOP-2314 URL: https://issues.apache.org/jira/browse/HADOOP-2314 Project: Hadoop Issue Type: Bug Affects Versions: 0.15.1 Reporter: Hairong Kuang Assignee: Hairong Kuang Fix For: 0.15.2 It turns out that in the case that tests an invalid deletion hint, either the newNode or source may be choosen to be deleted as an exessive replica since both of the nodes are on the same rack. The test assumes that only newNode will be deleted and wait for its deletion. This causes an infinite loop when source is chosen to be deleted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2288) Change FileSystem API to support access control.
[ https://issues.apache.org/jira/browse/HADOOP-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsz Wo (Nicholas), SZE updated HADOOP-2288: --- Attachment: (was: 2288_20071129b.patch) > Change FileSystem API to support access control. > > > Key: HADOOP-2288 > URL: https://issues.apache.org/jira/browse/HADOOP-2288 > Project: Hadoop > Issue Type: New Feature > Components: fs >Affects Versions: 0.15.0 >Reporter: Tsz Wo (Nicholas), SZE >Assignee: Tsz Wo (Nicholas), SZE > Fix For: 0.16.0 > > > - Some FileSystem methods like create and mkdir need an additional parameter > for permission. > - FileSystem has to provide methods for setting permission, changing > ownership, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2068) [hbase] RESTful interface
[ https://issues.apache.org/jira/browse/HADOOP-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Duxbury updated HADOOP-2068: -- Status: Patch Available (was: Open) Submitting preliminary REST implementation. > [hbase] RESTful interface > - > > Key: HADOOP-2068 > URL: https://issues.apache.org/jira/browse/HADOOP-2068 > Project: Hadoop > Issue Type: New Feature > Components: contrib/hbase >Reporter: stack >Priority: Minor > Attachments: rest-11-27-07-v2.patch, rest-11-27-07.3.patc, > rest-11-27-07.patch, rest-11-28-07.2.patch, rest-11-28-07.3.patch, > rest-11-28-07.patch, rest.patch > > > A RESTful interface would be one means of making hbase accessible to clients > that are not java. It might look something like the below: > + An HTTP GET of http://MASTER:PORT/ outputs the master's attributes: online > meta regions, list of tables, etc.: i.e. what you see now when you go to > http://MASTER:PORT/master.jsp. > + An HTTP GET of http://MASTER:PORT/TABLENAME: 200 if tables exists and > HTableDescription (mimetype: text/plain or text/xml) or 401 if no such table. > HTTP DELETE would drop the table. HTTP PUT would add one. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW: 200 if row exists and 401 > if not. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNFAMILY: > HColumnDescriptor (mimetype: text/plain or text/xml) or 401 if no such table. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/: 200 and latest > version (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE > would delete the cell. HTTP PUT would add a new version. > + An HTTP GET of http://MASTER:PORT/TABLENAME/ROW/COLUMNNAME/TIMESTAMP: 200 > (mimetype: binary/octet-stream) or 401 if no such cell. HTTP DELETE would > remove. HTTP PUT would put this record. > + Browser originally goes against master but master then redirects to the > hosting region server to serve, update, delete, etc. the addressed cell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2313) build does not fail when libhdfs build fails
[ https://issues.apache.org/jira/browse/HADOOP-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547239 ] Hadoop QA commented on HADOOP-2313: --- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12370680/HADOOP-2313.patch against trunk revision r599879. @author +1. The patch does not contain any @author tags. javadoc +1. The javadoc tool did not generate any warning messages. javac +1. The applied patch does not generate any new compiler warnings. findbugs +1. The patch does not introduce any new Findbugs warnings. core tests +1. The patch passed core unit tests. contrib tests +1. The patch passed contrib unit tests. Test results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1219/testReport/ Findbugs warnings: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1219/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Checkstyle results: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1219/artifact/trunk/build/test/checkstyle-errors.html Console output: http://lucene.zones.apache.org:8080/hudson/job/Hadoop-Patch/1219/console This message is automatically generated. > build does not fail when libhdfs build fails > > > Key: HADOOP-2313 > URL: https://issues.apache.org/jira/browse/HADOOP-2313 > Project: Hadoop > Issue Type: Bug > Components: libhdfs >Affects Versions: 0.15.1 >Reporter: Nigel Daley >Assignee: Nigel Daley >Priority: Minor > Fix For: 0.16.0 > > Attachments: HADOOP-2313.patch > > > compile-libhdfs: > [mkdir] Created dir: > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs > [exec] gcc -g -Wall -O2 -fPIC -m32 > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include/linux -c hdfs.c -o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfs.o > [exec] gcc -g -Wall -O2 -fPIC -m32 > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include/linux -c > hdfsJniHelper.c -o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfsJniHelper.o > [exec] gcc > -L/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/jre/lib/amd64/server -ljvm > -shared -m32 -Wl,-x -o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so.1 > -Wl,-soname,libhdfs.so > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfs.o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfsJniHelper.o > \ > [exec] && ln -sf > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so.1 > > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so > [exec] /usr/bin/ld: skipping incompatible > /home/hadoopqa/tools/java/jdk1.5.0_11-64bit/jre/lib/amd64/server/libjvm.so > when searching for -ljvm > [exec] /usr/bin/ld: cannot find -ljvm > [exec] collect2: ld returned 1 exit status > [exec] make: *** > [/home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so.1] > Error 1 > [exec] Result: 2 > ... > BUILD SUCCESSFUL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-2158) hdfsListDirectory in libhdfs does not scale
[ https://issues.apache.org/jira/browse/HADOOP-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547224 ] dhruba borthakur commented on HADOOP-2158: -- Good patch. Code looks good. + 1. II think the listPaths API on a directory used to return the size of the entire directory subtree. However, the listStatus API on a directory does not do so. If your application is not replying the original behaviour of listPaths then this change makes sense. > hdfsListDirectory in libhdfs does not scale > --- > > Key: HADOOP-2158 > URL: https://issues.apache.org/jira/browse/HADOOP-2158 > Project: Hadoop > Issue Type: Bug > Components: libhdfs >Affects Versions: 0.15.0 >Reporter: Christian Kunz >Assignee: Christian Kunz >Priority: Blocker > Fix For: 0.15.2 > > Attachments: 2158.patch > > > hdfsListDirectory makes one rpc call using deprecated > fs.FileSystem.listPaths, and then two rpc calls for every entry in the > returned array. When running a job with more than 3000 mappers each running a > pipes application using libhdfs to scan a dfs directory with about 100-200 > entries, this results in about 1M rpc calls to the namenode server > overwhelming it. > hdfsListDirectory should call fs.FileSystem.listStatus instead. > I will submit a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HADOOP-1841) IPC server should write repsonses asynchronously
[ https://issues.apache.org/jira/browse/HADOOP-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547222 ] Owen O'Malley commented on HADOOP-1841: --- I think on RPC patches, it is a very good idea to run a sort on 500 nodes to make sure that the system remains stable. > IPC server should write repsonses asynchronously > > > Key: HADOOP-1841 > URL: https://issues.apache.org/jira/browse/HADOOP-1841 > Project: Hadoop > Issue Type: Improvement > Components: ipc >Reporter: Doug Cutting >Assignee: dhruba borthakur > Attachments: asyncRPC-2.patch, asyncRPC.patch, asyncRPC.patch > > > Hadoop's IPC Server currently writes responses from request handler threads > using blocking writes. Performance and scalability might be improved if > responses were written asynchronously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2313) build does not fail when libhdfs build fails
[ https://issues.apache.org/jira/browse/HADOOP-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun C Murthy updated HADOOP-2313: -- Affects Version/s: 0.15.1 +1 > build does not fail when libhdfs build fails > > > Key: HADOOP-2313 > URL: https://issues.apache.org/jira/browse/HADOOP-2313 > Project: Hadoop > Issue Type: Bug > Components: libhdfs >Affects Versions: 0.15.1 >Reporter: Nigel Daley >Assignee: Nigel Daley >Priority: Minor > Fix For: 0.16.0 > > Attachments: HADOOP-2313.patch > > > compile-libhdfs: > [mkdir] Created dir: > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs > [exec] gcc -g -Wall -O2 -fPIC -m32 > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include/linux -c hdfs.c -o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfs.o > [exec] gcc -g -Wall -O2 -fPIC -m32 > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include > -I/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/include/linux -c > hdfsJniHelper.c -o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfsJniHelper.o > [exec] gcc > -L/home/hadoopqa/tools/java/jdk1.5.0_11-64bit/jre/lib/amd64/server -ljvm > -shared -m32 -Wl,-x -o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so.1 > -Wl,-soname,libhdfs.so > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfs.o > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/hdfsJniHelper.o > \ > [exec] && ln -sf > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so.1 > > /home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so > [exec] /usr/bin/ld: skipping incompatible > /home/hadoopqa/tools/java/jdk1.5.0_11-64bit/jre/lib/amd64/server/libjvm.so > when searching for -ljvm > [exec] /usr/bin/ld: cannot find -ljvm > [exec] collect2: ld returned 1 exit status > [exec] make: *** > [/home/hadoopqa/workspace/Hadoop-LinuxTest-0.15/branch/build/libhdfs/libhdfs.so.1] > Error 1 > [exec] Result: 2 > ... > BUILD SUCCESSFUL -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2224) [hbase] Add HTable.getRow(ROW, ts)
[ https://issues.apache.org/jira/browse/HADOOP-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-2224: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed (Failure was in the unrelated, currently-erratic TestTableMapReduce). Resolving. Thanks for the patch Bryan. > [hbase] Add HTable.getRow(ROW, ts) > -- > > Key: HADOOP-2224 > URL: https://issues.apache.org/jira/browse/HADOOP-2224 > Project: Hadoop > Issue Type: Improvement > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: stack >Assignee: stack >Priority: Minor > Fix For: 0.16.0 > > Attachments: get-full-timestamp.patch, get-full-ts-11-26-07.patch, > get-full-ts-11-29-07.patch, getfullts-v3.patch, testget2.patch > > > There is HTable.getRow(ROW). Need to add HTable.getRow(ROW, ts) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2304) [Hbase shell] Abbreviated symbol parsing error of dir path in jar command
[ https://issues.apache.org/jira/browse/HADOOP-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-2304: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed. Closing. Thanks for the patch Edward. > [Hbase shell] Abbreviated symbol parsing error of dir path in jar command > - > > Key: HADOOP-2304 > URL: https://issues.apache.org/jira/browse/HADOOP-2304 > Project: Hadoop > Issue Type: Bug > Components: contrib/hbase >Affects Versions: 0.15.0 >Reporter: Edward Yoon >Assignee: Edward Yoon > Fix For: 0.16.0 > > Attachments: 2304.patch > > > I found a abbreviated symbol parsing error of dir path. > Of course, arguments will have same error. > ./build/hadoop-*0.16.0*-examples.jar pi 10 10 (FLOATING_POINT_LITERAL, > DOT...) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HADOOP-2309) [hbase] ConcurrentModificationException doing get of all region start keys
[
https://issues.apache.org/jira/browse/HADOOP-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Kellerman updated HADOOP-2309:
--
Status: Open (was: Patch Available)
TestTableMapReduce failed in build 1217 - investigating
> [hbase] ConcurrentModificationException doing get of all region start keys
> --
>
> Key: HADOOP-2309
> URL: https://issues.apache.org/jira/browse/HADOOP-2309
> Project: Hadoop
> Issue Type: Bug
> Components: contrib/hbase
>Affects Versions: 0.16.0
>Reporter: stack
>Assignee: Jim Kellerman
>Priority: Minor
> Fix For: 0.16.0
>
> Attachments: patch.txt, patch.txt
>
>
> Reported by Paul Saab:
> {code}
> I'm getting the following exception when getting the start key from every
> table. If I try to grab it again, it will succeed. Is this a bug or do you
> need to catch these sort of exceptions in my code?...
> Looking for key: img529/6013/46da7e3f111daje2.jpg
> Exception in thread "main" java.io.IOException: java.io.IOException:
> java.util.ConcurrentModificationException
> at java.util.TreeMap$NavigableSubMap$SubMapIterator.nextEntry
> (TreeMap.java:1572)
> at
> java.util.TreeMap$NavigableSubMap$SubMapEntryIterator.next(TreeMap.java:1620)
> at
> java.util.TreeMap$NavigableSubMap$SubMapEntryIterator.next(TreeMap.java:1614)
> at org.apache.hadoop.hbase.HStore$Memcache.internalGet (HStore.java:223)
> at org.apache.hadoop.hbase.HStore$Memcache.get(HStore.java:152)
> at org.apache.hadoop.hbase.HStore.get(HStore.java:1490)
> at org.apache.hadoop.hbase.HRegion.get(HRegion.java:1002)
> at org.apache.hadoop.hbase.HRegion.get(HRegion.java:959)
> at org.apache.hadoop.hbase.HRegionServer.get(HRegionServer.java:1233)
> at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:379)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java :596)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> (DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.hadoop.hbase.RemoteExceptionHandler.decodeRemoteException(RemoteExceptionHandler.java
> :82)
> at org.apache.hadoop.hbase.HTable.get(HTable.java:202)
> at us.imageshack.hbase.ListRegions.run(ListRegions.java:25)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
> at us.imageshack.hbase.ListRegions.main (ListRegions.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.hadoop.util.RunJar.main(RunJar.java:155)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
