[jira] [Updated] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[
https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anoop Sam John updated HBASE-11423:
---
Attachment: HBASE-11423_v3.patch
This is what I committed to trunk. Slight change from V2
MultiRowMutationProcessor#postProcess()
{code}
+ // At the end call the CP hook postBatchMutateIndispensably
+ if (miniBatch != null) {
+// Directly calling this hook, with out calling pre/postBatchMutate()
when Processor do a
+// read only process. Then no need to call this batch based CP hook
also.
+coprocessorHost.postBatchMutateIndispensably(miniBatch, success);
+ }
{code}
And if check is added so as to handle the case of calling the postProcess()
directly after process() step ie. When the process is read only.
> Visibility label and per cell ACL feature not working with HTable#mutateRow()
> and MultiRowMutationEndpoint
> --
>
> Key: HBASE-11423
> URL: https://issues.apache.org/jira/browse/HBASE-11423
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, security
>Affects Versions: 0.98.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Blocker
> Fix For: 0.99.0, 0.98.4, 2.0.0
>
> Attachments: HBASE-11423.patch, HBASE-11423_0.98.patch,
> HBASE-11423_v2.patch, HBASE-11423_v2.patch, HBASE-11423_v3.patch
>
>
> This is because pre/postBatchMutate() APIs are not getting called from
> HRegion#processRowsWithLocks()
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-11423: --- Attachment: HBASE-11423_0.98.patch 0.98 version of patch what I committed. > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_0.98.patch, > HBASE-11423_v2.patch, HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-11423: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.98+ branches. Thanks for the reviews. > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_0.98.patch, > HBASE-11423_v2.patch, HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058484#comment-14058484 ] Anoop Sam John commented on HBASE-11423: This is a fix for a critical bug and I hope [~enis] is fine with that. Going to commit to branch-1 also. > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_v2.patch, > HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-11438: --- Component/s: security > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.5 > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058478#comment-14058478 ] Anoop Sam John commented on HBASE-11438: bq.Should we allow '&','!','|' to be used as visibility expression. You mean to be used in visibility labels? Yes we should allow IMO bq.Then we may have to provide a quote() api like Accumulo provides which the user can use to quote strings with these characters so that they can be used in the vis expressions. Yes better to give this helper API. > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement > Components: security >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.5 > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[
https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058472#comment-14058472
]
Matteo Bertozzi commented on HBASE-11497:
-
Does the InterfaceAudience means that you not only have to preserve the public
methods but also the "open" methods/members of the class?
e.g. With the latest changes SimpleRPCScheduler has not changed the public
interface (all the methods aside 1 private are still there), but the 3 queues
that were open at the package level were removed.
{code}
- final BlockingQueue callQueue;
- final BlockingQueue priorityCallQueue;
- final BlockingQueue replicationQueue;
{code}
> Expose RpcScheduling implementations as Public Interfaces
> -
>
> Key: HBASE-11497
> URL: https://issues.apache.org/jira/browse/HBASE-11497
> Project: HBase
> Issue Type: Improvement
> Components: io, regionserver, Usability
>Affects Versions: 0.99.0, 0.98.4
>Reporter: Jesse Yates
>Assignee: Jesse Yates
> Fix For: 0.99.0, 0.98.4, 2.0.0
>
> Attachments: hbase-11497-0.98-v0.patch
>
>
> In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by
> adding custom RPC handlers (so regular puts/reads don't interfere with index
> updates). However, we've run into a couple of snags where the interfaces
> change, making it a bit more difficult to support interoperability between
> minor versions as the underlying RPC handling changed (for the better, but
> still different :).
> This would just mark those interfaces Public, Evolving, so we still have some
> flexibility, but don't break existing usage.
> Note, this kind of thing will come up for any client who is doing custom RPC
> handling - beyond the recently added flexibility - but wants to stay in line
> with the current HBase implementation (rather than building their own RPC
> handling mechanisms).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11437) Modify cell tag handling code to treat the length as unsigned
[ https://issues.apache.org/jira/browse/HBASE-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058459#comment-14058459 ] Anoop Sam John commented on HBASE-11437: bq.The latest patch is lesser in size than the older ones. Hope all the places are changed Yes all places. This is because in latest trunk patch we have not renamed the method but changed the signature (as we discussed for the deprecation). So it is not touching many files where the change was only method name change. > Modify cell tag handling code to treat the length as unsigned > - > > Key: HBASE-11437 > URL: https://issues.apache.org/jira/browse/HBASE-11437 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11437.patch, HBASE-11437.patch, HBASE-11437.patch, > HBASE-11437_trunk.patch > > > We store each tag's length and total tags length with 2 bytes in KeyValue > buffer, HFiles etc and we treat these lengths as short through out the code. > So the max length can be Short.MAX_VALUE. We can treat these lengths as > unsigned and +ve always. So we can actually treat these lengths as int and > store with 2 bytes so that the max length can reach 65535. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11039) [VisibilityController] Integration test for labeled data set mixing and filtered excise
[ https://issues.apache.org/jira/browse/HBASE-11039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-11039: --- Attachment: HBASE-11039_v4_0.98.patch Adds a method in AccessControlClient to say if there is ACL running. Still mvn verify part am not able to make it run. I think we can commit this in 0.98 and because the IT runs in a cluster using ACL and VC specifying the required user. > [VisibilityController] Integration test for labeled data set mixing and > filtered excise > --- > > Key: HBASE-11039 > URL: https://issues.apache.org/jira/browse/HBASE-11039 > Project: HBase > Issue Type: Test >Affects Versions: 0.98.1 >Reporter: Andrew Purtell >Assignee: ramkrishna.s.vasudevan >Priority: Critical > Fix For: 0.99.0, 1.0.0, 0.98.4 > > Attachments: HBASE-11039_ITBLL_v1.patch, HBASE-11039_v3_0.98.patch, > HBASE-11039_v4_0.98.patch > > > Create an integration test for the VisibilityController that: > 1. Create several tables of test data > 2. Assign a set of auths to each table. Label all entries in the table with > appropriate visibility expressions. Insure that some data in every table > overlaps with data in other tables at common row/family/qualifier > coordinates. Generate data like ITBLL so we can verify all data present later. > 3. Mix the data from the different tables into a new common table > 4. Verify for each set of auths defined in step #2 that all entries found in > the source table can be found in the common table. Like the ITBLL > verification step but done N times for each set of auths defined in step #2. > 5. Choose one of the source tables. Get its set of auths. Perform a deletion > with visibility expression from the common table using those auths. > 6. Verify that no data in the common table with the auth set chosen in #5 > remains. A simple row count with the set of auths chosen in #5 that should > return 0. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11488) cancelTasks in SubprocedurePool can hang during task error
[
https://issues.apache.org/jira/browse/HBASE-11488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058415#comment-14058415
]
Jerry He commented on HBASE-11488:
--
Ping [~apurtell], [~enis].
> cancelTasks in SubprocedurePool can hang during task error
> --
>
> Key: HBASE-11488
> URL: https://issues.apache.org/jira/browse/HBASE-11488
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 0.96.1, 0.99.0, 0.98.3
>Reporter: Jerry He
>Assignee: Jerry He
>Priority: Minor
> Attachments: HBASE-11488-master.patch
>
>
> During snapshot on the region server side, if one RegionSnapshotTask throws
> exception, we will cancel other tasks.
> In
> RegionServerSnapshotManager.SnapshotSubprocedurePool.waitForOutstandingTasks():
> {code}
> LOG.debug("Waiting for local region snapshots to finish.");
> int sz = futures.size();
> try {
> // Using the completion service to process the futures that finish
> first first.
> for (int i = 0; i < sz; i++) {
> Future f = taskPool.take();
> f.get();
> if (!futures.remove(f)) {
> LOG.warn("unexpected future" + f);
> }
> LOG.debug("Completed " + (i+1) + "/" + sz + " local region
> snapshots.");
> }
> LOG.debug("Completed " + sz + " local region snapshots.");
> return true;
> } catch (InterruptedException e) {
> LOG.warn("Got InterruptedException in SnapshotSubprocedurePool", e);
> if (!stopped) {
> Thread.currentThread().interrupt();
> throw new ForeignException("SnapshotSubprocedurePool", e);
> }
> // we are stopped so we can just exit.
> } catch (ExecutionException e) {
> if (e.getCause() instanceof ForeignException) {
> LOG.warn("Rethrowing ForeignException from
> SnapshotSubprocedurePool", e);
> throw (ForeignException)e.getCause();
> }
> LOG.warn("Got Exception in SnapshotSubprocedurePool", e);
> throw new ForeignException(name, e.getCause());
> } finally {
> cancelTasks();
> }
> {code}
> If f.get() throws ExecutionException (for example, caused by
> NotServingRegionException), we will call cancelTasks().
> In cancelTasks():
> {code}
> ...
> // evict remaining tasks and futures from taskPool.
> while (!futures.isEmpty()) {
> // block to remove cancelled futures;
> LOG.warn("Removing cancelled elements from taskPool");
> futures.remove(taskPool.take());
> }
> {code}
> For example, suppose we have 3 tasks, the first one fails and we get an
> exception when we do:
> {code}
> Future f = taskPool.take();
> f.get();
> {code}
> We didn't remove the 'f' from the 'futures' list yet, but we already take one
> from taskPool.
> As a result, there are 3 in 'futures' list, but only 2 remain in taskPool.
> We'll block on taskPool.take() in the above cancelTasks() code.
> The end result is that the procedure will always fail timeout exception in
> the end.
> We could have bailed out earlier with the real cause.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11118) non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.Literal
[ https://issues.apache.org/jira/browse/HBASE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058403#comment-14058403 ] Nick Dimiduk commented on HBASE-8: -- Precisely my plan. I'll take care of it if I see you haven't. Don't want to hold up the RC any longer. > non environment variable solution for "IllegalAccessError: class > com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass > com.google.protobuf.LiteralByteString" > -- > > Key: HBASE-8 > URL: https://issues.apache.org/jira/browse/HBASE-8 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.2 >Reporter: André Kelpe >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: 8.098-0.txt, 8.098.txt, 8.bytestringer.txt, > 1118.suggested.undoing.optimization.on.clientside.txt, > 1118.suggested.undoing.optimization.on.clientside.txt, > HBASE-8-0.98.00.patch, HBASE-8-0.98.01.patch, > HBASE-8-0.98.02.patch, HBASE-8-0.98.patch.gz, > HBASE-8-trunk.patch.gz, HBASE-8.00.patch, HBASE-8.01.patch, > HBASE-8.02.patch, shade_attempt.patch > > > I am running into the problem described in > https://issues.apache.org/jira/browse/HBASE-10304, while trying to use a > newer version within cascading.hbase > (https://github.com/cascading/cascading.hbase). > One of the features of cascading.hbase is that you can use it from lingual > (http://www.cascading.org/projects/lingual/), our SQL layer for hadoop. > lingual has a notion of providers, which are fat jars that we pull down > dynamically at runtime. Those jars give users the ability to talk to any > system or format from SQL. They are added to the classpath programmatically > before we submit jobs to a hadoop cluster. > Since lingual does not know upfront , which providers are going to be used in > a given run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really > clunky and breaks the ease of use we had before. No other provider requires > this right now. > It would be great to have a programmatical way to fix this, when using fat > jars. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058391#comment-14058391 ] Hudson commented on HBASE-9745: --- SUCCESS: Integrated in hbase-0.96 #407 (See [https://builds.apache.org/job/hbase-0.96/407/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 0bd53be747986e398b8402848b2ff5dff2ea2495) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058392#comment-14058392 ] Hudson commented on HBASE-11496: SUCCESS: Integrated in hbase-0.96 #407 (See [https://builds.apache.org/job/hbase-0.96/407/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 0bd53be747986e398b8402848b2ff5dff2ea2495) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058381#comment-14058381 ] Hudson commented on HBASE-11496: FAILURE: Integrated in HBase-1.0 #25 (See [https://builds.apache.org/job/HBase-1.0/25/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 3d37252a3296f9c93c93a56e5aa1ecd557df5a6c) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058380#comment-14058380 ] Hudson commented on HBASE-9745: --- FAILURE: Integrated in HBase-1.0 #25 (See [https://builds.apache.org/job/HBase-1.0/25/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 3d37252a3296f9c93c93a56e5aa1ecd557df5a6c) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11437) Modify cell tag handling code to treat the length as unsigned
[ https://issues.apache.org/jira/browse/HBASE-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058377#comment-14058377 ] ramkrishna.s.vasudevan commented on HBASE-11437: The patch looks good to me. The latest patch is lesser in size than the older ones. Hope all the places are changed. +1 > Modify cell tag handling code to treat the length as unsigned > - > > Key: HBASE-11437 > URL: https://issues.apache.org/jira/browse/HBASE-11437 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11437.patch, HBASE-11437.patch, HBASE-11437.patch, > HBASE-11437_trunk.patch > > > We store each tag's length and total tags length with 2 bytes in KeyValue > buffer, HFiles etc and we treat these lengths as short through out the code. > So the max length can be Short.MAX_VALUE. We can treat these lengths as > unsigned and +ve always. So we can actually treat these lengths as int and > store with 2 bytes so that the max length can reach 65535. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11495) Support managing REST server as a deamon process
[ https://issues.apache.org/jira/browse/HBASE-11495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058341#comment-14058341 ] nijel commented on HBASE-11495: --- sorry i missed it.. I am able to start it .. > Support managing REST server as a deamon process > > > Key: HBASE-11495 > URL: https://issues.apache.org/jira/browse/HBASE-11495 > Project: HBase > Issue Type: Improvement >Reporter: nijel > > Now in HBase the REST server is started as a non daemon process. > It will be better it is supported as process from hbase-daemon.sh > Also can support stop and autorestart commands for REST server. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11438) [Visibility Controller] Support UTF8 character as Visibility Labels
[ https://issues.apache.org/jira/browse/HBASE-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058340#comment-14058340 ] ramkrishna.s.vasudevan commented on HBASE-11438: An internal patch for this is ready. Should we allow '&','!','|' to be used as visibility expression. Then we may have to provide a quote() api like Accumulo provides which the user can use to quote strings with these characters so that they can be used in the vis expressions. The corresponding parser code should handle it any way if quotes are found. > [Visibility Controller] Support UTF8 character as Visibility Labels > --- > > Key: HBASE-11438 > URL: https://issues.apache.org/jira/browse/HBASE-11438 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.4 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.98.5 > > > This would be an action item that we would be addressing so that the > visibility labels could have UTF8 characters in them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[
https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058339#comment-14058339
]
Hadoop QA commented on HBASE-11423:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655137/HBASE-11423_v2.patch
against trunk revision .
ATTACHMENT ID: 12655137
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 findbugs{color}. The patch appears to introduce 4 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10031//console
This message is automatically generated.
> Visibility label and per cell ACL feature not working with HTable#mutateRow()
> and MultiRowMutationEndpoint
> --
>
> Key: HBASE-11423
> URL: https://issues.apache.org/jira/browse/HBASE-11423
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors, security
>Affects Versions: 0.98.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
>Priority: Blocker
> Fix For: 0.99.0, 0.98.4, 2.0.0
>
> Attachments: HBASE-11423.patch, HBASE-11423_v2.patch,
> HBASE-11423_v2.patch
>
>
> This is because pre/postBatchMutate() APIs are not getting called from
> HRegion#processRowsWithLocks()
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-10297) LoadAndVerify Integration Test for cell visibility
[ https://issues.apache.org/jira/browse/HBASE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058338#comment-14058338 ] ramkrishna.s.vasudevan commented on HBASE-10297: But the above permission problem happens only when run with minicluster Andy. Not when run in a real cluster. In real cluster the only thing we may need is have a user called 'user1'. So with mvn verify what should we do to get it running ? > LoadAndVerify Integration Test for cell visibility > -- > > Key: HBASE-10297 > URL: https://issues.apache.org/jira/browse/HBASE-10297 > Project: HBase > Issue Type: Sub-task > Components: test >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 0.98.0, 0.99.0 > > Attachments: HBASE-10297.patch, HBASE-10297_V2.patch, > HBASE-10297_V3.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
[ https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058336#comment-14058336 ] Ted Yu commented on HBASE-11447: bq. Should TransactionInterface.commit() and TransactionInterface.rollback() have return values ? Alternatively, these methods can throw exception, indicating error condition. > Proposal for a generic transaction API for HBase > > > Key: HBASE-11447 > URL: https://issues.apache.org/jira/browse/HBASE-11447 > Project: HBase > Issue Type: New Feature > Components: Client >Affects Versions: 1.0.0 > Environment: Any. >Reporter: John de Roo >Priority: Minor > Labels: features, newbie > Fix For: 1.0.0 > > Attachments: Proposal for a common transactional API for HBase > v0.3_1.pdf, Proposal for a common transactional API for HBase v0.4_1.pdf, Re > Proposal for a generic transaction API for HBase.htm > > > HBase transaction management today is provided by a number of products, each > implementing a different API, each having different strengths. The lack of a > common API for transactional interfaces means that applications need to be > coded to work with a specific Transaction Manager. This proposal outlines an > API which, if implemented by the different Transaction Manager vendors would > provide stability and choice to HBase application developers. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
[ https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058335#comment-14058335 ] Shengzhe Yao commented on HBASE-11447: -- Oh, I think I am more interested in doing multiple transactions in a single TransactionTable instance. Think about a user do multi-row transaction, if two transactions operate two different set of rows, we could execute them together without creating another TransactionTable instance. > Proposal for a generic transaction API for HBase > > > Key: HBASE-11447 > URL: https://issues.apache.org/jira/browse/HBASE-11447 > Project: HBase > Issue Type: New Feature > Components: Client >Affects Versions: 1.0.0 > Environment: Any. >Reporter: John de Roo >Priority: Minor > Labels: features, newbie > Fix For: 1.0.0 > > Attachments: Proposal for a common transactional API for HBase > v0.3_1.pdf, Proposal for a common transactional API for HBase v0.4_1.pdf, Re > Proposal for a generic transaction API for HBase.htm > > > HBase transaction management today is provided by a number of products, each > implementing a different API, each having different strengths. The lack of a > common API for transactional interfaces means that applications need to be > coded to work with a specific Transaction Manager. This proposal outlines an > API which, if implemented by the different Transaction Manager vendors would > provide stability and choice to HBase application developers. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
[ https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058330#comment-14058330 ] Ted Yu commented on HBASE-11447: bq. a TransactionTable can only be associated with a single transaction at any point in time. That's my understanding too. > Proposal for a generic transaction API for HBase > > > Key: HBASE-11447 > URL: https://issues.apache.org/jira/browse/HBASE-11447 > Project: HBase > Issue Type: New Feature > Components: Client >Affects Versions: 1.0.0 > Environment: Any. >Reporter: John de Roo >Priority: Minor > Labels: features, newbie > Fix For: 1.0.0 > > Attachments: Proposal for a common transactional API for HBase > v0.3_1.pdf, Proposal for a common transactional API for HBase v0.4_1.pdf, Re > Proposal for a generic transaction API for HBase.htm > > > HBase transaction management today is provided by a number of products, each > implementing a different API, each having different strengths. The lack of a > common API for transactional interfaces means that applications need to be > coded to work with a specific Transaction Manager. This proposal outlines an > API which, if implemented by the different Transaction Manager vendors would > provide stability and choice to HBase application developers. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058320#comment-14058320 ] Hudson commented on HBASE-11496: SUCCESS: Integrated in HBase-0.98 #385 (See [https://builds.apache.org/job/HBase-0.98/385/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 86033abef298b4ff3397dac732ad1ab22fc22376) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058319#comment-14058319 ] Hudson commented on HBASE-9745: --- SUCCESS: Integrated in HBase-0.98 #385 (See [https://builds.apache.org/job/HBase-0.98/385/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 86033abef298b4ff3397dac732ad1ab22fc22376) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058317#comment-14058317 ] Hudson commented on HBASE-11496: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #365 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/365/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 86033abef298b4ff3397dac732ad1ab22fc22376) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058316#comment-14058316 ] Hudson commented on HBASE-9745: --- SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #365 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/365/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 86033abef298b4ff3397dac732ad1ab22fc22376) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[ https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-11497: --- Fix Version/s: 2.0.0 0.98.4 0.99.0 Assignee: Jesse Yates > Expose RpcScheduling implementations as Public Interfaces > - > > Key: HBASE-11497 > URL: https://issues.apache.org/jira/browse/HBASE-11497 > Project: HBase > Issue Type: Improvement > Components: io, regionserver, Usability >Affects Versions: 0.99.0, 0.98.4 >Reporter: Jesse Yates >Assignee: Jesse Yates > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: hbase-11497-0.98-v0.patch > > > In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by > adding custom RPC handlers (so regular puts/reads don't interfere with index > updates). However, we've run into a couple of snags where the interfaces > change, making it a bit more difficult to support interoperability between > minor versions as the underlying RPC handling changed (for the better, but > still different :). > This would just mark those interfaces Public, Evolving, so we still have some > flexibility, but don't break existing usage. > Note, this kind of thing will come up for any client who is doing custom RPC > handling - beyond the recently added flexibility - but wants to stay in line > with the current HBase implementation (rather than building their own RPC > handling mechanisms). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
[ https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058311#comment-14058311 ] John de Roo commented on HBASE-11447: - Thanks Shengzhe, good feedback. 1 & 2. I'll add more details to define the transaction states. I took them from JTA. They could be rationalized for our use - we don't need MARKED_ROLLBACK for example. However, I expect TMs will only provide those states which it makes sense for them to report. I'll add a comment to that effect. I don't want to remove them completely though because we really want applications to be able to have some consistency regarding what is returned by getStatus. It may be that transient states such as PREPARING are omitted by some TMs or have different timing windows, but the application needs to be able to tell the difference between the main states like ACTIVE, COMMITTING and ROLLING_BACK in an implementation independent manner. The actual mapping between a particular TMs internal states and these TransactionStatus values is up to the TM to decide. 3. Did you want to remove the static keyword? I made all the methods static after removing the begin transaction function from TransactionServiceClient and also removed the factory method as the remaining methods are all global - we don't need to instantiate a TransactionServiceClient for them. Perhaps you see something here that I'm missing? 4. I agree with you here, I didn't put enough thought into moving the begin methods out of the TransactionServiceClient interface into Transaction. I'll change it to an abstract base class. It would be nice to do without the parameters, but allowing a setter/getter approach would allow an application to change or set things like isolation level and transaction type part-way through a transaction which is very hard to implement at a TM level and could actually cause problems - for example changing a write-read transaction to read-only or moving to a higher isolation level. 5. I've used exceptions exclusively. Originally these where checked exceptions, but I just changed them to unchecked, so returning a status on rollback and commit might be a useful addition. 6. Good catch - I should have removed this method. It comes originally from the JTA spec, but I decided it was unnecessary during a transaction - better to set it on the begin. Originally I had the parameter defined as seconds, but changed it to timeout to make the parameters easier to read. BTW seconds seems very short for transaction timeouts - minutes might be a better metric. I'll compromise and define a TransactionTimeout type (probably just int) and change the parameter back to the unit - probably still seconds unless you think I should change it. 7. Could you expand on this idea? I certainly agree that a byte array is a bit basic. 8. Hmm, interesting. I'm not sure here whether I've confused you in the document or, perhaps, I am. As I see it, a TransactionTable can only be associated with a single transaction at any point in time. setTransaction seems appropriate because it if setTransaction is called when the TransactionTable is associated with a transaction, then the table becomes associated with the new transaction and is disassociated with the prior transaction. We have no nesting either as I wanted to keep the API as simple as possible. I know only a little about Themis. I took a look at the API to ensure that it should be possible to map it to the proposal. It's an interesting approach that I'd love to know more about. Are you based in the SF Bay Area? I'm there for the next 2 weeks, and, if you're local, it would be great to get in touch. I'll update the paper in the next few days, but there might be a little delay as I'm travelling to the US on Sunday. > Proposal for a generic transaction API for HBase > > > Key: HBASE-11447 > URL: https://issues.apache.org/jira/browse/HBASE-11447 > Project: HBase > Issue Type: New Feature > Components: Client >Affects Versions: 1.0.0 > Environment: Any. >Reporter: John de Roo >Priority: Minor > Labels: features, newbie > Fix For: 1.0.0 > > Attachments: Proposal for a common transactional API for HBase > v0.3_1.pdf, Proposal for a common transactional API for HBase v0.4_1.pdf, Re > Proposal for a generic transaction API for HBase.htm > > > HBase transaction management today is provided by a number of products, each > implementing a different API, each having different strengths. The lack of a > common API for transactional interfaces means that applications need to be > coded to work with a specific Transaction Manager. This proposal outlines an > API which, if implemented by the different Transa
[jira] [Commented] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[ https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058309#comment-14058309 ] Andrew Purtell commented on HBASE-11497: +1 for 0.98 and trunk, ping [~enis] for branch-1 > Expose RpcScheduling implementations as Public Interfaces > - > > Key: HBASE-11497 > URL: https://issues.apache.org/jira/browse/HBASE-11497 > Project: HBase > Issue Type: Improvement > Components: io, regionserver, Usability >Affects Versions: 0.99.0, 0.98.4 >Reporter: Jesse Yates > Attachments: hbase-11497-0.98-v0.patch > > > In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by > adding custom RPC handlers (so regular puts/reads don't interfere with index > updates). However, we've run into a couple of snags where the interfaces > change, making it a bit more difficult to support interoperability between > minor versions as the underlying RPC handling changed (for the better, but > still different :). > This would just mark those interfaces Public, Evolving, so we still have some > flexibility, but don't break existing usage. > Note, this kind of thing will come up for any client who is doing custom RPC > handling - beyond the recently added flexibility - but wants to stay in line > with the current HBase implementation (rather than building their own RPC > handling mechanisms). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11492) The servers do not honor the tcpNoDelay option
[
https://issues.apache.org/jira/browse/HBASE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058307#comment-14058307
]
Liang Xie commented on HBASE-11492:
---
I have no more knowledge on this area, but i could not convince me to believe
the original "socket().setTcpNoDelay" style did not take effect, since HDFS +
HBase always use this style, right? so weird, my god...
> The servers do not honor the tcpNoDelay option
> --
>
> Key: HBASE-11492
> URL: https://issues.apache.org/jira/browse/HBASE-11492
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.92.2, 0.98.0, 0.96.0, 0.99.0, 0.94.20
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Critical
> Fix For: 0.99.0, 0.98.5
>
> Attachments: 11492.v1.patch
>
>
> There is an option to set tcpNoDelay, defaulted to true, but the socket
> channel is actually not changed. As a consequence, the server works with
> nagle enabled. This leads to very degraded behavior when a single connection
> is shared between threads. We enter into conflicts with nagle and tcp delayed
> ack.
> Here is an example of performance with the PE tool plus HBASE-11491:
> {noformat}
> oneCon #client sleep exeTime (seconds)
> avg latency, sleep excluded (microseconds)
> true 1 031
> 310
> false 1 031
> 310
> true 2 050
> 500
> false 2 0 31
> 310
> true 25 488 (including 200s sleeping)
> 2880
> false 2 5 246 (including 200s sleeping)
> 460
> {noformat}
> The latency is multiple by 5 (2880 vs 460) when the connection is shared.
> This is the delayed ack kicking in. This can be fixed by really using tcp no
> delay.
> Any application sharing the tcp connection between threads has the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-11501: --- Affects Version/s: (was: 0.98.3) 2.0.0 > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 2.0.0 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch, HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[ https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-11497: Attachment: hbase-11497-0.98-v0.patch This labels the classes you would need to custom implement RPC handling and exposes the elements you would need (from default -> public). > Expose RpcScheduling implementations as Public Interfaces > - > > Key: HBASE-11497 > URL: https://issues.apache.org/jira/browse/HBASE-11497 > Project: HBase > Issue Type: Improvement > Components: io, regionserver, Usability >Affects Versions: 0.99.0, 0.98.4 >Reporter: Jesse Yates > Attachments: hbase-11497-0.98-v0.patch > > > In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by > adding custom RPC handlers (so regular puts/reads don't interfere with index > updates). However, we've run into a couple of snags where the interfaces > change, making it a bit more difficult to support interoperability between > minor versions as the underlying RPC handling changed (for the better, but > still different :). > This would just mark those interfaces Public, Evolving, so we still have some > flexibility, but don't break existing usage. > Note, this kind of thing will come up for any client who is doing custom RPC > handling - beyond the recently added flexibility - but wants to stay in line > with the current HBase implementation (rather than building their own RPC > handling mechanisms). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-11495) Support managing REST server as a deamon process
[ https://issues.apache.org/jira/browse/HBASE-11495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-11495. Resolution: Invalid The REST server can be launched and managed as a daemon. Please ask for help on u...@hbase.apache.org > Support managing REST server as a deamon process > > > Key: HBASE-11495 > URL: https://issues.apache.org/jira/browse/HBASE-11495 > Project: HBase > Issue Type: Improvement >Reporter: nijel > > Now in HBase the REST server is started as a non daemon process. > It will be better it is supported as process from hbase-daemon.sh > Also can support stop and autorestart commands for REST server. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058300#comment-14058300 ] Hudson commented on HBASE-9745: --- SUCCESS: Integrated in HBase-TRUNK #5285 (See [https://builds.apache.org/job/HBase-TRUNK/5285/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev d289eecd2f3694cef8571ded4a065ff00161980d) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058301#comment-14058301 ] Hudson commented on HBASE-11496: SUCCESS: Integrated in HBase-TRUNK #5285 (See [https://builds.apache.org/job/HBase-TRUNK/5285/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev d289eecd2f3694cef8571ded4a065ff00161980d) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11437) Modify cell tag handling code to treat the length as unsigned
[ https://issues.apache.org/jira/browse/HBASE-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-11437: --- Fix Version/s: (was: 0.98.5) 0.98.4 bq. Can we get this in for 0.98.4 itself. +1, updated the fix version > Modify cell tag handling code to treat the length as unsigned > - > > Key: HBASE-11437 > URL: https://issues.apache.org/jira/browse/HBASE-11437 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11437.patch, HBASE-11437.patch, HBASE-11437.patch, > HBASE-11437_trunk.patch > > > We store each tag's length and total tags length with 2 bytes in KeyValue > buffer, HFiles etc and we treat these lengths as short through out the code. > So the max length can be Short.MAX_VALUE. We can treat these lengths as > unsigned and +ve always. So we can actually treat these lengths as int and > store with 2 bytes so that the max length can reach 65535. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11118) non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.Literal
[ https://issues.apache.org/jira/browse/HBASE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058281#comment-14058281 ] Andrew Purtell commented on HBASE-8: This issue seems stuck on Maven/repo madness. We think we have a patch that fixes the issue, it has a +1, so I am going to commit this tomorrow so we can make forward progress and get out a 0.98.4 release, unless someone vetoes between now and then. Confirmation would be great but the snapshot repos have not been working out. We can verify through normal Maven channels with .4. > non environment variable solution for "IllegalAccessError: class > com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass > com.google.protobuf.LiteralByteString" > -- > > Key: HBASE-8 > URL: https://issues.apache.org/jira/browse/HBASE-8 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.2 >Reporter: André Kelpe >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: 8.098-0.txt, 8.098.txt, 8.bytestringer.txt, > 1118.suggested.undoing.optimization.on.clientside.txt, > 1118.suggested.undoing.optimization.on.clientside.txt, > HBASE-8-0.98.00.patch, HBASE-8-0.98.01.patch, > HBASE-8-0.98.02.patch, HBASE-8-0.98.patch.gz, > HBASE-8-trunk.patch.gz, HBASE-8.00.patch, HBASE-8.01.patch, > HBASE-8.02.patch, shade_attempt.patch > > > I am running into the problem described in > https://issues.apache.org/jira/browse/HBASE-10304, while trying to use a > newer version within cascading.hbase > (https://github.com/cascading/cascading.hbase). > One of the features of cascading.hbase is that you can use it from lingual > (http://www.cascading.org/projects/lingual/), our SQL layer for hadoop. > lingual has a notion of providers, which are fat jars that we pull down > dynamically at runtime. Those jars give users the ability to talk to any > system or format from SQL. They are added to the classpath programmatically > before we submit jobs to a hadoop cluster. > Since lingual does not know upfront , which providers are going to be used in > a given run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really > clunky and breaks the ease of use we had before. No other provider requires > this right now. > It would be great to have a programmatical way to fix this, when using fat > jars. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11437) Modify cell tag handling code to treat the length as unsigned
[ https://issues.apache.org/jira/browse/HBASE-11437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058277#comment-14058277 ] Anoop Sam John commented on HBASE-11437: [~apurtell] Can we get this in for 0.98.4 itself. My initial plan was to make it for 0.98.5 only. Now the 0.98.4 RC cut got delayed due to other issues. > Modify cell tag handling code to treat the length as unsigned > - > > Key: HBASE-11437 > URL: https://issues.apache.org/jira/browse/HBASE-11437 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 0.99.0, 0.98.5, 2.0.0 > > Attachments: HBASE-11437.patch, HBASE-11437.patch, HBASE-11437.patch, > HBASE-11437_trunk.patch > > > We store each tag's length and total tags length with 2 bytes in KeyValue > buffer, HFiles etc and we treat these lengths as short through out the code. > So the max length can be Short.MAX_VALUE. We can treat these lengths as > unsigned and +ve always. So we can actually treat these lengths as int and > store with 2 bytes so that the max length can reach 65535. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11256) [Visibility Controller] Enhance IntegrationTestWithCellVisibilityLoadAndVerify to verify delete behaviour
[ https://issues.apache.org/jira/browse/HBASE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058269#comment-14058269 ] Anoop Sam John commented on HBASE-11256: IMO also HBASE-11039 is good enough. > [Visibility Controller] Enhance > IntegrationTestWithCellVisibilityLoadAndVerify to verify delete behaviour > - > > Key: HBASE-11256 > URL: https://issues.apache.org/jira/browse/HBASE-11256 > Project: HBase > Issue Type: Test >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 0.99.0, 1.0.0, 0.98.4 > > Attachments: HBASE-11039_1.patch, HBASE-11256_2.patch > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058264#comment-14058264 ] Hudson commented on HBASE-11496: SUCCESS: Integrated in HBase-0.94-JDK7 #152 (See [https://builds.apache.org/job/HBase-0.94-JDK7/152/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 24f150ebbc132baf99022cbdd1b28fa7842522f7) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-11423: --- Attachment: HBASE-11423_v2.patch Reattaching same patch for a QA run. TestCacheConfig passing locally. Getting random failures in QA runs. (here and other patches). Let us see what QA says now. Thanks for the reviews Andy, Lars, Ram. Will commit after QA run > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_v2.patch, > HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058265#comment-14058265 ] Anoop Sam John commented on HBASE-11423: The inconsistency of MultiRowMutation from HRegion#batchMutate() wrt CP hook,s looks to be a bug for me. I will work on a patch for that issue and attach in another Jira. > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_v2.patch, > HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058263#comment-14058263 ] Hudson commented on HBASE-9745: --- SUCCESS: Integrated in HBase-0.94-JDK7 #152 (See [https://builds.apache.org/job/HBase-0.94-JDK7/152/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 24f150ebbc132baf99022cbdd1b28fa7842522f7) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-11423: --- Attachment: (was: HBASE-11423_v2.patch) > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058260#comment-14058260 ] Hudson commented on HBASE-11496: SUCCESS: Integrated in HBase-0.94 #1384 (See [https://builds.apache.org/job/HBase-0.94/1384/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 24f150ebbc132baf99022cbdd1b28fa7842522f7) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058259#comment-14058259 ] Hudson commented on HBASE-9745: --- SUCCESS: Integrated in HBase-0.94 #1384 (See [https://builds.apache.org/job/HBase-0.94/1384/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 24f150ebbc132baf99022cbdd1b28fa7842522f7) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11502) Track down broken images in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058257#comment-14058257 ] Misty Stanley-Jones commented on HBASE-11502: - I got it, it's a typo. The file is called ./src/main/site/resources/images/timeline_consitency.png. I will rename it. > Track down broken images in Ref Guide > - > > Key: HBASE-11502 > URL: https://issues.apache.org/jira/browse/HBASE-11502 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > > I realized that image support was broken in the Ref Guide. I fixed it by > making some changes to the pom.xml (in HBASE-11400). I need to track down > what images are broken besides the new ones I added, find out where they are, > and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11502) Track down broken images in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058256#comment-14058256 ] Misty Stanley-Jones commented on HBASE-11502: - [~enis] did you make that change on purpose? Did you want to add a new image instead of the hfile.png? > Track down broken images in Ref Guide > - > > Key: HBASE-11502 > URL: https://issues.apache.org/jira/browse/HBASE-11502 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > > I realized that image support was broken in the Ref Guide. I fixed it by > making some changes to the pom.xml (in HBASE-11400). I need to track down > what images are broken besides the new ones I added, find out where they are, > and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11502) Track down broken images in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058253#comment-14058253 ] Misty Stanley-Jones commented on HBASE-11502: - Change was introduced in commit e50811a7ab21069ad941eeebd81c2d3d9ee98c00 Author: Enis Soztutar Date: Thu May 15 23:38:45 2014 + HBASE-10513 Provide user documentation for region replicas git-svn-id: https://svn.apache.org/repos/asf/hbase/branches/hbase-10070@1595077 13f79535-47bb-0310-9956-ffa450edef68 I will explore this more. > Track down broken images in Ref Guide > - > > Key: HBASE-11502 > URL: https://issues.apache.org/jira/browse/HBASE-11502 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > > I realized that image support was broken in the Ref Guide. I fixed it by > making some changes to the pom.xml (in HBASE-11400). I need to track down > what images are broken besides the new ones I added, find out where they are, > and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11367) Pluggable replication endpoint
[
https://issues.apache.org/jira/browse/HBASE-11367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058249#comment-14058249
]
Hadoop QA commented on HBASE-11367:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655122/hbase-11367_v4.patch
against trunk revision .
ATTACHMENT ID: 12655122
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 22 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 findbugs{color}. The patch appears to introduce 4 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.replication.TestReplicationEndpoint
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
at
org.apache.hadoop.hbase.client.TestReplicaWithCluster.testCreateDeleteTable(TestReplicaWithCluster.java:138)
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10030//console
This message is automatically generated.
> Pluggable replication endpoint
> --
>
> Key: HBASE-11367
> URL: https://issues.apache.org/jira/browse/HBASE-11367
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>Priority: Blocker
> Fix For: 0.99.0
>
> Attachments: 0001-11367.patch, hbase-11367_v1.patch,
> hbase-11367_v2.patch, hbase-11367_v3.patch, hbase-11367_v4.patch,
> hbase-11367_v4.patch
>
>
> We need a pluggable endpoint for replication for more flexibility. See parent
> jira for more context.
> ReplicationSource tails the logs for each peer. This jira introduces
> ReplicationEndpoint which is customizable per peer. ReplicationEndpoint is
> run in the same RS process and instantiated per replication peer per region
> server. Implementations of this interface handle the actual shipping of WAL
> edits to the remote cluster.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058241#comment-14058241 ] Hudson commented on HBASE-11496: FAILURE: Integrated in HBase-0.94-security #497 (See [https://builds.apache.org/job/HBase-0.94-security/497/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 24f150ebbc132baf99022cbdd1b28fa7842522f7) * bin/hbase > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-9745) Append HBASE_CLASSPATH to end of Java classpath and use another env var for prefix
[ https://issues.apache.org/jira/browse/HBASE-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058240#comment-14058240 ] Hudson commented on HBASE-9745: --- FAILURE: Integrated in HBase-0.94-security #497 (See [https://builds.apache.org/job/HBase-0.94-security/497/]) HBASE-11496 HBASE-9745 broke cygwin CLASSPATH translation (Dave Latham) (apurtell: rev 24f150ebbc132baf99022cbdd1b28fa7842522f7) * bin/hbase > Append HBASE_CLASSPATH to end of Java classpath and use another env var for > prefix > -- > > Key: HBASE-9745 > URL: https://issues.apache.org/jira/browse/HBASE-9745 > Project: HBase > Issue Type: Bug > Components: scripts >Affects Versions: 0.98.0, 0.95.2, 0.94.11 >Reporter: Aditya Kishore >Assignee: Aditya Kishore > Labels: scripts > Fix For: 0.98.0, 0.94.13, 0.96.1 > > Attachments: HBASE-9745.patch, HBASE-9745_v2.patch > > > HBASE-9097 changed the behavior to prefix HBASE_CLASSPATH to end of Java > classpath instead of appending it. This break existing behavior (read more on > HBASE-9097). > We should revert to existing behavior and provide another way to prefix > certain jars to the classpath. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11502) Track down broken images in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058234#comment-14058234 ] Misty Stanley-Jones commented on HBASE-11502: - The timeline_consistency.png should actually be hfile.png but was changed at some point (I verified at commit 8943f02ff8bc57b1580364f01e3559c793e9cad8 which was in Sep 2013). Going to do a bit of checking and see when it changed but will probalby just change it back. > Track down broken images in Ref Guide > - > > Key: HBASE-11502 > URL: https://issues.apache.org/jira/browse/HBASE-11502 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > > I realized that image support was broken in the Ref Guide. I fixed it by > making some changes to the pom.xml (in HBASE-11400). I need to track down > what images are broken besides the new ones I added, find out where they are, > and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11502) Track down broken images in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058224#comment-14058224 ] Misty Stanley-Jones commented on HBASE-11502: - The timeline_consistency.png file is missing. I'll see if I can find it elsewhere and put it back. The others are just in the site/ directory and need to be copied to the docbkx/ directory. It's best not to try to single-source images between the website and the book for simplicity. > Track down broken images in Ref Guide > - > > Key: HBASE-11502 > URL: https://issues.apache.org/jira/browse/HBASE-11502 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > > I realized that image support was broken in the Ref Guide. I fixed it by > making some changes to the pom.xml (in HBASE-11400). I need to track down > what images are broken besides the new ones I added, find out where they are, > and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11502) Track down broken images in Ref Guide
[ https://issues.apache.org/jira/browse/HBASE-11502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058223#comment-14058223 ] Misty Stanley-Jones commented on HBASE-11502: - Mistys-MacBook-Pro:docbkx misty$ grep "fileref" * book.xml: fileref="hbase_logo.png" /> book.xml:fileref="timeline_consistency.png" /> book.xml: book.xml: book.xml.orig: fileref="hbase_logo.png" /> book.xml.orig: book.xml.orig: book.xml.orig: > Track down broken images in Ref Guide > - > > Key: HBASE-11502 > URL: https://issues.apache.org/jira/browse/HBASE-11502 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > > I realized that image support was broken in the Ref Guide. I fixed it by > making some changes to the pom.xml (in HBASE-11400). I need to track down > what images are broken besides the new ones I added, find out where they are, > and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11502) Track down broken images in Ref Guide
Misty Stanley-Jones created HBASE-11502: --- Summary: Track down broken images in Ref Guide Key: HBASE-11502 URL: https://issues.apache.org/jira/browse/HBASE-11502 Project: HBase Issue Type: Bug Components: documentation Reporter: Misty Stanley-Jones Assignee: Misty Stanley-Jones I realized that image support was broken in the Ref Guide. I fixed it by making some changes to the pom.xml (in HBASE-11400). I need to track down what images are broken besides the new ones I added, find out where they are, and make them work again. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058212#comment-14058212 ] Virag Kothari commented on HBASE-11501: --- Without the fix, the JmxCacheBusterRunnable is never called and metrics are not removed from cache. With the fix, the metrics will be removed as the runnable will run and will stop the metrics system (DefaultMetricsSystem.instance().stop()). However when it tries to start the metrics system ( DefaultMetricsSystem.instance().start()), it cant register the mbeans with the same name as before due to Hadoop-9559. This will cause the metrics system to even stop publishing metrics. So, running on hadoop 2.4 with this fix will do more harm than good. So either it should go with hadoop 2.5 or if Hadoop-9559 is backported to 2.4 (and other versions if required), then I believe this patch can go in before. > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.98.3 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch, HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[ https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058175#comment-14058175 ] Jesse Yates commented on HBASE-11497: - That seems reasonable. I'll put together a patch > Expose RpcScheduling implementations as Public Interfaces > - > > Key: HBASE-11497 > URL: https://issues.apache.org/jira/browse/HBASE-11497 > Project: HBase > Issue Type: Improvement > Components: io, regionserver, Usability >Affects Versions: 0.99.0, 0.98.4 >Reporter: Jesse Yates > > In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by > adding custom RPC handlers (so regular puts/reads don't interfere with index > updates). However, we've run into a couple of snags where the interfaces > change, making it a bit more difficult to support interoperability between > minor versions as the underlying RPC handling changed (for the better, but > still different :). > This would just mark those interfaces Public, Evolving, so we still have some > flexibility, but don't break existing usage. > Note, this kind of thing will come up for any client who is doing custom RPC > handling - beyond the recently added flexibility - but wants to stay in line > with the current HBase implementation (rather than building their own RPC > handling mechanisms). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058174#comment-14058174 ] Ted Yu commented on HBASE-11501: bq. I was hit with HADOOP-9559 as I was running on Hadoop-2.4 Does this mean this fix needs to go with hadoop 2.5 ? > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.98.3 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch, HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11367) Pluggable replication endpoint
[ https://issues.apache.org/jira/browse/HBASE-11367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-11367: -- Attachment: hbase-11367_v4.patch hadoopqa seems broken with p0 patches. Giri changed the build nodes, so maybe the bash version is causing some problems. Anyway, attaching -p1 patch. > Pluggable replication endpoint > -- > > Key: HBASE-11367 > URL: https://issues.apache.org/jira/browse/HBASE-11367 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar >Priority: Blocker > Fix For: 0.99.0 > > Attachments: 0001-11367.patch, hbase-11367_v1.patch, > hbase-11367_v2.patch, hbase-11367_v3.patch, hbase-11367_v4.patch, > hbase-11367_v4.patch > > > We need a pluggable endpoint for replication for more flexibility. See parent > jira for more context. > ReplicationSource tails the logs for each peer. This jira introduces > ReplicationEndpoint which is customizable per peer. ReplicationEndpoint is > run in the same RS process and instantiated per replication peer per region > server. Implementations of this interface handle the actual shipping of WAL > edits to the remote cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-11496: --- Resolution: Fixed Fix Version/s: 2.0.0 0.98.4 0.96.3 0.99.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Committed to 0.94+. > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.99.0, 0.96.3, 0.98.4, 0.94.22, 2.0.0 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11501) Metrics from JMX cache are not cleared
[
https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058166#comment-14058166
]
Hadoop QA commented on HBASE-11501:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655105/HBASE-11501.patch
against trunk revision .
ATTACHMENT ID: 12655105
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 findbugs{color}. The patch appears to introduce 4 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10027//console
This message is automatically generated.
> Metrics from JMX cache are not cleared
> --
>
> Key: HBASE-11501
> URL: https://issues.apache.org/jira/browse/HBASE-11501
> Project: HBase
> Issue Type: Bug
> Components: metrics
>Affects Versions: 0.98.3
>Reporter: Virag Kothari
>Assignee: Virag Kothari
> Attachments: HBASE-11501.patch, HBASE-11501.patch
>
>
> In JmxCacheBuster, clearJmxCache() has incorrect condition for starting
> JmxCacheBusterRunnable
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[
https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058160#comment-14058160
]
Andrew Purtell commented on HBASE-11497:
bq. It seems like a LimitedPrivate with either Coprocessors or similar
audience would be a better target.
{code}
@InterfaceAudience.LimitedPrivate({"Coprocessor","Phoenix"})
{code}
could work as long as the RM checks with the designated users. For 0.98 I can
definitely do that. What do you think [~jesse_yates]?
> Expose RpcScheduling implementations as Public Interfaces
> -
>
> Key: HBASE-11497
> URL: https://issues.apache.org/jira/browse/HBASE-11497
> Project: HBase
> Issue Type: Improvement
> Components: io, regionserver, Usability
>Affects Versions: 0.99.0, 0.98.4
>Reporter: Jesse Yates
>
> In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by
> adding custom RPC handlers (so regular puts/reads don't interfere with index
> updates). However, we've run into a couple of snags where the interfaces
> change, making it a bit more difficult to support interoperability between
> minor versions as the underlying RPC handling changed (for the better, but
> still different :).
> This would just mark those interfaces Public, Evolving, so we still have some
> flexibility, but don't break existing usage.
> Note, this kind of thing will come up for any client who is doing custom RPC
> handling - beyond the recently added flexibility - but wants to stay in line
> with the current HBase implementation (rather than building their own RPC
> handling mechanisms).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11497) Expose RpcScheduling implementations as Public Interfaces
[ https://issues.apache.org/jira/browse/HBASE-11497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058155#comment-14058155 ] Enis Soztutar commented on HBASE-11497: --- I would refrain from adding InterfaceAudience.Public to the RPC handler interfaces. Regular clients are not going to implement / use those. It seems like a LimitedPrivate with either Coprocessors or similar audience would be a better target. > Expose RpcScheduling implementations as Public Interfaces > - > > Key: HBASE-11497 > URL: https://issues.apache.org/jira/browse/HBASE-11497 > Project: HBase > Issue Type: Improvement > Components: io, regionserver, Usability >Affects Versions: 0.99.0, 0.98.4 >Reporter: Jesse Yates > > In PHOENIX-938 we are attempting to resolve cross-RS deadlocks in indexing by > adding custom RPC handlers (so regular puts/reads don't interfere with index > updates). However, we've run into a couple of snags where the interfaces > change, making it a bit more difficult to support interoperability between > minor versions as the underlying RPC handling changed (for the better, but > still different :). > This would just mark those interfaces Public, Evolving, so we still have some > flexibility, but don't break existing usage. > Note, this kind of thing will come up for any client who is doing custom RPC > handling - beyond the recently added flexibility - but wants to stay in line > with the current HBase implementation (rather than building their own RPC > handling mechanisms). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (HBASE-11494) RegionServer throws Exception when response is too long
[
https://issues.apache.org/jira/browse/HBASE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar resolved HBASE-11494.
---
Resolution: Not a Problem
> RegionServer throws Exception when response is too long
> ---
>
> Key: HBASE-11494
> URL: https://issues.apache.org/jira/browse/HBASE-11494
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
> Environment: HDP 2.1, REHL 6.0
>Reporter: Roger Xu
>
> Table’s cell having a large number of versions, it works fine when I read
> 100K VERSIONS from the cell, but regionServer gives exception when I
> attempted to read upto 1M VERSIONS. error happens with both hbase shell , and
> happy base client
> 2014-07-10 10:45:30,098 WARN [RpcServer.handler=47,port=60020] ipc.RpcServer:
> (responseTooLarge):
> {“processingtimems”:104,”call”:”Get(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$GetRequest)”,”client”:”17.203.54.172:56290″,”starttimems”:1405014329979,”queuetimems”:0,”class”:”HRegionServer”,”responsesize”:157334052,”method”:”Get”}
> 2014-07-10 10:45:30,923 INFO [RpcServer.reader=6,port=60020] ipc.RpcServer:
> RpcServer.listener,port=60020: count of bytes read: 0
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> at org.apache.hadoop.hbase.ipc.RpcServer.channelRead(RpcServer.java:2224)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Connection.readAndProcess(RpcServer.java:1415)
> at org.apache.hadoop.hbase.ipc.RpcServer$Listener.doRead(RpcServer.java:790)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.doRunLoop(RpcServer.java:581)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.run(RpcServer.java:556)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-07-10 10:45:30,923 WARN [RpcServer.responder] ipc.RpcServer:
> RpcServer.respondercallId: 93 service: ClientService methodName: Get size:
> 225 connection: 17.203.54.172:56290: output error
> 2014-07-10 10:45:30,924 INFO [RpcServer.responder] ipc.RpcServer:
> RpcServer.responder: asyncWrite
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.writev0(Native Method)
> at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51)
> at sun.nio.ch.IOUtil.write(IOUtil.java:148)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524)
> at org.apache.hadoop.hbase.ipc.BufferChain.write(BufferChain.java:106)
> at org.apache.hadoop.hbase.ipc.RpcServer.channelWrite(RpcServer.java:2204)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1004)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doAsyncWrite(RpcServer.java:944)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRunLoop(RpcServer.java:873)
> at org.apache.hadoop.hbase.ipc.RpcServer$Responder.run(RpcServer.java:849)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11494) RegionServer throws Exception when response is too long
[
https://issues.apache.org/jira/browse/HBASE-11494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058152#comment-14058152
]
Enis Soztutar commented on HBASE-11494:
---
There is no streaming rpc or scanner like streaming for gets with multiple
versions. If you are using a lot of versions, you should restrict the number of
versions returned and do windowing from client side.
> RegionServer throws Exception when response is too long
> ---
>
> Key: HBASE-11494
> URL: https://issues.apache.org/jira/browse/HBASE-11494
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
> Environment: HDP 2.1, REHL 6.0
>Reporter: Roger Xu
>
> Table’s cell having a large number of versions, it works fine when I read
> 100K VERSIONS from the cell, but regionServer gives exception when I
> attempted to read upto 1M VERSIONS. error happens with both hbase shell , and
> happy base client
> 2014-07-10 10:45:30,098 WARN [RpcServer.handler=47,port=60020] ipc.RpcServer:
> (responseTooLarge):
> {“processingtimems”:104,”call”:”Get(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$GetRequest)”,”client”:”17.203.54.172:56290″,”starttimems”:1405014329979,”queuetimems”:0,”class”:”HRegionServer”,”responsesize”:157334052,”method”:”Get”}
> 2014-07-10 10:45:30,923 INFO [RpcServer.reader=6,port=60020] ipc.RpcServer:
> RpcServer.listener,port=60020: count of bytes read: 0
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379)
> at org.apache.hadoop.hbase.ipc.RpcServer.channelRead(RpcServer.java:2224)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Connection.readAndProcess(RpcServer.java:1415)
> at org.apache.hadoop.hbase.ipc.RpcServer$Listener.doRead(RpcServer.java:790)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.doRunLoop(RpcServer.java:581)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Listener$Reader.run(RpcServer.java:556)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-07-10 10:45:30,923 WARN [RpcServer.responder] ipc.RpcServer:
> RpcServer.respondercallId: 93 service: ClientService methodName: Get size:
> 225 connection: 17.203.54.172:56290: output error
> 2014-07-10 10:45:30,924 INFO [RpcServer.responder] ipc.RpcServer:
> RpcServer.responder: asyncWrite
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.writev0(Native Method)
> at sun.nio.ch.SocketDispatcher.writev(SocketDispatcher.java:51)
> at sun.nio.ch.IOUtil.write(IOUtil.java:148)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:524)
> at org.apache.hadoop.hbase.ipc.BufferChain.write(BufferChain.java:106)
> at org.apache.hadoop.hbase.ipc.RpcServer.channelWrite(RpcServer.java:2204)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.processResponse(RpcServer.java:1004)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doAsyncWrite(RpcServer.java:944)
> at
> org.apache.hadoop.hbase.ipc.RpcServer$Responder.doRunLoop(RpcServer.java:873)
> at org.apache.hadoop.hbase.ipc.RpcServer$Responder.run(RpcServer.java:849)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058150#comment-14058150 ] Andrew Purtell commented on HBASE-11496: I think the existence of this JIRA indicates at least one active cygwin user. I've got no opinion beyond 0.98, where I think we should leave it in. Will commit shortly. > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.94.22 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11367) Pluggable replication endpoint
[
https://issues.apache.org/jira/browse/HBASE-11367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058145#comment-14058145
]
Hadoop QA commented on HBASE-11367:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655119/hbase-11367_v4.patch
against trunk revision .
ATTACHMENT ID: 12655119
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 22 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10029//console
This message is automatically generated.
> Pluggable replication endpoint
> --
>
> Key: HBASE-11367
> URL: https://issues.apache.org/jira/browse/HBASE-11367
> Project: HBase
> Issue Type: Sub-task
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>Priority: Blocker
> Fix For: 0.99.0
>
> Attachments: 0001-11367.patch, hbase-11367_v1.patch,
> hbase-11367_v2.patch, hbase-11367_v3.patch, hbase-11367_v4.patch
>
>
> We need a pluggable endpoint for replication for more flexibility. See parent
> jira for more context.
> ReplicationSource tails the logs for each peer. This jira introduces
> ReplicationEndpoint which is customizable per peer. ReplicationEndpoint is
> run in the same RS process and instantiated per replication peer per region
> server. Implementations of this interface handle the actual shipping of WAL
> edits to the remote cluster.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058143#comment-14058143 ] Enis Soztutar commented on HBASE-11496: --- +1. But out of curiosity, we have windows scripts (hbase.cmd) now, should we remove cygwin support now? > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.94.22 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11367) Pluggable replication endpoint
[ https://issues.apache.org/jira/browse/HBASE-11367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-11367: -- Attachment: hbase-11367_v4.patch Rebased the patch. [~jdcryans] or any body else up for review this? > Pluggable replication endpoint > -- > > Key: HBASE-11367 > URL: https://issues.apache.org/jira/browse/HBASE-11367 > Project: HBase > Issue Type: Sub-task >Reporter: Enis Soztutar >Assignee: Enis Soztutar >Priority: Blocker > Fix For: 0.99.0 > > Attachments: 0001-11367.patch, hbase-11367_v1.patch, > hbase-11367_v2.patch, hbase-11367_v3.patch, hbase-11367_v4.patch > > > We need a pluggable endpoint for replication for more flexibility. See parent > jira for more context. > ReplicationSource tails the logs for each peer. This jira introduces > ReplicationEndpoint which is customizable per peer. ReplicationEndpoint is > run in the same RS process and instantiated per replication peer per region > server. Implementations of this interface handle the actual shipping of WAL > edits to the remote cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11492) The servers do not honor the tcpNoDelay option
[
https://issues.apache.org/jira/browse/HBASE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058140#comment-14058140
]
Enis Soztutar commented on HBASE-11492:
---
Should we set both of these just in case if this is a JDK issue indeed?
> The servers do not honor the tcpNoDelay option
> --
>
> Key: HBASE-11492
> URL: https://issues.apache.org/jira/browse/HBASE-11492
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.92.2, 0.98.0, 0.96.0, 0.99.0, 0.94.20
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Critical
> Fix For: 0.99.0, 0.98.5
>
> Attachments: 11492.v1.patch
>
>
> There is an option to set tcpNoDelay, defaulted to true, but the socket
> channel is actually not changed. As a consequence, the server works with
> nagle enabled. This leads to very degraded behavior when a single connection
> is shared between threads. We enter into conflicts with nagle and tcp delayed
> ack.
> Here is an example of performance with the PE tool plus HBASE-11491:
> {noformat}
> oneCon #client sleep exeTime (seconds)
> avg latency, sleep excluded (microseconds)
> true 1 031
> 310
> false 1 031
> 310
> true 2 050
> 500
> false 2 0 31
> 310
> true 25 488 (including 200s sleeping)
> 2880
> false 2 5 246 (including 200s sleeping)
> 460
> {noformat}
> The latency is multiple by 5 (2880 vs 460) when the connection is shared.
> This is the delayed ack kicking in. This can be fixed by really using tcp no
> delay.
> Any application sharing the tcp connection between threads has the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11492) The servers do not honor the tcpNoDelay option
[
https://issues.apache.org/jira/browse/HBASE-11492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-11492:
--
Summary: The servers do not honor the tcpNoDelay option (was: The servers
do not honnor the tcpNoDelay option)
> The servers do not honor the tcpNoDelay option
> --
>
> Key: HBASE-11492
> URL: https://issues.apache.org/jira/browse/HBASE-11492
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.92.2, 0.98.0, 0.96.0, 0.99.0, 0.94.20
>Reporter: Nicolas Liochon
>Assignee: Nicolas Liochon
>Priority: Critical
> Fix For: 0.99.0, 0.98.5
>
> Attachments: 11492.v1.patch
>
>
> There is an option to set tcpNoDelay, defaulted to true, but the socket
> channel is actually not changed. As a consequence, the server works with
> nagle enabled. This leads to very degraded behavior when a single connection
> is shared between threads. We enter into conflicts with nagle and tcp delayed
> ack.
> Here is an example of performance with the PE tool plus HBASE-11491:
> {noformat}
> oneCon #client sleep exeTime (seconds)
> avg latency, sleep excluded (microseconds)
> true 1 031
> 310
> false 1 031
> 310
> true 2 050
> 500
> false 2 0 31
> 310
> true 25 488 (including 200s sleeping)
> 2880
> false 2 5 246 (including 200s sleeping)
> 460
> {noformat}
> The latency is multiple by 5 (2880 vs 460) when the connection is shared.
> This is the delayed ack kicking in. This can be fixed by really using tcp no
> delay.
> Any application sharing the tcp connection between threads has the issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11400) Edit, consolidate, and update Compression and data encoding docs
[
https://issues.apache.org/jira/browse/HBASE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058121#comment-14058121
]
Hadoop QA commented on HBASE-11400:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655113/HBASE-11400-2.patch
against trunk revision .
ATTACHMENT ID: 12655113
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10028//console
This message is automatically generated.
> Edit, consolidate, and update Compression and data encoding docs
>
>
> Key: HBASE-11400
> URL: https://issues.apache.org/jira/browse/HBASE-11400
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
>Priority: Minor
> Attachments: HBASE-11400-1.patch, HBASE-11400-2.patch,
> HBASE-11400.patch
>
>
> Current docs are here: http://hbase.apache.org/book.html#compression.test
> It could use some editing and expansion.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11400) Edit, consolidate, and update Compression and data encoding docs
[ https://issues.apache.org/jira/browse/HBASE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058116#comment-14058116 ] Misty Stanley-Jones commented on HBASE-11400: - How do I actually get the images into the diff? Do I need to upload them here and you will put them in the images directory on your end? > Edit, consolidate, and update Compression and data encoding docs > > > Key: HBASE-11400 > URL: https://issues.apache.org/jira/browse/HBASE-11400 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones >Priority: Minor > Attachments: HBASE-11400-1.patch, HBASE-11400-2.patch, > HBASE-11400.patch > > > Current docs are here: http://hbase.apache.org/book.html#compression.test > It could use some editing and expansion. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11400) Edit, consolidate, and update Compression and data encoding docs
[ https://issues.apache.org/jira/browse/HBASE-11400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-11400: Attachment: HBASE-11400-2.patch Addressed feedback from [~j...@cloudera.com], including adding the images (permission pending). As part of adding the images, I also fixed the "mvn site" target so that it is actually possible to use images in the book again. I realize that is a little out of scope for this JIRA but I left it in the patch. I suspect there are lots of broken and thus invisible images in the book currently and will address those elsewhere. > Edit, consolidate, and update Compression and data encoding docs > > > Key: HBASE-11400 > URL: https://issues.apache.org/jira/browse/HBASE-11400 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones >Priority: Minor > Attachments: HBASE-11400-1.patch, HBASE-11400-2.patch, > HBASE-11400.patch > > > Current docs are here: http://hbase.apache.org/book.html#compression.test > It could use some editing and expansion. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11501: -- Attachment: HBASE-11501.patch Seems the precommit build is not accepting patches with git diff --no-prefix. Creating with git diff so patch p1 can be applied. > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.98.3 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch, HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11475) Distributed log replay should also replay compaction events
[ https://issues.apache.org/jira/browse/HBASE-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058051#comment-14058051 ] Hudson commented on HBASE-11475: SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #364 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/364/]) HBASE-11475 Distributed log replay should also replay compaction events (enis: rev d09a5cf4e52961657efb2c7d8ba24a25c0f4b8c4) * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/WALProtos.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALEditsReplaySink.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-server/src/test/java/org/apache/hadoop/hbase/TestIOFencing.java * hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java * hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationSmallTests.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogUtil.java * hbase-protocol/src/main/protobuf/WAL.proto * hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALEdit.java > Distributed log replay should also replay compaction events > --- > > Key: HBASE-11475 > URL: https://issues.apache.org/jira/browse/HBASE-11475 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: hbase-11475_v1.patch, hbase-11475_v2.patch, > hbase-11475_v3-0.98.patch, hbase-11475_v3.patch > > > Compaction events are written to WAL as of HBASE-2231 got committed. However, > it seems that distributed log replay skips those entries without sending it > to the replaying region. In contrast log split replays those. > It seems that we should fix log replay to also replay the compaction events. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11499) AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
[
https://issues.apache.org/jira/browse/HBASE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058044#comment-14058044
]
Hadoop QA commented on HBASE-11499:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655086/HBASE-11499.v2.patch.txt
against trunk revision .
ATTACHMENT ID: 12655086
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 findbugs{color}. The patch appears to introduce 3 new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.io.hfile.TestCacheConfig
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10026//console
This message is automatically generated.
> AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
> -
>
> Key: HBASE-11499
> URL: https://issues.apache.org/jira/browse/HBASE-11499
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Mike Drob
>Priority: Trivial
> Labels: findbugs
> Attachments: HBASE-11499.patch.txt, HBASE-11499.v2.patch.txt
>
>
> The method is building a string using lots of concatenation, including in a
> loop, which will be {{O(n^2)}} because a new array will be allocated each
> time. Would be more efficient to use a StringBuilder for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11475) Distributed log replay should also replay compaction events
[ https://issues.apache.org/jira/browse/HBASE-11475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058035#comment-14058035 ] Hudson commented on HBASE-11475: FAILURE: Integrated in HBase-0.98 #384 (See [https://builds.apache.org/job/HBase-0.98/384/]) HBASE-11475 Distributed log replay should also replay compaction events (enis: rev d09a5cf4e52961657efb2c7d8ba24a25c0f4b8c4) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/WALProtos.java * hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogUtil.java * hbase-protocol/src/main/protobuf/WAL.proto * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALEditsReplaySink.java * hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationSmallTests.java * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/WALEdit.java * hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java * hbase-server/src/test/java/org/apache/hadoop/hbase/TestIOFencing.java > Distributed log replay should also replay compaction events > --- > > Key: HBASE-11475 > URL: https://issues.apache.org/jira/browse/HBASE-11475 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: hbase-11475_v1.patch, hbase-11475_v2.patch, > hbase-11475_v3-0.98.patch, hbase-11475_v3.patch > > > Compaction events are written to WAL as of HBASE-2231 got committed. However, > it seems that distributed log replay skips those entries without sending it > to the replaying region. In contrast log split replays those. > It seems that we should fix log replay to also replay the compaction events. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11118) non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.Literal
[
https://issues.apache.org/jira/browse/HBASE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058003#comment-14058003
]
Nick Dimiduk commented on HBASE-8:
--
Hi [~fs111]. I've "published" a built of this branch. Add the following
repository info and give it another spin. Thanks
{noformat}
apache.people.ndimiduk
http://people.apache.org/~ndimiduk/repository
true
{noformat}
> non environment variable solution for "IllegalAccessError: class
> com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass
> com.google.protobuf.LiteralByteString"
> --
>
> Key: HBASE-8
> URL: https://issues.apache.org/jira/browse/HBASE-8
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.2
>Reporter: André Kelpe
>Priority: Blocker
> Fix For: 0.99.0, 0.98.4, 2.0.0
>
> Attachments: 8.098-0.txt, 8.098.txt, 8.bytestringer.txt,
> 1118.suggested.undoing.optimization.on.clientside.txt,
> 1118.suggested.undoing.optimization.on.clientside.txt,
> HBASE-8-0.98.00.patch, HBASE-8-0.98.01.patch,
> HBASE-8-0.98.02.patch, HBASE-8-0.98.patch.gz,
> HBASE-8-trunk.patch.gz, HBASE-8.00.patch, HBASE-8.01.patch,
> HBASE-8.02.patch, shade_attempt.patch
>
>
> I am running into the problem described in
> https://issues.apache.org/jira/browse/HBASE-10304, while trying to use a
> newer version within cascading.hbase
> (https://github.com/cascading/cascading.hbase).
> One of the features of cascading.hbase is that you can use it from lingual
> (http://www.cascading.org/projects/lingual/), our SQL layer for hadoop.
> lingual has a notion of providers, which are fat jars that we pull down
> dynamically at runtime. Those jars give users the ability to talk to any
> system or format from SQL. They are added to the classpath programmatically
> before we submit jobs to a hadoop cluster.
> Since lingual does not know upfront , which providers are going to be used in
> a given run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really
> clunky and breaks the ease of use we had before. No other provider requires
> this right now.
> It would be great to have a programmatical way to fix this, when using fat
> jars.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
[ https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058002#comment-14058002 ] Shengzhe Yao commented on HBASE-11447: -- 1. Could you please explain TransactionStatus in more details ? It might be super helpful if we can also draw some concrete examples how we gonna to use these status, this provide a guideline for transaction implementor to use correct status in the right way and avoid misinterpretation. 2. As someone mentioned earlier, do we really need to provide TransactionStatus in the public API, could this be implementation specific ? 3. TransactionServiceClient declares all methods as static, could we remove that keyword ? 4. TransactionInterface contains several Transaction(...) methods, looks like all these are constructors. It is better to not include them in the interface, let implementation to decide the proper way to initialize the object. Even if we really want to control the existence of some properties, it is better to define setter&getter or provide a base abstract implementation. 5. Should TransactionInterface.commit() and TransactionInterface.rollback() have return values ? 6. TransactionInterface.setTransactionTimeout should be better to have extra TimeUnit parameter, so that user won't be confused by timeout resolution (the meaning of timeout could be milliseconds, seconds or even hours). 7. TransactionInterface.toByteArray, instead of this, maybe we can add one more method that accepts an OutputStream, so that it might allow more efficient implementation of Transaction serialization. 8. It might be better to replace TransactionTable.setTransaction by TransactionTable.addTransaction, because I think most of time there is not only a single transaction but multiple of them can happen. [~cuijianwei] recently announced a transaction implementation based on HBase, called Themis which is inspired by Google's percolator. I'd like to hear if you ([~cuijianwei]) have comments for this transaction API. > Proposal for a generic transaction API for HBase > > > Key: HBASE-11447 > URL: https://issues.apache.org/jira/browse/HBASE-11447 > Project: HBase > Issue Type: New Feature > Components: Client >Affects Versions: 1.0.0 > Environment: Any. >Reporter: John de Roo >Priority: Minor > Labels: features, newbie > Fix For: 1.0.0 > > Attachments: Proposal for a common transactional API for HBase > v0.3_1.pdf, Proposal for a common transactional API for HBase v0.4_1.pdf, Re > Proposal for a generic transaction API for HBase.htm > > > HBase transaction management today is provided by a number of products, each > implementing a different API, each having different strengths. The lack of a > common API for transactional interfaces means that applications need to be > coded to work with a specific Transaction Manager. This proposal outlines an > API which, if implemented by the different Transaction Manager vendors would > provide stability and choice to HBase application developers. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11118) non environment variable solution for "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.Literal
[ https://issues.apache.org/jira/browse/HBASE-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058006#comment-14058006 ] Nick Dimiduk commented on HBASE-8: -- Same as before, artifact version is still 0.98.4-SNAPSHOT, built against hadoop2. > non environment variable solution for "IllegalAccessError: class > com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass > com.google.protobuf.LiteralByteString" > -- > > Key: HBASE-8 > URL: https://issues.apache.org/jira/browse/HBASE-8 > Project: HBase > Issue Type: Bug >Affects Versions: 0.98.2 >Reporter: André Kelpe >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: 8.098-0.txt, 8.098.txt, 8.bytestringer.txt, > 1118.suggested.undoing.optimization.on.clientside.txt, > 1118.suggested.undoing.optimization.on.clientside.txt, > HBASE-8-0.98.00.patch, HBASE-8-0.98.01.patch, > HBASE-8-0.98.02.patch, HBASE-8-0.98.patch.gz, > HBASE-8-trunk.patch.gz, HBASE-8.00.patch, HBASE-8.01.patch, > HBASE-8.02.patch, shade_attempt.patch > > > I am running into the problem described in > https://issues.apache.org/jira/browse/HBASE-10304, while trying to use a > newer version within cascading.hbase > (https://github.com/cascading/cascading.hbase). > One of the features of cascading.hbase is that you can use it from lingual > (http://www.cascading.org/projects/lingual/), our SQL layer for hadoop. > lingual has a notion of providers, which are fat jars that we pull down > dynamically at runtime. Those jars give users the ability to talk to any > system or format from SQL. They are added to the classpath programmatically > before we submit jobs to a hadoop cluster. > Since lingual does not know upfront , which providers are going to be used in > a given run, the HADOOP_CLASSPATH trick proposed in the JIRA above is really > clunky and breaks the ease of use we had before. No other provider requires > this right now. > It would be great to have a programmatical way to fix this, when using fat > jars. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11442) ReplicationSourceManager doesn't cleanup the queues for recovered sources
[ https://issues.apache.org/jira/browse/HBASE-11442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058000#comment-14058000 ] Virag Kothari commented on HBASE-11442: --- [~jdcryans] Can you take a look? Thxs > ReplicationSourceManager doesn't cleanup the queues for recovered sources > - > > Key: HBASE-11442 > URL: https://issues.apache.org/jira/browse/HBASE-11442 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11442.patch, HBASE-11442_2.patch > > > Currently, ReplicationSourceManager only cleanups the queues for recovered > sources when the queue is being closed. This can cause the already read WAL's > files to be read again when a region server doing failover also dies. This > can cause replication to possibly happen again > For e.g lets say RS1 dies with 5 files in queue and RS2 is doing the > failover. Now, lets say RS2 dies after going thru 3 files in queue and RS3 is > doing the failover. In this case, RS3 will again read those 3 files as they > were not removed from the queue. (Though it will read the first file from the > set pos. in ZK) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11501) Metrics from JMX cache are not cleared
[
https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057999#comment-14057999
]
Hadoop QA commented on HBASE-11501:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655085/HBASE-11501.patch
against trunk revision .
ATTACHMENT ID: 12655085
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10025//console
This message is automatically generated.
> Metrics from JMX cache are not cleared
> --
>
> Key: HBASE-11501
> URL: https://issues.apache.org/jira/browse/HBASE-11501
> Project: HBase
> Issue Type: Bug
> Components: metrics
>Affects Versions: 0.98.3
>Reporter: Virag Kothari
>Assignee: Virag Kothari
> Attachments: HBASE-11501.patch
>
>
> In JmxCacheBuster, clearJmxCache() has incorrect condition for starting
> JmxCacheBusterRunnable
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057997#comment-14057997 ] Virag Kothari commented on HBASE-11501: --- After making the above change, I was hit with https://issues.apache.org/jira/browse/HADOOP-9559 as I was running on Hadoop-2.4 > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.98.3 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11499) AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
[
https://issues.apache.org/jira/browse/HBASE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-11499:
--
Attachment: HBASE-11499.v2.patch.txt
Attaching a patch created with {{git --format-patch}} that can be applied with
either {{git am \[--signoff]}} or {{patch -p1}}.
> AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
> -
>
> Key: HBASE-11499
> URL: https://issues.apache.org/jira/browse/HBASE-11499
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Mike Drob
>Priority: Trivial
> Labels: findbugs
> Attachments: HBASE-11499.patch.txt, HBASE-11499.v2.patch.txt
>
>
> The method is building a string using lots of concatenation, including in a
> loop, which will be {{O(n^2)}} because a new array will be allocated each
> time. Would be more efficient to use a StringBuilder for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11499) AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
[
https://issues.apache.org/jira/browse/HBASE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-11499:
--
Status: Open (was: Patch Available)
> AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
> -
>
> Key: HBASE-11499
> URL: https://issues.apache.org/jira/browse/HBASE-11499
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Mike Drob
>Priority: Trivial
> Labels: findbugs
> Attachments: HBASE-11499.patch.txt, HBASE-11499.v2.patch.txt
>
>
> The method is building a string using lots of concatenation, including in a
> loop, which will be {{O(n^2)}} because a new array will be allocated each
> time. Would be more efficient to use a StringBuilder for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11499) AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
[
https://issues.apache.org/jira/browse/HBASE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-11499:
--
Status: Patch Available (was: Open)
> AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
> -
>
> Key: HBASE-11499
> URL: https://issues.apache.org/jira/browse/HBASE-11499
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Mike Drob
>Priority: Trivial
> Labels: findbugs
> Attachments: HBASE-11499.patch.txt, HBASE-11499.v2.patch.txt
>
>
> The method is building a string using lots of concatenation, including in a
> loop, which will be {{O(n^2)}} because a new array will be allocated each
> time. Would be more efficient to use a StringBuilder for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11501: -- Affects Version/s: 0.98.3 > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.98.3 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11501: -- Status: Patch Available (was: Open) > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11501: -- Attachment: HBASE-11501.patch Primary change is to simply change the if condition from fut == null to fut !=null. > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 0.98.3 >Reporter: Virag Kothari >Assignee: Virag Kothari > Attachments: HBASE-11501.patch > > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11423) Visibility label and per cell ACL feature not working with HTable#mutateRow() and MultiRowMutationEndpoint
[ https://issues.apache.org/jira/browse/HBASE-11423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057988#comment-14057988 ] Lars Hofhansl commented on HBASE-11423: --- +1. Thanks [~anoop.hbase]! > Visibility label and per cell ACL feature not working with HTable#mutateRow() > and MultiRowMutationEndpoint > -- > > Key: HBASE-11423 > URL: https://issues.apache.org/jira/browse/HBASE-11423 > Project: HBase > Issue Type: Bug > Components: Coprocessors, security >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Blocker > Fix For: 0.99.0, 0.98.4, 2.0.0 > > Attachments: HBASE-11423.patch, HBASE-11423_v2.patch, > HBASE-11423_v2.patch > > > This is because pre/postBatchMutate() APIs are not getting called from > HRegion#processRowsWithLocks() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11501) Metrics from JMX cache are not cleared
[ https://issues.apache.org/jira/browse/HBASE-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virag Kothari updated HBASE-11501: -- Component/s: metrics > Metrics from JMX cache are not cleared > -- > > Key: HBASE-11501 > URL: https://issues.apache.org/jira/browse/HBASE-11501 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Virag Kothari >Assignee: Virag Kothari > > In JmxCacheBuster, clearJmxCache() has incorrect condition for starting > JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (HBASE-11499) AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
[
https://issues.apache.org/jira/browse/HBASE-11499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057983#comment-14057983
]
Mike Drob commented on HBASE-11499:
---
It looks like HadoopQA is applying the patches with -p1 now? Which would mean
that the docs at
http://hbase.apache.org/book/submitting.patches.html#submitting.patches.create
need to be updated to not suggest using {{--no-prefix}}. Can somebody verify?
> AsyncProcess.buildDetailedErrorMessage concatenates strings using + in a loop
> -
>
> Key: HBASE-11499
> URL: https://issues.apache.org/jira/browse/HBASE-11499
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Mike Drob
>Priority: Trivial
> Labels: findbugs
> Attachments: HBASE-11499.patch.txt
>
>
> The method is building a string using lots of concatenation, including in a
> loop, which will be {{O(n^2)}} because a new array will be allocated each
> time. Would be more efficient to use a StringBuilder for this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11500) Possible null pointer dereference of regionLocation in ReversedScannerCallable
[
https://issues.apache.org/jira/browse/HBASE-11500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057978#comment-14057978
]
Hadoop QA commented on HBASE-11500:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12655078/HBASE-11500.patch.txt
against trunk revision .
ATTACHMENT ID: 12655078
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/10024//console
This message is automatically generated.
> Possible null pointer dereference of regionLocation in ReversedScannerCallable
> --
>
> Key: HBASE-11500
> URL: https://issues.apache.org/jira/browse/HBASE-11500
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Mike Drob
>Priority: Minor
> Labels: findbugs
> Attachments: HBASE-11500.patch.txt
>
>
> If regionLocation is null in ReversedScannerCallable.locateRegionsInRange
> then the else branch will attempt to dereference it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (HBASE-11496) HBASE-9745 broke cygwin CLASSPATH translation
[ https://issues.apache.org/jira/browse/HBASE-11496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057977#comment-14057977 ] Lars Hofhansl commented on HBASE-11496: --- +1 > HBASE-9745 broke cygwin CLASSPATH translation > - > > Key: HBASE-11496 > URL: https://issues.apache.org/jira/browse/HBASE-11496 > Project: HBase > Issue Type: Bug >Reporter: Dave Latham >Assignee: Dave Latham >Priority: Minor > Fix For: 0.94.22 > > Attachments: HBASE-11496.patch > > > HBASE-9745 put HBASE_CLASSPATH back at the end of the Java classpath, but > also moved it to happen after the cygwin translation which broke it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (HBASE-11501) Metrics from JMX cache are not cleared
Virag Kothari created HBASE-11501: - Summary: Metrics from JMX cache are not cleared Key: HBASE-11501 URL: https://issues.apache.org/jira/browse/HBASE-11501 Project: HBase Issue Type: Bug Reporter: Virag Kothari Assignee: Virag Kothari In JmxCacheBuster, clearJmxCache() has incorrect condition for starting JmxCacheBusterRunnable -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11500) Possible null pointer dereference of regionLocation in ReversedScannerCallable
[ https://issues.apache.org/jira/browse/HBASE-11500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-11500: -- Labels: findbugs (was: ) Status: Patch Available (was: Open) > Possible null pointer dereference of regionLocation in ReversedScannerCallable > -- > > Key: HBASE-11500 > URL: https://issues.apache.org/jira/browse/HBASE-11500 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Mike Drob >Priority: Minor > Labels: findbugs > Attachments: HBASE-11500.patch.txt > > > If regionLocation is null in ReversedScannerCallable.locateRegionsInRange > then the else branch will attempt to dereference it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (HBASE-11500) Possible null pointer dereference of regionLocation in ReversedScannerCallable
[ https://issues.apache.org/jira/browse/HBASE-11500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-11500: -- Attachment: HBASE-11500.patch.txt > Possible null pointer dereference of regionLocation in ReversedScannerCallable > -- > > Key: HBASE-11500 > URL: https://issues.apache.org/jira/browse/HBASE-11500 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Mike Drob >Priority: Minor > Labels: findbugs > Attachments: HBASE-11500.patch.txt > > > If regionLocation is null in ReversedScannerCallable.locateRegionsInRange > then the else branch will attempt to dereference it. -- This message was sent by Atlassian JIRA (v6.2#6252)
