[jira] [Commented] (FLINK-8918) Introduce Runtime Filter Join

[Sihua Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394817#comment-16394817
 ] 

Sihua Zhou commented on FLINK-8918:
---

Hi [~fhueske] could you please have a look at this after flink 1.5 is released ?

> Introduce Runtime Filter Join
> -
>
> Key: FLINK-8918
> URL: https://issues.apache.org/jira/browse/FLINK-8918
> Project: Flink
>  Issue Type: Bug
>  Components: Table API  SQL
>Reporter: Sihua Zhou
>Assignee: Sihua Zhou
>Priority: Major
> Fix For: 1.6.0
>
>
> Right now, for every record that need to be joined, we need to query both 
> `left stream's state` and `right stream's state`. I proposal to introduce RF 
> join to reduce the `query count` of state, which could improve the 
> performance of `stream join`, especially when the joined rate is low. A 
> simple description for RF join can be found 
> [here|https://www.cloudera.com/documentation/enterprise/5-9-x/topics/impala_runtime_filtering.html]
>  (even though it not for stream join original, but we can easily refer it to 
> `stream join`).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FLINK-8918) Introduce Runtime Filter Join

[Sihua Zhou (JIRA)]

Sihua Zhou created FLINK-8918:
-

 Summary: Introduce Runtime Filter Join
 Key: FLINK-8918
 URL: https://issues.apache.org/jira/browse/FLINK-8918
 Project: Flink
  Issue Type: Bug
  Components: Table API  SQL
Reporter: Sihua Zhou
Assignee: Sihua Zhou
 Fix For: 1.6.0


Right now, for every record that need to be joined, we need to query both `left 
stream's state` and `right stream's state`. I proposal to introduce RF join to 
reduce the `query count` of state, which could improve the performance of 
`stream join`, especially when the joined rate is low. A simple description for 
RF join can be found 
[here|https://www.cloudera.com/documentation/enterprise/5-9-x/topics/impala_runtime_filtering.html]
 (even though it not for stream join original, but we can easily refer it to 
`stream join`).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8690) Update logical rule set to generate FlinkLogicalAggregate explicitly allow distinct agg on DataStream

[Rong Rong (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394806#comment-16394806
 ] 

Rong Rong commented on FLINK-8690:
--

Sweet. Thank you [~hequn8128]!
I am still a bit skeptical putting a "LOGICAL_RULESET" which is not entirely 
logical, I guess I will receive more feedback once the PR is out. :-P
Much appreciate the feedback and suggestion Hequn.

> Update logical rule set to generate FlinkLogicalAggregate explicitly allow 
> distinct agg on DataStream
> -
>
> Key: FLINK-8690
> URL: https://issues.apache.org/jira/browse/FLINK-8690
> Project: Flink
>  Issue Type: Sub-task
>Reporter: Rong Rong
>Assignee: Rong Rong
>Priority: Major
>
> Currently, *FlinkLogicalAggregate / FlinkLogicalWindowAggregate* does not 
> allow distinct aggregate.
> We are proposing to reuse distinct aggregate codegen work designed for 
> *FlinkLogicalOverAggregate*, to support unbounded distinct aggregation on 
> datastream as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8689) Add runtime support of distinct filter using MapView

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394805#comment-16394805
 ] 

ASF GitHub Bot commented on FLINK-8689:
---

Github user walterddr commented on the issue:

https://github.com/apache/flink/pull/
  
Thanks @hequn8128 for the prompt review. 
Are you suggesting we created the mapView parallel with the accumulator? 
The reason why I kept `DistinctAccumulator` is to act as a delegate to enclose 
the actual accumulator so that it can be passed around in the 
`accumulatorState` field without extending the arity.

I guess if we separate the mapView with the accumulator. I guess I can 
separately create another field in the `accumulatorState` `Row` to store the 
`mapView`(s)... This way it might be easier to handle the "reuse same mapView 
for multiple different distinct agg function" case as we discussed in the doc.

Another question is I was trying to reuse as much utility of dataview 
codegen as possible, as most of them are tightly coupled with the accumulators. 
I guess I can further refactor (which I already did quite a bit already).

Please let me know if that's what you had in mind @hequn8128 

--
Rong


