[jira] Updated: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-06-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4379: -- Attachment: hadoop-stack-namenode-aa0-000-12.u.powerset.com.log.gz Namenode log that covers the forever cycle

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-06-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721409#action_12721409 ] stack commented on HADOOP-4379: --- I can manufacture a situation where we're stuck

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-28 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714168#action_12714168 ] stack commented on HADOOP-4379: --- In this test run, the append never succeeds o

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-27 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713779#action_12713779 ] stack commented on HADOOP-4379: --- I tested some more and new reader sees 0 data and get

[jira] Commented: (HADOOP-4681) DFSClient block read failures cause open DFSInputStream to become unusable

2009-05-27 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713704#action_12713704 ] stack commented on HADOOP-4681: --- .bq For e.g. it looks like 'a failure' is

[jira] Commented: (HADOOP-4681) DFSClient block read failures cause open DFSInputStream to become unusable

2009-05-27 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713656#action_12713656 ] stack commented on HADOOP-4681: --- .bq We could define successful datanode conenctio

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-26 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713329#action_12713329 ] stack commented on HADOOP-4379: --- ... and the read finds a zero-length file (nothing

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-26 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713316#action_12713316 ] stack commented on HADOOP-4379: --- After a chat with Hairong and Dhruba, it was thought

[jira] Commented: (HADOOP-4681) DFSClient block read failures cause open DFSInputStream to become unusable

2009-05-23 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712493#action_12712493 ] stack commented on HADOOP-4681: --- +1 on patch being applied to TRUNK as well as to 0.20,

[jira] Created: (HADOOP-5904) Hung on hdfs: writeChunk, DFSClient.java:2126, DataStreamer socketWrite

