Jeff Zhang created FLINK-11264:
--
Summary: Fail to start scala shell
Key: FLINK-11264
URL: https://issues.apache.org/jira/browse/FLINK-11264
Project: Flink
Issue Type: Bug
Reporter:
Hongtao Zhang created FLINK-11263:
-
Summary: yarn session script doesn't boot up task managers
Key: FLINK-11263
URL: https://issues.apache.org/jira/browse/FLINK-11263
Project: Flink
Issue
There’s the related issue of Async I/O not showing up in back pressure
reporting, also due to the same issue of threads not being sampled.
— Ken
> On Jan 3, 2019, at 10:25 AM, Jamie Grier wrote:
>
> One unfortunate problem with the current back-pressure detection mechanism
> is that it
.. Maybe we should add a way to register those threads such that they are
also sampled. Thoughts?
On Thu, Jan 3, 2019 at 10:25 AM Jamie Grier wrote:
> One unfortunate problem with the current back-pressure detection mechanism
> is that it doesn't work well with all of our sources. The
One unfortunate problem with the current back-pressure detection mechanism
is that it doesn't work well with all of our sources. The problem is that
some sources (Kinesis for sure) emit elements from threads Flink knows
nothing about and therefore those stack traces aren't sampled. The result
is
Would a couple folks raise their hand to make a review pass thru the 6 PRs
listed above? It is a lovely stack of PRs that is 'all green' at the
moment. I would be happy to open follow-on PRs to rapidly align with
other efforts.
Note that the code is agnostic to the details of the
Hi everyone,
I updated FLIP-28 according to the feedback that I received (online and
offline).
The biggest change is that a user now needs to add two dependencies (api
and planner) if a table program should be runnable in an IDE (as
Aljoscha suggested). This allows for a clear separation of
Fokko Driesprong created FLINK-11262:
Summary: Bump jython-standalone to 2.7.1
Key: FLINK-11262
URL: https://issues.apache.org/jira/browse/FLINK-11262
Project: Flink
Issue Type:
Chesnay Schepler created FLINK-11261:
Summary: BlobServer moves file with open OutputStream
Key: FLINK-11261
URL: https://issues.apache.org/jira/browse/FLINK-11261
Project: Flink
Issue
Fokko Driesprong created FLINK-11259:
Summary: Bump Zookeeper dependency to 3.4.13
Key: FLINK-11259
URL: https://issues.apache.org/jira/browse/FLINK-11259
Project: Flink
Issue Type:
Fokko Driesprong created FLINK-11260:
Summary: Bump Janino compiler dependency
Key: FLINK-11260
URL: https://issues.apache.org/jira/browse/FLINK-11260
Project: Flink
Issue Type:
Fokko Driesprong created FLINK-11258:
Summary: Add badge to the README
Key: FLINK-11258
URL: https://issues.apache.org/jira/browse/FLINK-11258
Project: Flink
Issue Type: Improvement
Sounds good.
> On 3. Jan 2019, at 14:27, Chesnay Schepler wrote:
>
> Since neither of these repositories are in use (flink-libraries is empty, and
> incubator-flink is 3+ years old) we could just drop them I suppose.
>
> Any objections?
>
> On 03.01.2019 14:18, Apache Infrastructure Team
Since neither of these repositories are in use (flink-libraries is
empty, and incubator-flink is 3+ years old) we could just drop them I
suppose.
Any objections?
On 03.01.2019 14:18, Apache Infrastructure Team wrote:
Hello, flink folks.
As stated earlier in 2018, all git repositories must be
Hello, flink folks.
As stated earlier in 2018, all git repositories must be migrated from
the git-wip-us.apache.org URL to gitbox.apache.org, as the old service
is being decommissioned. Your project is receiving this email because
you still have repositories on git-wip-us that needs to be
Hi Gyula,
I see the benefit of having such an option. In fact, it goes in a similar
direction as the currently ongoing discussion about blacklisting TMs. In
the end it could work by reporting failures to the RM which aggregates some
statistics for the individual TMs. Based on some thresholds it
Hi Felipe,
for streaming Flink currently does not optimize the data flow graph. I
think the best reference is actually going through the code as you've done
for the batch case.
Cheers,
Till
On Wed, Dec 19, 2018 at 3:14 PM Felipe Gutierrez <
felipe.o.gutier...@gmail.com> wrote:
> Hi,
>
> I was
Hi Chesnay, I do not think so this will work. There will be
KeyGroupStreamPartitioner involved, which calls key selector and then
involve KeyGroupRangeAssignment
So, the context here is that I am running an Apache Beam application on
Flink and Keyed stream is used e.g. to provide sharding for writing to
filesystem.
E.g. each worker is owning one or two shards and writing GBK windowed
values into files. So any custom IO which needs too shape parallelism
What you could try is using a KeySelector that maps the input records to
a range of 0-N. This should effectively behave like partitionCustom,
except that you get a keyedStream back.
On 02.01.2019 22:13, Ken Krugler wrote:
Hi Jozef,
Processing just a few keys (# of keys ≅ # of operators) in
Hi all,
peiliping: I think your idea could be problematic for couple of reasons.
Probably minor concern is that checkpoint time could be affected not only
because of the back pressure, but also because how long does it take to
actually perform the checkpoint. Bigger issues are that this
You now have contributor permissions.
On 03.01.2019 04:49, peibin wang wrote:
Hi guys,
Could anyone kindly give me the contributor permission?
My JIRA username is wangpeibin.
Thanks,
Peibin
I have some ideas about detecting the backpressure (the blocking
operators) by checkpoint barrier .
I have some flink-jobs with checkpoint , but their checkpoints will take
a long time to be completed .
I need to find out the blocking operators , the same as the
backpressure detection .
23 matches
Mail list logo
