Fix/control kafka mqtt block

[ION127]

No description provided.

[gemini-code-assist]

Code Review

This pull request introduces a new taxi stand retrieval endpoint in the dispatch service, including its JPA entity, repository, and gateway routing. It also configures the Kafka producer in the control service to prevent blocking and adds rate-limited logging for publish failures. Feedback highlights critical issues: setting MAX_BLOCK_MS_CONFIG to 0 may cause immediate timeouts, a race condition exists in the logging rate-limiter, Kotlin JPA entities should use mutable fields (var), returning Spring Data's Page directly exposes internal metadata, and the new gateway route lacks authentication.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Setting ProducerConfig.MAX_BLOCK_MS_CONFIG to 0 will cause immediate TimeoutExceptions (e.g., Failed to update metadata after 0 ms) during the very first send() call or during metadata refreshes, because fetching metadata from the broker requires a non-zero network round-trip time.

To prevent blocking the MQTT thread without causing spurious failures, consider setting MAX_BLOCK_MS_CONFIG to a small but reasonable value (e.g., 500 ms). Alternatively, offload the Kafka publish operation to a separate thread pool or use Kotlin Coroutines (Dispatchers.IO) so that the MQTT thread is never blocked regardless of Kafka's blocking behavior.

Suggested change

	ProducerConfig.MAX_BLOCK_MS_CONFIG to 0,
	ProducerConfig.RETRIES_CONFIG to 0,
	ProducerConfig.MAX_BLOCK_MS_CONFIG to 500,
	ProducerConfig.RETRIES_CONFIG to 0,

[gemini-code-assist]

Under high concurrency (e.g., when Kafka is down and multiple MQTT threads fail to publish simultaneously), there is a race condition between kafkaFailLoggedAt.get() and kafkaFailLoggedAt.set(now). Multiple threads can pass the if condition and log duplicate warnings.

Using compareAndSet ensures that only one thread successfully updates the timestamp and logs the warning, effectively rate-limiting the logs as intended.

Suggested change

	private fun logKafkaFailure(message: String?) {
	val count = kafkaFailCount.incrementAndGet()
	val now = System.currentTimeMillis()
	val last = kafkaFailLoggedAt.get()
	// 최초 실패 또는 30초마다 한 번만 로그
	if (count == 1L || now - last > 30_000) {
	kafkaFailLoggedAt.set(now)
	log.warn("Kafka publish 실패 (누적 {}건): {}", count, message)
	}
	}
	private fun logKafkaFailure(message: String?) {
	val count = kafkaFailCount.incrementAndGet()
	val now = System.currentTimeMillis()
	val last = kafkaFailLoggedAt.get()
	if (count == 1L || now - last > 30_000) {
	if (kafkaFailLoggedAt.compareAndSet(last, now)) {
	log.warn("Kafka publish 실패 (누적 {}건): {}", count, message)
	}
	}
	}

[gemini-code-assist]

In Kotlin, JPA entities should ideally use var instead of val for fields mapped to database columns (except possibly the @Id field if it's immutable).

Hibernate relies on mutability for proxying, lazy loading, and dirty checking. Using val makes the fields immutable, which can cause issues if Hibernate needs to instantiate proxies or if you need to update these fields in the future.

Additionally, ensure that the Kotlin allopen and noarg compiler plugins are configured in your build file to allow Hibernate to subclass and instantiate the entity correctly.

class TaxiStandEntity(
    @Id
    @Column(name = "id")
    val id: String = "",

    @Column(name = "longitude", nullable = false)
    var longitude: Double = 0.0,

    @Column(name = "latitude", nullable = false)
    var latitude: Double = 0.0,

    @Column(name = "district")
    var district: String? = null,

    @Column(name = "road_address")
    var roadAddress: String? = null,

    @Column(name = "extra_road")
    var extraRoad: String? = null,

    @Column(name = "name")
    var name: String? = null,
)

[gemini-code-assist]

Returning Spring Data's Page object directly from the controller exposes internal pagination metadata (such as pageable, sort, first, last, etc.) to the API clients. This tightly couples your API contract to Spring Data's implementation details.

Consider wrapping the paginated result in a custom API response DTO that only exposes the necessary pagination fields (e.g., content, pageNumber, pageSize, totalElements, totalPages).

[gemini-code-assist]

The route dispatch-service-stands uses RemoveRequestHeader=Authorization and does not include the JwtAuthentication filter. This makes the /dispatch/stands endpoint publicly accessible without any authentication.

If taxi stand data is sensitive or should only be accessible to authenticated users, please ensure that JwtAuthentication is added to the filters list instead of removing the Authorization header.