Hi Saikat, I think that we should have a discussion and choose a place where a "default query timeout" property will be configured.
Generally, I think that a real (user) problem is possibility for queries to execute indefinitely. And I have no doubts that we can improve there. There could be several implementation strategies. One is adding a property to CacheConfiguration. But it opens various questions. E.g. how should it work if we execute SQL JOIN spanning multiple tables (caches)? Also I am concerned about queries executed not via cache.query() method. We have multiple alternative options, e.g. thin clients (IgniteClient.query) or JDBC. I believe that introducing a default timeout for all them is not a bad idea. What do you think? вт, 23 апр. 2019 г. в 03:01, Saikat Maitra <saikat.mai...@gmail.com>: > > Hi Ivan, > > Thank you for your email. My understanding from the jira issue was it will > be cache level configuration for query default timeout. > > I need more info on the usage for this config property and if it is shared > in this jira issue I can make changes or if there is a separate jira issue > I can assign myself. > > > Regards, > Saikat > > On Mon, Apr 22, 2019 at 5:31 AM Павлухин Иван <vololo...@gmail.com> wrote: > > > Hi Saikat, > > > > I see that a configuration property is added in PR but I do not see > > how the property is used. Was it done intentionally? > > > > Also, we need to decide whether such timeout should be configured per > > cache or for all caches in one place. For example, we have already > > TransactionConfiguration#setDefaultTxTimeout which is a global one. > > > > Share you thoughts. > > > > вс, 21 апр. 2019 г. в 00:38, Saikat Maitra <saikat.mai...@gmail.com>: > > > > > > Hi, > > > > > > I have raised a PR for the below issue. > > > > > > IGNITE-7285 Add default query timeout > > > > > > PR - https://github.com/apache/ignite/pull/6490 > > > > > > Please take a look and share feedback. > > > > > > Regards, > > > Saikat > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin
