Elliott Clark created HBASE-15135:
-
Summary: Add metrics for storefile age
Key: HBASE-15135
URL: https://issues.apache.org/jira/browse/HBASE-15135
Project: HBase
Issue Type: New Feature
Elliott Clark created HBASE-15134:
-
Summary: Add visibility into Flush and Compaction queues
Key: HBASE-15134
URL: https://issues.apache.org/jira/browse/HBASE-15134
Project: HBase
Issue Type:
I am pleased to announce that the second release candidate for the release
1.0.3
(HBase-1.0.3RC1), is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.0.3RC1/
Maven artifacts are also available in the temporary repository
https://repository.apache.org/content/reposit
bq. that only checked test-compile on jdk1.7 instead of the full unit test
suite.
This would be sufficient for branch-1.x and master branch.
Cheers
On Tue, Jan 19, 2016 at 6:52 PM, Sean Busbey wrote:
> Alternatively, I could attempt to turn precommit into a matrix build that
> runs yetus agai
> Is the performance OK if i request the number of incoming-follow-nodes?
Yes, I think no problem.
At least, in our use case, the performance is OK.
2016-01-18 16:05 GMT+09:00 Heng Chen :
> The incoming-follow-nodes and outgoing-follow-nodes of one node exceed
> Integer.MAX_VALUE, unbelievable!
On Tue, Jan 19, 2016 at 11:48 AM, Stack wrote:
> On Tue, Jan 19, 2016 at 5:46 AM, Sean Busbey wrote:
>
> > We could start forcing a clean repository on every build (though this
> > seems heavy handed).
> >
> > IIRC, we ran into this ages ago and it was one particular dependency.
> > Presuming we
Toshihiro Suzuki created HBASE-15133:
Summary: Data loss after compaction when a row has more than
Integer.MAX_VALUE columns
Key: HBASE-15133
URL: https://issues.apache.org/jira/browse/HBASE-15133
Alternatively, I could attempt to turn precommit into a matrix build that
runs yetus against the two java versions independently. Main disadvantage
is doubling up on the feedback for other tests.
Or we could come up with a yetus plugin that only checked test-compile on
jdk1.7 instead of the full u
Ted Yu created HBASE-15132:
--
Summary: Master region merge RPC should authorize user request
Key: HBASE-15132
URL: https://issues.apache.org/jira/browse/HBASE-15132
Project: HBase
Issue Type: Bug
Enis Soztutar created HBASE-15131:
-
Summary: Turn on multi-WAL by default
Key: HBASE-15131
URL: https://issues.apache.org/jira/browse/HBASE-15131
Project: HBase
Issue Type: New Feature
I wasn't clear in previous message.
MOB is a big feature. There is not enough time to get it into 1.2.0
I intended to vote for MOB getting merged into branch-1 (1.3.0)
Thanks
On Tue, Jan 19, 2016 at 5:31 PM, Jonathan Hsieh wrote:
> +1 to 1.2 being feature complete corrently. There has alrea
+1 to 1.2 being feature complete corrently. There has already been a
release candidate and folks are burning down the blockers currently to prep
for the next RC.
I like the idea of mob and sparkonhbase for 1.3. I'm more comfortable with
sparkonhbase -- it is a new module and thus not as invasive
Pretty sure Sean expressed 1.2 is feature complete and I'd support that. Can we
wait for 1.3 for MOB ? Can look at Spark connector then too.
> On Jan 19, 2016, at 4:52 PM, Ted Yu wrote:
>
> Looks like 1.2.0 RC is in near future.
>
> I wonder if it is time to revive this thread (due to custome
Looks like 1.2.0 RC is in near future.
I wonder if it is time to revive this thread (due to customer interest).
As far as I can tell, the Mob related tests have been passing in the recent
past.
Thanks
On Wed, Oct 28, 2015 at 2:07 PM, Andrew Purtell wrote:
> I haven't heard an user answer in t
Can we do that with pre-commit, but leave all supported java versions based
on the branch's compatibility guarantees?
On Tue, Jan 19, 2016 at 2:31 PM, Stack wrote:
> We are running all unit tests with java 1.7 and then 1.8. This is
> effectively doubling the time it takes for an hadoopqa build t
We are running all unit tests with java 1.7 and then 1.8. This is
effectively doubling the time it takes for an hadoopqa build to come home
(~4hr vs just over 2). How about running just 1.8 for hadoopqa builds?
St.Ack
churro morales created HBASE-15130:
--
Summary: Backport 0.98 Scan different TimeRange for each column
family
Key: HBASE-15130
URL: https://issues.apache.org/jira/browse/HBASE-15130
Project: HBase
On Tue, Jan 19, 2016 at 5:46 AM, Sean Busbey wrote:
> We could start forcing a clean repository on every build (though this
> seems heavy handed).
>
> IIRC, we ran into this ages ago and it was one particular dependency.
> Presuming we can track down what that was, we could add some pre-build
> w
[
https://issues.apache.org/jira/browse/HBASE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Singhi reopened HBASE-9393:
--
This is a issue we need to fix it, so reopening it.
> Hbase does not closing a closed socket result
We could start forcing a clean repository on every build (though this
seems heavy handed).
IIRC, we ran into this ages ago and it was one particular dependency.
Presuming we can track down what that was, we could add some pre-build
work that verifies a known good copy of that dependency is present
Yu Li created HBASE-15129:
-
Summary: Set default value for hbase.fs.tmp.dir rather than fully
depend on hbase-default.xml
Key: HBASE-15129
URL: https://issues.apache.org/jira/browse/HBASE-15129
Project: HBase
21 matches
Mail list logo