> Add runtime support of distinct filter using MapView 
> -
>
> Key: FLINK-8689
> URL: https://issues.apache.org/jira/browse/FLINK-8689
> Project: Flink
>  Issue Type: Sub-task
>Reporter: Rong Rong
>Assignee: Rong Rong
>Priority: Major
>
> This ticket should cover distinct aggregate function support to codegen for 
> *AggregateCall*, where *isDistinct* fields is set to true.
> This can be verified using the following SQL, which is not currently 
> producing correct results.
> {code:java}
> SELECT
>   a,
>   SUM(b) OVER (PARTITION BY a ORDER BY proctime ROWS BETWEEN 5 PRECEDING AND 
> CURRENT ROW)
> FROM
>   MyTable{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5555: [FLINK-8689][table]Add runtime support of distinct filter...

[walterddr]

Github user walterddr commented on the issue:

https://github.com/apache/flink/pull/
  
Thanks @hequn8128 for the prompt review. 
Are you suggesting we created the mapView parallel with the accumulator? 
The reason why I kept `DistinctAccumulator` is to act as a delegate to enclose 
the actual accumulator so that it can be passed around in the 
`accumulatorState` field without extending the arity.

I guess if we separate the mapView with the accumulator. I guess I can 
separately create another field in the `accumulatorState` `Row` to store the 
`mapView`(s)... This way it might be easier to handle the "reuse same mapView 
for multiple different distinct agg function" case as we discussed in the doc.

Another question is I was trying to reuse as much utility of dataview 
codegen as possible, as most of them are tightly coupled with the accumulators. 
I guess I can further refactor (which I already did quite a bit already).

Please let me know if that's what you had in mind @hequn8128 

--
Rong


---

[GitHub] flink pull request #5679: [FLINK-8916] Checkpointing Mode is always shown to...

[yanghua]

GitHub user yanghua opened a pull request:

https://github.com/apache/flink/pull/5679

[FLINK-8916] Checkpointing Mode is always shown to be "At Least Once" in 
Web UI

## What is the purpose of the change

*This pull request add a customized serializer for checkpoint processing 
mode to support the Web UI's Presentation. *


## Brief change log

  - *Add a customized serializer for checkpoint processing mode*

## Verifying this change

This change is already covered by existing tests*.

## Does this pull request potentially affect one of the following parts:

  - Dependencies (does it add or upgrade a dependency): (yes / **no**)
  - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`: (yes / **no**)
  - The serializers: (yes / **no** / don't know)
  - The runtime per-record code paths (performance sensitive): (yes / 
**no** / don't know)
  - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / **no** / don't know)
  - The S3 file system connector: (yes / **no** / don't know)

## Documentation

  - Does this pull request introduce a new feature? (yes / **no**)
  - If yes, how is the feature documented? (not applicable / docs / 
JavaDocs / **not documented**)


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yanghua/flink FLINK-8916

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/flink/pull/5679.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5679


commit ff1370e7727d4c6e58f0ab249dcf58bff076c480
Author: yanghua 
Date:   2018-03-12T04:12:56Z

[FLINK-8916] Checkpointing Mode is always shown to be "At Least Once" in 
Web UI




---

[jira] [Commented] (FLINK-8916) Checkpointing Mode is always shown to be "At Least Once" in Web UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394800#comment-16394800
 ] 

ASF GitHub Bot commented on FLINK-8916:
---

GitHub user yanghua opened a pull request:

https://github.com/apache/flink/pull/5679

[FLINK-8916] Checkpointing Mode is always shown to be "At Least Once" in 
Web UI

## What is the purpose of the change

*This pull request add a customized serializer for checkpoint processing 
mode to support the Web UI's Presentation. *


## Brief change log

  - *Add a customized serializer for checkpoint processing mode*

## Verifying this change

This change is already covered by existing tests*.

## Does this pull request potentially affect one of the following parts:

  - Dependencies (does it add or upgrade a dependency): (yes / **no**)
  - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`: (yes / **no**)
  - The serializers: (yes / **no** / don't know)
  - The runtime per-record code paths (performance sensitive): (yes / 
**no** / don't know)
  - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / **no** / don't know)
  - The S3 file system connector: (yes / **no** / don't know)

## Documentation

  - Does this pull request introduce a new feature? (yes / **no**)
  - If yes, how is the feature documented? (not applicable / docs / 
JavaDocs / **not documented**)


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yanghua/flink FLINK-8916

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/flink/pull/5679.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5679


commit ff1370e7727d4c6e58f0ab249dcf58bff076c480
Author: yanghua 
Date:   2018-03-12T04:12:56Z

[FLINK-8916] Checkpointing Mode is always shown to be "At Least Once" in 
Web UI




> Checkpointing Mode is always shown to be "At Least Once" in Web UI
> --
>
> Key: FLINK-8916
> URL: https://issues.apache.org/jira/browse/FLINK-8916
> Project: Flink
>  Issue Type: Bug
>  Components: REST
>Affects Versions: 1.5.0, 1.6.0
>Reporter: Gary Yao
>Assignee: vinoyang
>Priority: Blocker
>  Labels: flip6
> Fix For: 1.5.0, 1.6.0
>
>
> This only happens in flip6 mode. The {{CheckpointConfigHandler}} returns the 
> checkpoint mode uppercased. For example:
> {code}
> {"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
> {code}
> However, the Web UI expects the value to be lower cased:
> {code}
>   
> Checkpointing Mode
> Exactly 
> Once
> At Least 
> Once
>   
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8357) enable rolling in default log settings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394784#comment-16394784
 ] 

ASF GitHub Bot commented on FLINK-8357:
---

Github user zhangminglei commented on the issue:

https://github.com/apache/flink/pull/5371
  
Actually , I want do some test under the latest master code. 


> enable rolling in default log settings
> --
>
> Key: FLINK-8357
> URL: https://issues.apache.org/jira/browse/FLINK-8357
> Project: Flink
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Xu Mingmin
>Assignee: mingleizhang
>Priority: Major
> Fix For: 1.5.0
>
>
> The release packages uses {{org.apache.log4j.FileAppender}} for log4j and 
> {{ch.qos.logback.core.FileAppender}} for logback, which could results in very 
> large log files. 
> For most cases, if not all, we need to enable rotation in a production 
> cluster, and I suppose it's a good idea to make rotation as default.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5371: [FLINK-8357] [conf] Enable rolling in default log setting...

[zhangminglei]

Github user zhangminglei commented on the issue:

https://github.com/apache/flink/pull/5371
  
Actually , I want do some test under the latest master code. 


---

[jira] [Commented] (FLINK-8357) enable rolling in default log settings

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394778#comment-16394778
 ] 

ASF GitHub Bot commented on FLINK-8357:
---

Github user zhangminglei commented on the issue:

https://github.com/apache/flink/pull/5371
  
Hi, @StephanEwen .Sorry for later.

1. For the first question, I do not have a machine for this test at this 
moment and wont test it until I have a linux machine. Can not get a linux 
machine at my environment, even a virtual machine. also can not afford a Apple 
computer.

2. I agree with you at this point. Size is a confused number in a way. I 
did not see there is a shell scripts rotates the log file before.




> enable rolling in default log settings
> --
>
> Key: FLINK-8357
> URL: https://issues.apache.org/jira/browse/FLINK-8357
> Project: Flink
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Xu Mingmin
>Assignee: mingleizhang
>Priority: Major
> Fix For: 1.5.0
>
>
> The release packages uses {{org.apache.log4j.FileAppender}} for log4j and 
> {{ch.qos.logback.core.FileAppender}} for logback, which could results in very 
> large log files. 
> For most cases, if not all, we need to enable rotation in a production 
> cluster, and I suppose it's a good idea to make rotation as default.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5371: [FLINK-8357] [conf] Enable rolling in default log setting...

[zhangminglei]

Github user zhangminglei commented on the issue:

https://github.com/apache/flink/pull/5371
  
Hi, @StephanEwen .Sorry for later.

1. For the first question, I do not have a machine for this test at this 
moment and wont test it until I have a linux machine. Can not get a linux 
machine at my environment, even a virtual machine. also can not afford a Apple 
computer.

2. I agree with you at this point. Size is a confused number in a way. I 
did not see there is a shell scripts rotates the log file before.




---

[jira] [Commented] (FLINK-8917) FlinkMiniCluster default createHighAvailabilityServices is not same as ClusterClient

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394776#comment-16394776
 ] 

ASF GitHub Bot commented on FLINK-8917:
---

GitHub user jianran opened a pull request:

https://github.com/apache/flink/pull/5678

[FLINK-8917] [Job-Submission] FlinkMiniCluster haService not same as 
ClusterClient

FlinkMiniCluster default createHighAvailabilityServices is not same as 
ClusterClient，

the FlinkMiniCluster used 

`HighAvailabilityServicesUtils.createAvailableOrEmbeddedServices
`
but the ClusterClient used

`HighAvailabilityServicesUtils.createHighAvailabilityServices`，so if you 
use the flink-1.4 in zeppelin，the job submission will be failed with the follow 
msg: 

Discard message 
LeaderSessionMessage(----,SubmitJob(JobGraph(jobId:
 33d8e7d74aa48f76a1622d4d8f78105e),EXECUTION_RESULT_AND_STATE_CHANGES)) because 
the expected leader session ID 87efb7ca-b761-4977-9696-d521bc178703 did not 
equal the received leader session ID ----.


## Verifying this change


This change is already covered by existing tests, such as 
`LocalFlinkMiniClusterITCase`.

## Does this pull request potentially affect one of the following parts:

  - Dependencies (does it add or upgrade a dependency):no 
  - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`:  no
  - The serializers:  don't know
  - The runtime per-record code paths (performance sensitive):  don't know
  - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Yarn/Mesos, ZooKeeper: no
  - The S3 file system connector:no

## Documentation
  - Does this pull request introduce a new feature? no


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jianran/flink master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/flink/pull/5678.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5678


commit 3ca135017332861762b56f21401c01e07a545b87
Author: jianran.tfh 
Date:   2018-03-12T03:25:39Z

[FLINK-8917]FlinkMiniCluster default createHighAvailabilityServices is not 
same as ClusterClient




> FlinkMiniCluster default createHighAvailabilityServices is not same as 
> ClusterClient
> 
>
> Key: FLINK-8917
> URL: https://issues.apache.org/jira/browse/FLINK-8917
> Project: Flink
>  Issue Type: Bug
>  Components: Job-Submission
>Affects Versions: 1.4.0
>Reporter: jianran.tfh
>Priority: Minor
> Fix For: 1.4.2
>
>
> FlinkMiniCluster default createHighAvailabilityServices is not same as 
> ClusterClient，
> the FlinkMiniCluster used 
> HighAvailabilityServicesUtils.createAvailableOrEmbeddedServices
> but the ClusterClient used
> HighAvailabilityServicesUtils.createHighAvailabilityServices，so if you use 
> the flink-1.4 in zeppelin，the job submission will be failed with the follow 
> msg: 
> Discard message 
> LeaderSessionMessage(----,SubmitJob(JobGraph(jobId:
>  33d8e7d74aa48f76a1622d4d8f78105e),EXECUTION_RESULT_AND_STATE_CHANGES)) 
> because the expected leader session ID 87efb7ca-b761-4977-9696-d521bc178703 
> did not equal the received leader session ID 
> ----.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink pull request #5678: [FLINK-8917] [Job-Submission] FlinkMiniCluster haS...

[jianran]

GitHub user jianran opened a pull request:

https://github.com/apache/flink/pull/5678

[FLINK-8917] [Job-Submission] FlinkMiniCluster haService not same as 
ClusterClient

FlinkMiniCluster default createHighAvailabilityServices is not same as 
ClusterClient，

the FlinkMiniCluster used 

`HighAvailabilityServicesUtils.createAvailableOrEmbeddedServices
`
but the ClusterClient used

`HighAvailabilityServicesUtils.createHighAvailabilityServices`，so if you 
use the flink-1.4 in zeppelin，the job submission will be failed with the 
follow msg: 

Discard message 
LeaderSessionMessage(----,SubmitJob(JobGraph(jobId:
 33d8e7d74aa48f76a1622d4d8f78105e),EXECUTION_RESULT_AND_STATE_CHANGES)) because 
the expected leader session ID 87efb7ca-b761-4977-9696-d521bc178703 did not 
equal the received leader session ID ----.


## Verifying this change


This change is already covered by existing tests, such as 
`LocalFlinkMiniClusterITCase`.

## Does this pull request potentially affect one of the following parts:

  - Dependencies (does it add or upgrade a dependency):no 
  - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`:  no
  - The serializers:  don't know
  - The runtime per-record code paths (performance sensitive):  don't know
  - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Yarn/Mesos, ZooKeeper: no
  - The S3 file system connector:no

## Documentation
  - Does this pull request introduce a new feature? no


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jianran/flink master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/flink/pull/5678.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #5678


commit 3ca135017332861762b56f21401c01e07a545b87
Author: jianran.tfh 
Date:   2018-03-12T03:25:39Z

[FLINK-8917]FlinkMiniCluster default createHighAvailabilityServices is not 
same as ClusterClient




---

[jira] [Assigned] (FLINK-8916) Checkpointing Mode is always shown to be "At Least Once" in Web UI

[vinoyang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

vinoyang reassigned FLINK-8916:
---

Assignee: vinoyang

> Checkpointing Mode is always shown to be "At Least Once" in Web UI
> --
>
> Key: FLINK-8916
> URL: https://issues.apache.org/jira/browse/FLINK-8916
> Project: Flink
>  Issue Type: Bug
>  Components: REST
>Affects Versions: 1.5.0, 1.6.0
>Reporter: Gary Yao
>Assignee: vinoyang
>Priority: Blocker
>  Labels: flip6
> Fix For: 1.5.0, 1.6.0
>
>
> This only happens in flip6 mode. The {{CheckpointConfigHandler}} returns the 
> checkpoint mode uppercased. For example:
> {code}
> {"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
> {code}
> However, the Web UI expects the value to be lower cased:
> {code}
>   
> Checkpointing Mode
> Exactly 
> Once
> At Least 
> Once
>   
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FLINK-8917) FlinkMiniCluster default createHighAvailabilityServices is not same as ClusterClient

[jianran.tfh (JIRA)]

jianran.tfh created FLINK-8917:
--

 Summary: FlinkMiniCluster default createHighAvailabilityServices 
is not same as ClusterClient
 Key: FLINK-8917
 URL: https://issues.apache.org/jira/browse/FLINK-8917
 Project: Flink
  Issue Type: Bug
  Components: Job-Submission
Affects Versions: 1.4.0
Reporter: jianran.tfh
 Fix For: 1.4.2


FlinkMiniCluster default createHighAvailabilityServices is not same as 
ClusterClient，

the FlinkMiniCluster used 

HighAvailabilityServicesUtils.createAvailableOrEmbeddedServices

but the ClusterClient used

HighAvailabilityServicesUtils.createHighAvailabilityServices，so if you use the 
flink-1.4 in zeppelin，the job submission will be failed with the follow msg: 

Discard message 
LeaderSessionMessage(----,SubmitJob(JobGraph(jobId:
 33d8e7d74aa48f76a1622d4d8f78105e),EXECUTION_RESULT_AND_STATE_CHANGES)) because 
the expected leader session ID 87efb7ca-b761-4977-9696-d521bc178703 did not 
equal the received leader session ID ----.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8907) Unable to start the process by start-cluster.sh

[mingleizhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394732#comment-16394732
 ] 

mingleizhang commented on FLINK-8907:
-

I test this on a linux machine. All works well. So, I might be close this issue 
if there is no more discussion.

> Unable to start the process by start-cluster.sh
> ---
>
> Key: FLINK-8907
> URL: https://issues.apache.org/jira/browse/FLINK-8907
> Project: Flink
>  Issue Type: Bug
>  Components: Startup Shell Scripts
>Reporter: mingleizhang
>Priority: Blocker
> Fix For: 1.5.0
>
>
> Build a flink based on the latest code from master branch. And I get the 
> flink binary of flink-1.6-SNAPSHOT. When I run ./start-cluster.sh by the 
> default flink-conf.yaml. I can not start the process and get the error below.
> {code:java}
>  [root@ricezhang-pjhzf bin]# ./start-cluster.sh 
> >> Starting cluster.
> >> Starting standalonesession daemon on host ricezhang-pjhzf.vclound.com.
> >> : Temporary failure in name resolutionost
> {code}
> *By the way, I build this flink from a windows computer. And copy that folder 
> {{flink-1.6-SNAPSHOT}} to centos.*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FLINK-7897) Consider using nio.Files for file deletion in TransientBlobCleanupTask

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-7897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated FLINK-7897:
--
Description: 
nio.Files#delete() provides better clue as to why the deletion may fail:

