[jira] [Resolved] (KAFKA-5528) Error while reading topic, offset, partition info from process method

[Nishkam Ravi (JIRA)]

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

Nishkam Ravi resolved KAFKA-5528.
-
Resolution: Fixed

> Error while reading topic, offset, partition info from process method
> -
>
> Key: KAFKA-5528
> URL: https://issues.apache.org/jira/browse/KAFKA-5528
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 0.10.2.0
>Reporter: Nishkam Ravi
>
> We are encountering an {{IllegalStateException}} while trying to access 
> {{context.topic()}} from process function. The code is written in Scala and 
> is being launched using sbt (spring isn't involved). Here's the code sketch:
> {noformat}
> class GenericProcessor[T <: ThriftStruct](serDe: ThriftStructSerDe[T], 
> decrypt: Boolean, config: Config) extends AbstractProcessor[Array[Byte], 
> Array[Byte]] with LazyLogging {
>   private var hsmClient: HSMClient = _
>   override def init(processorContext: ProcessorContext): Unit = { 
> super.init(processorContext) 
> hsmClient = HSMClient(config).getOrElse(null) 
>   }
>   override def process(key: Array[Byte], value: Array[Byte]): Unit = { 
> val topic: String = this.context.topic() 
> partition: Int = this.context.partition() 
> val offset: Long = this.context.offset() 
> val timestamp: Long = this.context.timestamp() 
> // business logic 
>   }
> }
> {noformat}
> The exception is thrown only for the multi-consumer case (when number of 
> partitions for a topic > 1 and parallelism > 1). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[DISCUSS] KIP-175: Additional '--describe' views for ConsumerGroupCommand

[Vahid S Hashemian]

Hi,

I created KIP-175 to make some improvements to the ConsumerGroupCommand 
tool.
The KIP can be found here: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-175%3A+Additional+%27--describe%27+views+for+ConsumerGroupCommand

Your review and feedback is welcome!

Thanks.
--Vahid

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

[Apache Jenkins Server]

See 


Changes:

[damian.guy] MINOR: compatibility tests for streams

--
[...truncated 4.30 MB...]
kafka.tools.ConsoleProducerTest > testInvalidConfigs PASSED

kafka.tools.ConsoleProducerTest > testValidConfigsNewProducer STARTED

kafka.tools.ConsoleProducerTest > testValidConfigsNewProducer PASSED

kafka.tools.ReplicaVerificationToolTest > testReplicaBufferVerifyChecksum 
STARTED

kafka.tools.ReplicaVerificationToolTest > testReplicaBufferVerifyChecksum PASSED

kafka.tools.ConsoleConsumerTest > shouldLimitReadsToMaxMessageLimit STARTED

kafka.tools.ConsoleConsumerTest > shouldLimitReadsToMaxMessageLimit PASSED

kafka.tools.ConsoleConsumerTest > shouldParseValidNewConsumerValidConfig STARTED

kafka.tools.ConsoleConsumerTest > shouldParseValidNewConsumerValidConfig PASSED

kafka.tools.ConsoleConsumerTest > shouldStopWhenOutputCheckErrorFails STARTED

kafka.tools.ConsoleConsumerTest > shouldStopWhenOutputCheckErrorFails PASSED

kafka.tools.ConsoleConsumerTest > 
shouldParseValidNewSimpleConsumerValidConfigWithStringOffset STARTED

kafka.tools.ConsoleConsumerTest > 
shouldParseValidNewSimpleConsumerValidConfigWithStringOffset PASSED

kafka.tools.ConsoleConsumerTest > shouldParseConfigsFromFile STARTED

kafka.tools.ConsoleConsumerTest > shouldParseConfigsFromFile PASSED

kafka.tools.ConsoleConsumerTest > 
shouldParseValidNewSimpleConsumerValidConfigWithNumericOffset STARTED

kafka.tools.ConsoleConsumerTest > 
shouldParseValidNewSimpleConsumerValidConfigWithNumericOffset PASSED

kafka.tools.ConsoleConsumerTest > testDefaultConsumer STARTED

kafka.tools.ConsoleConsumerTest > testDefaultConsumer PASSED

kafka.tools.ConsoleConsumerTest > shouldParseValidOldConsumerValidConfig STARTED

kafka.tools.ConsoleConsumerTest > shouldParseValidOldConsumerValidConfig PASSED

kafka.security.auth.PermissionTypeTest > testJavaConversions STARTED

kafka.security.auth.PermissionTypeTest > testJavaConversions PASSED

kafka.security.auth.PermissionTypeTest > testFromString STARTED

kafka.security.auth.PermissionTypeTest > testFromString PASSED

kafka.security.auth.ResourceTypeTest > testJavaConversions STARTED

kafka.security.auth.ResourceTypeTest > testJavaConversions PASSED

kafka.security.auth.ResourceTypeTest > testFromString STARTED

kafka.security.auth.ResourceTypeTest > testFromString PASSED

kafka.security.auth.OperationTest > testJavaConversions STARTED

kafka.security.auth.OperationTest > testJavaConversions PASSED

kafka.security.auth.AclTest > testAclJsonConversion STARTED

kafka.security.auth.AclTest > testAclJsonConversion PASSED

kafka.security.auth.ZkAuthorizationTest > classMethod STARTED

kafka.security.auth.ZkAuthorizationTest > classMethod FAILED
java.lang.AssertionError: Found unexpected threads, 
allThreads=Set(ZkClient-EventThread-41440-127.0.0.1:49291, 
/0:0:0:0:0:0:0:1:58020 to /0:0:0:0:0:0:0:1:45393 workers Thread 2, 
ThrottledRequestReaper-Produce, SessionTracker, metrics-meter-tick-thread-2, 
main, Signal Dispatcher, /0:0:0:0:0:0:0:1:58020 to /0:0:0:0:0:0:0:1:45393 
workers Thread 3, Reference Handler, ExpirationReaper-0-Produce, 
ExpirationReaper-0-DeleteRecords, ThrottledRequestReaper-Fetch, 
ThrottledRequestReaper-Request, kafka-request-handler-2, Test worker, 
SyncThread:0, ReplicaFetcherThread-0-1, Test 
worker-SendThread(127.0.0.1:49291), NIOServerCxn.Factory:/127.0.0.1:0, Test 
worker-EventThread, ExpirationReaper-0-Fetch, ProcessThread(sid:0 
cport:49291):, Finalizer, kafka-coordinator-heartbeat-thread | group1, 
metrics-meter-tick-thread-1)

kafka.security.auth.ZkAuthorizationTest > classMethod STARTED

kafka.security.auth.ZkAuthorizationTest > classMethod FAILED
java.lang.AssertionError: Found unexpected threads, 
allThreads=Set(ZkClient-EventThread-41440-127.0.0.1:49291, 
/0:0:0:0:0:0:0:1:58020 to /0:0:0:0:0:0:0:1:45393 workers Thread 2, 
ThrottledRequestReaper-Produce, SessionTracker, metrics-meter-tick-thread-2, 
main, Signal Dispatcher, /0:0:0:0:0:0:0:1:58020 to /0:0:0:0:0:0:0:1:45393 
workers Thread 3, Reference Handler, ExpirationReaper-0-Produce, 
ExpirationReaper-0-DeleteRecords, ThrottledRequestReaper-Fetch, 
ThrottledRequestReaper-Request, kafka-request-handler-2, Test worker, 
SyncThread:0, ReplicaFetcherThread-0-1, Test 
worker-SendThread(127.0.0.1:49291), NIOServerCxn.Factory:/127.0.0.1:0, Test 
worker-EventThread, ExpirationReaper-0-Fetch, ProcessThread(sid:0 
cport:49291):, Finalizer, kafka-coordinator-heartbeat-thread | group1, 
metrics-meter-tick-thread-1)

kafka.security.auth.SimpleAclAuthorizerTest > classMethod STARTED

kafka.security.auth.SimpleAclAuthorizerTest > classMethod FAILED
java.lang.AssertionError: Found unexpected threads, 
allThreads=Set(ZkClient-EventThread-41440-127.0.0.1:49291, 
/0:0:0:0:0:0:0:1:58020 to /0:0:0:0:0:0:0:1:45393 workers Thread 2, 
ThrottledRequestReaper-Produce, SessionTracker, metrics-meter-tick-thread-2, 

[GitHub] kafka pull request #3481: MINOR: Configuration name corrected in the upgrade...

[Kamal15]

GitHub user Kamal15 opened a pull request:

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

MINOR: Configuration name corrected in the upgrade docs.



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

$ git pull https://github.com/Kamal15/kafka upgrade_doc

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

https://github.com/apache/kafka/pull/3481.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 #3481


commit a73b0c4793516f8028be4e60d5e00730b744f26f
Author: Kamal C 
Date:   2017-07-03T16:49:21Z

MINOR: Configuration name corrected in the upgrade docs.




---
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.
---

[GitHub] kafka pull request #3479: MINOR: compatibility tests for streams

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[GitHub] kafka pull request #3473: MINOR: Follow-up Streams doc changes to break into...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (KAFKA-5530) Balancer is dancing with KStream all the time, and due to that Kafka cannot work :-)

[Seweryn Habdank-Wojewodzki (JIRA)]

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

Seweryn Habdank-Wojewodzki resolved KAFKA-5530.
---
Resolution: Not A Bug

The main problem, at least what we had observed at the end, was that our was 
simply *_too_* small.

Currently we set: max.poll.interval.ms=100 and Kafka Stream (consuming one) 
is starting properly.

Perhaps it would be good to have some hint in documentation, that 
max.poll.interval.ms should not be too small, as it will cause endless 
rebalancing. 

The implicit explanation is here:
If poll() is not called before expiration of this timeout, then the consumer is 
considered failed and the group will rebalance in order to reassign the 
partitions to another member. 

But explicitely it is not stated, that max.poll.interval.ms shall be somewhat 
big :-).

> Balancer is dancing with KStream all the time, and due to that Kafka cannot 
> work :-)
> 
>
> Key: KAFKA-5530
> URL: https://issues.apache.org/jira/browse/KAFKA-5530
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 0.10.2.0, 0.10.2.1, 0.11.0.0
> Environment: Linux, Windows
>Reporter: Seweryn Habdank-Wojewodzki
> Attachments: streamer_20-topics_1-thread-K-0.11.0.0.log.zip, 
> streamer_20-topics_4-threads-K-0.11.0.0.log.zip, 
> streamer_2-topics_1-thread-K-0.11.0.0.log.zip, 
> streamer_2-topics_4_threads-K-0.11.0.0.log.zip
>
>
> Dears,
> There are problems with balancer in KStreams (v. 0.10.2.x), when 
> _num.stream.threads_ is bigger than 1 and the number of the input topics are 
> bigger than 1.
> I am doing more less such a setup in the code:
> {code:java}
> // loop over the inTopicName(s) {
> KStream stringInput = kBuilder.stream( STRING_SERDE, 
> STRING_SERDE, inTopicName );
> stringInput.filter( streamFilter::passOrFilterMessages ).map( ndmNormalizer 
> ).to( outTopicName );
> // } end of loop
> streams = new KafkaStreams( kBuilder, streamsConfig );
> streams.cleanUp();
> streams.start();
> {code}
> And if there are *_num.stream.threads=4_* but there are 2 or more but less 
> than num.stream.threads inTopicNames, then complete application startup is 
> totally self-blocked, by writing endless starnge things in log and not 
> starting.
> Even more problematic is when the nuber of topics is higher than 
> _num.stream.threads_ what I had commented in *KAFKA-5167 streams task gets 
> stuck after re-balance due to LockException*.
> I am attaching logs for two scenarios:
>  * when: 1 < num.stream.threads < numer of topics (KAFKA-5167)
>  * when: 1 < numer of topics < num.stream.threads (this ticket).
> I can fully reproduce the behaviour. Even I found workaround for it, but is 
> not desired. When _num.stream.threads=1_ than all works fine :-( (for K v. 
> 0.10.2.x, v. 0.11.0.0 does not work at all).
> {code:bash}
> 2017-06-27 19:45:00 INFO StreamPartitionAssignor:466 - stream-thread 
> [StreamThread-3] Assigned tasks to clients as 
> {de0ead97-89d8-49b0-be84-876ca5b41cd8=[activeTasks: ([]) assignedTasks: ([]) 
> prevActiveTasks: ([]) prevAssignedTasks: ([]) capacity: 2.0 cost: 0.0]}.
> 2017-06-27 19:45:00 INFO AbstractCoordinator:375 - Successfully joined group 
> stream with generation 2701
> 2017-06-27 19:45:00 INFO AbstractCoordinator:375 - Successfully joined group 
> stream with generation 2701
> 2017-06-27 19:45:00 INFO ConsumerCoordinator:252 - Setting newly assigned 
> partitions [] for group stream
> 2017-06-27 19:45:00 INFO ConsumerCoordinator:252 - Setting newly assigned 
> partitions [] for group stream
> 2017-06-27 19:45:00 INFO StreamThread:228 - stream-thread [StreamThread-3] 
> New partitions [[]] assigned at the end of consumer rebalance.
> 2017-06-27 19:45:00 INFO StreamThread:228 - stream-thread [StreamThread-1] 
> New partitions [[]] assigned at the end of consumer rebalance.
> 2017-06-27 19:45:00 INFO ConsumerCoordinator:393 - Revoking previously 
> assigned partitions [] for group stream
> 2017-06-27 19:45:00 INFO StreamThread:254 - stream-thread [StreamThread-1] 
> partitions [[]] revoked at the beginning of consumer rebalance.
> 2017-06-27 19:45:00 INFO StreamThread:1012 - stream-thread [StreamThread-1] 
> Updating suspended tasks to contain active tasks [[]]
> 2017-06-27 19:45:00 INFO StreamThread:1019 - stream-thread [StreamThread-1] 
> Removing all active tasks [[]]
> 2017-06-27 19:45:00 INFO StreamThread:1034 - stream-thread [StreamThread-1] 
> Removing all standby tasks [[]]
> 2017-06-27 19:45:00 INFO AbstractCoordinator:407 - (Re-)joining group stream
> 2017-06-27 19:45:00 INFO StreamPartitionAssignor:290 - stream-thread 
> [StreamThread-1] Constructed client metadata 
> {de0ead97-89d8-49b0-be84-876ca5b41cd8=ClientMetadata{hostInfo=null, 
> 

[jira] [Created] (KAFKA-5552) testTransactionalProducerTopicAuthorizationExceptionInCommit fails

[Eno Thereska (JIRA)]

Eno Thereska created KAFKA-5552:
---

 Summary: 
testTransactionalProducerTopicAuthorizationExceptionInCommit fails 
 Key: KAFKA-5552
 URL: https://issues.apache.org/jira/browse/KAFKA-5552
 Project: Kafka
  Issue Type: Bug
  Components: core
Affects Versions: 0.11.0.0
Reporter: Eno Thereska
 Fix For: 0.11.1.0


Got a unit test error: 
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/5877/

Error Message

org.apache.kafka.common.KafkaException: Cannot execute transactional method 
because we are in an error state
Stacktrace

org.apache.kafka.common.KafkaException: Cannot execute transactional method 
because we are in an error state
at 
org.apache.kafka.clients.producer.internals.TransactionManager.maybeFailWithError(TransactionManager.java:524)
at 
org.apache.kafka.clients.producer.internals.TransactionManager.beginCommit(TransactionManager.java:190)
at 
org.apache.kafka.clients.producer.KafkaProducer.commitTransaction(KafkaProducer.java:583)
at 
kafka.api.AuthorizerIntegrationTest.testTransactionalProducerTopicAuthorizationExceptionInCommit(AuthorizerIntegrationTest.scala:1027)
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 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
at 

[GitHub] kafka pull request #3480: MINOR: Define the term tombstone, since it's used ...

[tombentley]

GitHub user tombentley opened a pull request:

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

MINOR: Define the term tombstone, since it's used elsewhere in the docs



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

$ git pull https://github.com/tombentley/kafka tombstone

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

https://github.com/apache/kafka/pull/3480.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 #3480


commit 480327c53b6ad5278b5a7a50c043829e6a58be32
Author: Tom Bentley 
Date:   2017-07-03T09:55:49Z

MINOR: Define the term tombstone, since it's used elsewhere in the docs




---
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.
---

[GitHub] kafka pull request #3479: MINOR: compatibility tests for streams

[enothereska]

GitHub user enothereska opened a pull request:

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

MINOR: compatibility tests for streams

Add on to https://github.com/apache/kafka/pull/3454

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

$ git pull https://github.com/enothereska/kafka minor-compatibility-tests

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

https://github.com/apache/kafka/pull/3479.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 #3479


commit 0953c6b638d14b7cce493b661abdfe3ae1423b20
Author: Eno Thereska 
Date:   2017-07-03T08:31:57Z

Updated tests

commit 1d00d8a3acb638e2830064ae7ac59184241f6301
Author: Eno Thereska 
Date:   2017-07-03T09:22:48Z

Removed unneeded test




---
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.
---

[GitHub] kafka pull request #3478: KAFKA-3539: KafkaProducer.send() should not block

[evis]

GitHub user evis opened a pull request:

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

KAFKA-3539: KafkaProducer.send() should not block

Just wrapped current `doSend()` method invocation into another `Future` to 
get rid of blocking while calling `KafkaProducer#send()`. I know, that a lot of 
tests will be failed (including one I added), just want to know, is it 
appropriate to do such thing? If it is, I will try to fix tests.

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

$ git pull https://github.com/evis/kafka 3539-producer-send-blocks

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

https://github.com/apache/kafka/pull/3478.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 #3478


commit add2c39023dda5a5c49cba69fb7a467bf57d8eda
Author: Evgeny Veretennikov 
Date:   2017-07-03T09:18:50Z

KAFKA-3539: KafkaProducer.send() should not block




---
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.
---

[GitHub] kafka pull request #3428: HOTFIX: Add back the copy-constructor of abstract ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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.
---

[GitHub] kafka pull request #3477: KAFKA-1044: eliminating log4j from core

[viktorsomogyi]

GitHub user viktorsomogyi opened a pull request:

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

KAFKA-1044: eliminating log4j from core

The aim of this PR to move kafka core/main away from log4j and introduce 
using slf4j only.
To accomplish this task I:
- refactored Log4jController into its own module as it is very tightly 
coupled with log4j (and removing these dependencies would have been impossible 
without feature loss).
- as log4j supports FATAL level but slf4j doesn't, I introduced a FATAL 
marker similarly to the log4j-slf4j bridge

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

$ git pull https://github.com/viktorsomogyi/kafka KAFKA-1044

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

https://github.com/apache/kafka/pull/3477.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 #3477


commit 9abe1a37c2ca4f9ea95fdee394b7135ad779d971
Author: Viktor Somogyi 
Date:   2017-06-08T22:22:36Z

KAFKA-1044: eliminating log4j from core




---
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.
---