2009-05-23 Thread stack (JIRA)
Issue Type: Bug Components: dfs Affects Versions: 0.19.1, 0.19.0, 0.18.3 Reporter: stack We've seen this hang rare enough but when it happens it locks up the application. We've seen it at least in 0.18.x and 0.19.x (we don't have much experience with

[jira] Created: (HADOOP-5903) DFSClient "Could not obtain block:..."

2009-05-23 Thread stack (JIRA)
s Versions: 0.20.0, 0.19.1, 0.19.0, 0.18.3 Reporter: stack We see this frequently in our application, hbase, where dfsclients are held open across long periods of time. It would seem that any hiccup fetching a block becomes a permanent black mark and though the serving datanode pas

[jira] Commented: (HADOOP-5744) Revisit append

2009-05-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710608#action_12710608 ] stack commented on HADOOP-5744: --- @ Hairong .bq ..do you still need to recover the l

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710549#action_12710549 ] stack commented on HADOOP-4379: --- My testing was done with hadoop 0.20.0 (I amended patc

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710546#action_12710546 ] stack commented on HADOOP-4379: --- v9 works well in basic testing. If I crash the wr

[jira] Commented: (HADOOP-5744) Revisit append

2009-05-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710541#action_12710541 ] stack commented on HADOOP-5744: --- @ Hairong .bq My question is that why the file need

[jira] Commented: (HADOOP-5744) Revisit append

2009-05-15 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709961#action_12709961 ] stack commented on HADOOP-5744: --- Thanks Hairong. Any comment on the unqualified &#

[jira] Commented: (HADOOP-5744) Revisit append

2009-05-14 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709612#action_12709612 ] stack commented on HADOOP-5744: --- A few comments and questions: Document is without con

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-05-11 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708275#action_12708275 ] stack commented on HADOOP-4379: --- Tried the patch on loaded cluster. First attempt got

[jira] Updated: (HADOOP-5797) Better distribution in the PerformanceEvaluation MapReduce when rows run to the Billions

2009-05-08 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5797: -- Attachment: pe.java Randomize the way we write the splits. > Better distribution in

[jira] Created: (HADOOP-5797) Better distribution in the PerformanceEvaluation MapReduce when rows run to the Billions

2009-05-08 Thread stack (JIRA)
Project: Hadoop Core Issue Type: Bug Reporter: stack Assignee: stack Fix For: 0.20.0 Performance Evaluation when the number of clients was large (and thus number of rows to input) was clumping so we'd beat up on one box then the next. --

[jira] Commented: (HADOOP-4379) In HDFS, sync() not yet guarantees data available to the new readers

2009-04-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701392#action_12701392 ] stack commented on HADOOP-4379: --- @Dhruba Any luck testing at scale? (Looks like HADOOP-

[jira] Commented: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-02-16 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674006#action_12674006 ] stack commented on HADOOP-5079: --- I moved the patch that was added to the reopened issu

[jira] Updated: (HADOOP-5255) Fix for HADOOP-5079 HashFunction inadvertently destroys some randomness

2009-02-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5255: -- Status: Patch Available (was: Open) Attached patch works for TRUNK also. Passing to hudson. > Fix

[jira] Updated: (HADOOP-5255) Fix for HADOOP-5079 HashFunction inadvertently destroys some randomness

2009-02-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5255: -- Attachment: hadoop-core-hash-2-branch-0.20.patch Jonathan Ellis patch moved over from HADOOP-5079. Fixes

[jira] Created: (HADOOP-5255) Fix for HADOOP-5079 HashFunction inadvertently destroys some randomness

2009-02-13 Thread stack (JIRA)
Issue Type: Bug Components: io Affects Versions: 0.20.0, 0.21.0 Reporter: stack Priority: Minor Fix For: 0.20.0, 0.21.0 HADOOP-5079 did this "HashFunction.hash restricts initval for the next hash to the [0, maxValue) range of the hash in

[jira] Commented: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-02-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672157#action_12672157 ] stack commented on HADOOP-5079: --- I took a look at the patch and confirmed Math

Re: Hadoop 0.19.1

2009-02-04 Thread stack
On Thu, Jan 29, 2009 at 4:16 PM, Nigel Daley wrote: > > I would like to propose that we apply this same "fix" to sync in 0.19.1 and > 0.20.0. Since append requires the full semantics of sync, I propose we also > disable append (perhaps throw UnsupportedOperationException from API?). > Yes, this

Re: Hadoop 0.19.1

2009-02-04 Thread stack
On Tue, Feb 3, 2009 at 7:02 PM, Sanjay Radia wrote: > > Many in the team have come to the conclusion that complex projects like > append should be done on a separate branch in the first place and integrated > with trunk when the project is stable. > How do we determine when a feature on the bra

[jira] Updated: (HADOOP-3315) New binary file format

2009-02-03 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3315: -- Comment: was deleted > New binary file format > -- > > Key:

[jira] Updated: (HADOOP-3315) New binary file format

2009-02-03 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3315: -- Attachment: (was: hfile2.patch) > New binary file format > -- > >

[jira] Updated: (HADOOP-3315) New binary file format

2009-02-02 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3315: -- Attachment: hfile2.patch More stripping. This patch has HFile sort of working again (Its a hackup with ugly

[jira] Commented: (HADOOP-3315) New binary file format

2009-02-02 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669778#action_12669778 ] stack commented on HADOOP-3315: --- Thanks Hong. I was talking about fact that '2

[jira] Issue Comment Edited: (HADOOP-3315) New binary file format

2009-02-01 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669359#action_12669359 ] stack edited comment on HADOOP-3315 at 2/1/09 1:07 AM: --- Movin

[jira] Updated: (HADOOP-3315) New binary file format

2009-02-01 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3315: -- Status: In Progress (was: Patch Available) Moving it to 'resume progress' because of Hong'

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-31 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669312#action_12669312 ] stack commented on HADOOP-3315: --- Digging, looks like ChunkDecoder.close is actually c

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-30 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669146#action_12669146 ] stack commented on HADOOP-3315: --- Here's one issue in TFile that was causing gri

Re: Hadoop 0.19.1

2009-01-30 Thread stack
The below proposes pushing a working append out 6 months or so. Can we have pointers as to what is meant by 'quality issues' in the below so we can make a more informed vote or is it just the hdfs issue posted against 0.19.1? Is it there also that we would find what is involved making append work

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-29 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668761#action_12668761 ] stack commented on HADOOP-3315: --- I should add I tested using local filesystem and

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-29 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668759#action_12668759 ] stack commented on HADOOP-3315: --- Thanks for the above especially the bit on concur

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-29 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668588#action_12668588 ] stack commented on HADOOP-3315: --- Hmm. Looking at doing random accesses and it seems li

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-29 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668538#action_12668538 ] stack commented on HADOOP-3315: --- On an alternate BCFile implementation, we're thin

[jira] Commented: (HADOOP-3315) New binary file format

2009-01-28 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668271#action_12668271 ] stack commented on HADOOP-3315: --- I've been playing around w/ the last patch

[jira] Commented: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-28 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668095#action_12668095 ] stack commented on HADOOP-5079: --- Thanks Raghu. I moved the CHANGES.txt e

[jira] Commented: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-23 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666850#action_12666850 ] stack commented on HADOOP-5079: --- Committed to 0.20 branch too. > HashF

[jira] Assigned: (HADOOP-5121) Fix shell usage for format.width

2009-01-23 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HADOOP-5121: - Assignee: stack > Fix shell usage for format.wi

[jira] Resolved: (HADOOP-5121) Fix shell usage for format.width

2009-01-23 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HADOOP-5121. --- Resolution: Fixed Fix Version/s: 0.20.0 > Fix shell usage for format.wi

[jira] Created: (HADOOP-5121) Fix shell usage for format.width

2009-01-23 Thread stack (JIRA)
Fix shell usage for format.width Key: HADOOP-5121 URL: https://issues.apache.org/jira/browse/HADOOP-5121 Project: Hadoop Core Issue Type: Bug Reporter: stack -- This message is automatically

[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-23 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5079: -- Resolution: Fixed Status: Resolved (was: Patch Available) Committed (One line change that improves a

hudson and patch submissions

2009-01-23 Thread stack
HADOOP-5079 has been in patch-submitted state with a few days now and the few times I've looked, hudson patch queue is empty. Maybe I missed a flag on the JIRA? Could a kind soul tell me where I went awry? Thanks, St.Ack

[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5079: -- Status: In Progress (was: Patch Available) > HashFunction inadvertently destroys some randomn

[jira] Assigned: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HADOOP-5079: - Assignee: stack > HashFunction inadvertently destroys some randomn

[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5079: -- Status: Patch Available (was: In Progress) > HashFunction inadvertently destroys some randomn

[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-5079: -- Fix Version/s: 0.20.0 Hadoop Flags: [Reviewed] > HashFunction inadvertently destroys some randomn

[jira] Commented: (HADOOP-5079) HashFunction inadvertently destroys some randomness

2009-01-19 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665247#action_12665247 ] stack commented on HADOOP-5079: --- Patch looks good to me. Will commit in a day or so un

[jira] Commented: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2009-01-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663442#action_12663442 ] stack commented on HADOOP-4802: --- Removed my patches. Write me offline if want to know

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2009-01-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: (was: 4802-v2.patch) > RPC Server send buffer retains size of largest response ever s

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2009-01-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: (was: 4802-v4-TRUNK.patch) > RPC Server send buffer retains size of largest response e

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2009-01-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: (was: 4802.patch) > RPC Server send buffer retains size of largest response ever s

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2009-01-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: (was: 4802-v3.patch) > RPC Server send buffer retains size of largest response ever s

[jira] Resolved: (HADOOP-5011) Scanner setup takes too long...

2009-01-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HADOOP-5011. --- Resolution: Invalid Pardon... wrong component > Scanner setup takes too l

[jira] Created: (HADOOP-5011) Scanner setup takes too long...

2009-01-09 Thread stack (JIRA)
Scanner setup takes too long... --- Key: HADOOP-5011 URL: https://issues.apache.org/jira/browse/HADOOP-5011 Project: Hadoop Core Issue Type: Bug Reporter: stack posix4? and dr_ryan are trying to

Re: short-circuiting HDFS reads

2009-01-08 Thread stack
On Thu, Jan 8, 2009 at 10:39 AM, Doug Cutting wrote: > So this sort of optimization may only have a significant impact for jobs > whose maps do not produce much output. Don't forget the lowly non-MR users of HDFS. The short-circuit looks promising improving HDFS random access times. St.Ack

[jira] Commented: (HADOOP-4801) DFS read performance suboptimal when client co-located on nodes with data

2008-12-15 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656875#action_12656875 ] stack commented on HADOOP-4801: --- Tried installing patch to see what for an improvement

[jira] Assigned: (HADOOP-3063) BloomMapFile - fail-fast version of MapFile for sparsely populated key space

2008-12-15 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HADOOP-3063: - Assignee: Andrzej Bialecki > BloomMapFile - fail-fast version of MapFile for sparsely populated

[jira] Updated: (HADOOP-3063) BloomMapFile - fail-fast version of MapFile for sparsely populated key space

2008-12-15 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3063: -- Resolution: Fixed Fix Version/s: 0.20.0 Release Note: Implements a subclass of MapFile that

[jira] Commented: (HADOOP-3063) BloomMapFile - fail-fast version of MapFile for sparsely populated key space

2008-12-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656360#action_12656360 ] stack commented on HADOOP-3063: --- The failing tests seem unrelated to this patch: {

[jira] Commented: (HADOOP-3063) BloomMapFile - fail-fast version of MapFile for sparsely populated key space

2008-12-13 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656329#action_12656329 ] stack commented on HADOOP-3063: --- +1 Test now passes locally with v4. Took quick loo

[jira] Commented: (HADOOP-3063) BloomMapFile - fail-fast version of MapFile for sparsely populated key space

2008-12-11 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655793#action_12655793 ] stack commented on HADOOP-3063: --- Reviewing the patch, it looks great. The above fai

[jira] Commented: (HADOOP-3063) BloomMapFile - fail-fast version of MapFile for sparsely populated key space

2008-12-11 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655778#action_12655778 ] stack commented on HADOOP-3063: --- Andrzej: It failed its own unit test up on hu

[jira] Commented: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655095#action_12655095 ] stack commented on HADOOP-4802: --- > It's probably a premature optimization.

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: 4802-v4-TRUNK.patch Made HBAOS static (Had to move it out of Server#Handler to do so). Removed

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: 4802-v3.patch v3 removes the unnecessary equality test (Thanks Raghu) > RPC Server send buf

[jira] Commented: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654990#action_12654990 ] stack commented on HADOOP-4802: --- > I'm still not convinced we should do more

[jira] Commented: (HADOOP-4797) RPC Server can leave a lot of direct buffers

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654956#action_12654956 ] stack commented on HADOOP-4797: --- Raghu: There is one on line #60 ('lager') b

[jira] Commented: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654951#action_12654951 ] stack commented on HADOOP-4802: --- Patch applies to 0.19 and to TRUNK. > RPC Serv

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: 4802-v2.patch Thanks for the feedback lads. I like your suggestions Raghu. This patch removes

[jira] Commented: (HADOOP-4797) RPC Server can leave a lot of direct buffers

2008-12-07 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654242#action_12654242 ] stack commented on HADOOP-4797: --- Suggested fix sounds good to me. +1 on patch. W

[jira] Updated: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-07 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-4802: -- Attachment: 4802.patch Suggested fix: reset BAOS if larger than N * initial buffer size. > RPC Server s

[jira] Created: (HADOOP-4802) RPC Server send buffer retains size of largest response ever sent

2008-12-07 Thread stack (JIRA)
: Bug Components: ipc Affects Versions: 0.19.0, 0.18.2 Reporter: stack The stack-based ByteArrayOutputStream in Server.Hander is reset each time through the run loop. This will set the BAOS 'size' back to zero but the allocated backing buffer is unaltered. If

[jira] Updated: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-25 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3422: -- Resolution: Fixed Fix Version/s: (was: 0.19.1) (was: hudson) Hadoop

[jira] Commented: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-24 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650279#action_12650279 ] stack commented on HADOOP-3422: --- Thanks for the review Brian. Unless objection,

[jira] Updated: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3422: -- Status: Patch Available (was: In Progress) Try hudson w/ new version of patch. > Ganglia counter metr

[jira] Updated: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3422: -- Status: In Progress (was: Patch Available) > Ganglia counter metrics are all reported with the metric n

[jira] Assigned: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HADOOP-3422: - Assignee: stack > Ganglia counter metrics are all reported with the metric name "value&

[jira] Updated: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-21 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HADOOP-3422: -- Attachment: ganglia-patch-3422-updated-v2.patch Version of patch that addresses the above comments (Uses

[jira] Commented: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-20 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649534#action_12649534 ] stack commented on HADOOP-3422: --- I agree the test failure is unrelated but would lik

[jira] Commented: (HADOOP-3315) New binary file format

2008-11-20 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649458#action_12649458 ] stack commented on HADOOP-3315: --- Thanks for update Hong. If you get a minute, yeah,

[jira] Commented: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-11-18 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648700#action_12648700 ] stack commented on HADOOP-3422: --- Couple of nitpicks: Use StringBuilder instea

[jira] Commented: (HADOOP-3315) New binary file format

2008-11-14 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647714#action_12647714 ] stack commented on HADOOP-3315: --- Hows it going lads? Any update? Do you think TFile

[jira] Resolved: (HADOOP-4562) Logs filled with "IOException: Checksum ok was sent and should not be sent again"

2008-10-31 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HADOOP-4562. --- Resolution: Duplicate Thanks. I confirmed that the debug message no longer shows (My bad, HBase was using

[jira] Commented: (HADOOP-4499) DFSClient should invoke checksumOk only once.

2008-10-31 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644405#action_12644405 ] stack commented on HADOOP-4499: --- Is this supposed to have fixed HADOOP-4562? > DF

[jira] Commented: (HADOOP-4562) Logs filled with "IOException: Checksum ok was sent and should not be sent again"

2008-10-31 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-4562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644404#action_12644404 ] stack commented on HADOOP-4562: --- I'm running with r709534 so HADOOP-4499 is in pl

[jira] Created: (HADOOP-4562) Logs filled with "IOException: Checksum ok was sent and should not be sent again"

2008-10-31 Thread stack (JIRA)
Project: Hadoop Core Issue Type: Bug Components: dfs Affects Versions: 0.19.0 Reporter: stack Priority: Blocker Updating hbase to use 0.19.0RC0 or latest from branch-0.19, I see reams of this in logs: {code} 2008-10-31 18:33:4

Re: [VOTE] Release Hadoop 0.18.2 (candidate 0)

2008-10-30 Thread stack
+1 - I took a run through the documentation and the UIs - Ran hbase unit tests and load test St.Ack Nigel Daley wrote: I have created a candidate build for Hadoop 0.18.2. This fixes 25 issues in 0.18.1. *** Please download and test it before the *** vote closes on Monday, November 3. htt

[jira] Commented: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-10-10 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638717#action_12638717 ] stack commented on HADOOP-3422: --- Good stuff Brian. 1). Just by way of FYI,

[jira] Commented: (HADOOP-3422) Ganglia counter metrics are all reported with the metric name "value", so the counter values can not be seen

2008-10-09 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638491#action_12638491 ] stack commented on HADOOP-3422: --- I took a look at the patch. You have this in a few pl

[jira] Commented: (HADOOP-3315) New binary file format

2008-10-02 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636455#action_12636455 ] stack commented on HADOOP-3315: --- @Hong So, to read a random key, I'd now d

[jira] Commented: (HADOOP-3315) New binary file format

2008-09-24 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634322#action_12634322 ] stack commented on HADOOP-3315: --- bq. ...would your auxiilary index remember how

[jira] Commented: (HADOOP-3315) New binary file format

2008-09-24 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634262#action_12634262 ] stack commented on HADOOP-3315: --- To Owen's list I'd suggest adding amenable

[jira] Commented: (HADOOP-3315) New binary file format

2008-09-23 Thread stack (JIRA)
[ https://issues.apache.org/jira/browse/HADOOP-3315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634028#action_12634028 ] stack commented on HADOOP-3315: --- @Hong. Yeah. You got all my questions. Here&#x

  1   2   3   >