Yes, there is a workaround, as mentioned in the other thread: https://lists.apache.org/thread.html/eb7e256146fbe069a4210e1690fac5d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E <https://lists.apache.org/thread.html/eb7e256146fbe069a4210e1690fac5d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E>. It’s just a bit cumbersome but I agree that it’s not a blocker now.
Best, Aljoscha > On 8. Jun 2017, at 09:47, Till Rohrmann <trohrm...@apache.org> wrote: > > There should be an easy work-around for this problem. Start a standalone > cluster and run the queries against this cluster. But I also see that it > might be annoying for users who used to do it differently. The basic > question here should be whether we want the users to use the > LocalFlinkMiniCluster in a remote setting (running queries against it from > a different process). > > Cheers, > Till > > On Wed, Jun 7, 2017 at 4:59 PM, Aljoscha Krettek <aljos...@apache.org> > wrote: > >> I would also like to raise another potential blocker: it’s currently not >> easily possible for users to start a job in local mode in the IDE and to >> then interact with that cluster, say for experimenting with queryable >> state. At least one user walked into this problem already with the 1.3.0 >> RC: https://lists.apache.org/thread.html/eb7e256146fbe069a4210e1690fac5 >> d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E < >> https://lists.apache.org/thread.html/eb7e256146fbe069a4210e1690fac5 >> d3453208fab61515ab1a2f6bf7@%3Cuser.flink.apache.org%3E> >> >> The reasons I have so far analysed are: >> * the local flink cluster starts with HAServices that don’t allow >> external querying, by default. (Broadly spoken) >> * the queryable state server is not started in the local flink mini >> cluster anymore and it cannot be configured to do so easily >> >> What do you think? >> >> Best, >> Aljoscha >>> On 7. Jun 2017, at 11:54, Robert Metzger <rmetz...@apache.org> wrote: >>> >>> From the list [1], not many of the JIRAs have been fixed. >>> I think it would be nice to put the RC for 1.3.1 out this week, given >> that >>> multiple users have complained about some issues in the 1.3.0 release. >>> >>> >>> >>> [1] >>> https://issues.apache.org/jira/issues/?jql=labels%20%3D% >> 20flink-rel-1.3.1-blockers >>> >>> On Tue, Jun 6, 2017 at 10:58 AM, Tzu-Li (Gordon) Tai < >> tzuli...@apache.org> >>> wrote: >>> >>>> After an offline discussion with Till, we decided to not include >>>> FLINK-6763 and FLINK-6764 as blockers for 1.3.1, and only merge them for >>>> 1.4.0 since they change serialization formats for checkpoints. >>>> >>>> In turn, I’ve included https://issues.apache.org/jira/browse/FLINK-6804 >> as >>>> a 1.3.1 blocker. >>>> >>>> >>>> On 2 June 2017 at 5:27:18 PM, Nico Kruber (n...@data-artisans.com) >> wrote: >>>> >>>> while fixing build issues - what about FLINK-6654? >>>> >>>> On Friday, 2 June 2017 11:05:34 CEST Robert Metzger wrote: >>>>> Hi devs, >>>>> >>>>> I would like to release Apache Flink 1.3.1 with the following fixes: >>>>> >>>>> - FLINK-6812 Elasticsearch 5 release artifacts not published to Maven >>>>> central >>>>> - FLINK-6783 Wrongly extracted TypeInformations for >>>>> WindowedStream::aggregate >>>>> - FLINK-6780 ExternalTableSource should add time attributes in the row >>>> type >>>>> - FLINK-6775 StateDescriptor cannot be shared by multiple subtasks >>>>> - FLINK-6763 Inefficient PojoSerializerConfigSnapshot serialization >>>> format >>>>> - FLINK-6764 Deduplicate stateless TypeSerializers when serializing >>>>> composite TypeSerializers >>>>> >>>>> Is there anything else that we need to wait for before we vote on the >>>> first >>>>> RC? >>>>> >>>>> >>>>> Regards, >>>>> Robert >>>> >>>> >> >>
