You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@flink.apache.org by Theo Diefenthal <th...@scoop-software.de> on 2020/12/10 10:47:53 UTC

Re: Logs of JobExecutionListener

I would vote for ClusterClient not being internal. I use it a lot in my end-to-end tests to e.g. trigger savepoints and shut down the streaming jobs which I think is not possible via ExecutionEnvironments. 

So in my opinion, having a more powerful ClusterClient adds a lot of powerful features for quite some usecases.. 

Best regards 
Theo 


Von: "Flavio Pompermaier" <po...@okkam.it> 
An: "Aljoscha Krettek" <al...@apache.org> 
CC: "user" <us...@flink.apache.org>, "Till Rohrmann" <tr...@apache.org> 
Gesendet: Mittwoch, 25. November 2020 10:44:57 
Betreff: Re: Logs of JobExecutionListener 

Thank you all for the clarification..now things are much more clear. I hope this discussion could be of clarification for other people having the same doubts. 

Best, 
Flavio 

On Wed, Nov 25, 2020 at 10:27 AM Aljoscha Krettek < [ mailto:aljoscha@apache.org | aljoscha@apache.org ] > wrote: 


One bigger problem here is that the code base is very inconsistent when 
it comes to the @Public//@Internal annotations. Initially, only the 
packages that were meant to be "public" had them. For example flink-core 
has thorough annotations. Packages that were not meant to have any 
user-facing code didn't initially have annotations, so flink-runtime has 
barely no annotations. 

The reason why some classes in non-public-facing packages have 
annotations is just that at some point someone decided to make something 
consciously @Public or @Internal. 

On 24.11.20 12:25, Flavio Pompermaier wrote: 
> ok that's fine to me, just add an @internal annotation on the 
> RestClusterClient if it is intended only for internal use.. but wouldn't be 
> easier to provide some sort of client generation facility (e.g. swagger or 
> similar)? 
> 
> Il mar 24 nov 2020, 11:38 Till Rohrmann < [ mailto:trohrmann@apache.org | trohrmann@apache.org ] > ha scritto: 
> 
>> I see the point in having a richer RestClusterClient. However, I think we 
>> first have to make a decision whether the RestClusterClient is something 
>> internal or not. If it is something internal, then only extending the 
>> RestClusterClient and not adding these convenience methods to ClusterClient 
>> could be quite easy. However if it is internal, then we don't need these 
>> methods because the RestClusterClient is not used in such a way that it is 
>> needed. I believe Flavio that you could build your own RestClusterClient 
>> offering these methods. 
>> 
>> If we say that these methods should be usable by users, then they should 
>> also be added to the ClusterClient. Here I see the problem that some of 
>> these methods won't work with a per-job or application deployment. For 
>> example, public JarUploadResponseBody uploadJar(Path uploadedFile) would 
>> not work. 
>> 
>> Long story short, I think the easiest solution would be to build yourself 
>> an utility class which offers the required methods. The second best option 
>> in my opinion would be to add these methods to the RestClusterClient w/o 
>> giving guarantees for their stability. 
>> 
>> Cheers, 
>> Till 
>> 
>> On Mon, Nov 23, 2020 at 8:29 PM Flavio Pompermaier < [ mailto:pompermaier@okkam.it | pompermaier@okkam.it ] > 
>> wrote: 
>> 
>>> For the sake of simplification (so everybody looking for missing methods 
>>> in RestClusterClient) I just shared the new methods at [1]. 
>>> In this way you can add them to the RestClusterClient when you want (if 
>>> you want to). 
>>> I also had to change the visibility of some variables and methods in 
>>> order to make it work. 
>>> Probably it would be useful to put DTOs of flink-webmonitor in a 
>>> standalone project in order to be "importable" in the client project.. 
>>> 
>>> Best, 
>>> Flavio 
>>> 
>>> [1] 
>>> [ https://github.com/fpompermaier/flink-job-server/blob/main/flink-rest-client/src/main/java/org/apache/flink/client/program/rest/RestClusterClientExtended.java | https://github.com/fpompermaier/flink-job-server/blob/main/flink-rest-client/src/main/java/org/apache/flink/client/program/rest/RestClusterClientExtended.java ] 
>>> 
>>> On Mon, Nov 23, 2020 at 4:38 PM Flavio Pompermaier < [ mailto:pompermaier@okkam.it | pompermaier@okkam.it ] > 
>>> wrote: 
>>> 
>>>> I don't know if they need to be added also to the ClusterClient but for 
>>>> sure they are missing in the RestClusterClient 
>>>> 
>>>> On Mon, Nov 23, 2020 at 4:31 PM Aljoscha Krettek < [ mailto:aljoscha@apache.org | aljoscha@apache.org ] > 
>>>> wrote: 
>>>> 
>>>>> On 23.11.20 16:26, Flavio Pompermaier wrote: 
>>>>>> Thank you Aljosha,.now that's more clear! 
>>>>>> I didn't know that jobGraph.getJobID() was the solution for my use 
>>>>> case..I 
>>>>>> was convinced that the job ID was assigned by the cluster! 
>>>>>> And to me it's really weird that the job listener was not called by 
>>>>> the 
>>>>>> submitJob...Probably this should be documented at least. 
>>>>>> In the meanwhile I extended a little bit the RestClusterClient..do you 
>>>>>> think it could be worth issuing a PR to add some unimplemented 
>>>>> methods? 
>>>>>> 
>>>>>> For example I added: 
>>>>>> - public JobExceptionsInfo getFlinkJobExceptionsInfo(JobID 
>>>>> flinkJobId); 
>>>>>> - public EmptyResponseBody deleteJar(String jarFileName); 
>>>>>> - public boolean isJobRunning(JobID fjid) 
>>>>>> - public JarUploadResponseBody uploadJar(Path uploadedFile); 
>>>>>> 
>>>>>> and I was also going to add jarRun.. 
>>>>> 
>>>>> I would be OK with adding these. But you would also need to add them to 
>>>>> the base ClusterClient, right? 
>>>>> 
>>>>> @Till or @Chesnay, any concerns with this? 
>>>> 
>>>> 
>