[GitHub] [kafka] jeffkbkim commented on a diff in pull request #12847: KAFKA-14367; Add `SyncGroup` to the new `GroupCoordinator` interface

[GitBox]

jeffkbkim commented on code in PR #12847:
URL: https://github.com/apache/kafka/pull/12847#discussion_r1036231308


##
core/src/main/scala/kafka/server/KafkaApis.scala:
##
@@ -1696,45 +1696,37 @@ class KafkaApis(val requestChannel: RequestChannel,
   def handleSyncGroupRequest(request: RequestChannel.Request, requestLocal: 
RequestLocal): Unit = {
 val syncGroupRequest = request.body[SyncGroupRequest]
 
-def sendResponseCallback(syncGroupResult: SyncGroupResult): Unit = {
-  requestHelper.sendResponseMaybeThrottle(request, requestThrottleMs =>
-new SyncGroupResponse(
-  new SyncGroupResponseData()
-.setErrorCode(syncGroupResult.error.code)
-.setProtocolType(syncGroupResult.protocolType.orNull)
-.setProtocolName(syncGroupResult.protocolName.orNull)
-.setAssignment(syncGroupResult.memberAssignment)
-.setThrottleTimeMs(requestThrottleMs)
-))
+def sendResponse(response: AbstractResponse): Unit = {
+  trace("Sending sync group response %s for correlation id %d to client 
%s."
+.format(response, request.header.correlationId, 
request.header.clientId))
+  requestHelper.sendResponseMaybeThrottle(request, requestThrottleMs => {
+response.maybeSetThrottleTimeMs(requestThrottleMs)
+response
+  })

Review Comment:
   thanks, makes sense to me.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka] jeffkbkim commented on a diff in pull request #12847: KAFKA-14367; Add `SyncGroup` to the new `GroupCoordinator` interface

[GitBox]

jeffkbkim commented on code in PR #12847:
URL: https://github.com/apache/kafka/pull/12847#discussion_r1035483192


##
core/src/main/scala/kafka/server/KafkaApis.scala:
##
@@ -1696,45 +1696,37 @@ class KafkaApis(val requestChannel: RequestChannel,
   def handleSyncGroupRequest(request: RequestChannel.Request, requestLocal: 
RequestLocal): Unit = {
 val syncGroupRequest = request.body[SyncGroupRequest]
 
-def sendResponseCallback(syncGroupResult: SyncGroupResult): Unit = {
-  requestHelper.sendResponseMaybeThrottle(request, requestThrottleMs =>
-new SyncGroupResponse(
-  new SyncGroupResponseData()
-.setErrorCode(syncGroupResult.error.code)
-.setProtocolType(syncGroupResult.protocolType.orNull)
-.setProtocolName(syncGroupResult.protocolName.orNull)
-.setAssignment(syncGroupResult.memberAssignment)
-.setThrottleTimeMs(requestThrottleMs)
-))
+def sendResponse(response: AbstractResponse): Unit = {
+  trace("Sending sync group response %s for correlation id %d to client 
%s."
+.format(response, request.header.correlationId, 
request.header.clientId))
+  requestHelper.sendResponseMaybeThrottle(request, requestThrottleMs => {
+response.maybeSetThrottleTimeMs(requestThrottleMs)
+response
+  })

Review Comment:
   thoughts on reusing this? it's identical to handleJoinGroupRequest except 
for the response type and it looks like we can use this for the other 
coordinator APIs as well



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka] jeffkbkim commented on a diff in pull request #12847: KAFKA-14367; Add `SyncGroup` to the new `GroupCoordinator` interface

[GitBox]

jeffkbkim commented on code in PR #12847:
URL: https://github.com/apache/kafka/pull/12847#discussion_r1024721499


##
core/src/test/scala/unit/kafka/coordinator/group/GroupCoordinatorAdapterTest.scala:
##
@@ -135,4 +133,71 @@ class GroupCoordinatorAdapterTest {
 assertEquals(expectedData, future.get())
   }
 
+  @ParameterizedTest
+  @ApiKeyVersionsSource(apiKey = ApiKeys.SYNC_GROUP)
+  def testSyncGroup(version: Short): Unit = {
+val groupCoordinator = mock(classOf[GroupCoordinator])
+val adapter = new GroupCoordinatorAdapter(groupCoordinator)
+
+val ctx = makeContext(version)
+val data = new SyncGroupRequestData()
+  .setGroupId("group")
+  .setMemberId("member1")
+  .setGroupInstanceId("instance")
+  .setProtocolType("consumer")
+  .setProtocolName("range")
+  .setGenerationId(10)
+  .setAssignments(List(
+new SyncGroupRequestData.SyncGroupRequestAssignment()
+  .setMemberId("member1")
+  .setAssignment("member1".getBytes()),
+new SyncGroupRequestData.SyncGroupRequestAssignment()
+  .setMemberId("member2")
+  .setAssignment("member2".getBytes())
+  ).asJava)
+
+val future = adapter.syncGroup(ctx, data)
+assertFalse(future.isDone)
+
+val capturedAssignment: ArgumentCaptor[Map[String, Array[Byte]]] =
+  ArgumentCaptor.forClass(classOf[Map[String, Array[Byte]]])
+val capturedCallback: ArgumentCaptor[SyncGroupCallback] =
+  ArgumentCaptor.forClass(classOf[SyncGroupCallback])
+
+verify(groupCoordinator).handleSyncGroup(
+  ArgumentMatchers.eq(data.groupId),
+  ArgumentMatchers.eq(data.generationId),
+  ArgumentMatchers.eq(data.memberId),
+  ArgumentMatchers.eq(Some(data.protocolType)),
+  ArgumentMatchers.eq(Some(data.protocolName)),
+  ArgumentMatchers.eq(Some(data.groupInstanceId)),
+  capturedAssignment.capture(),
+  capturedCallback.capture(),
+  ArgumentMatchers.eq(RequestLocal(ctx.bufferSupplier))
+)
+
+assertEquals(Map(
+  "member1" -> "member1",
+  "member2" -> "member2",
+), capturedAssignment.getValue.map { case (member, metadata) =>
+  (member, new String(metadata))
+}.toMap)

Review Comment:
   do we need toMap?



##
core/src/test/scala/unit/kafka/coordinator/group/GroupCoordinatorAdapterTest.scala:
##
@@ -135,4 +133,71 @@ class GroupCoordinatorAdapterTest {
 assertEquals(expectedData, future.get())
   }
 
+  @ParameterizedTest
+  @ApiKeyVersionsSource(apiKey = ApiKeys.SYNC_GROUP)
+  def testSyncGroup(version: Short): Unit = {
+val groupCoordinator = mock(classOf[GroupCoordinator])
+val adapter = new GroupCoordinatorAdapter(groupCoordinator)
+
+val ctx = makeContext(version)
+val data = new SyncGroupRequestData()
+  .setGroupId("group")
+  .setMemberId("member1")
+  .setGroupInstanceId("instance")
+  .setProtocolType("consumer")
+  .setProtocolName("range")
+  .setGenerationId(10)
+  .setAssignments(List(
+new SyncGroupRequestData.SyncGroupRequestAssignment()
+  .setMemberId("member1")
+  .setAssignment("member1".getBytes()),
+new SyncGroupRequestData.SyncGroupRequestAssignment()
+  .setMemberId("member2")
+  .setAssignment("member2".getBytes())
+  ).asJava)
+
+val future = adapter.syncGroup(ctx, data)
+assertFalse(future.isDone)
+
+val capturedAssignment: ArgumentCaptor[Map[String, Array[Byte]]] =
+  ArgumentCaptor.forClass(classOf[Map[String, Array[Byte]]])
+val capturedCallback: ArgumentCaptor[SyncGroupCallback] =
+  ArgumentCaptor.forClass(classOf[SyncGroupCallback])
+
+verify(groupCoordinator).handleSyncGroup(
+  ArgumentMatchers.eq(data.groupId),
+  ArgumentMatchers.eq(data.generationId),
+  ArgumentMatchers.eq(data.memberId),
+  ArgumentMatchers.eq(Some(data.protocolType)),
+  ArgumentMatchers.eq(Some(data.protocolName)),
+  ArgumentMatchers.eq(Some(data.groupInstanceId)),
+  capturedAssignment.capture(),
+  capturedCallback.capture(),
+  ArgumentMatchers.eq(RequestLocal(ctx.bufferSupplier))
+)
+
+assertEquals(Map(
+  "member1" -> "member1",
+  "member2" -> "member2",
+), capturedAssignment.getValue.map { case (member, metadata) =>
+  (member, new String(metadata))
+}.toMap)
+
+capturedCallback.getValue.apply(SyncGroupResult(
+  error = Errors.NONE,
+  protocolType = Some("consumer"),
+  protocolName = Some("range"),
+  memberAssignment = "member1".getBytes()
+))
+
+val expectedResponseData = new SyncGroupResponseData()
+  .setErrorCode(Errors.NONE.code)
+  .setProtocolType("consumer")
+  .setProtocolName("range")

Review Comment:
   generally i see a lot of literal strings being used across the tests in 
GroupCoordinatorAdapterTest. what's the reason for not re-using them, is it the 
convention?



-- 
This is an automated message from th