M. Manna created KAFKA-7358:
---
Summary: Extended Partitioner to Support "Always Round Robin"
Selection
Key: KAFKA-7358
URL: https://issues.apache.org/jira/browse/KAFKA-7358
Project: Kafka
Issue Typ
Hello,
I opened a very simple KIP and there exists a JIRA for it.
I have already sent it to users' list - but the mail thread doesn't seem to
get updated.
I would be grateful if any comments are available for action.
Regards,
Hello, John.
I've updated KIP according on your comments.
Please, take a look.
Are we ready to vot now?
В Ср, 29/08/2018 в 14:51 -0500, John Roesler пишет:
> Hey Nikolay, sorry for the silence. I'm taking another look at the KIP
> before voting...
>
>
>1. I think the Window constructor sho
Hi there,
I can't see this KIP on the KIP wiki, could you double check?
Thanks
Eno
On Thu, Aug 30, 2018 at 9:56 AM, M. Manna wrote:
> Hello,
>
> I opened a very simple KIP and there exists a JIRA for it.
>
> I have already sent it to users' list - but the mail thread doesn't seem to
> get upd
I just added you as a "Watcher". I can see the page via this link -
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=89070828
1) visited cwiki.apache.org
2) Opened "Apache Kafka" from Space Directory
3) Browsed to Kafka Improvement Proposals (or Design Proposals).
4) From the side
Dmitry created KAFKA-7359:
-
Summary: How to align kafka partition
Key: KAFKA-7359
URL: https://issues.apache.org/jira/browse/KAFKA-7359
Project: Kafka
Issue Type: Task
Components: documenta
Thanks for the KIP and the updates Viktor!
+1 (non-binding)
On Wed, Aug 29, 2018 at 10:44 AM Manikumar
wrote:
> +1 (non-binding)
>
> Thanks for the KIP.
>
> On Wed, Aug 29, 2018 at 1:41 AM Jason Gustafson
> wrote:
>
> > +1 Thanks for the updates.
> >
> > On Tue, Aug 28, 2018 at 1:15 AM, Vikt
Nick,
Would be good to understand the difference between the current approach
and what Jan suggested. If we believe that the current proposal is too
limited in functionality and also hard to extend later on, it might make
sense to work on a more generic solution from the beginning on. On the
other
Changing subject back to DISCUSS.
> On Aug 20, 2018, at 6:52 AM, Jan Filipiak wrote:
>
> Just saying that we should peek at the Samza approach, it's a much more
> powerful abstraction. We can ship a default MessageChooser
> that looks at the topics priority.
Thanks Jan for your input.
Here’
Sven Erik Knop created KAFKA-7360:
-
Summary: Code example in "Accessing Processor Context" misses a
closing parenthesis
Key: KAFKA-7360
URL: https://issues.apache.org/jira/browse/KAFKA-7360
Project: K
Just clarifying that the API below would be in addition to the API specified in
KIP-349
https://cwiki.apache.org/confluence/display/KAFKA/KIP-349%3A+Priorities+for+Source+Topics
--
Nick
> On Aug 30, 2018, at 9:57 AM, n...@afshartous.com wrote:
>
> Here’s an attempt at incorporating
C Schabert created KAFKA-7361:
-
Summary: Kafka wont reconnect after NoRouteToHostException
Key: KAFKA-7361
URL: https://issues.apache.org/jira/browse/KAFKA-7361
Project: Kafka
Issue Type: Bug
+1.
Thanks,
Harsha
On Thu, Aug 30, 2018, at 4:19 AM, Attila Sasvári wrote:
> Thanks for the KIP and the updates Viktor!
>
> +1 (non-binding)
>
>
>
> On Wed, Aug 29, 2018 at 10:44 AM Manikumar
> wrote:
>
> > +1 (non-binding)
> >
> > Thanks for the KIP.
> >
> > On Wed, Aug 29, 2018 at 1:41 AM
[
https://issues.apache.org/jira/browse/KAFKA-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ismael Juma resolved KAFKA-7338.
Resolution: Fixed
> Fix SASL Kerberos tests with Java 11
>
>
>
Hi,
Thanks for the KIP.
Have you considered using the overloaded ProducerRecord constructor where
you can specify the partition? I mention this as an option as I
encountered the same issue on a previous project and that is how we handled
round-robin distribution with non-null keys.
Would that
Hi,
NOTE: I sent this earlier, but that message just went to the dev list. I'm
including both users and dev now.
Thanks for the KIP.
Have you considered using the overloaded ProducerRecord constructor where
you can specify the partition? I mention this as an option as I
encountered the same i
Hey Bill,
Thanks for reading the KIP, much appreciated.
The reason we want it to be a separate Partitioner is because:
a) We don’t want to specify partition anywhere.
b) we want to be able to reuse what’s been done for NULL key in
DefaultPartitioner.
Using the constructor means we need to assi
Oh! I missed one minor thing: UnlimitedWindows doesn't need to set grace
(it currently does not either).
Otherwise, it looks good to me!
Thanks so much,
-John
On Thu, Aug 30, 2018 at 5:30 AM Nikolay Izhikov wrote:
> Hello, John.
>
> I've updated KIP according on your comments.
> Please, take a
+including both dev and user mailing lists.
Hi,
Thanks for the KIP.
"* For us, the message keys represent some metadata which we use to either
ignore messages (if a loop-back to the sender), or log some information.*"
Above statement was mentioned in the KIP about how key value is used. I
guess
John, thank you.
I've updated KIP.
Dear commiters, please take a look and share your opinion.
В Чт, 30/08/2018 в 14:58 -0500, John Roesler пишет:
> Oh! I missed one minor thing: UnlimitedWindows doesn't need to set grace
> (it currently does not either).
>
> Otherwise, it looks good to me!
>
Hi Guozhang,
Thanks for reviewing the proposal. I didn't think of out of order events
and glad that you brought it up.
In the example you gave,
(10, 10), (19, 5), (15, 3) ...
my understanding is that the correct result window should be the same as in
order events
(10, 10), (15, 3), (19, 5) ...
Hi All,
I'd like to start the vote on KIP-359: https://cwiki.apache.org/
confluence/display/KAFKA/KIP-359%3A+Verify+leader+epoch+in+produce+requests.
Thanks in advance for reviewing.
-Jason
Sorry for chiming in late, there was a lot of detail to catch up on.
Overall I'm +1 in the KIP. But I do have one question about the KIP in
regards to Matthias's comments about defining dual use.
In the "Proposed Changes" section, there is "Try to reduce the visibility
of methods in next tickets
xiongqi wu created KAFKA-7362:
-
Summary: enable kafka broker to remove orphan partitions
automatically
Key: KAFKA-7362
URL: https://issues.apache.org/jira/browse/KAFKA-7362
Project: Kafka
Issue
Thanks for the KIP!
+1 (binding)
On Thu, Aug 30, 2018 at 3:56 PM, Jason Gustafson wrote:
> Hi All,
>
> I'd like to start the vote on KIP-359: https://cwiki.apache.org/
> confluence/display/KAFKA/KIP-359%3A+Verify+leader+epoch+in+
> produce+requests.
> Thanks in advance for reviewing.
>
> -Jason
Neat, this would be super helpful! I submitted this ages ago:
https://issues.apache.org/jira/browse/KAFKA-
On Fri, Aug 31, 2018 at 5:04 AM, Satish Duggana
wrote:
> +including both dev and user mailing lists.
>
> Hi,
> Thanks for the KIP.
>
> "* For us, the message keys represent some metadat
Thanks for the KIP. I'm +1 (non-binding).
Best,
Dongjin
On Fri, Aug 31, 2018 at 9:25 AM Dong Lin wrote:
> Thanks for the KIP!
>
> +1 (binding)
>
> On Thu, Aug 30, 2018 at 3:56 PM, Jason Gustafson
> wrote:
>
> > Hi All,
> >
> > I'd like to start the vote on KIP-359: https://cwiki.apache.org/
>
+1 for this. The only small suggestion would be to possibly call this
RondRobinPartitioner which makes the intent obvious.
On Thu, Aug 30, 2018 at 5:31 PM Stephen Powis wrote:
> Neat, this would be super helpful! I submitted this ages ago:
> https://issues.apache.org/jira/browse/KAFKA-
>
> O
Seweryn Habdank-Wojewodzki created KAFKA-7363:
-
Summary: How num.stream.threads in streaming application influence
memory consumption?
Key: KAFKA-7363
URL: https://issues.apache.org/jira/browse/KAFKA-7
Yu Yang created KAFKA-7364:
--
Summary: kafka periodically run into high cpu usage with ssl
writing
Key: KAFKA-7364
URL: https://issues.apache.org/jira/browse/KAFKA-7364
Project: Kafka
Issue Type: Bu
Hello, Bill
> In the "Proposed Changes" section, there is "Try to reduce the visibility of
> methods in next tickets" does that mean eventual deprecation and removal?
1. Some methods will become deprecated. I think they will be removed in the
future.
You can find list of deprecated methods in K
31 matches
Mail list logo
