quot; is set by the patch submitter who wants the patch
to be reviewed...
Alex
On Tue, Feb 26, 2013 at 2:20 PM, Stack wrote:
> On Tue, Feb 19, 2013 at 5:12 PM, Alex Baranau >wrote:
>
> > Sorry guys I had leave early (the dev powwow).
> >
> > On the bright side (?) whi
-SNAPSHOT
[ERROR]
[ERROR] --
[ERROR] 1 required artifact is missing.
[ERROR]
Alex Baranau:
Heh,
Take a look at http://jira.codehaus.org/browse/MRRESOURCES-53. I guess we
are facing this problem. I tried to fix by moving remote plugin from
execution phase as it was suggested by adding [1] to pa
Hi, I don't know the details of what Todd suggested, could you please take
a look at last two comments at
https://issues.apache.org/jira/browse/HBASE-4050, to see if I understand
correctly the options here.
Thank you in advance,
Alex Baranau
--
Sematext :: http://blog.sematext.com/ : H
the fact that code
implemented on top of metrics2 will not compile against 1.0+, 2.0+ and 3.0+
hadoop at the same time because class names, etc. changed between 1.0 and
2.0. But that's a separate story, will look at it tomorrow (Ted pointed me
to smth to look at).
Alex Baranau
On Tue, Jul 10,
eted metrics related JIRAs. But I will finish it over the weekend and
> create the issue, if that is OK?
>
> Lars
>
> On Jun 29, 2012, at 7:06 PM, Alex Baranau wrote:
>
> > Hi Lars,
> >
> > Any chance you created umbrella jira for that?
> >
> > Thank
Hi Lars,
Any chance you created umbrella jira for that?
Thank you,
Alex
On Sat, Jun 23, 2012 at 3:10 AM, Lars George wrote:
> Hi Greg,
>
> I am going through all related JIRAs right now so that we can consolidate
> the effort into one umbrella issue. I should have that done today and will
> th
ssage isn't really a problem.
Perhaps we could even stick a coprocessor in such memstore compactions so
that even greater compaction can be made based on application logic? Would
it be valuable?
Thank you!
Alex Baranau
On Wed, May 2, 2012 at 1:29 AM, lars hofhansl wrote:
> HBASE-4241 so
t.
4) anything else?
Esp. 3rd point - am I getting it right?
Thanx,
Alex Baranau
All correct. No changes in HBase needed (no were requested actually,
changing default retry behavior was just suggestion by Stack). Thank you all
for participating!
Alex Baranau
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - Hadoop - HBase
On Wed, Jun 29, 2011 at 4:44 PM, Doug
er after failures
* internally put uses batch anyways (i.e. connection.processBatch)
Alex Baranau
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - Hadoop - HBase
On Tue, Jun 28, 2011 at 10:41 PM, Doug Meil
wrote:
>
> But if Flume used the htable 'batch' method i
> if the sink "dies" for some reason, then it should
> push that back to the upstream parts of the flume dataflow, and have them
> buffer data on local disk.
True. But this seem to be a separate issue:
https://issues.cloudera.org/browse/FLUME-390.
Alex Baranau
--
s the best default behavior and do we need to allow
user override it on Flume ML (or directly at
https://issues.cloudera.org/browse/FLUME-685).
Thank you guys,
Alex Baranau
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - Hadoop - HBase
On Mon, Jun 27, 2011 at 11:40 PM, Stack wrote:
able.put to use
configuration properties "hbase.client.pause" and
"hbase.client.retries.number"? I.e. make retries attempts to be (reasonably)
close to "perform forever". Is that what you meant?
Thank you,
Alex Baranau
Sematext :: http://sematext.com/ :: Solr - Lucene - N
down)
+LOG.error("Writing data to HBase failed, will try again in " +
RETRY_INTERVAL_ON_WRITE_FAIL + " sec", ioe);
+Thread.currentThread().wait(RETRY_INTERVAL_ON_WRITE_FAIL * 1000);
+ }
+} while (!dataWritten);
Thank you in advance,
Alex Baranau
Sematext :: htt
-0.1.0-SNAPSHOT-2011.05.19.jar
(downloadable from https://github.com/sematext/HBaseWD)
Alex Baranau
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - Hadoop - HBase
P.S.
> Can you summarize HBaseWD in your blog
That is on my todo list! You pushed it higher to the top priority it
te hash of
original key (https://github.com/sematext/HBaseWD/issues/2).
In either way you don't need to delete record to update some cells of it or
add new cells.
Please let me know if you have more Qs!
Alex Baranau
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - Hadoop -
Thanks for the interest!
We are using it in production. It is simple and hence quite stable. Though
some minor pieces are missing (like
https://github.com/sematext/HBaseWD/issues/1) this doesn't affect stability
and/or major functionality.
Alex Baranau
Sematext :: http://sematex
rceScan" attribute.
>
> It is Okay to keep all versions of your patch in the JIRA. Maybe the second
> should be named
> HBASE-3811-v2.patch<https://issues.apache.org/jira/secure/attachment/12478694/HBASE-3811.patch>?
>
> Thanks
>
>
> On Wed, May 11, 2011
27;s
what you want, distributed
> scan can generate unique ID and set, say "sourceScan" attribute to its
value. This way we'll
> have <# of distinct "sourceScan" attribute values> = client side> and two scans on server side will have the same "sourceScan&qu
19 matches
Mail list logo
