[GitHub] kafka pull request #2347: Initial commit of partition assignment check in co...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/kafka/pull/2347


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: kafka-trunk-jdk8 #1250

[Apache Jenkins Server]

See 

--
[...truncated 8 lines...]
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1695)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1317)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1329)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.hasGitRepo(CliGitAPIImpl.java:195)
at hudson.plugins.git.GitAPI.hasGitRepo(GitAPI.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:818)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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:745)
Caused by: java.io.IOException: Cannot run program "git" (in directory 
": error=11, Resource 
temporarily unavailable
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
at hudson.Proc$LocalProc.(Proc.java:240)
at hudson.Proc$LocalProc.(Proc.java:212)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:815)
at hudson.Launcher$ProcStarter.start(Launcher.java:381)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1719)
... 21 more
Caused by: java.io.IOException: error=11, Resource temporarily unavailable
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:186)
at java.lang.ProcessImpl.start(ProcessImpl.java:130)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
... 26 more
Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/kafka.git
 > git init  # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init 

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:652)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:463)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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:745)
at ..remote call to ubuntu-eu2(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor946.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy177.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1046)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1086)
at 

[GitHub] kafka pull request #2504: KAFKA-4735; Fix deadlock issue during MM shutdown

[lindong28]

GitHub user lindong28 opened a pull request:

https://github.com/apache/kafka/pull/2504

KAFKA-4735; Fix deadlock issue during MM shutdown



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lindong28/kafka KAFKA-4735

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/2504.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2504


commit b0049582bf72a6cda8a8e46641f7dce640fab5a1
Author: Dong Lin 
Date:   2017-02-05T10:18:55Z

KAFKA-4735; Fix deadlock issue during MM shutdown




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] KIP-117: Add a public AdministrativeClient API for Kafka admin operations

[Ismael Juma]

Hi Colin,

I was thinking about the API and the fact that the AdminClient will be used
by a variety of somewhat unrelated things (unlike the Consumer and
Producer), so I think we should consider an approach where not all the
methods are at the top-level. One idea is that you could perform operations
on topics by doing something like `adminClient.topics().create(...)`,
`adminClient.topics().delete(...)`, `adminClient.topics().describe(...)`,
etc. This is just an initial sketch to describe the idea, but I think it
would be a nice way to group methods by the relevant resource. It would
also make it easier to enforce consistency by using shared interfaces for
the types returned by the resource method (e.g. `topics()`, `acls()`, etc.).

One additional comment inline.

On Fri, Feb 3, 2017 at 6:40 PM, Colin McCabe  wrote:
>
> I guess my thought process was that users might find it confusing if the
> public API and the old private API had the same name.  "What do you
> mean, I have to upgrade to release X to get AdminClient, I have it right
> here?"  I do have a slight preference for the shorter name, though, so
> if this isn't a worry, we can change it to AdminClient.
>

Yes, I don't think this is a worry. The package name and implementation
language are different, so it's easy enough to distinguish. We should not
choose a worse name for a public class because of an internal class, as a
general rule, in my opinion.

More to follow later.

Ismael

[jira] [Created] (KAFKA-4735) Fix deadlock issue during MM shutdown

[Dong Lin (JIRA)]

Dong Lin created KAFKA-4735:
---

 Summary: Fix deadlock issue during MM shutdown
 Key: KAFKA-4735
 URL: https://issues.apache.org/jira/browse/KAFKA-4735
 Project: Kafka
  Issue Type: Bug
Reporter: Dong Lin
Assignee: Dong Lin


In https://issues.apache.org/jira/browse/KAFKA-4521 we fixed a potential 
message reorder bug in MM. However, the patch introduced another bug that can 
cause deadlock during MM shutdown. The deadlock will happen if zookeeper 
listener thread call requestAndWaitForCommit() after MirrorMaker thread has 
already exited loop of consuming and producing messages.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (KAFKA-4558) throttling_test fails if the producer starts too fast.

