n Mon, Aug 6, 2018 at 10:55 AM, Jan Lukavský wrote:
Hi,
I have a question about log compaction. LogCleaner's JavaDoc states that:
{quote}
A message with key K and offset O is obsolete if there exists a message
with key K and offset O' such that O < O'.
{/quote}
That wor
Hi,
I have a question about log compaction. LogCleaner's JavaDoc states that:
{quote}
A message with key K and offset O is obsolete if there exists a message
with key K and offset O' such that O < O'.
{/quote}
That works fine if messages are arriving "in-order", i.e. with timestamp
assigne
g
if (r.offset == endOffset) {
done = true;
break;
}
}
}
}
Does this help?
-Matthias
On 2/14/17 12:31 AM, Jan Lukavský wrote:
> Hi Matthias,
>
> I understand that the local cache will not be automatically cleared, but
> that is not an issue for me now.
>
> The probl
nly loading keys that got
not deleted. But this is of course a quite expensive approach and you
should be very careful about using it.
-Matthias
On 2/13/17 12:25 AM, Jan Lukavský wrote:
Hi Michael,
sorry for my late answer. Configuring the topic as you suggest is one
option (and I will conf
e wiped. So even if you don't send any data to a Kafka
partition of this (now log-compacted) "state topic" for a long period of
time, you'd always have access to (at least) the latest value for every key.
Would that help?
-Michael
On Thu, Feb 9, 2017 at 10:16 AM, Jan Lukav
same as "endOfLog"
for each partition, you can figure out that there is nothing to read. So
why would you need the last old message to figure this out?
-Matthias
On 2/7/17 3:46 AM, Jan Lukavský wrote:
Hi all,
I have a question how to do a correct caching in KTable-like structure
on ap
Hi all,
I have a question how to do a correct caching in KTable-like structure
on application startup. I'm not sure if this belongs to user or dev
maillist, so sorry if I've chosen the bad one. What is my observation so
far:
- if I don't send any data to a kafka partition for a period longe
Hi Ismael,
short answer at the end of this email. :)
On 02/02/2017 02:52 PM, Ismael Juma wrote:
I hadn't quite understood this. So the asynchronous code continues to
update the map, I see.
Regarding your suggested fix, the required change is not to hold a lock to
the map passed to `commitSync
the map to avoid this scenario as the
heartbeat thread is meant to be an implementation detail. Jason, what do
you think?
Let me know if this fixes your issue.
Ismael
On Thu, Feb 2, 2017 at 12:17 PM, Jan Lukavský wrote:
Hi Ismael,
yes, no problem:
The following thread is the main thread i
Hi Ismael,
yes, no problem:
The following thread is the main thread interacting with the
KafkaConsumer (polling topic and committing offsets):
"pool-3-thread-1" #14 prio=5 os_prio=0 tid=0x7f00f4434800 nid=0x32a9
runnable [0x7f00b6662000]
java.lang.Thread.State: RUNNABLE
a
10 matches
Mail list logo
