[
https://issues.apache.org/jira/browse/KUDU-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317718#comment-16317718
]
Min Du commented on KUDU-1948:
------------------------------
Hi there,
I wonder if there is any update on this issue.
I am currently working in Kudu version 1.4.0 and cannot find any configuration
file. Basically what I wanna do is to set a customised rpc timeout. By looking
at the Kudu source code (Java API) , it seems the default value is 30000
millisecond. I knew that a customised value can be set when creating a
kuduClient object.
However, it seems not allowing user to set the customised value in KuduContext
class.
This is my scenarios, I have a Spark application, which connects to Kudu and
tries to do insert / update / delete on Kudu table. I am using
KuduContext.class to create a kuduContext instance and its (a)syncClient.
upsertRows() method in the KuduContext class is the method that I often call to
insert / update data to Kudu table.
Basing on my basic understanding, upsertRows() method is calling
writePartitionRows() method, which will create a new kudu session from Kudu
syncClient. Since it does NOT allow me to set customised value for rpc timeout,
it will always use the default one (30000 millisecond). The default value works
for some queries, but might not work for long-running queries, which needs to
insert a large resultset to Kudu table.
Do we have a way to set customised configuration values when using KuduContext
class?
According to the Kudu configuration guide
(https://kudu.apache.org/docs/configuration_reference.html), I would expect
these configuration parameters can be also set in Java API.
Could you please let me know if I miss anything? If it is not the right jira
ticket to ask, could you please guide me to raise this issue?
Thanks a lot.
Cheers,
Min
> Client-side configuration of cluster details
> --------------------------------------------
>
> Key: KUDU-1948
> URL: https://issues.apache.org/jira/browse/KUDU-1948
> Project: Kudu
> Issue Type: New Feature
> Components: client, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
> Assignee: Grant Henke
>
> In the beginning, Kudu clients were configured with only the address of the
> single Kudu master. This was nice and simple, and there was no need for a
> client "configuration file".
> Then, we added multi-masters, and the client API had to take a list of master
> addresses. This wasn't awful, but started to be a bit aggravating when trying
> to use tools on a multi-master cluster (who wants to type out three long
> hostnames in a 'ksck' command line every time?).
> Now with security, we have a couple more bits of configuration for the
> client. Namely:
> - "require SSL" and "require authentication" booleans -- necessary to prevent
> MITM downgrade attacks
> - custom Kerberos principal -- if the server wants to use a principal other
> than 'kudu/<HOST>@REALM' then the client needs to know to expect it and fetch
> the appropriate service ticket. (Note this isn't yet supported but would like
> to be!)
> In the future, there are other items that might be best specified as part of
> a client configuration as well (e.g. CA cert for BYO PKI, wire compression
> options, etc).
> For the above use cases it would be nicer to allow the various options to be
> specified in a configuration file rather than adding specific APIs for all
> options.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
