Also in this case will it fall back to a full request?
Hence no data is lost but it might increase latency?
Thanks
Mark
On Thu, 26 Jul 2018, 12:28 Mark Anderson, wrote:
> Ted,
>
> Below are examples of the DEBUG entries from FetchSession
>
> [2018-07-26 11:14:43,461] DEBUG Created a new error
Ted,
Below are examples of the DEBUG entries from FetchSession
[2018-07-26 11:14:43,461] DEBUG Created a new error FetchContext for
session id 1139872548: expected epoch 13719, but got epoch 13718.
(kafka.server.FetchManager)
[2018-07-26 11:24:35,339] DEBUG Created a new error FetchContext for
se
In log4j.properties, can you make the following change (you can keep
whatever follows the first comma in the rootLogger line):
log4j.rootLogger=DEBUG
log4j.logger.org.apache.kafka=DEBUG
FetchSession.scala is in kafka.server package. You can just turn on DEBUG
for this package.
FYI
On Wed, Jun
Ted
I don't see any other INFO log messages so I assume that means it is the
DEBUG case I'm seeing?
I don't have DEBUG enabled at the moment.
Thanks
On Wed, 13 Jun 2018, 00:21 Ted Yu, wrote:
> Before Errors.INVALID_FETCH_SESSION_EPOCH is returned, FetchSession.scala
> would log the reason for
Before Errors.INVALID_FETCH_SESSION_EPOCH is returned, FetchSession.scala
would log the reason for the response.
There are 3 cases, 2 with info log and 1 with debug log.
Here is one code snippet:
if (session.epoch != reqMetadata.epoch()) {
debug(s"Created a new error Fet
We recently updated our Kafka brokers and clients to 1.1.0. Since the
upgrade we periodically see INFO log entries such as
INFO Jun 08 08:30:20.335 61161458 [KafkaRecordConsumer-0]
org.apache.kafka.clients.FetchSessionHandler [Consumer clientId=consumer-1,
groupId=group_60_10] Node 3 was unable to
