[jira] [Resolved] (KUDU-1581) Kudu-Spark read failure when the Kudu table contains BINARY column
[
https://issues.apache.org/jira/browse/KUDU-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adar Dembo resolved KUDU-1581.
--
Resolution: Fixed
Fix Version/s: 1.0.0
Fixed in commit efb6024. Thanks, Ram!
> Kudu-Spark read failure when the Kudu table contains BINARY column
> --
>
> Key: KUDU-1581
> URL: https://issues.apache.org/jira/browse/KUDU-1581
> Project: Kudu
> Issue Type: Bug
> Components: client
>Affects Versions: 0.10.0
>Reporter: Ram Mettu
>Assignee: Ram Mettu
> Fix For: 1.0.0
>
>
> Using kudu-spark, create a Spark dataframe for a Kudu table containing BINARY
> column, any action fails to serialize.
> Steps to reproduce:
> 1. Create kudu table with binary column(s)
> 2. Populate table with data
> 3. Create Spark Dataframe and perform an action
> val data = sqlContext.read.options(Map("kudu.master" -> masterAddress,
> "kudu.table" -> "test")).kudu
> data.show()
> Results in an error
> org.apache.spark.SparkException: Job aborted due to stage failure: Task 0.0
> in stage 1.0 (TID 1) had a not serializable result: java.nio.HeapByteBuffer
> Serialization stack:
> - object not serializable (class: java.nio.HeapByteBuffer, value:
> java.nio.HeapByteBuffer[pos=677 lim=682 cap=727])
> - element of array (index: 8)
> - array (class [Ljava.lang.Object;, size 9)
> - field (class:
> org.apache.spark.sql.catalyst.expressions.GenericInternalRow, name: values,
> type: class [Ljava.lang.Object;)
> - object (class
> org.apache.spark.sql.catalyst.expressions.GenericInternalRow,
> [0,0,0,0.0,0,false,0,0.0,java.nio.HeapByteBuffer[pos=677 lim=682 cap=727]])
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (KUDU-456) Implement AUTO_FLUSH_BACKGROUND flush mode
[ https://issues.apache.org/jira/browse/KUDU-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin resolved KUDU-456. Resolution: Fixed Fix Version/s: 1.0.0 Implemented in changelist 93be1310d227cf05025864654ca3f6713c2ddc2c > Implement AUTO_FLUSH_BACKGROUND flush mode > -- > > Key: KUDU-456 > URL: https://issues.apache.org/jira/browse/KUDU-456 > Project: Kudu > Issue Type: New Feature > Components: client >Affects Versions: M4.5 >Reporter: Todd Lipcon >Assignee: Alexey Serbin > Labels: kudu-roadmap > Fix For: 1.0.0 > > > The C++ client doesn't yet support this flush mode. This is the easiest mode > to program against for "bulk" operations, since the user gets good > performance but doesn't have to manually manage flushing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KUDU-1376) [c++ client] KuduSession::SetMutationBufferSpace is not defined
[ https://issues.apache.org/jira/browse/KUDU-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin resolved KUDU-1376. - Resolution: Fixed Fix Version/s: 1.0.0 Implemented in changelist 93be1310d227cf05025864654ca3f6713c2ddc2c > [c++ client] KuduSession::SetMutationBufferSpace is not defined > --- > > Key: KUDU-1376 > URL: https://issues.apache.org/jira/browse/KUDU-1376 > Project: Kudu > Issue Type: Bug >Reporter: Dan Burkert >Assignee: Alexey Serbin > Fix For: 1.0.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-868) Support replacement of tombstoned replicas on tablet server
[ https://issues.apache.org/jira/browse/KUDU-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Percy updated KUDU-868: Description: Certain steps must be taken to safely remotely bootstrap deleted tablets. See relevant section in the Tablet Copy design doc @ https://github.com/apache/kudu/blob/master/docs/design-docs/raft-tablet-copy.md for details and rationale. (was: Certain steps must be taken to safely remotely bootstrap deleted tablets. See relevant section in the remote bootstrap spec @ https://docs.google.com/document/d/1zSibYnwPv9cFRnWn0ORyu2uCGB9Neb-EsF0M6AiMSEE for details and rationale.) > Support replacement of tombstoned replicas on tablet server > --- > > Key: KUDU-868 > URL: https://issues.apache.org/jira/browse/KUDU-868 > Project: Kudu > Issue Type: Sub-task > Components: consensus >Affects Versions: Feature Complete >Reporter: Mike Percy >Assignee: Mike Percy > > Certain steps must be taken to safely remotely bootstrap deleted tablets. See > relevant section in the Tablet Copy design doc @ > https://github.com/apache/kudu/blob/master/docs/design-docs/raft-tablet-copy.md > for details and rationale. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-888) Consensus peers must specify and validate each others' UUIDs when communicating
[ https://issues.apache.org/jira/browse/KUDU-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Percy updated KUDU-888: Description: Specifying and validating a remote peer's UUID during communication is required for correctness, because we assume that if a peer has forgotten or lost its durable consensus state then it has also forgotten or lost its UUID, so it will get a new one assigned. Violations of the consensus protocol can occur if a peer has amnesia, but if it refuses requests intended for a prior incarnation of itself then it should be possible to maintain safety. See more discussion of this amnesia scenario in the remote bootstrap design doc, under "Failure of a disk with consensus metadata is a catastrophic failure": https://github.com/apache/kudu/blob/master/docs/design-docs/raft-tablet-copy.md This also helps guard against bad misconfigurations, such as a tablet sending a DeleteTablet RPC message to itself when it thinks it is deleting a remote replica. was: Specifying and validating a remote peer's UUID during communication is required for correctness, because we assume that if a peer has forgotten or lost its durable consensus state then it has also forgotten or lost its UUID, so it will get a new one assigned. Violations of the consensus protocol can occur if a peer has amnesia, but if it refuses requests intended for a prior incarnation of itself then it should be possible to maintain safety. See more discussion of this amnesia scenario in the remote bootstrap design doc, under "Failure of a disk with consensus metadata is a catastrophic failure": https://docs.google.com/document/d/1zSibYnwPv9cFRnWn0ORyu2uCGB9Neb-EsF0M6AiMSEE/edit#heading=h.s6ennwonsuz8 This also helps guard against bad misconfigurations, such as a tablet sending a DeleteTablet RPC message to itself when it thinks it is deleting a remote replica. > Consensus peers must specify and validate each others' UUIDs when > communicating > --- > > Key: KUDU-888 > URL: https://issues.apache.org/jira/browse/KUDU-888 > Project: Kudu > Issue Type: Bug > Components: consensus >Affects Versions: Public beta >Reporter: Mike Percy >Assignee: Mike Percy >Priority: Critical > > Specifying and validating a remote peer's UUID during communication is > required for correctness, because we assume that if a peer has forgotten or > lost its durable consensus state then it has also forgotten or lost its UUID, > so it will get a new one assigned. Violations of the consensus protocol can > occur if a peer has amnesia, but if it refuses requests intended for a prior > incarnation of itself then it should be possible to maintain safety. > See more discussion of this amnesia scenario in the remote bootstrap design > doc, under "Failure of a disk with consensus metadata is a catastrophic > failure": > https://github.com/apache/kudu/blob/master/docs/design-docs/raft-tablet-copy.md > This also helps guard against bad misconfigurations, such as a tablet sending > a DeleteTablet RPC message to itself when it thinks it is deleting a remote > replica. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
