PartitionNotFoundException after deployment

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

PartitionNotFoundException after deployment

Gyula Fóra
Hi Ufuk,

Do you have any quick idea what could cause this problems in flink 1.4.2?
Seems like one operator takes too long to deploy and downstream tasks error out on partition not found. This only seems to happen when the job is restored from state and in fact that operator has some keyed and operator state as well.

Deploying the same job from empty state works well. We tried increasing the taskmanager.network.request-backoff.max that didnt help.

It would be great if you have some pointers where to look further, I havent seen this happening before.

Thank you!
Gyula

The errror:
org.apache.flink.runtime.io.network.partition.: Partition 4c5e9cd5dd410331103f51127996068a@b35ef4ffe25e3d17c5d6051ebe2860cd not found.
    at org.apache.flink.runtime.io.network.partition.ResultPartitionManager.createSubpartitionView(ResultPartitionManager.java:77)
    at org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel.requestSubpartition(LocalInputChannel.java:115)
    at org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel$1.run(LocalInputChannel.java:159)
    at java.util.TimerThread.mainLoop(Timer.java:555)
    at java.util.TimerThread.run(Timer.java:505)
Reply | Threaded
Open this post in threaded view
|

Re: PartitionNotFoundException after deployment

Ufuk Celebi-2
Hey Gyula!

I'm including Piotr and Nico (cc'd) who have worked on the network
stack in the last releases.

Registering the network structures including the intermediate results
actually happens **before** any state is restored. I'm not sure why
this reproducibly happens when you restore state. @Nico, Piotr: any
ideas here?

In general I think what happens here is the following:
- a task requests the result of a local upstream producer, but that
one has not registered its intermediate result yet
- this should result in a retry of the request with some backoff
(controlled via the config params you mention
taskmanager.network.request-backoff.max,
taskmanager.network.request-backoff.initial)

As a first step I would set logging to DEBUG and check the TM logs for
messages like "Retriggering partition request {}:{}."

You can also check the SingleInputGate code which has the logic for
retriggering requests.

– Ufuk


On Fri, May 4, 2018 at 10:27 AM, Gyula Fóra <[hidden email]> wrote:

> Hi Ufuk,
>
> Do you have any quick idea what could cause this problems in flink 1.4.2?
> Seems like one operator takes too long to deploy and downstream tasks error
> out on partition not found. This only seems to happen when the job is
> restored from state and in fact that operator has some keyed and operator
> state as well.
>
> Deploying the same job from empty state works well. We tried increasing the
> taskmanager.network.request-backoff.max that didnt help.
>
> It would be great if you have some pointers where to look further, I havent
> seen this happening before.
>
> Thank you!
> Gyula
>
> The errror:
> org.apache.flink.runtime.io.network.partition.: Partition
> 4c5e9cd5dd410331103f51127996068a@b35ef4ffe25e3d17c5d6051ebe2860cd not found.
>     at
> org.apache.flink.runtime.io.network.partition.ResultPartitionManager.createSubpartitionView(ResultPartitionManager.java:77)
>     at
> org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel.requestSubpartition(LocalInputChannel.java:115)
>     at
> org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel$1.run(LocalInputChannel.java:159)
>     at java.util.TimerThread.mainLoop(Timer.java:555)
>     at java.util.TimerThread.run(Timer.java:505)



--
Data Artisans GmbH | Stresemannstr. 121a | 10963 Berlin

[hidden email]
+49-30-43208879

Registered at Amtsgericht Charlottenburg - HRB 158244 B
Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
Reply | Threaded
Open this post in threaded view
|

Re: PartitionNotFoundException after deployment

Piotr Nowojski
Ufuk: I don’t know why.

+1 for your other suggestions.

Piotrek