https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#delete(java.nio.file.Path)

Depending on the potential exception (FileNotFound), the call to 
localFile.exists() may be skipped.

  was:
nio.Files#delete() provides better clue as to why the deletion may fail:

https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#delete(java.nio.file.Path)


Depending on the potential exception (FileNotFound), the call to 
localFile.exists() may be skipped.


> Consider using nio.Files for file deletion in TransientBlobCleanupTask
> --
>
> Key: FLINK-7897
> URL: https://issues.apache.org/jira/browse/FLINK-7897
> Project: Flink
>  Issue Type: Improvement
>  Components: Local Runtime
>Reporter: Ted Yu
>Priority: Minor
>
> nio.Files#delete() provides better clue as to why the deletion may fail:
> https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#delete(java.nio.file.Path)
> Depending on the potential exception (FileNotFound), the call to 
> localFile.exists() may be skipped.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FLINK-8394) Lack of synchronization accessing expectedRecord in ReceiverThread#shutdown

[Ted Yu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated FLINK-8394:
--
Description: 
{code}
  public void shutdown() {
running = false;
interrupt();
expectedRecord.complete(0L);
{code}
Access to expectedRecord should be protected by synchronization, as done on 
other methods.

  was:
{code}
  public void shutdown() {
running = false;
interrupt();
expectedRecord.complete(0L);
{code}

Access to expectedRecord should be protected by synchronization, as done on 
other methods.


> Lack of synchronization accessing expectedRecord in ReceiverThread#shutdown
> ---
>
> Key: FLINK-8394
> URL: https://issues.apache.org/jira/browse/FLINK-8394
> Project: Flink
>  Issue Type: Test
>  Components: Streaming
>Reporter: Ted Yu
>Priority: Minor
>
> {code}
>   public void shutdown() {
> running = false;
> interrupt();
> expectedRecord.complete(0L);
> {code}
> Access to expectedRecord should be protected by synchronization, as done on 
> other methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8832) Create a SQL Client Kafka fat-jar

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394624#comment-16394624
 ] 

ASF GitHub Bot commented on FLINK-8832:
---

Github user twalthr commented on the issue:

https://github.com/apache/flink/pull/5673
  
@zentol there is no big difference. It just an explicit suffix for users. 
It is not intended to be used in Maven projects. We will deploy it on Maven 
central and link to the jar in a special download section on the Flink website.


> Create a SQL Client Kafka fat-jar
> -
>
> Key: FLINK-8832
> URL: https://issues.apache.org/jira/browse/FLINK-8832
> Project: Flink
>  Issue Type: Sub-task
>  Components: Table API  SQL
>Reporter: Timo Walther
>Assignee: Timo Walther
>Priority: Major
>
> Create fat-jars for Apache Kafka.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5673: [FLINK-8832] [sql-client] Create a SQL Client Kafka 0.11 ...

[twalthr]

Github user twalthr commented on the issue:

https://github.com/apache/flink/pull/5673
  
@zentol there is no big difference. It just an explicit suffix for users. 
It is not intended to be used in Maven projects. We will deploy it on Maven 
central and link to the jar in a special download section on the Flink website.


---

[jira] [Commented] (FLINK-8832) Create a SQL Client Kafka fat-jar

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394568#comment-16394568
 ] 

ASF GitHub Bot commented on FLINK-8832:
---

Github user zentol commented on the issue:

https://github.com/apache/flink/pull/5673
  
How is this any different to a regular fat jar? I'm wondering what the 
purpose of the `sql-jar` suffix is.


> Create a SQL Client Kafka fat-jar
> -
>
> Key: FLINK-8832
> URL: https://issues.apache.org/jira/browse/FLINK-8832
> Project: Flink
>  Issue Type: Sub-task
>  Components: Table API  SQL
>Reporter: Timo Walther
>Assignee: Timo Walther
>Priority: Major
>
> Create fat-jars for Apache Kafka.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5673: [FLINK-8832] [sql-client] Create a SQL Client Kafka 0.11 ...

[zentol]

Github user zentol commented on the issue:

https://github.com/apache/flink/pull/5673
  
How is this any different to a regular fat jar? I'm wondering what the 
purpose of the `sql-jar` suffix is.


---

[jira] [Commented] (FLINK-8487) State loss after multiple restart attempts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394544#comment-16394544
 ] 

