volvement.
> > > >
> > > > Please join me in congratulating LarsF! (Opting to use last name
> > > > initials as we now have three Lars' as committers)
> > > >
> > > > --
> > > > Best regards,
> > > > LarsG
> >
us far and look forward to
> > > continued involvement.
> > >
> > > Please join me in congratulating Peter!
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>
--
==
Openinx blog : http://openinx.github.io
TO BE A GREAT HACKER !
==
fp/hbaseconasia-2018>*
> [2] https://easychair.org/conferences/?conf=hbaseconasia2018
> [3] https://hbase.apache.org/hbaseconasia-2018/
>
--
==
Openinx blog : http://openinx.github.io
TO BE A GREAT HACKER !
==
Congratulations!
On Mon, Jun 4, 2018 at 6:16 PM, ashish singhi
wrote:
> Congrats and Welcome!
>
> Regards,
> Ashish
> -Original Message-
> From: 张铎(Duo Zhang) [mailto:palomino...@gmail.com]
> Sent: Monday, June 04, 2018 12:30 PM
> To: HBase Dev List ; hbase-user <
> user@hbase.apache.org
Congrats Peter! You deserve it !
On Tue, Jan 22, 2019 at 9:44 AM Sakthi wrote:
> Congrats Peter!
>
> Sakthi
>
> On Mon, Jan 21, 2019 at 5:36 PM Duo Zhang wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Peter
> > Somogyi
> > has accepted our invitation to become a P
Congratulation, Jan! Thanks for your work.
On Thu, May 9, 2019 at 6:08 AM Artem Ervits wrote:
> Well deserved Jan!
>
> On Wed, May 8, 2019, 5:37 PM Sean Busbey wrote:
>
> > On behalf of the Apache HBase PMC I am pleased to announce that Jan
> > Hentschel has accepted our invitation to become a
Congratulations!
On Fri, May 24, 2019 at 3:12 PM Guanghao Zhang wrote:
> On behalf of the Apache HBase PMC, I am pleased to announce that Yi Mei has
> accepted the PMC's invitation to become a committer on the project. We
> appreciate all of Yi Mei's generous contributions thus far and look forw
Congratulations Wellington!
On Sat, Jun 8, 2019 at 5:01 AM Xu Cang wrote:
> Congrats Wellington and welcome!
>
>
> On Fri, Jun 7, 2019 at 1:21 PM Sakthi wrote:
>
> > Hurray! Congrats Wellington. Well deserved one!
> >
> > Sakthi
> >
> > On Fri, Jun 7, 2019 at 12:58 PM Wei-Chiu Chuang
> > wrote
Hi Vitaliy
> What would be NOT conservative upper bound for such case?
Good Question, there some reasons I can think about :
1. The BucketCache won't cache big block (IIRC, 2MB?) by default . say if
you have a 10MB cell, then it won't
cache in BucketCache, it need to read disk very time. quit ti
One more thing is compaction, if cell is so big, then we need much IO to
read & write
the value of big cell. Actually, when compaction, key of the cell is the
key point.
On Mon, Jul 1, 2019 at 11:02 PM OpenInx wrote:
> Hi Vitaliy
>
> > What would be NOT conservative upper bou
Hi marjana. when you alter to the new replication peer, you only want the
new replication data redirect to
the new slave cluster ? how about the old data in the master cluster ? is
that necessary to migrate to the
new slave cluster also ? In our XiaoMi clusters, when doing the migration
to a ne
ve the peer right now.
Thanks.
On Thu, Jul 11, 2019 at 9:45 AM OpenInx wrote:
> Hi marjana. when you alter to the new replication peer, you only want the
> new replication data redirect to
> the new slave cluster ? how about the old data in the master cluster ?
> is that necessary
are replicated to sink by ORIGIANL_ID peer. If still
some lag and you remove
the old peer, then all edits from hlog1 will be loss.
On Thu, Jul 11, 2019 at 6:17 PM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:
> Hi Marjana,
>
> I guess OpenInx (much valid) point here is
Kang
Yeah, better to have a check as Sean suggested. If you're just building the
repo, and
really want to skip the license check. you can try to comment
the check-aggregate-license
part as the following:
diff --git a/pom.xml b/pom.xml
index ebd97f7d0c..d36479d01c 100755
--- a/pom.xml
+++ b/pom.xml
Austin is right. The pre-splitting is mainly used for generate&load HFiles,
say
when do bulkload, it will load each generated hfile to the corresponding
region
who include the rowkey interval of the hfile. If no pre-splitting, then all
HFiles
will be in one region, bulkload will be time-consuming a
Congratulations Duo! and thanks Misty.
On Fri, Jul 19, 2019 at 9:34 AM Guanghao Zhang wrote:
> Congratulations!
>
> Duo Zhang 于2019年7月19日周五 上午9:33写道:
>
> > Thanks Misty for the great job you have done these years.
> >
> > And thanks all for trusting me. Will try my best.
> >
> > Jan Hentschel
iles, if needed, they
> will
> > > be split according to the regions boundaries.
> > >
> > > Because between when you start your job and when you push your files,
> > there
> > > might have been some "natural" splits on the table side, the bulk
> My question is: is it safe to ignore these TimeoutExceptions? if the
SnapshotRegionManifests are not being written due to a timeout does that
mean we are losing data or getting inconsistencies?
I don't think ignoring the TimeoutException is a good idea. You need to
find out why did the snapshot
Say you wan to encode a scan to base64 ? then you may need to encode the
scan to protobuf Scan object, then encode the protobuf byte[] to Base64.
1. Scan scan = ...
2. ClientProtos.Scan protoScan = ProtobufUtil#toScan(scan);
3. byte[] bytes = make the protoScan to byte[];
4. encode the bytes to ba
You mean you can start the RS by hbase-daemons.sh, but failed by
start-hbase.sh ? That makes no sense, because the start-hbase.sh is just
executing the hbase-daemons.sh scripts.
Could you provide more information about the failure ?
On Thu, Jul 25, 2019 at 10:26 AM wrote:
> Hello User.
>
> (HB
Congratulations, Sakthi.
On Thu, Aug 1, 2019 at 3:09 PM Jan Hentschel <
jan.hentsc...@ultratendency.com> wrote:
> Congrats Sakthi
>
> From: Reid Chan
> Reply-To: "user@hbase.apache.org"
> Date: Thursday, August 1, 2019 at 9:04 AM
> To: "user@hbase.apache.org" , dev <
> d...@hbase.apache.org>
>
> the docs for the SimpleRegionNormalizer say that empty regions are not
merged.
Which docs you mean ? Please provide it if you have the link, I've checked
the code it would merge two
empty regions if the merging condition fit.
Thanks.
On Mon, Aug 5, 2019 at 2:10 PM Lars Francke wrote:
> Hi,
I'm so glad to join the PMC, Apache HBase is a great open source project
and the
community is also very nice and friendly. In the comming days, will do
more to make
the project & community forward, also we need more work to attract people
to enhance
and expand the community: blog/post/book/talk
Hi
I've checked the code, I think you can use the deprecated TimeRange(ts+1)
first, also the methods defined in TimeRange
is not good enough now, we may need to create an issue to address this
thing.
Thanks.
On Tue, Aug 6, 2019 at 10:15 AM Wilson, Huon (Data61, Eveleigh) <
huon.wil...@data61.csi
Hi Alexander
Thanks for the log report & share. I guess we did not handle
the NotServingRegionException for hbase:meta correctly, says when a client
encounter a NotServingRegionException from hbase:meta, it won't try to
relocate the hbase:meta location. (in 1.4.8)
Let me have a check.
On Wed, Aug
I think upgrading to HBase1.4.10 can fix your problem here.
Please see: https://issues.apache.org/jira/browse/HBASE-21464
Thanks.
On Wed, Aug 14, 2019 at 10:22 AM OpenInx wrote:
> Hi Alexander
> Thanks for the log report & share. I guess we did not handle
> the NotServingRegion
We have an issue https://issues.apache.org/jira/browse/HBASE-22862, Let's
discuss there.
Thanks.
On Sat, Aug 17, 2019 at 1:17 AM Stack wrote:
> Interesting. The Cells differ in sequence id. Would seem to imply race
> around the getting of sequenceid writing the WAL. The crashes are happening
>
Hi
> (1) Sort the printed data in ascending order of timestamp value
Currently, the hbase jruby scripts cannot meet your requirements now. If
you really want this feature, you
may need to edit the *_scan_internal* method in
hbase-shell/src/main/ruby/hbase/table.rb. say sort the cells
by your ti
Seems the TestHRegionWithInMemoryFlush is always failed under my host,
filed issue to address this:
https://issues.apache.org/jira/browse/HBASE-22995
* Signature: ok
* Checksum : ok
* Rat check (1.8.0_202): ok
- mvn clean apache-rat:check
* Built from sourc
Agree, give my +1 (binding).
BTW Peter Somogyi also have commit the fix to related branches.
Thanks.
On Mon, Sep 9, 2019 at 5:40 PM 张铎(Duo Zhang) wrote:
> Seems to be a UT issue? I do not think it is sufficient to sink an RC?
>
> OpenInx 于2019年9月9日周一 下午4:35写道:
>
&
Seems your block size is very small (16KB), so there will be
70*1024*1024/16=4587520 block (at most) in your BucketCache.
For each block, the RS will maintain a soft reference idLock and a
BucketEntry in its bucket cache. So maybe you can try to
enlarge the block size ?
On Sun, Sep 29, 2019 at 10
ill be remission by your advise,but there only get request in our
> business,so 16KB is better.
> IMO,the locks of offset will always be used,so is the strong reference a
> better choice?
>
>
>
>
> ------ 原始邮件 --
> 发件人: "OpenInx";
> 发
00: 125161.629: [JNI Weak
> Reference, 0.0001070 secs]
> , 0.6667733 secs]
> 2019-09-18T03:16:42.756+0800: 125162.146:
> [Unloading, 0.0224078 secs]
> , 0.6987032 secs]
>
>
> -- 原始邮件 --
> 发件人: "OpenInx";
Congrats and welcome !
On Tue, Dec 6, 2022 at 2:21 AM Andrew Purtell wrote:
> Congratulations, and welcome!
>
> On Sat, Dec 3, 2022 at 5:51 AM Yu Li wrote:
>
> > Hi All,
> >
> > On behalf of the Apache HBase PMC, I am pleased to announce that Liangjun
> > He (heliangjun) has accepted the PMC's
34 matches
Mail list logo