Build failed in Jenkins: kafka-0.10.1-jdk7 #135

[Apache Jenkins Server]

See 

--
[...truncated 588.74 KB...]
org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldMapUserEndPointToTopicPartitions PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldAddUserDefinedEndPointToSubscription STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldAddUserDefinedEndPointToSubscription PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithStandbyReplicas STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithStandbyReplicas PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithNewTasks STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithNewTasks PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldExposeHostStateToTopicPartitionsOnAssignment STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldExposeHostStateToTopicPartitionsOnAssignment PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldReturnLowestAssignmentVersionForDifferentSubscriptionVersions STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldReturnLowestAssignmentVersionForDifferentSubscriptionVersions PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithStates STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithStates PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldThrowExceptionIfApplicationServerConfigPortIsNotAnInteger STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldThrowExceptionIfApplicationServerConfigPortIsNotAnInteger PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldDownGradeSubscription STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldDownGradeSubscription PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldReturnEmptyClusterMetadataIfItHasntBeenBuilt STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldReturnEmptyClusterMetadataIfItHasntBeenBuilt PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignBasic STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignBasic PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testOnAssignment STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testOnAssignment PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithInternalTopicThatsSourceIsAnotherInternalTopic STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithInternalTopicThatsSourceIsAnotherInternalTopic PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testSubscription STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testSubscription PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldSetClusterMetadataOnAssignment STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
shouldSetClusterMetadataOnAssignment PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithInternalTopics STARTED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithInternalTopics PASSED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
shouldNotAllowNullProcessorSupplier STARTED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
shouldNotAllowNullProcessorSupplier PASSED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
shouldNotSetApplicationIdToNull STARTED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
shouldNotSetApplicationIdToNull PASSED

org.apache.kafka.streams.processor.TopologyBuilderTest > testSourceTopics 
STARTED

org.apache.kafka.streams.processor.TopologyBuilderTest > testSourceTopics PASSED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
shouldNotAllowNullNameWhenAddingSink STARTED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
shouldNotAllowNullNameWhenAddingSink PASSED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
testNamedTopicMatchesAlreadyProvidedPattern STARTED

org.apache.kafka.streams.processor.TopologyBuilderTest > 
testNamedTopicMatchesAlreadyProvidedPattern PASSED

org.apache.kafka.streams.processor.TopologyBuilderTest > 

Build failed in Jenkins: kafka-0.11.0-jdk7 #367

[Apache Jenkins Server]

See 

--
[...truncated 2.45 MB...]

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToCommitMultiplePartitionOffsets PASSED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToRunWithTwoSubtopologies STARTED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToRunWithTwoSubtopologies PASSED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldNotViolateEosIfOneTaskGetsFencedUsingIsolatedAppInstances STARTED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldNotViolateEosIfOneTaskGetsFencedUsingIsolatedAppInstances PASSED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldNotViolateEosIfOneTaskFailsWithState STARTED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldNotViolateEosIfOneTaskFailsWithState PASSED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToRunWithTwoSubtopologiesAndMultiplePartitions STARTED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToRunWithTwoSubtopologiesAndMultiplePartitions PASSED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToRestartAfterClose STARTED

org.apache.kafka.streams.integration.EosIntegrationTest > 
shouldBeAbleToRestartAfterClose PASSED

org.apache.kafka.streams.integration.GlobalKTableIntegrationTest > 
shouldKStreamGlobalKTableLeftJoin STARTED

org.apache.kafka.streams.integration.GlobalKTableIntegrationTest > 
shouldKStreamGlobalKTableLeftJoin PASSED

org.apache.kafka.streams.integration.GlobalKTableIntegrationTest > 
shouldRestoreTransactionalMessages STARTED

org.apache.kafka.streams.integration.GlobalKTableIntegrationTest > 
shouldRestoreTransactionalMessages PASSED

org.apache.kafka.streams.integration.GlobalKTableIntegrationTest > 
shouldKStreamGlobalKTableJoin STARTED

org.apache.kafka.streams.integration.GlobalKTableIntegrationTest > 
shouldKStreamGlobalKTableJoin PASSED

org.apache.kafka.streams.integration.InternalTopicIntegrationTest > 
shouldCompactTopicsForStateChangelogs STARTED

org.apache.kafka.streams.integration.InternalTopicIntegrationTest > 
shouldCompactTopicsForStateChangelogs PASSED

org.apache.kafka.streams.integration.InternalTopicIntegrationTest > 
shouldUseCompactAndDeleteForWindowStoreChangelogs STARTED

org.apache.kafka.streams.integration.InternalTopicIntegrationTest > 
shouldUseCompactAndDeleteForWindowStoreChangelogs PASSED

org.apache.kafka.streams.StreamsConfigTest > shouldUseNewConfigsWhenPresent 
STARTED

org.apache.kafka.streams.StreamsConfigTest > shouldUseNewConfigsWhenPresent 
PASSED

org.apache.kafka.streams.StreamsConfigTest > testGetConsumerConfigs STARTED

org.apache.kafka.streams.StreamsConfigTest > testGetConsumerConfigs PASSED

org.apache.kafka.streams.StreamsConfigTest > shouldAcceptAtLeastOnce STARTED

org.apache.kafka.streams.StreamsConfigTest > shouldAcceptAtLeastOnce PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldUseCorrectDefaultsWhenNoneSpecified STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldUseCorrectDefaultsWhenNoneSpecified PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldAllowSettingProducerEnableIdempotenceIfEosDisabled STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldAllowSettingProducerEnableIdempotenceIfEosDisabled PASSED

org.apache.kafka.streams.StreamsConfigTest > defaultSerdeShouldBeConfigured 
STARTED

org.apache.kafka.streams.StreamsConfigTest > defaultSerdeShouldBeConfigured 
PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldSetDifferentDefaultsIfEosEnabled STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldSetDifferentDefaultsIfEosEnabled PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldNotOverrideUserConfigRetriesIfExactlyOnceEnabled STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldNotOverrideUserConfigRetriesIfExactlyOnceEnabled PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldSupportPrefixedConsumerConfigs STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldSupportPrefixedConsumerConfigs PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldOverrideStreamsDefaultConsumerConfigs STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldOverrideStreamsDefaultConsumerConfigs PASSED

org.apache.kafka.streams.StreamsConfigTest > testGetProducerConfigs STARTED

org.apache.kafka.streams.StreamsConfigTest > testGetProducerConfigs PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldAllowSettingProducerMaxInFlightRequestPerConnectionsWhenEosDisabled 
STARTED

org.apache.kafka.streams.StreamsConfigTest > 
shouldAllowSettingProducerMaxInFlightRequestPerConnectionsWhenEosDisabled PASSED

org.apache.kafka.streams.StreamsConfigTest > 
shouldThrowStreamsExceptionIfValueSerdeConfigFails STARTED

org.apache.kafka.streams.StreamsConfigTest > 

Jenkins build is back to normal : kafka-0.10.2-jdk7 #209

[Apache Jenkins Server]

See 

Build failed in Jenkins: kafka-0.10.0-jdk7 #219

[Apache Jenkins Server]

See 

--
[...truncated 228.63 KB...]

org.apache.kafka.streams.kstream.TimeWindowsTest > advanceIntervalMustNotBeZero 
PASSED

org.apache.kafka.streams.kstream.TimeWindowsTest > windowSizeMustNotBeNegative 
PASSED

org.apache.kafka.streams.kstream.TimeWindowsTest > 
advanceIntervalMustNotBeNegative PASSED

org.apache.kafka.streams.kstream.TimeWindowsTest > 
advanceIntervalMustNotBeLargerThanWindowSize PASSED

org.apache.kafka.streams.kstream.TimeWindowsTest > windowsForTumblingWindows 
PASSED

org.apache.kafka.streams.kstream.TimeWindowsTest > windowsForHoppingWindows 
PASSED

org.apache.kafka.streams.kstream.TimeWindowsTest > 
windowsForBarelyOverlappingHoppingWindows PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > afterBelowLower PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > nameMustNotBeEmpty PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > beforeOverUpper PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > nameMustNotBeNull PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > 
shouldHaveSaneEqualsAndHashCode PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > validWindows PASSED

org.apache.kafka.streams.kstream.JoinWindowsTest > 
timeDifferenceMustNotBeNegative PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > nameMustNotBeEmpty 
PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > 
startTimeMustNotBeNegative PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > 
shouldIncludeRecordsThatHappenedOnWindowStart PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > nameMustNotBeNull PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > startTimeCanBeZero 
PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > 
shouldIncludeRecordsThatHappenedAfterWindowStart PASSED

