{"push_id":3381532232,"size":9,"distinct_size":9,"ref":"refs/heads/2.2","head":"4ace51a4827d2e3fac8ccbe751ffddb6db48035e","before":"5653989d12cf875cf4189fd89f0737b74c61d26f","commits":[{"sha":"78648dab04f5b9edf598c73d0cf3b11e529e9c45","author":{"name":"Jun Rao","email":"3b8fe158618db0e3f4afb5782d706a350bebb0b8@gmail.com"},"message":"KAFKA-8018: Flaky Test SaslSslAdminClientIntegrationTest#testLegacyAclOpsNeverAffectOrReturnPrefixed\n\nDisable forceSync in EmbeddedZookeeper.\nIncrease ZK tick to allow longer maxSessionTimeout in tests.\nIncrease ZK client session timeout in tests.\nHandle transient ZK session expiration exception in test utils for createTopic.\n\nAuthor: Jun Rao <junrao@gmail.com>\n\nReviewers: Guozhang Wang <wangguoz@gmail.com>, Manikumar Reddy <manikumar.reddy@gmail.com>, Ismael Juma <ismael@juma.me.uk>\n\nCloses #6354 from junrao/KAFKA-8018","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/78648dab04f5b9edf598c73d0cf3b11e529e9c45"},{"sha":"d738d2feea2bfc43b4ba66b4904a96b2f5981bb4","author":{"name":"Rajini Sivaram","email":"2e743c5cf650e12d7db950775eab7636545b5b8c@googlemail.com"},"message":"KAFKA-8039 - Use MockTime in fast reauth test to avoid transient failures (#6383)\n\nTest uses 100ms as connections.max.reauth.ms and checks that a second reauthentication doesn't occur within the hard-coded 1 second minimum interval. But since the interval is small, we cannot guarantee that the time between the two checks is not higher than 1 second. Change the test to use MockTime so that we can control the time.\r\n\r\nReviewers: Ron Dagostino <rndgstn@gmail.com>, Manikumar Reddy <manikumar.reddy@gmail.com>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/d738d2feea2bfc43b4ba66b4904a96b2f5981bb4"},{"sha":"64eb5c15dacf8084537b80c484329eb2ef72aa00","author":{"name":"Rajini Sivaram","email":"2e743c5cf650e12d7db950775eab7636545b5b8c@googlemail.com"},"message":"KAFKA-7288 - Make sure no bytes buffered when relying on idle timeout in channel close test (#6390)\n\nSelectorTest.testCloseConnectionInClosingState sends and receives messages to get the channel into a state with staged receives and then waits for idle timeout to close the channel. When run with SSL, the channel may have buffered bytes that prevent the channel from being closed. Updated the test to wait until there are no buffered bytes as well.\r\n\r\nReviewers: Ismael Juma <ismael@juma.me.uk>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/64eb5c15dacf8084537b80c484329eb2ef72aa00"},{"sha":"dfc59fa0cbb61842e168c27b2071d22dc3f9ce1b","author":{"name":"Manikumar Reddy","email":"5c5b03b4d6e1a3a45d39ad15b70eab568fe0a48b@gmail.com"},"message":"KAFKA-8061; Handle concurrent ProducerId reset and call to Sender thread shutdown (#6388)\n\nIn KAFKA-5503, we have added a check  for `running` flag in the loop inside maybeWaitForProducerId.  This is to handle concurrent call to Sender close(), while we attempt to get the ProducerId. This avoids blocking indefinitely when the producer is shutting down.\r\n\r\nThis created a corner case, where Sender thread gets blocked, if we had concurrent producerId reset and call to Sender thread close. The fix here is to check the `forceClose` flag in the loop inside maybeWaitForProducerId instead of the `running` flag.\r\n\r\nReviewers: Jason Gustafson <jason@confluent.io>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/dfc59fa0cbb61842e168c27b2071d22dc3f9ce1b"},{"sha":"8179e8fdc04d8968e2aa11d7959bdbbecea19141","author":{"name":"cadonna","email":"8548e651fb34cb712e02d8943f3f81ebe776615b@users.noreply.github.com"},"message":"Improve API docs of (flatT|t)ransform (#6365)\n\nThis commit is a follow-up of pull request #5273\r\n\r\nReviewers: Matthias J. Sax <mjsax@apache.org>, Bill Bejeck <bbejeck@gmail.com>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/8179e8fdc04d8968e2aa11d7959bdbbecea19141"},{"sha":"10c2169fd127b3bd4f27885c429ef7f3bdbbb3cb","author":{"name":"Rajini Sivaram","email":"2e743c5cf650e12d7db950775eab7636545b5b8c@googlemail.com"},"message":"KAFKA-7980 - Fix timing issue in SocketServerTest.testConnectionRateLimit (#6391)\n\nTest currently checks that there were at least 5 polls when 5 connections are established with connectionQueueSize=1. But we could be doing the check just after the 5th connection before the 5th poll, so updated the check to verify that there were at least 4 polls.\r\n\r\nReviewers: Ismael Juma <ismael@juma.me.uk>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/10c2169fd127b3bd4f27885c429ef7f3bdbbb3cb"},{"sha":"ebbde6378c61776b468e2e9843b6b70b30d5688c","author":{"name":"John Roesler","email":"884ff5c4006c6f627a23dfdf6dcce23badd4698e@users.noreply.github.com"},"message":"KAFKA-8040: Streams handle initTransactions timeout (#6372)\n\nAs of 2.0, Producer.initTransactions may throw a TimeoutException, which is retriable. Streams should retry instead of crashing when we encounter this exception\r\n\r\nReviewers: Guozhang Wang <wangguoz@gmail.com>, Matthias J. Sax <mjsax@apache.org>,  Bill Bejeck <bbejeck@gmail.com>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/ebbde6378c61776b468e2e9843b6b70b30d5688c"},{"sha":"cec1dfab3ff6c66c4457f147c0d567dd99c54957","author":{"name":"Rajini Sivaram","email":"2e743c5cf650e12d7db950775eab7636545b5b8c@googlemail.com"},"message":"KAFKA-8070: Increase consumer startup timeout in system tests (#6405)\n\nFor consumers using SSL, this timeout includes the time to create and copy keystores and truststores and sometime it takes longer than 10s to complete the security setup before starting the consumer process.\r\n\r\nReviewers: Ismael Juma <ismael@juma.me.uk>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/cec1dfab3ff6c66c4457f147c0d567dd99c54957"},{"sha":"4ace51a4827d2e3fac8ccbe751ffddb6db48035e","author":{"name":"Zhanxiang (Patrick) Huang","email":"538a2bc234a41f6d404803dc15d9ca507059c975@hotmail.com"},"message":"KAFKA-8069; Fix early expiration of offsets due to invalid loading of expire timestamp (#6401)\n\nAfter the 2.1 release, if the broker hasn't been upgrade to the latest inter-broker protocol version, the committed offsets stored in the __consumer_offset topic will get cleaned up way earlier than it should be when the offsets are loaded back from the __consumer_offset topic in GroupCoordinator, which will happen during leadership transition or after broker bounce. This patch fixes the bug by setting expireTimestamp to None if it is the default value after loading v1 offset records from __consumer_offsets.\r\n\r\nReviewers: Ismael Juma <ismael@juma.me.uk>, Jason Gustafson <jason@confluent.io>","distinct":true,"url":"https://api.github.com/repos/confluentinc/kafka/commits/4ace51a4827d2e3fac8ccbe751ffddb6db48035e"}]}
{"actor":{"display_login":"ConfluentJenkins"}}