On Mon, Apr 18, 2016 at 10:59 PM, wrote:
> Whenever we added new source files, the default template injected our
> names into those files.
>
There are copyrights from:
Copyright (C) 1994 X Consortium
Copyright (C) 1996-2013 Free Software Foundation, Inc.
Originally written by Fran,cois Pinard ,
On Mon, Apr 18, 2016 at 10:40 PM, Devaraj Das wrote:
> why would we block it.
AsyncProcess is what we get if we don't. I don't want to ever inflict that
on another person.
Will address this at the earliest..
On 4/19/16, 1:59 AM, "va...@hashmapinc.com" wrote:
>>There's GNU licensed code. GNU is specifically called out as not being able
>>to be in our repos.
>>None of these are addressed and to be honest they scare me. We can move
>>fast and import code that's not
On 2016-04-18 21:41, Elliott Clark wrote:
> On Mon, Apr 18, 2016 at 4:57 PM, Devaraj Das wrote:
>
>> 1. Be able to do async RPC. Vamsi's current implementation does sync. I
>> know Vamsi is already looking at that aspect. Just to be clear, this in my
>> mind this doesn't qualify as a blocker -
Elliott, on the point about sync versus async, as I said earlier, that's an
area we are looking at, and we'd welcome contributions from you very much as
well. But at the same time, I don't want the perfect to be the enemy of the
good. If something is working well in the sync mode, why would we b
On Mon, Apr 18, 2016 at 8:41 PM, Elliott Clark wrote:
> There are copyright headers from other projects (install-sh, missing).
To be clear those are just the first two that I saw. There could be more,
but I don't really want to have to go through everything to check what
project it came from.
Rohit Sinha created HBASE-15676:
---
Summary: FuzzyRowFilter fails and matches all the rows in the
table if the mask consists of all 0s
Key: HBASE-15676
URL: https://issues.apache.org/jira/browse/HBASE-15676
On Mon, Apr 18, 2016 at 4:57 PM, Devaraj Das wrote:
> 1. Be able to do async RPC. Vamsi's current implementation does sync. I
> know Vamsi is already looking at that aspect. Just to be clear, this in my
> mind this doesn't qualify as a blocker - since we don't have an async
> client API to suppor
[
https://issues.apache.org/jira/browse/HBASE-15660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser resolved HBASE-15660.
Resolution: Invalid
Assignee: (was: Josh Elser)
Fix Version/s: (was: 1.2.2)
Yu Li created HBASE-15675:
-
Summary: Add more details about region on table.jsp
Key: HBASE-15675
URL: https://issues.apache.org/jira/browse/HBASE-15675
Project: HBase
Issue Type: Sub-task
Your mail is very timely, Stack. Since I have been involved in this work for
some time now, let me try replying to this email...
Vamsi and his team is working with us (Hortonworks) to get a C++ HBase client
implementation up and running. We were discussing internally that we should
reach out to
Elliott Clark created HBASE-15674:
-
Summary: HRegionLocator#getAllRegionLocations should put the
results in cache
Key: HBASE-15674
URL: https://issues.apache.org/jira/browse/HBASE-15674
Project: HBase
Appy created HBASE-15673:
Summary: Fix latency metrics for multiGet
Key: HBASE-15673
URL: https://issues.apache.org/jira/browse/HBASE-15673
Project: HBase
Issue Type: Bug
Reporter: Appy
Yeah there's currently two different implementation efforts on-going.
I started working on a cpp client a while ago. Then there was some interest
in working on the cpp client from other parties. So I put some of the
implementation up. Things stayed there for a while. Then interest surged
again. Va
Vladimir Rodionov created HBASE-15672:
-
Summary:
hadoop.hbase.security.visibility.TestVisibilityLabelsWithDeletes fails
Key: HBASE-15672
URL: https://issues.apache.org/jira/browse/HBASE-15672
Proj
Correct me if I am wrong, but it seems like there are two (different?) C++
clients underway? There is the work by Vamsi Mohan V S Thattikota that is
going on in HBASE-15534 and then there is what seems like a different
effort over in HBASE-14850 C++ client implementation by the mighty Elliott.
Wha
Alicia Ying Shu created HBASE-15671:
---
Summary: Add per-table metrics on memstore, storefile and
regionsize
Key: HBASE-15671
URL: https://issues.apache.org/jira/browse/HBASE-15671
Project: HBase
[
https://issues.apache.org/jira/browse/HBASE-15506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov reopened HBASE-15506:
---
> FSDataOutputStream.write() allocates new byte buffer on each operation
> --
[
https://issues.apache.org/jira/browse/HBASE-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack reopened HBASE-15667:
---
FYI Sai, the process is that you attach the patch and then move the status to
'submit patch'. That will get your
It's about time for another 0.98 release. Let me put something together
later this week.
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Enis Soztutar created HBASE-15670:
-
Summary: Add missing Snapshot.proto to the maven profile for
compiling protobuf
Key: HBASE-15670
URL: https://issues.apache.org/jira/browse/HBASE-15670
Project: HBa
Build status: Successful
If successful, the website and docs have been generated. If failed, skip to the
bottom of this email.
Use the following commands to download the patch and apply it to a clean branch
based on origin/asf-site. If you prefer to keep the hbase-site repo around
permanently,
Ashish Singhi created HBASE-15669:
-
Summary: HFile size is not considered correctly in a replication
request
Key: HBASE-15669
URL: https://issues.apache.org/jira/browse/HBASE-15669
Project: HBase
Ashish Singhi created HBASE-15668:
-
Summary: Bulk loaded data fails to replicate hfiles when a hfile
in not found in FS anywhere
Key: HBASE-15668
URL: https://issues.apache.org/jira/browse/HBASE-15668
Successful
If successful, the HTML and link-checking report for http://hbase.apache.org is
available at
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/35/artifact/link_report/index.html.
If failed, see
https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/35/console.
>>store.getSmallestReadPoint()
This is the problem. At the time of write some other readers (opened
in past) were present, then all those are present readPnts and u will
get min of all such read points.
Its a pity that we are not passing the read point to the CP pre hook.
That is obtained in Re
[
https://issues.apache.org/jira/browse/HBASE-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Teja Ranuva resolved HBASE-15667.
-
Resolution: Fixed
Attached Patch File with changed documentation.
> Add more clarity to
[
https://issues.apache.org/jira/browse/HBASE-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Teja Ranuva reopened HBASE-15667:
-
patch not attached
> Add more clarity to Reference Guide related to importing Eclipse Format
[
https://issues.apache.org/jira/browse/HBASE-15667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Teja Ranuva resolved HBASE-15667.
-
Resolution: Fixed
> Add more clarity to Reference Guide related to importing Eclipse Form
I have new information after some more debugging:
I am sure coprocessor is not filtering out values in get/put hooks.
The observed behavior is:
We create non-existing cell via PUT and immediately after the call
returns, we are trying to get the created cell value via GET. The GET
is done eve
30 matches
Mail list logo