[Ismael Juma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ismael Juma resolved KAFKA-4558.

   Resolution: Fixed
Fix Version/s: 0.10.2.0

Issue resolved by pull request 2347
[https://github.com/apache/kafka/pull/2347]

> throttling_test fails if the producer starts too fast.
> --
>
> Key: KAFKA-4558
> URL: https://issues.apache.org/jira/browse/KAFKA-4558
> Project: Kafka
>  Issue Type: Bug
>Reporter: Apurva Mehta
>Assignee: Apurva Mehta
> Fix For: 0.10.2.0
>
>
> As described in https://issues.apache.org/jira/browse/KAFKA-4526, the 
> throttling test will fail if the producer in the produce-consume-validate 
> loop starts up before the consumer is fully initialized.
> We need to block the start of the producer until the consumer is ready to go. 
> The current plan is to poll the consumer for a particular metric (like, for 
> instance, partition assignment) which will act as a good proxy for successful 
> initialization. Currently, we just check for the existence of a process with 
> the PID, which is not a strong enough check, causing the test to fail 
> intermittently. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] KIP-48 Support for delegation tokens as an authentication mechanism

[Manikumar]

Hi Jun,

 Please see the replies inline.


> >
> > Only one broker does the deletion. Broker updates the expiration in its
> > local cache
> > and on zookeeper so other brokers also get notified and their cache
> > statuses are updated as well.
> >
> >
> Which broker does the deletion?
>

Any broker can handle the create/expire/renew/describe delegationtoken
requests.
changes are propagated through zk notifications.  Every broker is
responsible for
expiring the tokens. This check be can done during request handling time
and/or
during token authentication time.


>
>
> 110. The diagrams in the wiki still show MD5 digest. Could you change it to
> SCRAM?
>
>
  Updated the diagram.



Thanks,
Manikumar




>
>
> >
> > Thanks.
> > Manikumar
> >
> >
> > >
> > > On Fri, Dec 23, 2016 at 9:26 AM, Manikumar 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I would like to initiate the vote on KIP-48:
> > > >
> > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-48+
> > > > Delegation+token+support+for+Kafka
> > > >
> > > >
> > > > Thanks,
> > > > Manikumar
> > > >
> > >
> >
>

Build failed in Jenkins: kafka-trunk-jdk8 #1251

[Apache Jenkins Server]

See 

Changes:

[ismael] KAFKA-4558; throttling_test fails if the producer starts too fast

--
[...truncated 32030 lines...]
kafka.api.RackAwareAutoTopicCreationTest > testAutoCreateTopic STARTED

kafka.api.RackAwareAutoTopicCreationTest > testAutoCreateTopic PASSED

kafka.api.PlaintextConsumerTest > testEarliestOrLatestOffsets STARTED

kafka.api.PlaintextConsumerTest > testEarliestOrLatestOffsets PASSED

kafka.api.PlaintextConsumerTest > testPartitionsForAutoCreate STARTED

kafka.api.PlaintextConsumerTest > testPartitionsForAutoCreate PASSED

kafka.api.PlaintextConsumerTest > testShrinkingTopicSubscriptions STARTED

kafka.api.PlaintextConsumerTest > testShrinkingTopicSubscriptions PASSED

kafka.api.PlaintextConsumerTest > testMaxPollIntervalMs STARTED

kafka.api.PlaintextConsumerTest > testMaxPollIntervalMs PASSED

kafka.api.PlaintextConsumerTest > testOffsetsForTimes STARTED

kafka.api.PlaintextConsumerTest > testOffsetsForTimes PASSED

kafka.api.PlaintextConsumerTest > testSubsequentPatternSubscription STARTED

kafka.api.PlaintextConsumerTest > testSubsequentPatternSubscription PASSED

kafka.api.PlaintextConsumerTest > testAsyncCommit STARTED

kafka.api.PlaintextConsumerTest > testAsyncCommit PASSED

kafka.api.PlaintextConsumerTest > testLowMaxFetchSizeForRequestAndPartition 
STARTED

kafka.api.PlaintextConsumerTest > testLowMaxFetchSizeForRequestAndPartition 
PASSED

kafka.api.PlaintextConsumerTest > testMultiConsumerSessionTimeoutOnStopPolling 
STARTED

kafka.api.PlaintextConsumerTest > testMultiConsumerSessionTimeoutOnStopPolling 
PASSED

kafka.api.PlaintextConsumerTest > testMaxPollIntervalMsDelayInRevocation STARTED

kafka.api.PlaintextConsumerTest > testMaxPollIntervalMsDelayInRevocation PASSED

kafka.api.PlaintextConsumerTest > testPerPartitionLagMetricsCleanUpWithAssign 
STARTED

kafka.api.PlaintextConsumerTest > testPerPartitionLagMetricsCleanUpWithAssign 
PASSED

kafka.api.PlaintextConsumerTest > testPartitionsForInvalidTopic STARTED

kafka.api.PlaintextConsumerTest > testPartitionsForInvalidTopic PASSED

kafka.api.PlaintextConsumerTest > testPauseStateNotPreservedByRebalance STARTED

kafka.api.PlaintextConsumerTest > testPauseStateNotPreservedByRebalance PASSED

kafka.api.PlaintextConsumerTest > 
testFetchHonoursFetchSizeIfLargeRecordNotFirst STARTED

kafka.api.PlaintextConsumerTest > 
testFetchHonoursFetchSizeIfLargeRecordNotFirst PASSED

kafka.api.PlaintextConsumerTest > testSeek STARTED

kafka.api.PlaintextConsumerTest > testSeek PASSED

kafka.api.PlaintextConsumerTest > testPositionAndCommit STARTED

kafka.api.PlaintextConsumerTest > testPositionAndCommit PASSED

kafka.api.PlaintextConsumerTest > 
testFetchRecordLargerThanMaxPartitionFetchBytes STARTED

kafka.api.PlaintextConsumerTest > 
testFetchRecordLargerThanMaxPartitionFetchBytes PASSED

kafka.api.PlaintextConsumerTest > testUnsubscribeTopic STARTED

kafka.api.PlaintextConsumerTest > testUnsubscribeTopic PASSED

kafka.api.PlaintextConsumerTest > testMultiConsumerSessionTimeoutOnClose STARTED

kafka.api.PlaintextConsumerTest > testMultiConsumerSessionTimeoutOnClose PASSED

kafka.api.PlaintextConsumerTest > testFetchRecordLargerThanFetchMaxBytes STARTED

kafka.api.PlaintextConsumerTest > testFetchRecordLargerThanFetchMaxBytes PASSED

kafka.api.PlaintextConsumerTest > testMultiConsumerDefaultAssignment STARTED

kafka.api.PlaintextConsumerTest > testMultiConsumerDefaultAssignment PASSED

kafka.api.PlaintextConsumerTest > testAutoCommitOnClose STARTED

kafka.api.PlaintextConsumerTest > testAutoCommitOnClose PASSED

kafka.api.PlaintextConsumerTest > testListTopics STARTED

kafka.api.PlaintextConsumerTest > testListTopics PASSED

kafka.api.PlaintextConsumerTest > testExpandingTopicSubscriptions STARTED

kafka.api.PlaintextConsumerTest > testExpandingTopicSubscriptions PASSED

kafka.api.PlaintextConsumerTest > testInterceptors STARTED

kafka.api.PlaintextConsumerTest > testInterceptors PASSED

kafka.api.PlaintextConsumerTest > testPatternUnsubscription STARTED

kafka.api.PlaintextConsumerTest > testPatternUnsubscription PASSED

kafka.api.PlaintextConsumerTest > testGroupConsumption STARTED

kafka.api.PlaintextConsumerTest > testGroupConsumption PASSED

kafka.api.PlaintextConsumerTest > testPartitionsFor STARTED

kafka.api.PlaintextConsumerTest > testPartitionsFor PASSED

kafka.api.PlaintextConsumerTest > testAutoCommitOnRebalance STARTED

kafka.api.PlaintextConsumerTest > testAutoCommitOnRebalance PASSED

kafka.api.PlaintextConsumerTest > testInterceptorsWithWrongKeyValue STARTED

kafka.api.PlaintextConsumerTest > testInterceptorsWithWrongKeyValue PASSED

kafka.api.PlaintextConsumerTest > testMaxPollIntervalMsDelayInAssignment STARTED

kafka.api.PlaintextConsumerTest > testMaxPollIntervalMsDelayInAssignment PASSED

kafka.api.PlaintextConsumerTest > testMultiConsumerRoundRobinAssignment STARTED

kafka.api.PlaintextConsumerTest > 

[jira] [Created] (KAFKA-4736) producer failed too slow when meta request failed

[Jun Yao (JIRA)]

Jun Yao created KAFKA-4736:
--

 Summary: producer failed too slow when meta request failed
 Key: KAFKA-4736
 URL: https://issues.apache.org/jira/browse/KAFKA-4736
 Project: Kafka
  Issue Type: Bug
  Components: producer 
Reporter: Jun Yao


This might be similar to https://issues.apache.org/jira/browse/KAFKA-4385 but 
happen in a different case. 
In some cases as tested, the producer may get some invalid metadata (and it's 
always invalid when there are some issues on the broker side), 

so whenever calling KafkaProducer.send(), it will spent 60seconds (in default 
configuration) on KafkaProducer.waitOnMetadata() and then throw 
TimeoutException("Failed to update metadata after 6 ms"),

so when there are something wrong on some topic that the producer did not get 
the metadata of the topic, it will be like 'blocked' by this topic for 
60seconds,  and impacting other topics sending. 

for cases that we want to utilizing the "Callback" to save those failed 
requests data in a different place and retry later, the Callback is also called 
every 60seconds. so if upstream is keep receiving data and calling 
producer.send(), 
it will soon be blocking or buffering too much in memory if upstream has a 
buffer of data before calling producer.send. 

It looks to me the KafkaProducer.send() is failing too slow (not fail fast) 
when something is wrong on some topic/broker.  and it's always in this slow 
failure state. 

I am not sure if reducing the "max.block.ms" is the right way to avoid this, 
since when meta data changes it will need some time to get updated metadata; 
and if auto topic creation it will also need enough time to wait for the topic 
created 

as from [~sslavic]'s comment, 
I am wondering if a better way of defining and utilizing RetriableException 
will help on this, maybe need some support from server side, that some 
exception is not retriable so client side would not need to waste the time to 
keep retrying. 

Or maybe consider my proposal on 
https://issues.apache.org/jira/browse/KAFKA-4385 to have another config to 
limit the consecutive failures on one topic. 

or maybe some adaptive behavior that the block time will be decreased after 
some consecutive failures. 









--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (KAFKA-4385) producer is sending too many unnecessary meta data request if the meta data for a topic is not available and "auto.create.topics.enable" =false

[Jun Yao (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853324#comment-15853324
 ] 

Jun Yao commented on KAFKA-4385:


[~ewencp]  is it possible to have some server side support to have better 
definition of what is retriable and what is not retriable? 
right now this seems to that client just keep retrying on some cases that is 
not actually needed. 

> producer is sending too many unnecessary meta data request if the meta data 
> for a topic is not available and "auto.create.topics.enable" =false
> ---
>
> Key: KAFKA-4385
> URL: https://issues.apache.org/jira/browse/KAFKA-4385
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.9.0.1
>Reporter: Jun Yao
>
> All current kafka-client producer implementation (<= 0.10.1.0),
> When sending a msg to a topic, it will first check if meta data for this 
> topic is available or not, 
> when not available, it will set "metadata.requestUpdate()" and wait for meta 
> data from brokers, 
> The thing is inside "org.apache.kafka.clients.Metadata.awaitUpdate()", it's 
> already doing a "while (this.version <= lastVersion)" loop waiting for new 
> version response, 
> So the loop inside 
> "org.apache.kafka.clients.producer.KafkaProducer.waitOnMetadata() is not 
> needed, 
> When "auto.create.topics.enable" is false, sending msgs to a non-exist topic 
> will trigger too many meta requests, everytime a metadata response is 
> returned, because it does not contain the metadata for the topic, it's going 
> to try again until TimeoutException is thrown; 
> This is a waste and sometimes causes too much overhead when unexpected msgs 
> are arrived. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (KAFKA-4276) REST configuration not visible in connector properties config files

[Akhilesh Naidu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Akhilesh Naidu updated KAFKA-4276:
--
Reviewer: Ewen Cheslack-Postava
  Status: Patch Available  (was: Open)

> REST configuration not visible in connector properties config files
> ---
>
> Key: KAFKA-4276
> URL: https://issues.apache.org/jira/browse/KAFKA-4276
> Project: Kafka
>  Issue Type: Improvement
>  Components: KafkaConnect
>Reporter: Gwen Shapira
>Assignee: Akhilesh Naidu
>  Labels: newbie
>
> REST host and port configs are not visible in connect-distributed.properties. 
> I think this leads to some confusion as users don't know there's even a REST 
> port and need to read the docs to find about it and the default (and these 
> are marked as LOW configs).
> We can easily improve that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [DISCUSS] KIP-117: Add a public AdministrativeClient API for Kafka admin operations

[Manikumar]

+1 for ismael's suggestion.  grouping of methods by the relevant resource
will simply the
API. In future, we will be adding delegation token related operations to
admin client.
I can imagine methods like adminClient.token().create(...),
adminClient.token().renew(...), etc..


Thanks,
Manikumar

On Sun, Feb 5, 2017 at 7:27 PM, Ismael Juma  wrote:

> Hi Colin,
>
> I was thinking about the API and the fact that the AdminClient will be used
> by a variety of somewhat unrelated things (unlike the Consumer and
> Producer), so I think we should consider an approach where not all the
> methods are at the top-level. One idea is that you could perform operations
> on topics by doing something like `adminClient.topics().create(...)`,
> `adminClient.topics().delete(...)`, `adminClient.topics().describe(...)`,
> etc. This is just an initial sketch to describe the idea, but I think it
> would be a nice way to group methods by the relevant resource. It would
> also make it easier to enforce consistency by using shared interfaces for
> the types returned by the resource method (e.g. `topics()`, `acls()`,
> etc.).
>
> One additional comment inline.
>
> On Fri, Feb 3, 2017 at 6:40 PM, Colin McCabe  wrote:
> >
> > I guess my thought process was that users might find it confusing if the
> > public API and the old private API had the same name.  "What do you
> > mean, I have to upgrade to release X to get AdminClient, I have it right
> > here?"  I do have a slight preference for the shorter name, though, so
> > if this isn't a worry, we can change it to AdminClient.
> >
>
> Yes, I don't think this is a worry. The package name and implementation
> language are different, so it's easy enough to distinguish. We should not
> choose a worse name for a public class because of an internal class, as a
> general rule, in my opinion.
>
> More to follow later.
>
> Ismael
>

[jira] [Commented] (KAFKA-4722) Add application.id to StreamThread name

[Sharad (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853260#comment-15853260
 ] 

Sharad commented on KAFKA-4722:
---

PR submitted:
https://github.com/apache/kafka/pull/2487

> Add application.id to StreamThread name
> ---
>
> Key: KAFKA-4722
> URL: https://issues.apache.org/jira/browse/KAFKA-4722
> Project: Kafka
>  Issue Type: Improvement
>  Components: streams
>Affects Versions: 0.10.1.1
>Reporter: Steven Schlansker
>Assignee: Sharad
>Priority: Minor
>  Labels: beginner, easyfix, newbie
>
> StreamThread currently sets its name thusly:
> {code}
> super("StreamThread-" + STREAM_THREAD_ID_SEQUENCE.getAndIncrement());
> {code}
> If you have multiple {{KafkaStreams}} instance within a single application, 
> it would help to add the application ID to {{StreamThread}} name to identify 
> which thread belong to what {{KafkaStreams}} instance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (KAFKA-4737) Streams apps hang if started when brokers are not available

[Umesh Chaudhary (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853422#comment-15853422
 ] 

Umesh Chaudhary commented on KAFKA-4737:


Hi [~gwenshap], does the intent is similar to KAFKA-4564?

> Streams apps hang if started when brokers are not available
> ---
>
> Key: KAFKA-4737
> URL: https://issues.apache.org/jira/browse/KAFKA-4737
> Project: Kafka
>  Issue Type: Bug
>Reporter: Gwen Shapira
>
> Start a streams example while broker is down, and it will just hang there. It 
> will also hang on shutdown.
> I'd expect it to exit with an error message if broker is not available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (KAFKA-4737) Streams apps hang if started when brokers are not available

[Gwen Shapira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gwen Shapira resolved KAFKA-4737.
-
Resolution: Duplicate

> Streams apps hang if started when brokers are not available
> ---
>
> Key: KAFKA-4737
> URL: https://issues.apache.org/jira/browse/KAFKA-4737
> Project: Kafka
>  Issue Type: Bug
>Reporter: Gwen Shapira
>
> Start a streams example while broker is down, and it will just hang there. It 
> will also hang on shutdown.
> I'd expect it to exit with an error message if broker is not available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (KAFKA-4737) Streams apps hang if started when brokers are not available

[Gwen Shapira (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853423#comment-15853423
 ] 

Gwen Shapira commented on KAFKA-4737:
-

It is! Sorry for the duplicate. I'll close this.

> Streams apps hang if started when brokers are not available
> ---
>
> Key: KAFKA-4737
> URL: https://issues.apache.org/jira/browse/KAFKA-4737
> Project: Kafka
>  Issue Type: Bug
>Reporter: Gwen Shapira
>
> Start a streams example while broker is down, and it will just hang there. It 
> will also hang on shutdown.
> I'd expect it to exit with an error message if broker is not available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (KAFKA-4737) Streams apps hang if started when brokers are not available

[Umesh Chaudhary (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853424#comment-15853424
 ] 

Umesh Chaudhary commented on KAFKA-4737:


No worries. Thanks [~gwenshap] !

> Streams apps hang if started when brokers are not available
> ---
>
> Key: KAFKA-4737
> URL: https://issues.apache.org/jira/browse/KAFKA-4737
> Project: Kafka
>  Issue Type: Bug
>Reporter: Gwen Shapira
>
> Start a streams example while broker is down, and it will just hang there. It 
> will also hang on shutdown.
> I'd expect it to exit with an error message if broker is not available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (KAFKA-4737) Streams apps hang if started when brokers are not available

[Gwen Shapira (JIRA)]

Gwen Shapira created KAFKA-4737:
---

 Summary: Streams apps hang if started when brokers are not 
available
 Key: KAFKA-4737
 URL: https://issues.apache.org/jira/browse/KAFKA-4737
 Project: Kafka
  Issue Type: Bug
Reporter: Gwen Shapira


Start a streams example while broker is down, and it will just hang there. It 
will also hang on shutdown.

I'd expect it to exit with an error message if broker is not available.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] kafka pull request #2505: KAFKA-4276: Add REST configuration in connector pr...

[akhilesh1194]

GitHub user akhilesh1194 opened a pull request:

https://github.com/apache/kafka/pull/2505

KAFKA-4276: Add REST configuration in connector properties

Addition of REST configuration in connect-distributed.properties config file
@gwenshap @ewencp - Please review.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/akhilesh1194/kafka JIRA_KAFKA-4276

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/2505.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2505


commit 17f38b787d48b5c43164037e722fac45533798d8
Author: Akhilesh Naidu 
Date:   2017-02-03T11:58:32Z

JIRA_KAFKA-4276:- Addition of REST configuration in 
connect-distributed.properties config file




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (KAFKA-4276) REST configuration not visible in connector properties config files

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/KAFKA-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15853573#comment-15853573
 ] 

ASF GitHub Bot commented on KAFKA-4276:
---

GitHub user akhilesh1194 opened a pull request:

https://github.com/apache/kafka/pull/2505

KAFKA-4276: Add REST configuration in connector properties

Addition of REST configuration in connect-distributed.properties config file
@gwenshap @ewencp - Please review.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/akhilesh1194/kafka JIRA_KAFKA-4276

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/kafka/pull/2505.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2505


commit 17f38b787d48b5c43164037e722fac45533798d8
Author: Akhilesh Naidu 
Date:   2017-02-03T11:58:32Z

JIRA_KAFKA-4276:- Addition of REST configuration in 
connect-distributed.properties config file




> REST configuration not visible in connector properties config files
> ---
>
> Key: KAFKA-4276
> URL: https://issues.apache.org/jira/browse/KAFKA-4276
> Project: Kafka
>  Issue Type: Improvement
>  Components: KafkaConnect
>Reporter: Gwen Shapira
>Assignee: Akhilesh Naidu
>  Labels: newbie
>
> REST host and port configs are not visible in connect-distributed.properties. 
> I think this leads to some confusion as users don't know there's even a REST 
> port and need to read the docs to find about it and the default (and these 
> are marked as LOW configs).
> We can easily improve that.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)