> On 4 May 2018, at 14:52, Ufuk Celebi <[hidden email]> wrote:
>
> Hey Gyula!
>
> I'm including Piotr and Nico (cc'd) who have worked on the network
> stack in the last releases.
>
> Registering the network structures including the intermediate results
> actually happens **before** any state is restored. I'm not sure why
> this reproducibly happens when you restore state. @Nico, Piotr: any
> ideas here?
>
> In general I think what happens here is the following:
> - a task requests the result of a local upstream producer, but that
> one has not registered its intermediate result yet
> - this should result in a retry of the request with some backoff
> (controlled via the config params you mention
> taskmanager.network.request-backoff.max,
> taskmanager.network.request-backoff.initial)
>
> As a first step I would set logging to DEBUG and check the TM logs for
> messages like "Retriggering partition request {}:{}."
>
> You can also check the SingleInputGate code which has the logic for
> retriggering requests.
>
> – Ufuk
>
>
> On Fri, May 4, 2018 at 10:27 AM, Gyula Fóra <[hidden email]> wrote:
>> Hi Ufuk,
>>
>> Do you have any quick idea what could cause this problems in flink 1.4.2?
>> Seems like one operator takes too long to deploy and downstream tasks error
>> out on partition not found. This only seems to happen when the job is
>> restored from state and in fact that operator has some keyed and operator
>> state as well.
>>
>> Deploying the same job from empty state works well. We tried increasing the
>> taskmanager.network.request-backoff.max that didnt help.
>>
>> It would be great if you have some pointers where to look further, I havent
>> seen this happening before.
>>
>> Thank you!
>> Gyula
>>
>> The errror:
>> org.apache.flink.runtime.io.network.partition.: Partition
>> 4c5e9cd5dd410331103f51127996068a@b35ef4ffe25e3d17c5d6051ebe2860cd not found.
>>    at
>> org.apache.flink.runtime.io.network.partition.ResultPartitionManager.createSubpartitionView(ResultPartitionManager.java:77)
>>    at
>> org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel.requestSubpartition(LocalInputChannel.java:115)
>>    at
>> org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel$1.run(LocalInputChannel.java:159)
>>    at java.util.TimerThread.mainLoop(Timer.java:555)
>>    at java.util.TimerThread.run(Timer.java:505)
>
>
>
> --
> Data Artisans GmbH | Stresemannstr. 121a | 10963 Berlin
>
> [hidden email]
> +49-30-43208879
>
> Registered at Amtsgericht Charlottenburg - HRB 158244 B
> Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen

Reply | Threaded
Open this post in threaded view
|

Re: PartitionNotFoundException after deployment

Gyula Fóra
Looks pretty clear that one operator takes too long to start (even on the UI it shows it in the created state for far too long). Any idea what might cause this delay? It actually often crashes on Akka ask timeout during scheduling the node.

Gyula

Piotr Nowojski <[hidden email]> ezt írta (időpont: 2018. máj. 4., P, 15:33):
Ufuk: I don’t know why.

+1 for your other suggestions.

Piotrek

> On 4 May 2018, at 14:52, Ufuk Celebi <[hidden email]> wrote:
>
> Hey Gyula!
>
> I'm including Piotr and Nico (cc'd) who have worked on the network
> stack in the last releases.
>
> Registering the network structures including the intermediate results
> actually happens **before** any state is restored. I'm not sure why
> this reproducibly happens when you restore state. @Nico, Piotr: any
> ideas here?
>
> In general I think what happens here is the following:
> - a task requests the result of a local upstream producer, but that
> one has not registered its intermediate result yet
> - this should result in a retry of the request with some backoff
> (controlled via the config params you mention
> taskmanager.network.request-backoff.max,
> taskmanager.network.request-backoff.initial)
>
> As a first step I would set logging to DEBUG and check the TM logs for
> messages like "Retriggering partition request {}:{}."
>
> You can also check the SingleInputGate code which has the logic for
> retriggering requests.
>
> – Ufuk
>
>
> On Fri, May 4, 2018 at 10:27 AM, Gyula Fóra <[hidden email]> wrote:
>> Hi Ufuk,
>>
>> Do you have any quick idea what could cause this problems in flink 1.4.2?
>> Seems like one operator takes too long to deploy and downstream tasks error
>> out on partition not found. This only seems to happen when the job is
>> restored from state and in fact that operator has some keyed and operator
>> state as well.
>>
>> Deploying the same job from empty state works well. We tried increasing the
>> taskmanager.network.request-backoff.max that didnt help.
>>
>> It would be great if you have some pointers where to look further, I havent
>> seen this happening before.
>>
>> Thank you!
>> Gyula
>>
>> The errror:
>> org.apache.flink.runtime.io.network.partition.: Partition
>> 4c5e9cd5dd410331103f51127996068a@b35ef4ffe25e3d17c5d6051ebe2860cd not found.
>>    at
>> org.apache.flink.runtime.io.network.partition.ResultPartitionManager.createSubpartitionView(ResultPartitionManager.java:77)
>>    at
>> org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel.requestSubpartition(LocalInputChannel.java:115)
>>    at
>> org.apache.flink.runtime.io.network.partition.consumer.LocalInputChannel$1.run(LocalInputChannel.java:159)
>>    at java.util.TimerThread.mainLoop(Timer.java:555)
>>    at java.util.TimerThread.run(Timer.java:505)
>
>
>
> --
> Data Artisans GmbH | Stresemannstr. 121a | 10963 Berlin
>
> [hidden email]
> <a href="tel:+49%2030%2043208879" value="+493043208879" target="_blank">+49-30-43208879
>
> Registered at Amtsgericht Charlottenburg - HRB 158244 B
> Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen

Reply | Threaded
Open this post in threaded view
|

Re: PartitionNotFoundException after deployment

Nico Kruber
Hi Gyula,
as a follow-up, you may be interested in
https://issues.apache.org/jira/browse/FLINK-9413


Nico

On 04/05/18 15:36, Gyula Fóra wrote:

> Looks pretty clear that one operator takes too long to start (even on
> the UI it shows it in the created state for far too long). Any idea what
> might cause this delay? It actually often crashes on Akka ask timeout
> during scheduling the node.
>
> Gyula
>
> Piotr Nowojski <[hidden email]
> <mailto:[hidden email]>> ezt írta (időpont: 2018. máj. 4., P,
> 15:33):
>
>     Ufuk: I don’t know why.
>
>     +1 for your other suggestions.
>
>     Piotrek
>
>     > On 4 May 2018, at 14:52, Ufuk Celebi <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     > Hey Gyula!
>     >
>     > I'm including Piotr and Nico (cc'd) who have worked on the network
>     > stack in the last releases.
>     >
>     > Registering the network structures including the intermediate results
>     > actually happens **before** any state is restored. I'm not sure why
>     > this reproducibly happens when you restore state. @Nico, Piotr: any
>     > ideas here?
>     >
>     > In general I think what happens here is the following:
>     > - a task requests the result of a local upstream producer, but that
>     > one has not registered its intermediate result yet
>     > - this should result in a retry of the request with some backoff
>     > (controlled via the config params you mention
>     > taskmanager.network.request-backoff.max,
>     > taskmanager.network.request-backoff.initial)
>     >
>     > As a first step I would set logging to DEBUG and check the TM logs for
>     > messages like "Retriggering partition request {}:{}."
>     >
>     > You can also check the SingleInputGate code which has the logic for
>     > retriggering requests.
>     >
>     > – Ufuk
>     >
>     >
>     > On Fri, May 4, 2018 at 10:27 AM, Gyula Fóra <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >> Hi Ufuk,
>     >>
>     >> Do you have any quick idea what could cause this problems in
>     flink 1.4.2?
>     >> Seems like one operator takes too long to deploy and downstream
>     tasks error
>     >> out on partition not found. This only seems to happen when the job is
>     >> restored from state and in fact that operator has some keyed and
>     operator
>     >> state as well.
>     >>
>     >> Deploying the same job from empty state works well. We tried
>     increasing the
>     >> taskmanager.network.request-backoff.max that didnt help.
>     >>
>     >> It would be great if you have some pointers where to look
>     further, I havent
>     >> seen this happening before.
>     >>
>     >> Thank you!
>     >> Gyula
>     >>
>     >> The errror:
>     >> org.apache.flink.runtime.io
>     <http://org.apache.flink.runtime.io>.network.partition.: Partition
>     >> 4c5e9cd5dd410331103f51127996068a@b35ef4ffe25e3d17c5d6051ebe2860cd
>     not found.
>     >>    at
>     >> org.apache.flink.runtime.io
>     <http://org.apache.flink.runtime.io>.network.partition.ResultPartitionManager.createSubpartitionView(ResultPartitionManager.java:77)
>     >>    at
>     >> org.apache.flink.runtime.io
>     <http://org.apache.flink.runtime.io>.network.partition.consumer.LocalInputChannel.requestSubpartition(LocalInputChannel.java:115)
>     >>    at
>     >> org.apache.flink.runtime.io
>     <http://org.apache.flink.runtime.io>.network.partition.consumer.LocalInputChannel$1.run(LocalInputChannel.java:159)
>     >>    at java.util.TimerThread.mainLoop(Timer.java:555)
>     >>    at java.util.TimerThread.run(Timer.java:505)
>     >
>     >
>     >
>     > --
>     > Data Artisans GmbH | Stresemannstr. 121a | 10963 Berlin
>     >
>     > [hidden email] <mailto:[hidden email]>
>     > +49-30-43208879 <tel:+49%2030%2043208879>
>     >
>     > Registered at Amtsgericht Charlottenburg - HRB 158244 B
>     > Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
>
--
Nico Kruber | Software Engineer
data Artisans

Follow us @dataArtisans
--
Join Flink Forward - The Apache Flink Conference
Stream Processing | Event Driven | Real Time
--
Data Artisans GmbH | Stresemannstr. 121A,10963 Berlin, Germany
data Artisans, Inc. | 1161 Mission Street, San Francisco, CA-94103, USA
--
Data Artisans GmbH
Registered at Amtsgericht Charlottenburg: HRB 158244 B
Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen


signature.asc (201 bytes) Download Attachment