[jira] [Commented] (HBASE-8078) REST for Multi-put Using JSON Ordering
[
https://issues.apache.org/jira/browse/HBASE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695278#comment-13695278
]
Chip Salzenberg commented on HBASE-8078:
This bug also manifests in that the $ entry for cells must be last.
REST for Multi-put Using JSON Ordering
--
Key: HBASE-8078
URL: https://issues.apache.org/jira/browse/HBASE-8078
Project: HBase
Issue Type: Bug
Components: REST
Reporter: Jesse Anderson
This issue only happens when doing a Multi-put using the REST interface and
with the JSON data format.
The bug is that the key entry must come before the Cell entry. The key
entry order shouldn't matter. If it doesn't come first, the REST interface
won't find the key and will use the URL's key over and over. For example, if
the row key in the URL is fakekey, then every cell would be added to the
same row despite the key being in the JSON.
Here is the workaround in Python:
cell = OrderedDict([
(key, rowKeyEncoded),
(Cell,
[
{ column : messagecolumnencoded, $ : line },
{ column : usernamecolumnencoded, $ :
usernameEncoded },
{ column : linenumbercolumnencoded, $ :
lineNumberEncoded },
])
])
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8078) REST for Multi-put Using JSON Ordering
[
https://issues.apache.org/jira/browse/HBASE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13695332#comment-13695332
]
Chip Salzenberg commented on HBASE-8078:
Further explanation:
http://jersey.576304.n2.nabble.com/Jersey-JAXB-incorrectly-consumes-JSON-if-elements-are-not-particularly-ordered-td4784190.html
REST for Multi-put Using JSON Ordering
--
Key: HBASE-8078
URL: https://issues.apache.org/jira/browse/HBASE-8078
Project: HBase
Issue Type: Bug
Components: REST
Reporter: Jesse Anderson
This issue only happens when doing a Multi-put using the REST interface and
with the JSON data format.
The bug is that the key entry must come before the Cell entry. The key
entry order shouldn't matter. If it doesn't come first, the REST interface
won't find the key and will use the URL's key over and over. For example, if
the row key in the URL is fakekey, then every cell would be added to the
same row despite the key being in the JSON.
Here is the workaround in Python:
cell = OrderedDict([
(key, rowKeyEncoded),
(Cell,
[
{ column : messagecolumnencoded, $ : line },
{ column : usernamecolumnencoded, $ :
usernameEncoded },
{ column : linenumbercolumnencoded, $ :
lineNumberEncoded },
])
])
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8811) REST service ignores misspelled check= parameter, causing unexpected mutations
Chip Salzenberg created HBASE-8811:
--
Summary: REST service ignores misspelled check= parameter,
causing unexpected mutations
Key: HBASE-8811
URL: https://issues.apache.org/jira/browse/HBASE-8811
Project: HBase
Issue Type: Bug
Components: REST
Affects Versions: 0.95.1
Reporter: Chip Salzenberg
Priority: Critical
In rest.RowResource.update(), this code keeps executing a request if a
misspelled check= parameter is provided.
{noformat}
if (CHECK_PUT.equalsIgnoreCase(check)) {
return checkAndPut(model);
} else if (CHECK_DELETE.equalsIgnoreCase(check)) {
return checkAndDelete(model);
} else if (check != null check.length() 0) {
LOG.warn(Unknown check value: + check + , ignored);
}
{noformat}
By my reading of the code, this results in the provided cell value that was
intended as a check instead being treated as a mutation, which is sure to
destroy user data. Thus the priority of this bug, as it can cause corruption.
I suggest that a better reaction than a warning would be, approximately:
{noformat}
return Response.status(Response.Status.BAD_REQUEST)
.type(MIMETYPE_TEXT).entity(Invalid check value ' + check + ')
.build();
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7464) Sending HTML for 404 is unhelpul; please send short text, or no text, on errors
Chip Salzenberg created HBASE-7464: -- Summary: Sending HTML for 404 is unhelpul; please send short text, or no text, on errors Key: HBASE-7464 URL: https://issues.apache.org/jira/browse/HBASE-7464 Project: HBase Issue Type: Bug Components: REST Reporter: Chip Salzenberg Priority: Minor The large HTML 404 page returned by Stargate is not helpful. The REST interface is not intended for humans to read, esp. when the client is known to be a program because it's asking for binary, but really any time. Nice big readable error pages use bandwidth and clutter network traces to no purpose. Please allow the 404 and other error pages to be configured away, or just stop sending them (my preference). If some body must be sent, a simple text/plain Not found would be fine, I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7456) Stargate's HTablePool maxSize is hard-coded at 10, too small for heavy loads
[ https://issues.apache.org/jira/browse/HBASE-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541187#comment-13541187 ] Chip Salzenberg commented on HBASE-7456: Thanks for the trivial patch; I'll see about building my local binaries with it. Stargate's HTablePool maxSize is hard-coded at 10, too small for heavy loads Key: HBASE-7456 URL: https://issues.apache.org/jira/browse/HBASE-7456 Project: HBase Issue Type: Bug Components: REST Affects Versions: 0.96.0, 0.94.4 Reporter: Chip Salzenberg Assignee: Andrew Purtell Priority: Minor Attachments: HBASE-7456-0.94.patch, HBASE-7456-trunk.patch Please allow the Configuration to override the hard-coded maxSize of 10 for its HTablePool. Under high loads, 10 is too small. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7464) Sending HTML for 404 is unhelpul; please send short text, or no text, on errors
[
https://issues.apache.org/jira/browse/HBASE-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13541266#comment-13541266
]
Chip Salzenberg commented on HBASE-7464:
I think I found a way:
http://java.net/jira/browse/JERSEY-1189?focusedCommentId=341322page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_341322
a related Jersey bug report, in which a maintainer suggests to supply a dummy
entity to the response - then nothing gets overwritten/reset by the container.
e.g.
{noformat}
return
Response.status(Response.Status.NOT_FOUND).cacheControl(getCacheControl()).type(text/plain).entity(404
Not Found).build();
{noformat}
Does this work for Stargate?
Sending HTML for 404 is unhelpul; please send short text, or no text, on
errors
---
Key: HBASE-7464
URL: https://issues.apache.org/jira/browse/HBASE-7464
Project: HBase
Issue Type: Bug
Components: REST
Affects Versions: 0.96.0, 0.94.5
Reporter: Chip Salzenberg
Assignee: Andrew Purtell
Priority: Minor
The large HTML 404 page returned by Stargate is not helpful. The REST
interface is not intended for humans to read, esp. when the client is known
to be a program because it's asking for binary, but really any time. Nice
big readable error pages use bandwidth and clutter network traces to no
purpose.
Please allow the 404 and other error pages to be configured away, or just
stop sending them (my preference). If some body must be sent, a simple
text/plain Not found would be fine, I think.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7456) Stargate's HTablePool maxSize is hard-coded at 10, too small for heavy loads
Chip Salzenberg created HBASE-7456: -- Summary: Stargate's HTablePool maxSize is hard-coded at 10, too small for heavy loads Key: HBASE-7456 URL: https://issues.apache.org/jira/browse/HBASE-7456 Project: HBase Issue Type: Bug Components: REST Reporter: Chip Salzenberg Please allow the Configuration to override the hard-coded maxSize of 10 for its HTablePool. Under high loads, 10 is too small. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3776) Add Bloom Filter Support to HFileOutputFormat
[ https://issues.apache.org/jira/browse/HBASE-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500939#comment-13500939 ] Chip Salzenberg commented on HBASE-3776: Hello? Anyone? Bueller? Add Bloom Filter Support to HFileOutputFormat - Key: HBASE-3776 URL: https://issues.apache.org/jira/browse/HBASE-3776 Project: HBase Issue Type: Sub-task Reporter: Nicolas Spiegelberg Assignee: Jerry Chen Priority: Critical Labels: hbase Fix For: 0.96.0 Add Bloom Filter support for bulk imports. Lacking a bloom filter, even on a single imported file, can cause perf degradation. Since we now set our compression type based on the HBase CF configuration, it would be good to follow this path for the bloom filter addition. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