ASF GitHub Bot commented on FLINK-8487:
---

Github user aljoscha commented on the issue:

https://github.com/apache/flink/pull/5656
  
merged


> State loss after multiple restart attempts
> --
>
> Key: FLINK-8487
> URL: https://issues.apache.org/jira/browse/FLINK-8487
> Project: Flink
>  Issue Type: Bug
>  Components: State Backends, Checkpointing
>Affects Versions: 1.3.2
>Reporter: Fabian Hueske
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.3.3, 1.5.0, 1.4.3
>
>
> A user [reported this 
> issue|https://lists.apache.org/thread.html/9dc9b719cf8449067ad01114fedb75d1beac7b4dff171acdcc24903d@%3Cuser.flink.apache.org%3E]
>  on the user@f.a.o mailing list and analyzed the situation.
> Scenario:
> - A program that reads from Kafka and computes counts in a keyed 15 minute 
> tumbling window.  StateBackend is RocksDB and checkpointing is enabled.
> {code}
> keyBy(0)
> .timeWindow(Time.of(window_size, TimeUnit.MINUTES))
> .allowedLateness(Time.of(late_by, TimeUnit.SECONDS))
> .reduce(new ReduceFunction(), new WindowFunction())
> {code}
> - At some point HDFS went into a safe mode due to NameNode issues
> - The following exception was thrown
> {code}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException):
>  Operation category WRITE is not supported in state standby. Visit 
> https://s.apache.org/sbnn-error
> ..
> at 
> org.apache.flink.runtime.fs.hdfs.HadoopFileSystem.mkdirs(HadoopFileSystem.java:453)
> at 
> org.apache.flink.core.fs.SafetyNetWrapperFileSystem.mkdirs(SafetyNetWrapperFileSystem.java:111)
> at 
> org.apache.flink.runtime.state.filesystem.FsCheckpointStreamFactory.createBasePath(FsCheckpointStreamFactory.java:132)
> {code}
> - The pipeline came back after a few restarts and checkpoint failures, after 
> the HDFS issues were resolved.
> - It was evident that operator state was lost. Either it was the Kafka 
> consumer that kept on advancing it's offset between a start and the next 
> checkpoint failure (a minute's worth) or the the operator that had partial 
> aggregates was lost. 
> The user did some in-depth analysis (see [mail 
> thread|https://lists.apache.org/thread.html/9dc9b719cf8449067ad01114fedb75d1beac7b4dff171acdcc24903d@%3Cuser.flink.apache.org%3E])
>  and might have (according to [~aljoscha]) identified the problem.
> [~stefanrichte...@gmail.com], can you have a look at this issue and check if 
> it is relevant?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8487) State loss after multiple restart attempts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394545#comment-16394545
 ] 

ASF GitHub Bot commented on FLINK-8487:
---

Github user aljoscha closed the pull request at:

https://github.com/apache/flink/pull/5656


> State loss after multiple restart attempts
> --
>
> Key: FLINK-8487
> URL: https://issues.apache.org/jira/browse/FLINK-8487
> Project: Flink
>  Issue Type: Bug
>  Components: State Backends, Checkpointing
>Affects Versions: 1.3.2
>Reporter: Fabian Hueske
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.3.3, 1.5.0, 1.4.3
>
>
> A user [reported this 
> issue|https://lists.apache.org/thread.html/9dc9b719cf8449067ad01114fedb75d1beac7b4dff171acdcc24903d@%3Cuser.flink.apache.org%3E]
>  on the user@f.a.o mailing list and analyzed the situation.
> Scenario:
> - A program that reads from Kafka and computes counts in a keyed 15 minute 
> tumbling window.  StateBackend is RocksDB and checkpointing is enabled.
> {code}
> keyBy(0)
> .timeWindow(Time.of(window_size, TimeUnit.MINUTES))
> .allowedLateness(Time.of(late_by, TimeUnit.SECONDS))
> .reduce(new ReduceFunction(), new WindowFunction())
> {code}
> - At some point HDFS went into a safe mode due to NameNode issues
> - The following exception was thrown
> {code}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException):
>  Operation category WRITE is not supported in state standby. Visit 
> https://s.apache.org/sbnn-error
> ..
> at 
> org.apache.flink.runtime.fs.hdfs.HadoopFileSystem.mkdirs(HadoopFileSystem.java:453)
> at 
> org.apache.flink.core.fs.SafetyNetWrapperFileSystem.mkdirs(SafetyNetWrapperFileSystem.java:111)
> at 
> org.apache.flink.runtime.state.filesystem.FsCheckpointStreamFactory.createBasePath(FsCheckpointStreamFactory.java:132)
> {code}
> - The pipeline came back after a few restarts and checkpoint failures, after 
> the HDFS issues were resolved.
> - It was evident that operator state was lost. Either it was the Kafka 
> consumer that kept on advancing it's offset between a start and the next 
> checkpoint failure (a minute's worth) or the the operator that had partial 
> aggregates was lost. 
> The user did some in-depth analysis (see [mail 
> thread|https://lists.apache.org/thread.html/9dc9b719cf8449067ad01114fedb75d1beac7b4dff171acdcc24903d@%3Cuser.flink.apache.org%3E])
>  and might have (according to [~aljoscha]) identified the problem.
> [~stefanrichte...@gmail.com], can you have a look at this issue and check if 
> it is relevant?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FLINK-8487) State loss after multiple restart attempts

[Aljoscha Krettek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aljoscha Krettek closed FLINK-8487.
---
Resolution: Fixed

Added final tests.

on release-1.5
b4f9e61b5d061f2fa9166bc5ea83ef6cd80eb0e6

on master
4c85b74016a1e6587038053f576b8293aa72126e

> State loss after multiple restart attempts
> --
>
> Key: FLINK-8487
> URL: https://issues.apache.org/jira/browse/FLINK-8487
> Project: Flink
>  Issue Type: Bug
>  Components: State Backends, Checkpointing
>Affects Versions: 1.3.2
>Reporter: Fabian Hueske
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.3.3, 1.5.0, 1.4.3
>
>
> A user [reported this 
> issue|https://lists.apache.org/thread.html/9dc9b719cf8449067ad01114fedb75d1beac7b4dff171acdcc24903d@%3Cuser.flink.apache.org%3E]
>  on the user@f.a.o mailing list and analyzed the situation.
> Scenario:
> - A program that reads from Kafka and computes counts in a keyed 15 minute 
> tumbling window.  StateBackend is RocksDB and checkpointing is enabled.
> {code}
> keyBy(0)
> .timeWindow(Time.of(window_size, TimeUnit.MINUTES))
> .allowedLateness(Time.of(late_by, TimeUnit.SECONDS))
> .reduce(new ReduceFunction(), new WindowFunction())
> {code}
> - At some point HDFS went into a safe mode due to NameNode issues
> - The following exception was thrown
> {code}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException):
>  Operation category WRITE is not supported in state standby. Visit 
> https://s.apache.org/sbnn-error
> ..
> at 
> org.apache.flink.runtime.fs.hdfs.HadoopFileSystem.mkdirs(HadoopFileSystem.java:453)
> at 
> org.apache.flink.core.fs.SafetyNetWrapperFileSystem.mkdirs(SafetyNetWrapperFileSystem.java:111)
> at 
> org.apache.flink.runtime.state.filesystem.FsCheckpointStreamFactory.createBasePath(FsCheckpointStreamFactory.java:132)
> {code}
> - The pipeline came back after a few restarts and checkpoint failures, after 
> the HDFS issues were resolved.
> - It was evident that operator state was lost. Either it was the Kafka 
> consumer that kept on advancing it's offset between a start and the next 
> checkpoint failure (a minute's worth) or the the operator that had partial 
> aggregates was lost. 
> The user did some in-depth analysis (see [mail 
> thread|https://lists.apache.org/thread.html/9dc9b719cf8449067ad01114fedb75d1beac7b4dff171acdcc24903d@%3Cuser.flink.apache.org%3E])
>  and might have (according to [~aljoscha]) identified the problem.
> [~stefanrichte...@gmail.com], can you have a look at this issue and check if 
> it is relevant?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5656: [FLINK-8487] Verify ZooKeeper checkpoint store behaviour ...

[aljoscha]

Github user aljoscha commented on the issue:

https://github.com/apache/flink/pull/5656
  
merged


---

[GitHub] flink pull request #5656: [FLINK-8487] Verify ZooKeeper checkpoint store beh...

[aljoscha]

Github user aljoscha closed the pull request at:

https://github.com/apache/flink/pull/5656


---

[jira] [Commented] (FLINK-8911) Add separate script for nightly end-to-end tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394542#comment-16394542
 ] 

ASF GitHub Bot commented on FLINK-8911:
---

Github user aljoscha closed the pull request at:

https://github.com/apache/flink/pull/5674


> Add separate script for nightly end-to-end tests
> 
>
> Key: FLINK-8911
> URL: https://issues.apache.org/jira/browse/FLINK-8911
> Project: Flink
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Major
> Fix For: 1.5.0
>
>
> Currently, we only have a single set of end-to-end tests. All of which are 
> being run via {{run-pre-commit-tests.sh}} for every Travis run.
> We should add another script, {{run-nightly-tests.sh}}, which runs more 
> heavyweight tests that we only want to run nightly or manually, for example 
> when verifying a release.
> We should:
>  - add the script
>  - document how to work with this in the {{README.md}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5674: [FLINK-8911] Add separate script for nightly end-to-end t...

[aljoscha]

Github user aljoscha commented on the issue:

https://github.com/apache/flink/pull/5674
  
Thanks, @zentol! merged


---

[jira] [Commented] (FLINK-8911) Add separate script for nightly end-to-end tests

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394541#comment-16394541
 ] 

ASF GitHub Bot commented on FLINK-8911:
---

Github user aljoscha commented on the issue:

https://github.com/apache/flink/pull/5674
  
Thanks, @zentol! merged


> Add separate script for nightly end-to-end tests
> 
>
> Key: FLINK-8911
> URL: https://issues.apache.org/jira/browse/FLINK-8911
> Project: Flink
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Major
> Fix For: 1.5.0
>
>
> Currently, we only have a single set of end-to-end tests. All of which are 
> being run via {{run-pre-commit-tests.sh}} for every Travis run.
> We should add another script, {{run-nightly-tests.sh}}, which runs more 
> heavyweight tests that we only want to run nightly or manually, for example 
> when verifying a release.
> We should:
>  - add the script
>  - document how to work with this in the {{README.md}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink pull request #5674: [FLINK-8911] Add separate script for nightly end-t...

[aljoscha]

Github user aljoscha closed the pull request at:

https://github.com/apache/flink/pull/5674


---

[jira] [Closed] (FLINK-8911) Add separate script for nightly end-to-end tests

[Aljoscha Krettek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aljoscha Krettek closed FLINK-8911.
---
Resolution: Fixed

On release-1.5
b4136d24831fe00d95e6d840748a6ee59b5336f8

On master
0f3b3f9404743e2920e50099645bb659a418bd00

> Add separate script for nightly end-to-end tests
> 
>
> Key: FLINK-8911
> URL: https://issues.apache.org/jira/browse/FLINK-8911
> Project: Flink
>  Issue Type: Improvement
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Major
> Fix For: 1.5.0
>
>
> Currently, we only have a single set of end-to-end tests. All of which are 
> being run via {{run-pre-commit-tests.sh}} for every Travis run.
> We should add another script, {{run-nightly-tests.sh}}, which runs more 
> heavyweight tests that we only want to run nightly or manually, for example 
> when verifying a release.
> We should:
>  - add the script
>  - document how to work with this in the {{README.md}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink pull request #5589: [FLINK-8797] Port AbstractOperatorRestoreTestBase ...

[aljoscha]

Github user aljoscha closed the pull request at:

https://github.com/apache/flink/pull/5589


---

[jira] [Closed] (FLINK-8778) Migrate queryable state ITCases to use MiniClusterResource

[Aljoscha Krettek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aljoscha Krettek closed FLINK-8778.
---
Resolution: Fixed

On release-1.5
735c95fbb93316475dc6dd6daa2aa91a7158c843

On master
8365c90b8d8fe637e8a54fb21d56e001258db5f2

> Migrate queryable state ITCases to use MiniClusterResource
> --
>
> Key: FLINK-8778
> URL: https://issues.apache.org/jira/browse/FLINK-8778
> Project: Flink
>  Issue Type: Sub-task
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FLINK-8797) Port AbstractOperatorRestoreTestBase to MiniClusterResource

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394538#comment-16394538
 ] 

ASF GitHub Bot commented on FLINK-8797:
---

Github user aljoscha closed the pull request at:

https://github.com/apache/flink/pull/5589


> Port AbstractOperatorRestoreTestBase to MiniClusterResource
> ---
>
> Key: FLINK-8797
> URL: https://issues.apache.org/jira/browse/FLINK-8797
> Project: Flink
>  Issue Type: Sub-task
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] flink issue #5589: [FLINK-8797] Port AbstractOperatorRestoreTestBase to Mini...

[aljoscha]

Github user aljoscha commented on the issue:

https://github.com/apache/flink/pull/5589
  
merged


---

[jira] [Commented] (FLINK-8797) Port AbstractOperatorRestoreTestBase to MiniClusterResource

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/FLINK-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394539#comment-16394539
 ] 

ASF GitHub Bot commented on FLINK-8797:
---

Github user aljoscha commented on the issue:

https://github.com/apache/flink/pull/5589
  
merged


> Port AbstractOperatorRestoreTestBase to MiniClusterResource
> ---
>
> Key: FLINK-8797
> URL: https://issues.apache.org/jira/browse/FLINK-8797
> Project: Flink
>  Issue Type: Sub-task
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FLINK-8797) Port AbstractOperatorRestoreTestBase to MiniClusterResource

[Aljoscha Krettek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aljoscha Krettek closed FLINK-8797.
---
Resolution: Fixed

On release-1.5
7ab8ac352f5cedff8f95357c66d2631eee2fba52

On master
6732669a684de0b230046b8f4291e367e35d9477

> Port AbstractOperatorRestoreTestBase to MiniClusterResource
> ---
>
> Key: FLINK-8797
> URL: https://issues.apache.org/jira/browse/FLINK-8797
> Project: Flink
>  Issue Type: Sub-task
>  Components: Tests
>Reporter: Aljoscha Krettek
>Assignee: Aljoscha Krettek
>Priority: Blocker
> Fix For: 1.5.0
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FLINK-8916) Checkpointing Mode is always shown to be "At Least Once" in Web UI

[Gary Yao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Yao updated FLINK-8916:

Description: 
This only happens in flip6 mode. The {{CheckpointConfigHandler}} returns the 
checkpoint mode uppercased. For example:
{code}
{"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
{code}
However, the Web UI expects the value to be lower cased:

{code}
  
Checkpointing Mode
Exactly Once
At Least 
Once
  
{code}

  was:
This only happens in flip6 mode. {{CheckpointConfigHandler}} returns the 
checkpoint mode uppercased. For example:
{code}
{"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
{code}
However, the Web UI expects the value to be lower cased:

{code}
  
Checkpointing Mode
Exactly Once
At Least 
Once
  
{code}


> Checkpointing Mode is always shown to be "At Least Once" in Web UI
> --
>
> Key: FLINK-8916
> URL: https://issues.apache.org/jira/browse/FLINK-8916
> Project: Flink
>  Issue Type: Bug
>  Components: REST
>Affects Versions: 1.5.0, 1.6.0
>Reporter: Gary Yao
>Priority: Blocker
>  Labels: flip6
> Fix For: 1.5.0, 1.6.0
>
>
> This only happens in flip6 mode. The {{CheckpointConfigHandler}} returns the 
> checkpoint mode uppercased. For example:
> {code}
> {"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
> {code}
> However, the Web UI expects the value to be lower cased:
> {code}
>   
> Checkpointing Mode
> Exactly 
> Once
> At Least 
> Once
>   
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FLINK-8916) Checkpointing Mode is shown to be always "At Least Once" in Web UI

[Gary Yao (JIRA)]

Gary Yao created FLINK-8916:
---

 Summary: Checkpointing Mode is shown to be always "At Least Once" 
in Web UI
 Key: FLINK-8916
 URL: https://issues.apache.org/jira/browse/FLINK-8916
 Project: Flink
  Issue Type: Bug
  Components: REST
Affects Versions: 1.5.0, 1.6.0
Reporter: Gary Yao
 Fix For: 1.5.0, 1.6.0


This only happens in flip6 mode. {{CheckpointConfigHandler}} returns the 
checkpoint mode uppercased. For example:
{code}
{"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
{code}
However, the Web UI expects the value to be lower cased:

{code}
  
Checkpointing Mode
Exactly Once
At Least 
Once
  
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FLINK-8916) Checkpointing Mode is always shown to be "At Least Once" in Web UI

[Gary Yao (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FLINK-8916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Yao updated FLINK-8916:

Summary: Checkpointing Mode is always shown to be "At Least Once" in Web UI 
 (was: Checkpointing Mode is shown to be always "At Least Once" in Web UI)

> Checkpointing Mode is always shown to be "At Least Once" in Web UI
> --
>
> Key: FLINK-8916
> URL: https://issues.apache.org/jira/browse/FLINK-8916
> Project: Flink
>  Issue Type: Bug
>  Components: REST
>Affects Versions: 1.5.0, 1.6.0
>Reporter: Gary Yao
>Priority: Blocker
>  Labels: flip6
> Fix For: 1.5.0, 1.6.0
>
>
> This only happens in flip6 mode. {{CheckpointConfigHandler}} returns the 
> checkpoint mode uppercased. For example:
> {code}
> {"mode":"EXACTLY_ONCE","interval":5000,"timeout":60,"min_pause":0,"max_concurrent":1,"externalization":{"enabled":false,"delete_on_cancellation":true}}
> {code}
> However, the Web UI expects the value to be lower cased:
> {code}
>   
> Checkpointing Mode
> Exactly 
> Once
> At Least 
> Once
>   
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)