org.apache.kafka.streams.kstream.UnlimitedWindowsTest > 
shouldExcludeRecordsThatHappenedBeforeWindowStart PASSED

org.apache.kafka.streams.kstream.KStreamBuilderTest > testMerge PASSED

org.apache.kafka.streams.kstream.KStreamBuilderTest > testFrom PASSED

org.apache.kafka.streams.kstream.KStreamBuilderTest > testNewName PASSED

org.apache.kafka.streams.processor.internals.StreamTaskTest > testProcessOrder 
PASSED

org.apache.kafka.streams.processor.internals.StreamTaskTest > testPauseResume 
PASSED

org.apache.kafka.streams.processor.internals.StreamTaskTest > 
testMaybePunctuate PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testRegisterNonPersistentStore PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testLockStateDirectory PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testGetStore PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testClose PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testChangeLogOffsets PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testRegisterPersistentStore PASSED

org.apache.kafka.streams.processor.internals.ProcessorStateManagerTest > 
testNoTopic PASSED

org.apache.kafka.streams.processor.internals.RecordCollectorTest > 
testSpecificPartition PASSED

org.apache.kafka.streams.processor.internals.RecordCollectorTest > 
testStreamPartitioner PASSED

org.apache.kafka.streams.processor.internals.PartitionGroupTest > 
testTimeTracking PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithStandbyReplicas PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithNewTasks PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithStates PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignBasic PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testOnAssignment PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testSubscription PASSED

org.apache.kafka.streams.processor.internals.StreamPartitionAssignorTest > 
testAssignWithInternalTopics PASSED

org.apache.kafka.streams.processor.internals.ProcessorTopologyTest > 
testDrivingMultiplexingTopology PASSED

org.apache.kafka.streams.processor.internals.ProcessorTopologyTest > 
testDrivingStatefulTopology PASSED

org.apache.kafka.streams.processor.internals.ProcessorTopologyTest > 
testDrivingSimpleTopology PASSED

org.apache.kafka.streams.processor.internals.ProcessorTopologyTest > 
testTopologyMetadata PASSED

org.apache.kafka.streams.processor.internals.ProcessorTopologyTest > 
testDrivingMultiplexByNameTopology PASSED

org.apache.kafka.streams.processor.internals.StreamThreadTest > 
testInjectClients PASSED

org.apache.kafka.streams.processor.internals.StreamThreadTest > testMaybeCommit 
PASSED

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

[Apache Jenkins Server]

See 


Changes:

