Congrats Alex!!
On Tue, Jan 2, 2024 at 10:12 Feng Jin wrote:
> Congratulations, Alex!
>
> Best,
> Feng
>
> On Tue, Jan 2, 2024 at 11:04 PM Chen Yu wrote:
>
> > Congratulations, Alex!
> >
> > Best,
> > Yu Chen
> >
> >
> > 发件人: Zhanghao Chen
> > 发送时间:
Congrats Matthias!!
On Sat, Aug 5, 2023 at 09:35 Runkang He wrote:
> Congratulations!
>
> Best,
> Runkang He
>
> Yanfei Lei 于2023年8月5日周六 20:13写道：
>
> > Congratulations!
> >
> > Best regards,
> > Yanfei
> >
> > Hong Liang 于2023年8月4日周五 20:02写道：
> > >
> > > Congratulations Matthias!
> > >
> > >
We discussed this in FLINK-29863[1] as well. While the JSON standard
doesn’t specify using null, the JavaScript standard encoding function
writes these values as null[2]. I think this will be least surprising to
users, and agree with the other points in this direction.
Best,
Austin
[1]:
It doesn't need to be part of the Flink 2.0 release perse, but starting to
wonder if we'd get more bang for our buck if we started fresh with a v2
REST API vs. one-off cleanups of the current v1 API. @Chesnay Schepler
-- wdyt?
The v1 REST API seemed to grow naturally from its original use case
+1
On Wed, Jul 19, 2023 at 5:14 PM Jing Ge wrote:
> +1
>
> On Mon, Jul 17, 2023 at 5:30 AM Xintong Song
> wrote:
>
> > +1
> >
> > Best,
> >
> > Xintong
> >
> >
> >
> > On Thu, Jul 13, 2023 at 9:41 PM Chesnay Schepler
> > wrote:
> >
> > > Hello,
> > >
> > > The job cancellation REST endpoint
Austin Cawley-Edwards created FLINK-32626:
-
Summary: Get Savepoint REST API doesn't distinguish non-existent
job from non-existent savepoint
Key: FLINK-32626
URL: https://issues.apache.org/jira/browse
Congrats Anton 拾
On Tue, Feb 21, 2023 at 04:08 Roman Khachatryan wrote:
> Congratulations Anton, well deserved!
>
> Regards,
> Roman
>
>
> On Tue, Feb 21, 2023 at 9:34 AM Martijn Visser
> wrote:
>
> > Congratulations Anton!
> >
> > On Tue, Feb 21, 2023 at 8:08 AM Lincoln Lee
> > wrote:
> >
>
Congrats Jing!
On Thu, Feb 16, 2023 at 01:37 Feng Jin wrote:
> Congratulations, Jing!
>
>
> Best,
> Feng
>
> On Thu, Feb 16, 2023 at 2:24 PM Weihua Hu wrote:
> >
> > Congratulations, Jing!
> >
> > Best,
> > Weihua
> >
> >
> > On Thu, Feb 16, 2023 at 2:03 PM Dian Fu wrote:
> >
> > >
Looking forward to this, thanks Alex!
On Tue, Aug 2, 2022 at 6:33 PM Alexander Fedulov
wrote:
> Hi, everyone.
>
> FLIP-238: Introduce FLIP-27-based Data Generator Source [1] has been
> accepted.
>
> Votes for: 3 binding and 2 non-binding.
>
> - Martijn Visser (binding)
> - Robert Metzger
ternal client and
> polling logic wrapped in a custom
> MapFunction implementation class? Would that answer your needs or do you
> have some
> more sophisticated scenario in mind?
>
> [1] https://cwiki.apache.org/confluence/x/9Av1D
> Best,
> Alexander Fedulov
>
> On
Thanks for the nice discussion all.
I was recently trying to implement a very simple polling source and
would've loved a higher-level base to work from. I'm wondering if in
addition to the data generator use cases, it would be good to support a
simple non-parallel polling abstraction to make it
Hey Jeremy,
Thanks for kicking off this discussion. As a Flink user, I too struggled
with the lack of HTTP support and rolled my own with AsyncIO. Reading
through the FLIP, I just have a few general questions and comments.
* It is not clear to me if multiple HTTP methods are supported or not?
> A lot of amazing devs / folks out there who maybe don’t see themselves as
> “prominent” enough but will speak up on slack.
>
> So +1 from your friends in Iceberg (at least me).
>
> Feel free to reach out if you have any questions!
>
> - Kyle
>
> On Fri, May
Hi all,
Would just like to share an interesting article from the dbt community[1],
which in part describes some of their challenges in managing Slack in a
large community. The biggest point it seems to make is that their Slack has
become a marketing tool for dbt/data vendors instead of a
Austin Cawley-Edwards created FLINK-27356:
-
Summary: Incorrect Number of Methods Listed for SplitReader
Key: FLINK-27356
URL: https://issues.apache.org/jira/browse/FLINK-27356
Project: Flink
Congrats David!
On Fri, Mar 4, 2022 at 12:18 PM Zhilong Hong wrote:
> Congratulations, David!
>
> Best,
> Zhilong
>
> On Sat, Mar 5, 2022 at 1:09 AM Piotr Nowojski
> wrote:
>
> > Congratulations :)
> >
> > pt., 4 mar 2022 o 16:04 Aitozi napisał(a):
> >
> > > Congratulations David!
> > >
> > >
Congrats Martijn!
On Thu, Mar 3, 2022 at 10:50 AM Robert Metzger wrote:
> Hi everyone,
>
> On behalf of the PMC, I'm very happy to announce Martijn Visser as a new
> Flink committer.
>
> Martijn is a very active Flink community member, driving a lot of efforts
> on the dev@flink mailing list.
JIRA issue for this proposal?
>>
>> Cheers,
>> Till
>>
>> On Wed, Feb 23, 2022 at 12:50 AM Galen Warren
>> wrote:
>>
>> > Yeah, good point. I wasn't considering that someone else might be
>> > implementing that interface. Practically, I th
work.
>
> Would that work for you? What do the rest of you think?
>
>
>
> On Tue, Feb 22, 2022 at 3:52 PM Austin Cawley-Edwards <
> austin.caw...@gmail.com> wrote:
>
>> What does "SomeOtherFunc" need with the statefun context
>>>
>>> I
gt;> > > key, val interface{}
>>>> >> >> > > }
>>>> >> >> > >
>>>> >> >> > > func (c *valueCtx) Value(key interface{}) interface{} {
>>>> >> >> > > if c.key == key {
>>>> >> >>
;> > Wiesman can elaborate a bit more on the design
>> > decisions to make sure that we have the full picture.
>> >
>> > As a cheap workaround you could create a context.Context object by
>> calling
>> > https://github.com/knative/pkg/blob/d48172451966/l
It would be helpful to have a small example though, if you have on Galen,
to see how you're passing it around.
On Fri, Feb 18, 2022 at 11:10 AM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> Looking through the statefun Context interface, it indeed doesn't give
b 18, 2022 at 11:03 AM Galen Warren
wrote:
> Sorry Austin, I didn't see your response before I replied. Yes, we're
> saying the same thing.
>
> On Fri, Feb 18, 2022 at 10:56 AM Austin Cawley-Edwards <
> austin.caw...@gmail.com> wrote:
>
> > Hey all, jumping in. This ma
Hey all, jumping in. This makes sense to me – for instance to attach a
logger with some common metadata, e.g trace ID for the request? This is
common in go to add arbitrary items without updating the method signatures,
similar to thread local storage in Java.
On Fri, Feb 18, 2022 at 10:53 AM Till
Pyroscope[1] and Parca[2] are other options for less-intrusive profiling (&
great fits for k8s) that move the burden from Flink & its UI to tools that
are purpose-built for this use case. Perhaps we could investigate what it
would take (if anything) to make Flink compatible with those?
Best,
Are there e2e tests that run on kubernetes? Perhaps k8s network policies[1]
would be an option to simulate asymmetric network partitions without
modifying iptables in a more approachable way?
Austin
[1]:
https://kubernetes.io/docs/concepts/services-networking/network-policies/
On Wed, Feb 9,
Austin Cawley-Edwards created FLINK-24275:
-
Summary: Allow idempotent job cancellation
Key: FLINK-24275
URL: https://issues.apache.org/jira/browse/FLINK-24275
Project: Flink
Issue
Congrats Yang!
On Wed, Jul 7, 2021 at 7:26 AM Jingsong Li wrote:
> Congratulations, Yang!
>
> Best,
> Jingsong
>
> On Wed, Jul 7, 2021 at 6:43 PM Arvid Heise wrote:
>
> > Congratulations!
> >
> > On Wed, Jul 7, 2021 at 12:17 PM godfrey he wrote:
> >
> > > Congratulations, Yang!
> > >
> > >
Hi Márton,
The FLIP looks generally good to me, though could we add the
`@Experimental` annotation to the proposed interfaces so it is in sync with
what was agreed in the discussion thread?
Thanks,
Austin
On Tue, Jul 6, 2021 at 9:40 AM Gyula Fóra wrote:
> +1 from my side
>
> This is a good
; This would simply restrict use-cases where order is not important.
> Limiting devs such an add way is no-go.
> I think the ordering came up multiple places which I think is a good
> reason fill this gap with a priority function.
> I've updated the doc and added it...
>
> BR,
>
> having the implementor of the internal authorization module bundle
> everything into one, as you have suggested. Since this is the only way to
> achieve order, why not restrict the service loader to only allow one? This
> way the API is explicit in what it supports.
>
>
> Let m
> Hi Austin,
>
> Please see my answers embedded down below.
>
> BR,
> G
>
>
>
> On Tue, Jun 29, 2021 at 9:59 PM Austin Cawley-Edwards <
> austin.caw...@gmail.com> wrote:
>
>> Hi all,
>>
>> Thanks for the updated proposal. I have a few ques
6Dg-hi-hEuL6hwM/edit#heading=h.ijcbce3c5gip
> [2]
>
> https://github.com/gaborgsomogyi/flink/commit/942f23679ac21428bb87fc85557b9b443fcaf310
>
> Thanks,
> Marton
>
> On Wed, Jun 23, 2021 at 9:36 PM Austin Cawley-Edwards <
> austin.caw...@gmail.com> wrote:
>
&g
odebase. I have worked with close
> > to a
> > > hundred Big Data customers as a consultant and an engineering manager
> and
> > > committed hundreds of changes to Apache Flink over the past decade,
> > please
> > > trust my judgement on a s
API would be added without any real
> > authentication logic?
> > That way every provider can add its own protocol implementation as
> > additional jar.
> >
> > BR,
> > G
> >
> >
> > On Thu, Jun 17, 2021 at 7:53 PM Austin Cawley-E
Hi all,
Sorry to be joining the conversation late. I'm also on the side of
Konstantin, generally, in that this seems to not be a core goal of Flink as
a project and adds a maintenance burden.
Would another con of Kerberos be that is likely a fading project in terms
of network security? (serious
Austin Cawley-Edwards created FLINK-22698:
-
Summary: RabbitMQ source does not stop unless message arrives in
queue
Key: FLINK-22698
URL: https://issues.apache.org/jira/browse/FLINK-22698
Sorry @dev list for the pings – I misread which thread I was replying to.
@Pedro Silva – the dev@flink.apache.org list is
used for developers working on Flink itself. Please use
u...@flink.apache.org for future questions :)
Best,
Austin
On Mon, May 17, 2021 at 3:58 PM Austin Cawley-Edwards
Hi Pedro,
There is currently no official Kubernetes Operator for Flink and, by
extension, there is no official Helm chart. It would be relatively easy to
create a chart for simply deploying standalone Flink resources via the
Kubernetes manifests described here[1], though it would leave out the
>
> On Fri, Oct 16, 2020 at 8:32 PM Austin Cawley-Edwards <
> austin.caw...@gmail.com> wrote:
>
>> Hey all,
>>
>> I'm ingesting CSV files with Flink 1.10.2 using SQL and the CSV
>> Format[1].
>>
>> Even with the `ignoreParseErrors()`
Austin Cawley-Edwards created FLINK-18755:
-
Summary: RabbitMQ QoS Chinese Documentation
Key: FLINK-18755
URL: https://issues.apache.org/jira/browse/FLINK-18755
Project: Flink
Issue
Ah, missed Till's response -- thanks as well!
I'll add those headers to the files, so just now wondering about including
the licenses/ notice in the RMQ connector resources.
On Mon, Jun 15, 2020 at 7:40 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> Hey Robert,
&
ou
> > would give these files the ASL license header and add a comment to the
> > source code from where it was copied.
> >
> > Cheers,
> > Till
> >
> > On Sat, Jun 13, 2020 at 10:41 PM Austin Cawley-Edwards <
> > austin.caw...@gmail.com> wrote:
&
Hi all,
I'm working on [FLINK-10195] on the RabbitMQ connector which involves
modifying some of the RMQ client source code (that has been moved out of
that package) and bringing it into Flink. The RMQ client code is
triple-licensed under Mozilla Public License 1.1 ("MPL"), the GNU General
Public
Austin Cawley-Edwards created FLINK-17529:
-
Summary: Replace Deprecated RMQ QueueingConsumer
Key: FLINK-17529
URL: https://issues.apache.org/jira/browse/FLINK-17529
Project: Flink
;
> > > Okay so keep the current constructors as is, create new ones with more
> > > granular parsing of the results. Sounds like a good plan.
> > >
> > > How do we proceed from here ?
> > >
> > > Regards,
> > > Karim Mansour
> > >
ore granular parsing ?
>
> Regards,
> Karim Mansour
>
> On Thu, Apr 30, 2020 at 5:23 PM Austin Cawley-Edwards <
> aus...@fintechstudios.com> wrote:
>
> > Hey all + thanks Konstantin,
> >
> > Like mentioned, we also run into issues with the RMQ Source
&
it at maintaining them!
Best,
Austin
From: Konstantin Knauf
Sent: Thursday, April 30, 2020 6:14 AM
To: dev
Cc: Austin Cawley-Edwards
Subject: Re: [DISCUSS] flink-connector-rabbitmq api changes
Hi everyone,
just looping in Austin as he mentioned that they also ran
48 matches
Mail list logo