[wangguoz] MINOR: Streams web doc table fix (#4942)

[wangguoz] Fix streams web doc configs tables (#4943)

--
[...truncated 3.60 MB...]
kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithSuccessOnAddPartitionsWhenStateIsCompleteAbort STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithSuccessOnAddPartitionsWhenStateIsCompleteAbort PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldWaitForCommitToCompleteOnHandleInitPidAndExistingTransactionInPrepareAbortState
 STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldWaitForCommitToCompleteOnHandleInitPidAndExistingTransactionInPrepareAbortState
 PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithErrorsNoneOnAddPartitionWhenNoErrorsAndPartitionsTheSame 
STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithErrorsNoneOnAddPartitionWhenNoErrorsAndPartitionsTheSame PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithInvalidRequestOnEndTxnWhenTransactionalIdIsEmpty STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithInvalidRequestOnEndTxnWhenTransactionalIdIsEmpty PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithInvalidRequestAddPartitionsToTransactionWhenTransactionalIdIsEmpty
 STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithInvalidRequestAddPartitionsToTransactionWhenTransactionalIdIsEmpty
 PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldAppendPrepareAbortToLogOnEndTxnWhenStatusIsOngoingAndResultIsAbort STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldAppendPrepareAbortToLogOnEndTxnWhenStatusIsOngoingAndResultIsAbort PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldAcceptInitPidAndReturnNextPidWhenTransactionalIdIsNull STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldAcceptInitPidAndReturnNextPidWhenTransactionalIdIsNull PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRemoveTransactionsForPartitionOnEmigration STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRemoveTransactionsForPartitionOnEmigration PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldWaitForCommitToCompleteOnHandleInitPidAndExistingTransactionInPrepareCommitState
 STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldWaitForCommitToCompleteOnHandleInitPidAndExistingTransactionInPrepareCommitState
 PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldAbortExpiredTransactionsInOngoingStateAndBumpEpoch STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldAbortExpiredTransactionsInOngoingStateAndBumpEpoch PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldReturnInvalidTxnRequestOnEndTxnRequestWhenStatusIsCompleteCommitAndResultIsNotCommit
 STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldReturnInvalidTxnRequestOnEndTxnRequestWhenStatusIsCompleteCommitAndResultIsNotCommit
 PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldReturnOkOnEndTxnWhenStatusIsCompleteCommitAndResultIsCommit STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldReturnOkOnEndTxnWhenStatusIsCompleteCommitAndResultIsCommit PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithConcurrentTransactionsOnAddPartitionsWhenStateIsPrepareCommit 
STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithConcurrentTransactionsOnAddPartitionsWhenStateIsPrepareCommit 
PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldIncrementEpochAndUpdateMetadataOnHandleInitPidWhenExistingCompleteTransaction
 STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldIncrementEpochAndUpdateMetadataOnHandleInitPidWhenExistingCompleteTransaction
 PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldGenerateNewProducerIdIfEpochsExhausted STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldGenerateNewProducerIdIfEpochsExhausted PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithNotCoordinatorOnInitPidWhenNotCoordinator STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithNotCoordinatorOnInitPidWhenNotCoordinator PASSED

kafka.coordinator.transaction.TransactionCoordinatorTest > 
shouldRespondWithConcurrentTransactionOnAddPartitionsWhenStateIsPrepareAbort 
STARTED

kafka.coordinator.transaction.TransactionCoordinatorTest > 

Build failed in Jenkins: kafka-0.11.0-jdk7 #366

[Apache Jenkins Server]

See 


Changes:

[ismael] MINOR: use jdk8 to build/run system tests (#4925)

--
[...truncated 835.89 KB...]

kafka.api.SslEndToEndAuthorizationTest > testProduceConsumeViaAssign PASSED

kafka.api.SslEndToEndAuthorizationTest > testNoConsumeWithDescribeAclViaAssign 
STARTED

kafka.api.SslEndToEndAuthorizationTest > testNoConsumeWithDescribeAclViaAssign 
PASSED

kafka.api.SslEndToEndAuthorizationTest > 
testNoConsumeWithDescribeAclViaSubscribe STARTED

kafka.api.SslEndToEndAuthorizationTest > 
testNoConsumeWithDescribeAclViaSubscribe PASSED

kafka.api.SslEndToEndAuthorizationTest > 
testNoConsumeWithoutDescribeAclViaAssign STARTED

kafka.api.SslEndToEndAuthorizationTest > 
testNoConsumeWithoutDescribeAclViaAssign PASSED

kafka.api.SslEndToEndAuthorizationTest > testNoGroupAcl STARTED

kafka.api.SslEndToEndAuthorizationTest > testNoGroupAcl PASSED

kafka.api.SslEndToEndAuthorizationTest > testNoProduceWithDescribeAcl STARTED

kafka.api.SslEndToEndAuthorizationTest > testNoProduceWithDescribeAcl PASSED

kafka.api.SslEndToEndAuthorizationTest > testProduceConsumeViaSubscribe STARTED

kafka.api.SslEndToEndAuthorizationTest > testProduceConsumeViaSubscribe PASSED

kafka.api.SslEndToEndAuthorizationTest > testNoProduceWithoutDescribeAcl STARTED

kafka.api.SslEndToEndAuthorizationTest > testNoProduceWithoutDescribeAcl PASSED

kafka.api.SaslPlainPlaintextConsumerTest > testZkAclsDisabled STARTED

kafka.api.SaslPlainPlaintextConsumerTest > testZkAclsDisabled PASSED

kafka.api.SaslPlainPlaintextConsumerTest > testCoordinatorFailover STARTED

kafka.api.SaslPlainPlaintextConsumerTest > testCoordinatorFailover PASSED

kafka.api.SaslPlainPlaintextConsumerTest > testSimpleConsumption STARTED

kafka.api.SaslPlainPlaintextConsumerTest > testSimpleConsumption PASSED

kafka.api.SslProducerSendTest > testSendNonCompressedMessageWithCreateTime 
STARTED

kafka.api.SslProducerSendTest > testSendNonCompressedMessageWithCreateTime 
PASSED

kafka.api.SslProducerSendTest > testClose STARTED

kafka.api.SslProducerSendTest > testClose PASSED

kafka.api.SslProducerSendTest > testFlush STARTED

kafka.api.SslProducerSendTest > testFlush PASSED

kafka.api.SslProducerSendTest > testSendToPartition STARTED

kafka.api.SslProducerSendTest > testSendToPartition PASSED

kafka.api.SslProducerSendTest > testSendOffset STARTED

kafka.api.SslProducerSendTest > testSendOffset PASSED

kafka.api.SslProducerSendTest > testSendCompressedMessageWithCreateTime STARTED

kafka.api.SslProducerSendTest > testSendCompressedMessageWithCreateTime PASSED

kafka.api.SslProducerSendTest > testCloseWithZeroTimeoutFromCallerThread STARTED

kafka.api.SslProducerSendTest > testCloseWithZeroTimeoutFromCallerThread PASSED

kafka.api.SslProducerSendTest > testCloseWithZeroTimeoutFromSenderThread STARTED

kafka.api.SslProducerSendTest > testCloseWithZeroTimeoutFromSenderThread PASSED

kafka.api.SslProducerSendTest > testSendBeforeAndAfterPartitionExpansion STARTED

kafka.api.SslProducerSendTest > testSendBeforeAndAfterPartitionExpansion PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testAcls STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testAcls PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testTwoConsumersWithDifferentSaslCredentials STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testTwoConsumersWithDifferentSaslCredentials PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithoutDescribeAclViaSubscribe STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithoutDescribeAclViaSubscribe PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testProduceConsumeViaAssign 
STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testProduceConsumeViaAssign 
PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithDescribeAclViaAssign STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithDescribeAclViaAssign PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithDescribeAclViaSubscribe STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithDescribeAclViaSubscribe PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithoutDescribeAclViaAssign STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testNoConsumeWithoutDescribeAclViaAssign PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testNoGroupAcl STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testNoGroupAcl PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testNoProduceWithDescribeAcl 
STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > testNoProduceWithDescribeAcl 
PASSED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testProduceConsumeViaSubscribe STARTED

kafka.api.SaslPlainSslEndToEndAuthorizationTest > 
testProduceConsumeViaSubscribe PASSED

Jenkins build is back to normal : kafka-trunk-jdk7 #3383

[Apache Jenkins Server]

See 

Build failed in Jenkins: kafka-0.10.2-jdk7 #208

[Apache Jenkins Server]

See 


Changes:

[ismael] MINOR: use jdk8 to build/run system tests (#4944)

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-eu3 (ubuntu xenial) in workspace 

Cloning the remote Git repository
Cloning repository https://github.com/apache/kafka.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/0.10.2^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/0.10.2^{commit} # timeout=10
Checking out Revision 3e84c656640fcb366106fa4c5053b65d7f91e5a8 
(refs/remotes/origin/0.10.2)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3e84c656640fcb366106fa4c5053b65d7f91e5a8
Commit message: "MINOR: use jdk8 to build/run system tests (#4944)"
 > git rev-list --no-walk 94e17b4c37b563b5c522d7ff494581b03df54b7c # timeout=10
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
[kafka-0.10.2-jdk7] $ /bin/bash -xe /tmp/jenkins5247399855101501060.sh
+ rm -rf 
+ /bin/gradle
/tmp/jenkins5247399855101501060.sh: line 4: /bin/gradle: No such file or 
directory
Build step 'Execute shell' marked build as failure
Recording test results
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
Not sending mail to unregistered user git...@alasdairhodge.co.uk
Not sending mail to unregistered user ism...@juma.me.uk
Not sending mail to unregistered user rajinisiva...@googlemail.com

Build failed in Jenkins: kafka-0.10.1-jdk7 #134

[Apache Jenkins Server]

See 


Changes:

[ismael] MINOR: use jdk8 to build/run system tests (#4944)

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-eu3 (ubuntu xenial) in workspace 

Cloning the remote Git repository
Cloning repository https://github.com/apache/kafka.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/0.10.1^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/0.10.1^{commit} # timeout=10
Checking out Revision 2a2def1d9f52422231591c810e637433ac3fc160 
(refs/remotes/origin/0.10.1)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 2a2def1d9f52422231591c810e637433ac3fc160
Commit message: "MINOR: use jdk8 to build/run system tests (#4944)"
 > git rev-list --no-walk faac933aeee5d976008a17248650943923728408 # timeout=10
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
[kafka-0.10.1-jdk7] $ /bin/bash -xe /tmp/jenkins3377613501328666319.sh
+ rm -rf 
+ /bin/gradle
/tmp/jenkins3377613501328666319.sh: line 4: /bin/gradle: No such file or 
directory
Build step 'Execute shell' marked build as failure
Recording test results
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
Not sending mail to unregistered user git...@alasdairhodge.co.uk
Not sending mail to unregistered user ism...@juma.me.uk

Jenkins build is back to normal : kafka-1.0-jdk7 #187

[Apache Jenkins Server]

See 

Build failed in Jenkins: kafka-0.10.0-jdk7 #218

[Apache Jenkins Server]

See 


Changes:

[ismael] MINOR: use jdk8 to build/run system tests (#4944)

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on H34 (ubuntu xenial) in workspace 

Cloning the remote Git repository
Cloning repository https://github.com/apache/kafka.git
 > git init  # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
Fetching upstream changes from https://github.com/apache/kafka.git
 > git fetch --tags --progress https://github.com/apache/kafka.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/0.10.0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/0.10.0^{commit} # timeout=10
Checking out Revision 5030b5d9d82bb08d520e07c4cd23e23e3caa58af 
(refs/remotes/origin/0.10.0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 5030b5d9d82bb08d520e07c4cd23e23e3caa58af
Commit message: "MINOR: use jdk8 to build/run system tests (#4944)"
 > git rev-list --no-walk 7fd224d3076c93f2e76feff5a346e40c7602b206 # timeout=10
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
[kafka-0.10.0-jdk7] $ /bin/bash -xe /tmp/jenkins6408694935789180460.sh
+ rm -rf 
+ /bin/gradle
/tmp/jenkins6408694935789180460.sh: line 4: /bin/gradle: No such file or 
directory
Build step 'Execute shell' marked build as failure
Recording test results
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
ERROR: No tool found matching GRADLE_2_4_RC_2_HOME
Not sending mail to unregistered user ism...@juma.me.uk

Re: [DISCUSS] KIP-289: Improve the default group id behavior in KafkaConsumer

[Ted Yu]

bq. If they attempt an offset commit they will receive an error.

Can you outline what specific error would be encountered ?

Thanks

On Fri, Apr 27, 2018 at 2:17 PM, Vahid S Hashemian <
vahidhashem...@us.ibm.com> wrote:

> Hi all,
>
> I have drafted a proposal for improving the behavior of KafkaConsumer when
> using the default group id:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 289%3A+Improve+the+default+group+id+behavior+in+KafkaConsumer
> The proposal based on the issue and suggestion reported in KAFKA-6774.
>
> Your feedback is welcome!
>
> Thanks.
> --Vahid
>
>

Build failed in Jenkins: kafka-trunk-jdk7 #3382

[Apache Jenkins Server]

See 


Changes:

[github] HOTFIX: rename run_test to execute in streams simple benchmark (#4941)

[wangguoz] MINOR: Streams web doc table fix (#4942)

--
[...truncated 415.21 KB...]
kafka.server.epoch.LeaderEpochFileCacheTest > shouldClearEarliestOnEmptyCache 
PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldPreserveResetOffsetOnClearEarliestIfOneExists STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldPreserveResetOffsetOnClearEarliestIfOneExists PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldUpdateOffsetBetweenEpochBoundariesOnClearEarliest STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldUpdateOffsetBetweenEpochBoundariesOnClearEarliest PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldReturnInvalidOffsetIfEpochIsRequestedWhichIsNotCurrentlyTracked STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldReturnInvalidOffsetIfEpochIsRequestedWhichIsNotCurrentlyTracked PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > shouldFetchEndOffsetOfEmptyCache 
STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > shouldFetchEndOffsetOfEmptyCache 
PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldRetainLatestEpochOnClearAllEarliestAndUpdateItsOffset STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldRetainLatestEpochOnClearAllEarliestAndUpdateItsOffset PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > shouldClearAllEntries STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > shouldClearAllEntries PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > shouldClearLatestOnEmptyCache 
STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > shouldClearLatestOnEmptyCache 
PASSED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldNotResetEpochHistoryHeadIfUndefinedPassed STARTED

kafka.server.epoch.LeaderEpochFileCacheTest > 
shouldNotResetEpochHistoryHeadIfUndefinedPassed PASSED

kafka.server.epoch.LeaderEpochIntegrationTest > 
shouldIncreaseLeaderEpochBetweenLeaderRestarts STARTED

kafka.server.epoch.LeaderEpochIntegrationTest > 
shouldIncreaseLeaderEpochBetweenLeaderRestarts PASSED

kafka.server.epoch.LeaderEpochIntegrationTest > 
shouldAddCurrentLeaderEpochToMessagesAsTheyAreWrittenToLeader STARTED

kafka.server.epoch.LeaderEpochIntegrationTest > 
shouldAddCurrentLeaderEpochToMessagesAsTheyAreWrittenToLeader PASSED

kafka.server.epoch.LeaderEpochIntegrationTest > 
shouldSendLeaderEpochRequestAndGetAResponse STARTED

kafka.server.epoch.LeaderEpochIntegrationTest > 
shouldSendLeaderEpochRequestAndGetAResponse PASSED

kafka.server.epoch.OffsetsForLeaderEpochTest > shouldGetEpochsFromReplica 
STARTED

kafka.server.epoch.OffsetsForLeaderEpochTest > shouldGetEpochsFromReplica PASSED

kafka.server.epoch.OffsetsForLeaderEpochTest > 
shouldReturnUnknownTopicOrPartitionIfThrown STARTED

kafka.server.epoch.OffsetsForLeaderEpochTest > 
shouldReturnUnknownTopicOrPartitionIfThrown PASSED

kafka.server.epoch.OffsetsForLeaderEpochTest > 
shouldReturnNoLeaderForPartitionIfThrown STARTED

kafka.server.epoch.OffsetsForLeaderEpochTest > 
shouldReturnNoLeaderForPartitionIfThrown PASSED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
shouldSurviveFastLeaderChange STARTED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
shouldSurviveFastLeaderChange PASSED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
offsetsShouldNotGoBackwards STARTED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
offsetsShouldNotGoBackwards PASSED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
shouldFollowLeaderEpochBasicWorkflow STARTED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
shouldFollowLeaderEpochBasicWorkflow PASSED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
shouldNotAllowDivergentLogs STARTED

kafka.server.epoch.EpochDrivenReplicationProtocolAcceptanceTest > 
shouldNotAllowDivergentLogs PASSED

kafka.server.ScramServerStartupTest > testAuthentications STARTED

kafka.server.ScramServerStartupTest > testAuthentications PASSED

kafka.server.MultipleListenersWithAdditionalJaasContextTest > 
testProduceConsume STARTED
ERROR: Could not install GRADLE_3_5_HOME
java.lang.NullPointerException
at 
hudson.plugins.toolenv.ToolEnvBuildWrapper$1.buildEnvVars(ToolEnvBuildWrapper.java:46)
at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:895)
at hudson.plugins.git.GitSCM.getParamExpandedRepos(GitSCM.java:458)
at 
hudson.plugins.git.GitSCM.compareRemoteRevisionWithImpl(GitSCM.java:666)
at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:631)
at hudson.scm.SCM.compareRemoteRevisionWith(SCM.java:391)
at hudson.scm.SCM.poll(SCM.java:408)
at hudson.model.AbstractProject._poll(AbstractProject.java:1384)
at 

[jira] [Created] (KAFKA-6834) log cleaner should handle the case when the size of a message set is larger than the max message size

[Jun Rao (JIRA)]

Jun Rao created KAFKA-6834:
--

 Summary: log cleaner should handle the case when the size of a 
message set is larger than the max message size
 Key: KAFKA-6834
 URL: https://issues.apache.org/jira/browse/KAFKA-6834
 Project: Kafka
  Issue Type: Bug
Reporter: Jun Rao


In KAFKA-5316, we added the logic to allow a message (set) larger than the per 
topic message size to be written to the log during log cleaning. However, the 
buffer size in the log cleaner is still bounded by the per topic message size. 
This can cause the log cleaner to die and cause the broker to run out of disk 
space.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[DISCUSS] KIP-289: Improve the default group id behavior in KafkaConsumer

[Vahid S Hashemian]

Hi all,

I have drafted a proposal for improving the behavior of KafkaConsumer when 
using the default group id: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-289%3A+Improve+the+default+group+id+behavior+in+KafkaConsumer
The proposal based on the issue and suggestion reported in KAFKA-6774.

Your feedback is welcome!

Thanks.
--Vahid

Re: Kafka mirror maker help

[Peter Bukowinski]

I run instances of Mirror Maker as supervisord tasks (http://supervisord.org 
). I’d recommend looking into it. In addition to 
letting you sidestep the service issue, supervisord watches the processes and 
can auto-restart them if they stop for any reason.

—
Peter Bukowinski

> On Apr 27, 2018, at 11:58 AM, Hans Jespersen  wrote:
> 
> Sorry I hit send a bit too soon. I was so focused on the systemd part of
> the email and not the Mirror Maker part.
> Confluent packages include Mirror Maker but the systemd scripts are setup
> to use Confluent Replicator rather than Mirror Maker.
> My apologies.
> 
> -hans
> 
> /**
> * Hans Jespersen, Director Systems Engineering, Confluent Inc.
> * h...@confluent.io (650)924-2670
> */
> 
> On Fri, Apr 27, 2018 at 11:56 AM, Hans Jespersen  wrote:
> 
>> The latest Confluent packages now ship with systemd scripts. That is since
>> Confluent Version 4.1 - which included Apache Kafka 1.1
>> 
>> -hans
>> 
>> /**
>> * Hans Jespersen, Director Systems Engineering, Confluent Inc.
>> * h...@confluent.io (650)924-2670
>> */
>> 
>> On Fri, Apr 27, 2018 at 11:15 AM, Andrew Otto  wrote:
>> 
>>> Hiya,
>>> 
>>> Saravanan, I saw you emailed my colleague Alex about WMF’s old debian
>>> packaging.  I’ll reply here.
>>> 
>>> We now use Confluent’s Kafka debian packaging which does not (or did not?)
>>> ship with init scripts.  We don’t use Sys V init.d scripts anymore either,
>>> but use systemd instead.  Our systemd service unit (ERB template format)
>>> is
>>> here:
>>> 
>>> https://github.com/wikimedia/puppet/blob/production/modules/
>>> confluent/templates/initscripts/kafka-mirror-instance.systemd.erb
>>> 
>>> 
>>> 
>>> On Fri, Apr 27, 2018 at 1:35 AM, Amrit Jangid 
>>> wrote:
>>> 
 You should share related info, such source-destination Kafka versions,
 sample Config or error if any.
 
 FYI,  Go through
 https://kafka.apache.org/documentation/#basic_ops_mirror_maker
 
>>> 
>> 
>> 

Re: [VOTE] KIP-219 - Improve Quota Communication

[Jonghyun Lee]

Thanks, Becket.

Assuming that requiring new client implementations to issue
ApiVersionsRequest before issuing any other requests is reasonable as you
mentioned, I am wondering if keeping track of brokers that support KIP-219
is actually simpler than keeping a map from each request type to its min
version number supporting KIP-219 and checking the version of every single
request to see whether or not to throttle from the client side. To me, it
looks like a broker property that can be cached, and checking every single
request seems excessive.

Thanks,
Jon




On Fri, Apr 27, 2018 at 11:36 AM, Becket Qin  wrote:

> The reason we wanted to bump up all the request versions was let the
> clients know whether the broker has already throttled the request or not.
> This avoids double throttling in both brokers and clients, if the clients
> implementation supports KIP-219.
>
> The new change uses only ApiVersionRequest, instead of all the requests, to
> indicate whether the brokers have applied throttling or not. The difference
> is that all the clients must issue ApiVersionRequest first before issuing
> any other requests. This has no impact on the existing clients. But for
> clients implementation that wants to support KIP-219, they need to follow
> this practice, which seems to be reasonable.
> Initially I thought the change is fine. However, thinking about this again,
> that means the clients implementation needs to remember the ApiVersions of
> each broker, which may have some complexity. Also this seems introduces the
> behavior dependency between different requests, which seems unnecessary.
>
> Due to the above reasons, I think it might be better to bump up all the
> request versions.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
>
> On Wed, Apr 25, 2018 at 3:19 PM, Jonghyun Lee  wrote:
>
> > Hello,
> >
> > Per Ismael's suggestion, I'd like to get comments from the original
> voters
> > for KIP-219 (Becket, Jun, Rajini) and others about the new interface
> change
> > proposed in the discussion thread (
> > https://markmail.org/search/?q=kafka+KIP-219#query:kafka%
> > 20KIP-219+page:1+mid:5rwju2gwpicojr3f+state:results).
> > Would you let me know?
> >
> > Thanks,
> > Jon
> >
> >
> > On Wed, Apr 25, 2018 at 2:43 PM, Dong Lin  wrote:
> >
> > > +Jon
> > >
> > > On Mon, 22 Jan 2018 at 10:38 AM Becket Qin 
> wrote:
> > >
> > >> Thanks for the discussion and voting.
> > >>
> > >> KIP-219 has passed with +3 binding votes (Becket, Jun, Rajini).
> > >>
> > >> On Thu, Jan 18, 2018 at 1:32 AM, Rajini Sivaram <
> > rajinisiva...@gmail.com>
> > >> wrote:
> > >>
> > >> > Hi Becket,
> > >> >
> > >> > Thanks for the update. Yes, it does address my concern.
> > >> >
> > >> > +1 (binding)
> > >> >
> > >> > Regards,
> > >> >
> > >> > Rajini
> > >> >
> > >> > On Wed, Jan 17, 2018 at 5:24 PM, Becket Qin 
> > >> wrote:
> > >> >
> > >> > > Actually returning an empty fetch request may still be useful to
> > >> reduce
> > >> > the
> > >> > > throttle time due to request quota violation because the
> > FetchResponse
> > >> > send
> > >> > > time will be less. I just updated the KIP.
> > >> > >
> > >> > > Rajini, does that address your concern?
> > >> > >
> > >> > > On Tue, Jan 16, 2018 at 7:01 PM, Becket Qin  >
> > >> > wrote:
> > >> > >
> > >> > > > Thanks for the reply, Jun.
> > >> > > >
> > >> > > > Currently the byte rate quota does not apply to
> HeartbeatRequest,
> > >> > > > JoinGroupRequest/SyncGroupRequest. So the only case those
> > requests
> > >> are
> > >> > > > throttled is because the request quota is violated. In that
> case,
> > >> the
> > >> > > > throttle time does not really matter whether we return a full
> > >> > > FetchResponse
> > >> > > > or an empty one. Would it be more consistent if we throttle
> based
> > on
> > >> > the
> > >> > > > actual throttle time / channel mute time?
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > Jiangjie (Becket) Qin
> > >> > > >
> > >> > > > On Tue, Jan 16, 2018 at 3:45 PM, Jun Rao 
> > wrote:
> > >> > > >
> > >> > > >> Hi, Jiangjie,
> > >> > > >>
> > >> > > >> You are right that the heartbeat is done in a channel different
> > >> from
> > >> > the
> > >> > > >> fetch request. I think it's still useful to return an empty
> fetch
> > >> > > response
> > >> > > >> when the quota is violated. This way, the throttle time for the
> > >> > > heartbeat
> > >> > > >> request won't be large. I agree that we can just mute the
> channel
> > >> for
> > >> > > the
> > >> > > >> fetch request for the throttle time computed based on a full
> > fetch
> > >> > > >> response. This probably also partially addresses Rajini's #1
> > >> concern.
> > >> > > >>
> > >> > > >> Thanks,
> > >> > > >>
> > >> > > >> Jun
> > >> > > >>
> > >> > > >> On Mon, Jan 15, 2018 at 9:27 PM, Becket Qin <
> > becket@gmail.com>
> > >> > > wrote:
> > >> > > >>
> > 

Re: [DISCUSS] KIP-285: Connect Rest Extension Plugin

[Randall Hauch]

Great work, Magesh. I like the overall approach a lot, so I left some
pretty nuanced comments about specific details.

Best regards,

Randall

On Wed, Apr 25, 2018 at 3:03 PM, Magesh Nandakumar 
wrote:

> Thanks Randall for your thoughts. I have created a replica of the required
> entities in the draft implementation. If you can take a look at the PR and
> let me know your thoughts, I will update the KIP to reflect the same
>
> https://github.com/apache/kafka/pull/4931
>
> On Tue, Apr 24, 2018 at 11:44 AM, Randall Hauch  wrote:
>
> > Magesh, I think our last emails cross in mid-stream.
> >
> > We definitely want to put the new public interfaces/classes in the API
> > module, and implementation in the runtime module. Yes, this will affect
> the
> > design, since for example we don't want to expose runtime types to the
> API,
> > and we want to prevent breaking changes. We don't really want to move the
> > REST entities if we don't have to, since that may break projects that are
> > extending the runtime module -- even though the runtime module is not a
> > public API we still want to _try_ to change things.
> >
> > Do you want to try to create a prototype to see what kind of impact and
> > choices we'll have to make?
> >
> > Best regards,
> >
> > Randall
> >
> > On Tue, Apr 24, 2018 at 12:48 PM, Randall Hauch 
> wrote:
> >
> > > Thanks for updating the KIP, Magesh. You've resolved all of my
> concerns,
> > > though I have one more: we should specify the package names for all new
> > > interfaces/classes.
> > >
> > > I'm looking forward to more feedback from others.
> > >
> > > Best regards,
> > >
> > > Randall
> > >
> > > On Fri, Apr 20, 2018 at 12:17 AM, Magesh Nandakumar <
> > mage...@confluent.io>
> > > wrote:
> > >
> > >> Hi All,
> > >>
> > >> I have updated the KIP with following changes
> > >>
> > >>1. Expanded the Motivation section
> > >>2. Included details about the interface in the public interface
> > section
> > >>3. Modified the config name to rest.extension.classes
> > >>4. Modified the ConnectRestExtension to include Configurable
> instead
> > of
> > >>ResourceConfig
> > >>5. Modified the "Rest Extension Integration with Connect" in
> > "Proposed
> > >>Approach" to include a new Custom implementation for Configurable
> > >>6. Provided examples for the Java Service provider mechanism
> > >>7. Included a reference implementation in scope
> > >>
> > >> Kindly let me know your thoughts on the updates.
> > >>
> > >> Thanks
> > >> Magesh
> > >>
> > >> On Thu, Apr 19, 2018 at 10:39 AM, Magesh Nandakumar <
> > mage...@confluent.io
> > >> >
> > >> wrote:
> > >>
> > >> > Hi Randall,
> > >> >
> > >> > Thanks for your feedback. I also would like to go with
> > >> > rest.extension.classes`.
> > >> >
> > >> > For exposing Configurable, my original intention was just to expose
> > that
> > >> > to the extension because that's all one needs to register JAX RS
> > >> resources.
> > >> > The fact that we use Jersey shouldn't even be exposed in the
> > interface.
> > >> > Hence it doesn't affect the public API by any means.
> > >> >
> > >> > I will update the KIP and let everyone know.
> > >> >
> > >> > Thanks
> > >> > Magesh
> > >> >
> > >> > On Thu, Apr 19, 2018 at 9:51 AM, Randall Hauch 
> > >> wrote:
> > >> >
> > >> >> On Thu, Apr 12, 2018 at 10:59 AM, Magesh Nandakumar <
> > >> mage...@confluent.io
> > >> >> >
> > >> >> wrote:
> > >> >>
> > >> >> > Hi Randall,
> > >> >> >
> > >> >> > Thanks a lot for your feedback.
> > >> >> >
> > >> >> > I will update the KIP to reflect your comments in (1), (2), (7)
> and
> > >> (8).
> > >> >> >
> > >> >>
> > >> >> Looking forward to these.
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > For comment # (3) , while it would be great to automatically
> > >> configure
> > >> >> the
> > >> >> > Rest Extensions, I would prefer that to be specified explicitly.
> > Lets
> > >> >> > assume a connector archive includes a implementation for the
> > >> >> RestExtension
> > >> >> > to do authentication using some header. We don't want this to be
> > >> >> > automatically included. Having said that I think that the config
> > key
> > >> >> name
> > >> >> > should probably be changed to something like "rest.extension" or
> > >> >> > "rest.extension.class".
> > >> >> >
> > >> >>
> > >> >> That's a good point. I do like `rest.extension.class` (or
> > `..classes`?)
> > >> >> much more than `rest.plugins`.
> > >> >>
> > >> >>
> > >> >> >
> > >> >> > For the comment regarding the resource loading into jersey, I
> have
> > >> the
> > >> >> > following proposal
> > >> >> >
> > >> >> > Create an implementation of Configurable(
> > >> >> > https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Config
> > >> urable.html
> > >> >> )
> > >> >> > that delegates to ResourceConfig. In the ConnectRestExtension, we
> > >> would
> > >> >> > expose only Configurable which is sufficient enough to 

Re: Kafka mirror maker help

[Hans Jespersen]

Sorry I hit send a bit too soon. I was so focused on the systemd part of
the email and not the Mirror Maker part.
Confluent packages include Mirror Maker but the systemd scripts are setup
to use Confluent Replicator rather than Mirror Maker.
My apologies.

-hans

/**
 * Hans Jespersen, Director Systems Engineering, Confluent Inc.
 * h...@confluent.io (650)924-2670
 */

On Fri, Apr 27, 2018 at 11:56 AM, Hans Jespersen  wrote:

> The latest Confluent packages now ship with systemd scripts. That is since
> Confluent Version 4.1 - which included Apache Kafka 1.1
>
> -hans
>
> /**
>  * Hans Jespersen, Director Systems Engineering, Confluent Inc.
>  * h...@confluent.io (650)924-2670
>  */
>
> On Fri, Apr 27, 2018 at 11:15 AM, Andrew Otto  wrote:
>
>> Hiya,
>>
>> Saravanan, I saw you emailed my colleague Alex about WMF’s old debian
>> packaging.  I’ll reply here.
>>
>> We now use Confluent’s Kafka debian packaging which does not (or did not?)
>> ship with init scripts.  We don’t use Sys V init.d scripts anymore either,
>> but use systemd instead.  Our systemd service unit (ERB template format)
>> is
>> here:
>>
>> https://github.com/wikimedia/puppet/blob/production/modules/
>> confluent/templates/initscripts/kafka-mirror-instance.systemd.erb
>>
>>
>>
>> On Fri, Apr 27, 2018 at 1:35 AM, Amrit Jangid 
>> wrote:
>>
>> > You should share related info, such source-destination Kafka versions,
>> > sample Config or error if any.
>> >
>> > FYI,  Go through
>> > https://kafka.apache.org/documentation/#basic_ops_mirror_maker
>> >
>>
>
>

Re: Kafka mirror maker help

[Hans Jespersen]

The latest Confluent packages now ship with systemd scripts. That is since
Confluent Version 4.1 - which included Apache Kafka 1.1

-hans

/**
 * Hans Jespersen, Director Systems Engineering, Confluent Inc.
 * h...@confluent.io (650)924-2670
 */

On Fri, Apr 27, 2018 at 11:15 AM, Andrew Otto  wrote:

> Hiya,
>
> Saravanan, I saw you emailed my colleague Alex about WMF’s old debian
> packaging.  I’ll reply here.
>
> We now use Confluent’s Kafka debian packaging which does not (or did not?)
> ship with init scripts.  We don’t use Sys V init.d scripts anymore either,
> but use systemd instead.  Our systemd service unit (ERB template format) is
> here:
>
> https://github.com/wikimedia/puppet/blob/production/
> modules/confluent/templates/initscripts/kafka-mirror-instance.systemd.erb
>
>
>
> On Fri, Apr 27, 2018 at 1:35 AM, Amrit Jangid 
> wrote:
>
> > You should share related info, such source-destination Kafka versions,
> > sample Config or error if any.
> >
> > FYI,  Go through
> > https://kafka.apache.org/documentation/#basic_ops_mirror_maker
> >
>

Re: [VOTE] KIP-219 - Improve Quota Communication

[Becket Qin]

The reason we wanted to bump up all the request versions was let the
clients know whether the broker has already throttled the request or not.
This avoids double throttling in both brokers and clients, if the clients
implementation supports KIP-219.

The new change uses only ApiVersionRequest, instead of all the requests, to
indicate whether the brokers have applied throttling or not. The difference
is that all the clients must issue ApiVersionRequest first before issuing
any other requests. This has no impact on the existing clients. But for
clients implementation that wants to support KIP-219, they need to follow
this practice, which seems to be reasonable.
Initially I thought the change is fine. However, thinking about this again,
that means the clients implementation needs to remember the ApiVersions of
each broker, which may have some complexity. Also this seems introduces the
behavior dependency between different requests, which seems unnecessary.

Due to the above reasons, I think it might be better to bump up all the
request versions.

Thanks,

Jiangjie (Becket) Qin


On Wed, Apr 25, 2018 at 3:19 PM, Jonghyun Lee  wrote:

> Hello,
>
> Per Ismael's suggestion, I'd like to get comments from the original voters
> for KIP-219 (Becket, Jun, Rajini) and others about the new interface change
> proposed in the discussion thread (
> https://markmail.org/search/?q=kafka+KIP-219#query:kafka%
> 20KIP-219+page:1+mid:5rwju2gwpicojr3f+state:results).
> Would you let me know?
>
> Thanks,
> Jon
>
>
> On Wed, Apr 25, 2018 at 2:43 PM, Dong Lin  wrote:
>
> > +Jon
> >
> > On Mon, 22 Jan 2018 at 10:38 AM Becket Qin  wrote:
> >
> >> Thanks for the discussion and voting.
> >>
> >> KIP-219 has passed with +3 binding votes (Becket, Jun, Rajini).
> >>
> >> On Thu, Jan 18, 2018 at 1:32 AM, Rajini Sivaram <
> rajinisiva...@gmail.com>
> >> wrote:
> >>
> >> > Hi Becket,
> >> >
> >> > Thanks for the update. Yes, it does address my concern.
> >> >
> >> > +1 (binding)
> >> >
> >> > Regards,
> >> >
> >> > Rajini
> >> >
> >> > On Wed, Jan 17, 2018 at 5:24 PM, Becket Qin 
> >> wrote:
> >> >
> >> > > Actually returning an empty fetch request may still be useful to
> >> reduce
> >> > the
> >> > > throttle time due to request quota violation because the
> FetchResponse
> >> > send
> >> > > time will be less. I just updated the KIP.
> >> > >
> >> > > Rajini, does that address your concern?
> >> > >
> >> > > On Tue, Jan 16, 2018 at 7:01 PM, Becket Qin 
> >> > wrote:
> >> > >
> >> > > > Thanks for the reply, Jun.
> >> > > >
> >> > > > Currently the byte rate quota does not apply to HeartbeatRequest,
> >> > > > JoinGroupRequest/SyncGroupRequest. So the only case those
> requests
> >> are
> >> > > > throttled is because the request quota is violated. In that case,
> >> the
> >> > > > throttle time does not really matter whether we return a full
> >> > > FetchResponse
> >> > > > or an empty one. Would it be more consistent if we throttle based
> on
> >> > the
> >> > > > actual throttle time / channel mute time?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Jiangjie (Becket) Qin
> >> > > >
> >> > > > On Tue, Jan 16, 2018 at 3:45 PM, Jun Rao 
> wrote:
> >> > > >
> >> > > >> Hi, Jiangjie,
> >> > > >>
> >> > > >> You are right that the heartbeat is done in a channel different
> >> from
> >> > the
> >> > > >> fetch request. I think it's still useful to return an empty fetch
> >> > > response
> >> > > >> when the quota is violated. This way, the throttle time for the
> >> > > heartbeat
> >> > > >> request won't be large. I agree that we can just mute the channel
> >> for
> >> > > the
> >> > > >> fetch request for the throttle time computed based on a full
> fetch
> >> > > >> response. This probably also partially addresses Rajini's #1
> >> concern.
> >> > > >>
> >> > > >> Thanks,
> >> > > >>
> >> > > >> Jun
> >> > > >>
> >> > > >> On Mon, Jan 15, 2018 at 9:27 PM, Becket Qin <
> becket@gmail.com>
> >> > > wrote:
> >> > > >>
> >> > > >> > Hi Rajini,
> >> > > >> >
> >> > > >> > Thanks for the comments. Pleas see the reply inline.
> >> > > >> >
> >> > > >> > Hi Jun,
> >> > > >> >
> >> > > >> > Thinking about the consumer rebalance case a bit more, I am not
> >> sure
> >> > > if
> >> > > >> we
> >> > > >> > need to worry about the delayed rebalance due to quota
> violation
> >> or
> >> > > not.
> >> > > >> > The rebalance actually uses a separate channel to coordinator.
> >> > > Therefore
> >> > > >> > unless the request quota is hit, the rebalance won't be
> >> throttled.
> >> > > Even
> >> > > >> if
> >> > > >> > request quota is hit, it seems unlikely to be delayed long. So
> it
> >> > > looks
> >> > > >> > that we don't need to unmute the channel earlier than needed.
> >> Does
> >> > > this
> >> > > >> > address your concern?
> >> > > >> >
> >> > > >> > Thanks,
> >> > > >> >
> >> > > >> > Jiangjie (Becket) Qin
> >> 

Re: [DISCUSS] KIP-280: Enhanced log compaction

[Guozhang Wang]

Hello Luis,

When the comparing the version returns `equal`, the original proposal is to
use the offset as the tie breaker. My previous comment is that

1) when we build the map calling `put`, if there is already an entry for
the key, compare its stored version, and replace if the put record's
version is "no smaller than" the stored record: this is because when
building the map we are always going from smaller offsets to larger ones.

2) when making a second pass to determine if each record should be retained
based on the map, we do not try to break the tie if the map's returned
version is the same but always treat it as "keep". In this case when we are
comparing a record with itself stored in the offset map, version comparison
would return `equals`. As I mentioned in the PR, one caveat is that we may
indeed have multiple records with the same key and the same version, but
once a new versioned record is appended it will be deleted.


Does that make sense?

Guozhang


On Fri, Apr 27, 2018 at 4:20 AM, Luís Cabral 
wrote:

>  Hi,
>
> I was updating the PR to match the latest decisions and noticed (or
> rather, the integration tests noticed) that without storing the offset,
> then the cache doesn't know when to keep the record itself.
>
> This is because, after the cache is populated, all the records are
> compared against the stored ones, so "Record{key:A,offset:1,version:1}"
> will compare against itself and be flagged as "don't keep", since we only
> compared based on the version and didn't check to see if the offset was the
> same or not.
>
> This sort of invalidates not storing the offset in the cache,
> unfortunately, and the binary footprint increases two-fold when "offset" is
> not used as a compaction strategy.
>
> Guozhang: Is it ok with you if we go back on this decision and leave the
> offset as a tie-breaker?
>
>
> Kind Regards,Luis
>
> On Friday, April 27, 2018, 11:11:55 AM GMT+2, Luís Cabral
>  wrote:
>
>   Hi,
>
> The KIP is now updated with the results of the byte array discussion.
>
> This is my first contribution to Kafka, so I'm not sure on what the
> processes are. Is it now acceptable to take this into a vote, or should I
> ask for more contributors to join the discussion first?
>
> Kind Regards,LuisOn Friday, April 27, 2018, 6:12:03 AM GMT+2, Guozhang
> Wang  wrote:
>
>  Hello Luís,
>
> > Offset is an integer? I've only noticed it being resolved as a long so
> far.
>
> You are right, offset is a long.
>
> As for timestamp / other types, I left a comment in your PR about handling
> tie breakers.
>
> > Given these arguments, is this point something that you absolutely must
> have?
>
> No I do not have a strong use case in mind to go with arbitrary byte
> arrays, was just thinking that if we are going to enhance log compaction
> why not generalize it more :)
>
> Your concern about the memory usage makes sense. I'm happy to take my
> suggestion back and enforce only long typed fields.
>
>
> Guozhang
>
>
>
>
>
> On Thu, Apr 26, 2018 at 1:44 AM, Luís Cabral  >
> wrote:
>
> >  Hi,
> >
> > bq. have a integer typed OffsetMap (for offset)
> >
> > Offset is an integer? I've only noticed it being resolved as a long so
> far.
> >
> >
> > bq. long typed OffsetMap (for timestamp)
> >
> > We would still need to store the offset, as it is functioning as a
> > tie-breaker. Not that this is a big deal, we can be easily have both (as
> > currently done on the PR).
> >
> >
> > bq. For the byte array typed offset map, we can use a general hashmap,
> > where the hashmap's CAPACITY will be reasoned from the given "val memory:
> > Int" parameter
> >
> > If you have a map with 128 byte capacity, then store a value with 16
> bytes
> > and another with 32 bytes, how many free slots do you have left in this
> map?
> >
> > You can make this work, but I think you would need to re-design the whole
> > log cleaner approach, which implies changing some of the already existing
> > configurations (like "log.cleaner.io.buffer.load.factor"). I would
> rather
> > maintain backwards compatibility as much as possible in this KIP, and if
> > this means that using "foo" / "bar" or "2.1-a" / "3.20-b" as record
> > versions is not viable, then so be it.
> >
> > Given these arguments, is this point something that you absolutely must
> > have? I'm still sort of hoping that you are just entertaining the idea
> and
> > are ok with having a long (now conceded to be unsigned, so the byte
> arrays
> > can be compared directly).
> >
> >
> > Kind Regards,Luis
> >
>
>
>
> --
> -- Guozhang
>



-- 
-- Guozhang

Re: Kafka mirror maker help

[Andrew Otto]

Hiya,

Saravanan, I saw you emailed my colleague Alex about WMF’s old debian
packaging.  I’ll reply here.

We now use Confluent’s Kafka debian packaging which does not (or did not?)
ship with init scripts.  We don’t use Sys V init.d scripts anymore either,
but use systemd instead.  Our systemd service unit (ERB template format) is
here:

https://github.com/wikimedia/puppet/blob/production/modules/confluent/templates/initscripts/kafka-mirror-instance.systemd.erb



On Fri, Apr 27, 2018 at 1:35 AM, Amrit Jangid 
wrote:

> You should share related info, such source-destination Kafka versions,
> sample Config or error if any.
>
> FYI,  Go through
> https://kafka.apache.org/documentation/#basic_ops_mirror_maker
>

[jira] [Created] (KAFKA-6833) KafkaProducer throws "Invalid partition given with record" exception

[Arjun Satish (JIRA)]

Arjun Satish created KAFKA-6833:
---

 Summary: KafkaProducer throws "Invalid partition given with 
record" exception
 Key: KAFKA-6833
 URL: https://issues.apache.org/jira/browse/KAFKA-6833
 Project: Kafka
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Arjun Satish


Currently, when creating topics via ZooKeeper, there is a small but definite 
delay between creating the nodes in ZK, and having the topics created in the 
brokers. the KafkaProducer maintains a metadata cache about topics which get 
updated after the broker metadata is updated. If an application creates topics, 
and immediately tries to produce records to a new partition, a KafkaException 
is throw with a message similar to the following:
{code:java}
Caused by: org.apache.kafka.common.KafkaException: Invalid partition given with 
record: 12 is not in the range [0...1).
{code}
In this case, since the application has context that it created the topics, it 
might be worthwhile to consider if a more specific exception can be thrown 
instead of KafkaException. For example:
{code:java}
public class PartitionNotFoundException extends KafkaException {...}{code}
This could allow the application to be able to interpret such an error, and act 
accordingly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Kafka mirror maker help

[Amrit Jangid]

You should share related info, such source-destination Kafka versions,
sample Config or error if any.

FYI,  Go through
https://kafka.apache.org/documentation/#basic_ops_mirror_maker

Jenkins build is back to normal : kafka-trunk-jdk8 #2600

[Apache Jenkins Server]

See 

Permission request

[Adam Kotwasinski]

Hello,

Could you please add me to the contributor list, so I could like to assign
https://issues.apache.org/jira/browse/KAFKA-6830 to myself?

Thank you.

Best regards,
Adam Kotwasinski

Re: [DISCUSS] KIP-280: Enhanced log compaction

[Luís Cabral]

 Hi,

I was updating the PR to match the latest decisions and noticed (or rather, the 
integration tests noticed) that without storing the offset, then the cache 
doesn't know when to keep the record itself.

This is because, after the cache is populated, all the records are compared 
against the stored ones, so "Record{key:A,offset:1,version:1}" will compare 
against itself and be flagged as "don't keep", since we only compared based on 
the version and didn't check to see if the offset was the same or not.

This sort of invalidates not storing the offset in the cache, unfortunately, 
and the binary footprint increases two-fold when "offset" is not used as a 
compaction strategy.

Guozhang: Is it ok with you if we go back on this decision and leave the offset 
as a tie-breaker?


Kind Regards,Luis

On Friday, April 27, 2018, 11:11:55 AM GMT+2, Luís Cabral 
 wrote:  
 
  Hi,

The KIP is now updated with the results of the byte array discussion.

This is my first contribution to Kafka, so I'm not sure on what the processes 
are. Is it now acceptable to take this into a vote, or should I ask for more 
contributors to join the discussion first?

Kind Regards,Luis    On Friday, April 27, 2018, 6:12:03 AM GMT+2, Guozhang Wang 
 wrote:  
 
 Hello Luís,

> Offset is an integer? I've only noticed it being resolved as a long so
far.

You are right, offset is a long.

As for timestamp / other types, I left a comment in your PR about handling
tie breakers.

> Given these arguments, is this point something that you absolutely must
have?

No I do not have a strong use case in mind to go with arbitrary byte
arrays, was just thinking that if we are going to enhance log compaction
why not generalize it more :)

Your concern about the memory usage makes sense. I'm happy to take my
suggestion back and enforce only long typed fields.


Guozhang





On Thu, Apr 26, 2018 at 1:44 AM, Luís Cabral 
wrote:

>  Hi,
>
> bq. have a integer typed OffsetMap (for offset)
>
> Offset is an integer? I've only noticed it being resolved as a long so far.
>
>
> bq. long typed OffsetMap (for timestamp)
>
> We would still need to store the offset, as it is functioning as a
> tie-breaker. Not that this is a big deal, we can be easily have both (as
> currently done on the PR).
>
>
> bq. For the byte array typed offset map, we can use a general hashmap,
> where the hashmap's CAPACITY will be reasoned from the given "val memory:
> Int" parameter
>
> If you have a map with 128 byte capacity, then store a value with 16 bytes
> and another with 32 bytes, how many free slots do you have left in this map?
>
> You can make this work, but I think you would need to re-design the whole
> log cleaner approach, which implies changing some of the already existing
> configurations (like "log.cleaner.io.buffer.load.factor"). I would rather
> maintain backwards compatibility as much as possible in this KIP, and if
> this means that using "foo" / "bar" or "2.1-a" / "3.20-b" as record
> versions is not viable, then so be it.
>
> Given these arguments, is this point something that you absolutely must
> have? I'm still sort of hoping that you are just entertaining the idea and
> are ok with having a long (now conceded to be unsigned, so the byte arrays
> can be compared directly).
>
>
> Kind Regards,Luis
>



-- 
-- Guozhang    

Re: Write access required to Confluence wiki

[Piyush Vijay]

Hi,

Can someone please help/guide me here? I really appreciate it.

Thanks


Piyush Vijay

On Thu, Apr 26, 2018 at 6:37 PM, Piyush Vijay 
wrote:

> Ping :)
>
>
> Piyush Vijay
>
> On Wed, Apr 25, 2018 at 7:45 PM, Piyush Vijay 
> wrote:
>
>>
>> I want to open a JIRA and a KIP. Can someone please grant me the
>> necessary permissions?
>> My username is *piyushvijay*.
>>
>> Thank you
>> Piyush Vijay
>>
>>
>

[jira] [Created] (KAFKA-6832) Wrong start position in the log file on the leader, on fetch request.

[Ciprian Pascu (JIRA)]

Ciprian Pascu created KAFKA-6832:


 Summary: Wrong start position in the log file on the leader, on 
fetch request.
 Key: KAFKA-6832
 URL: https://issues.apache.org/jira/browse/KAFKA-6832
 Project: Kafka
  Issue Type: Bug
  Components: core
Affects Versions: 1.1.0
Reporter: Ciprian Pascu


Hi,

We have an environment with 3 Kafka brokers; after hard reboot all brokers (by 
hard rebooting the VMs on which they are located), we experience drop in the 
ISR, for the topics that have replication factor greater than 1; it is caused 
by the death of some of the replica threads with the following exception:

Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: 
*kafka.common.KafkaException: Error processing data for partition 
__consumer_offsets-39 offset 308060*
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
scala.Option.foreach(Option.scala:257)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(Abs
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1.apply(Abs
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply$mcV$sp(AbstractFetcherThrea
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2.apply(AbstractFetcherThread.scala
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.utils.CoreUtils$.inLock(CoreUtils.scala:217)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread.processFetchRequest(AbstractFetcherThread.scala:167)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:113)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:64)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: *Caused by: 
java.lang.IllegalArgumentException: Out of order offsets found in List(308059, 
308060)*
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.log.Log$$anonfun$append$2.apply(Log.scala:683)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.log.Log$$anonfun$append$2.apply(Log.scala:624)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.log.Log.maybeHandleIOException(Log.scala:1679)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.log.Log.append(Log.scala:624)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.log.Log.appendAsFollower(Log.scala:607)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.ReplicaFetcherThread.processPartitionData(ReplicaFetcherThread.scala:102)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.ReplicaFetcherThread.processPartitionData(ReplicaFetcherThread.scala:41)
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: at 
kafka.server.AbstractFetcherThread$$anonfun$processFetchRequest$2$$anonfun$apply$mcV$sp$1$$anonfun$
Apr 27 08:46:24 hostname kafka-server-start.sh[11215]: ... 13 more

 

The replica requests for offset *308060, but it gets a message set containing 
(**308059, 308060), which makes the replica thread crash, due to the above 
exception. The reason why the leader sends a message set with a smaller offset 
than requested seems to be in the implementation of 'read' method from 
'LogSegment'; according to the comment, this method should '*Read a message set 
from this segment beginning with the first offset >= startOffset', but actually 
it is using 'translateOffset' method, which uses 'lookup' method which, 
according to comment, 'Find the largest offset less than or equal to the given 
targetOffset'; the code confirms this; so, it seems we have a contradiction 
here.

 

Ciprian.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] KIP-280: Enhanced log compaction

[Luís Cabral]

 Hi,

The KIP is now updated with the results of the byte array discussion.

This is my first contribution to Kafka, so I'm not sure on what the processes 
are. Is it now acceptable to take this into a vote, or should I ask for more 
contributors to join the discussion first?

Kind Regards,LuisOn Friday, April 27, 2018, 6:12:03 AM GMT+2, Guozhang Wang 
 wrote:  
 
 Hello Luís,

> Offset is an integer? I've only noticed it being resolved as a long so
far.

You are right, offset is a long.

As for timestamp / other types, I left a comment in your PR about handling
tie breakers.

> Given these arguments, is this point something that you absolutely must
have?

No I do not have a strong use case in mind to go with arbitrary byte
arrays, was just thinking that if we are going to enhance log compaction
why not generalize it more :)

Your concern about the memory usage makes sense. I'm happy to take my
suggestion back and enforce only long typed fields.


Guozhang





On Thu, Apr 26, 2018 at 1:44 AM, Luís Cabral 
wrote:

>  Hi,
>
> bq. have a integer typed OffsetMap (for offset)
>
> Offset is an integer? I've only noticed it being resolved as a long so far.
>
>
> bq. long typed OffsetMap (for timestamp)
>
> We would still need to store the offset, as it is functioning as a
> tie-breaker. Not that this is a big deal, we can be easily have both (as
> currently done on the PR).
>
>
> bq. For the byte array typed offset map, we can use a general hashmap,
> where the hashmap's CAPACITY will be reasoned from the given "val memory:
> Int" parameter
>
> If you have a map with 128 byte capacity, then store a value with 16 bytes
> and another with 32 bytes, how many free slots do you have left in this map?
>
> You can make this work, but I think you would need to re-design the whole
> log cleaner approach, which implies changing some of the already existing
> configurations (like "log.cleaner.io.buffer.load.factor"). I would rather
> maintain backwards compatibility as much as possible in this KIP, and if
> this means that using "foo" / "bar" or "2.1-a" / "3.20-b" as record
> versions is not viable, then so be it.
>
> Given these arguments, is this point something that you absolutely must
> have? I'm still sort of hoping that you are just entertaining the idea and
> are ok with having a long (now conceded to be unsigned, so the byte arrays
> can be compared directly).
>
>
> Kind Regards,Luis
>



-- 
-- Guozhang  

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

[Apache Jenkins Server]

See 

--
[...truncated 2.50 KB...]
at hudson.Proc$LocalProc.(Proc.java:218)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:930)
at hudson.Launcher$ProcStarter.start(Launcher.java:450)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1992)
... 20 more
Cloning the remote Git repository
Cloning repository https://github.com/apache/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:772)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:207)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:358)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H32
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:908)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor743.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:132)
at com.sun.proxy.$Proxy137.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1120)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Error performing git command
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2005)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770)
... 11 more
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at hudson.Proc$LocalProc.(Proc.java:269)
at hudson.Proc$LocalProc.(Proc.java:218)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:930)
at hudson.Launcher$ProcStarter.start(Launcher.java:450)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1992)
... 15 more
ERROR: Error cloning remote repo 'origin'
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
ERROR: Workspace has a .git repository, but it appears to be corrupt.
hudson.plugins.git.GitException: Error performing git command
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2005)
at 

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

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on H32 (ubuntu xenial) in workspace 

Cloning the remote Git repository
Cloning repository https://github.com/apache/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:772)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:207)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:358)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H32
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:908)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor743.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:132)
at com.sun.proxy.$Proxy137.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1120)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Error performing git command
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2005)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770)
... 11 more
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:717)
at hudson.Proc$LocalProc.(Proc.java:269)
at hudson.Proc$LocalProc.(Proc.java:218)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:930)
at hudson.Launcher$ProcStarter.start(Launcher.java:450)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1992)
... 15 more
ERROR: Error cloning remote repo 'origin'
Retrying after 10 seconds
 > git rev-parse --is-inside-work-tree # timeout=10
ERROR: Workspace has a .git repository, but it appears to be corrupt.
hudson.plugins.git.GitException: Error performing git command
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2005)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at 

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

[Apache Jenkins Server]

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on H32 (ubuntu xenial) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/apache/kafka.git # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://github.com/apache/kafka.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:862)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Error performing git command
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2005)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1609)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setRemoteUrl(CliGitAPIImpl.java:1243)
at hudson.plugins.git.GitAPI.setRemoteUrl(GitAPI.java:160)
at sun.reflect.GeneratedMethodAccessor117.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:922)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:896)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:853)
at hudson.remoting.UserRequest.perform(UserRequest.java:207)
at hudson.remoting.UserRequest.perform(UserRequest.java:53)
at hudson.remoting.Request$2.run(Request.java:358)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
H32
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1693)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:310)
at hudson.remoting.Channel.call(Channel.java:908)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:281)
at com.sun.proxy.$Proxy110.setRemoteUrl(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.setRemoteUrl(RemoteGitImpl.java:295)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:850)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1129)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1160)
at hudson.scm.SCM.checkout(SCM.java:495)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1202)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1724)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)