Hi Igniters,
I have a question. Why our async operation in not really async? GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async operation completed. This means all async operation in one thread will be executed one by one but not in parallel. Async operation is not async. Example for atomic cache f1=cache.getAsync(key1); f2=cache.getAsync(key2); f1 always will be complete before f2. I want to have the ability run multiple async operations in one thread. What do you think? Maybe we can add new cache adapter with fair async operations? |
+1
This would also be helpful for transactional SQL as it would allow to hide network latency. But there is a problem - deadlocks. We need to inform user that this mode should be used with great care. On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < [hidden email]> wrote: > Hi Igniters, > > I have a question. Why our async operation in not really async? > > GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async > operation completed. > > This means all async operation in one thread will be executed one by one > but not in parallel. Async operation is not async. > > Example for atomic cache > > f1=cache.getAsync(key1); > f2=cache.getAsync(key2); > > f1 always will be complete before f2. > > I want to have the ability run multiple async operations in one thread. > What do you think? > > Maybe we can add new cache adapter with fair async operations? > |
Vladimir,
Should we create the new cache adapter or rework GridCacheAdapter? On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]> wrote: > +1 > > This would also be helpful for transactional SQL as it would allow to hide > network latency. But there is a problem - deadlocks. We need to inform user > that this mode should be used with great care. > > On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < > [hidden email]> wrote: > > > Hi Igniters, > > > > I have a question. Why our async operation in not really async? > > > > GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async > > operation completed. > > > > This means all async operation in one thread will be executed one by one > > but not in parallel. Async operation is not async. > > > > Example for atomic cache > > > > f1=cache.getAsync(key1); > > f2=cache.getAsync(key2); > > > > f1 always will be complete before f2. > > > > I want to have the ability run multiple async operations in one thread. > > What do you think? > > > > Maybe we can add new cache adapter with fair async operations? > > > |
I think, the best option from API side is to add decorating
withExplicitAsync() method. We already have withKeepBinary, withExpiryPolicy and so on. Best Regards, Ivan Rakov On 11.05.2018 18:18, Dmitriy Govorukhin wrote: > Vladimir, > > Should we create the new cache adapter or rework GridCacheAdapter? > > On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]> > wrote: > >> +1 >> >> This would also be helpful for transactional SQL as it would allow to hide >> network latency. But there is a problem - deadlocks. We need to inform user >> that this mode should be used with great care. >> >> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < >> [hidden email]> wrote: >> >>> Hi Igniters, >>> >>> I have a question. Why our async operation in not really async? >>> >>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async >>> operation completed. >>> >>> This means all async operation in one thread will be executed one by one >>> but not in parallel. Async operation is not async. >>> >>> Example for atomic cache >>> >>> f1=cache.getAsync(key1); >>> f2=cache.getAsync(key2); >>> >>> f1 always will be complete before f2. >>> >>> I want to have the ability run multiple async operations in one thread. >>> What do you think? >>> >>> Maybe we can add new cache adapter with fair async operations? >>> |
Ivan,
My suggestion "withFairAsync()". What do you think? On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> wrote: > I think, the best option from API side is to add decorating > withExplicitAsync() method. > We already have withKeepBinary, withExpiryPolicy and so on. > > Best Regards, > Ivan Rakov > > > On 11.05.2018 18:18, Dmitriy Govorukhin wrote: > >> Vladimir, >> >> Should we create the new cache adapter or rework GridCacheAdapter? >> >> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]> >> wrote: >> >> +1 >>> >>> This would also be helpful for transactional SQL as it would allow to >>> hide >>> network latency. But there is a problem - deadlocks. We need to inform >>> user >>> that this mode should be used with great care. >>> >>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < >>> [hidden email]> wrote: >>> >>> Hi Igniters, >>>> >>>> I have a question. Why our async operation in not really async? >>>> >>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async >>>> operation completed. >>>> >>>> This means all async operation in one thread will be executed one by one >>>> but not in parallel. Async operation is not async. >>>> >>>> Example for atomic cache >>>> >>>> f1=cache.getAsync(key1); >>>> f2=cache.getAsync(key2); >>>> >>>> f1 always will be complete before f2. >>>> >>>> I want to have the ability run multiple async operations in one thread. >>>> What do you think? >>>> >>>> Maybe we can add new cache adapter with fair async operations? >>>> >>>> > |
Agree. "fair" is more descriptive.
Best Regards, Ivan Rakov On 11.05.2018 18:30, Dmitriy Govorukhin wrote: > Ivan, > > My suggestion "withFairAsync()". What do you think? > > On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> wrote: > >> I think, the best option from API side is to add decorating >> withExplicitAsync() method. >> We already have withKeepBinary, withExpiryPolicy and so on. >> >> Best Regards, >> Ivan Rakov >> >> >> On 11.05.2018 18:18, Dmitriy Govorukhin wrote: >> >>> Vladimir, >>> >>> Should we create the new cache adapter or rework GridCacheAdapter? >>> >>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]> >>> wrote: >>> >>> +1 >>>> This would also be helpful for transactional SQL as it would allow to >>>> hide >>>> network latency. But there is a problem - deadlocks. We need to inform >>>> user >>>> that this mode should be used with great care. >>>> >>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < >>>> [hidden email]> wrote: >>>> >>>> Hi Igniters, >>>>> I have a question. Why our async operation in not really async? >>>>> >>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async >>>>> operation completed. >>>>> >>>>> This means all async operation in one thread will be executed one by one >>>>> but not in parallel. Async operation is not async. >>>>> >>>>> Example for atomic cache >>>>> >>>>> f1=cache.getAsync(key1); >>>>> f2=cache.getAsync(key2); >>>>> >>>>> f1 always will be complete before f2. >>>>> >>>>> I want to have the ability run multiple async operations in one thread. >>>>> What do you think? >>>>> >>>>> Maybe we can add new cache adapter with fair async operations? >>>>> >>>>> |
Igniters,
I created the issue. IGNITE-8475 <https://issues.apache.org/jira/browse/IGNITE-8475> Any comments are welcome. On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov <[hidden email]> wrote: > Agree. "fair" is more descriptive. > > Best Regards, > Ivan Rakov > > > On 11.05.2018 18:30, Dmitriy Govorukhin wrote: > >> Ivan, >> >> My suggestion "withFairAsync()". What do you think? >> >> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> >> wrote: >> >> I think, the best option from API side is to add decorating >>> withExplicitAsync() method. >>> We already have withKeepBinary, withExpiryPolicy and so on. >>> >>> Best Regards, >>> Ivan Rakov >>> >>> >>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote: >>> >>> Vladimir, >>>> >>>> Should we create the new cache adapter or rework GridCacheAdapter? >>>> >>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov <[hidden email]> >>>> wrote: >>>> >>>> +1 >>>> >>>>> This would also be helpful for transactional SQL as it would allow to >>>>> hide >>>>> network latency. But there is a problem - deadlocks. We need to inform >>>>> user >>>>> that this mode should be used with great care. >>>>> >>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < >>>>> [hidden email]> wrote: >>>>> >>>>> Hi Igniters, >>>>> >>>>>> I have a question. Why our async operation in not really async? >>>>>> >>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last async >>>>>> operation completed. >>>>>> >>>>>> This means all async operation in one thread will be executed one by >>>>>> one >>>>>> but not in parallel. Async operation is not async. >>>>>> >>>>>> Example for atomic cache >>>>>> >>>>>> f1=cache.getAsync(key1); >>>>>> f2=cache.getAsync(key2); >>>>>> >>>>>> f1 always will be complete before f2. >>>>>> >>>>>> I want to have the ability run multiple async operations in one >>>>>> thread. >>>>>> What do you think? >>>>>> >>>>>> Maybe we can add new cache adapter with fair async operations? >>>>>> >>>>>> >>>>>> > |
Guys,
I am not sure I like this approach, especially for this code: f1=cache.getAsync(key1); f2=cache.getAsync(key2); You cannot complete f2 before f1. If you do, the code is unusable and it is impossible to predict anything. If you need to get 2 elements asynchronously, use getAllAsync() instead. Let's not introduce such usability issues into our API and stop trying to fix what's not broken. I propose to close the ticket as "Won't Fix". D. On Fri, May 11, 2018 at 6:14 PM, Dmitriy Govorukhin < [hidden email]> wrote: > Igniters, > > I created the issue. IGNITE-8475 > <https://issues.apache.org/jira/browse/IGNITE-8475> > > Any comments are welcome. > > On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov <[hidden email]> wrote: > > > Agree. "fair" is more descriptive. > > > > Best Regards, > > Ivan Rakov > > > > > > On 11.05.2018 18:30, Dmitriy Govorukhin wrote: > > > >> Ivan, > >> > >> My suggestion "withFairAsync()". What do you think? > >> > >> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> > >> wrote: > >> > >> I think, the best option from API side is to add decorating > >>> withExplicitAsync() method. > >>> We already have withKeepBinary, withExpiryPolicy and so on. > >>> > >>> Best Regards, > >>> Ivan Rakov > >>> > >>> > >>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote: > >>> > >>> Vladimir, > >>>> > >>>> Should we create the new cache adapter or rework GridCacheAdapter? > >>>> > >>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov < > [hidden email]> > >>>> wrote: > >>>> > >>>> +1 > >>>> > >>>>> This would also be helpful for transactional SQL as it would allow to > >>>>> hide > >>>>> network latency. But there is a problem - deadlocks. We need to > inform > >>>>> user > >>>>> that this mode should be used with great care. > >>>>> > >>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < > >>>>> [hidden email]> wrote: > >>>>> > >>>>> Hi Igniters, > >>>>> > >>>>>> I have a question. Why our async operation in not really async? > >>>>>> > >>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last > async > >>>>>> operation completed. > >>>>>> > >>>>>> This means all async operation in one thread will be executed one by > >>>>>> one > >>>>>> but not in parallel. Async operation is not async. > >>>>>> > >>>>>> Example for atomic cache > >>>>>> > >>>>>> f1=cache.getAsync(key1); > >>>>>> f2=cache.getAsync(key2); > >>>>>> > >>>>>> f1 always will be complete before f2. > >>>>>> > >>>>>> I want to have the ability run multiple async operations in one > >>>>>> thread. > >>>>>> What do you think? > >>>>>> > >>>>>> Maybe we can add new cache adapter with fair async operations? > >>>>>> > >>>>>> > >>>>>> > > > |
IMO you can complete async operations one before another if these
operations are related to independent data. It is strange why Ignite users are not confused by current API. So I support Dmitriy's G. suggestion. пт, 11 мая 2018 г. в 20:24, Dmitriy Setrakyan <[hidden email]>: > Guys, > > I am not sure I like this approach, especially for this code: > > f1=cache.getAsync(key1); > f2=cache.getAsync(key2); > > You cannot complete f2 before f1. If you do, the code is unusable and it is > impossible to predict anything. If you need to get 2 elements > asynchronously, use getAllAsync() instead. > > Let's not introduce such usability issues into our API and stop trying to > fix what's not broken. I propose to close the ticket as "Won't Fix". > > D. > > On Fri, May 11, 2018 at 6:14 PM, Dmitriy Govorukhin < > [hidden email]> wrote: > > > Igniters, > > > > I created the issue. IGNITE-8475 > > <https://issues.apache.org/jira/browse/IGNITE-8475> > > > > Any comments are welcome. > > > > On Fri, May 11, 2018 at 6:32 PM, Ivan Rakov <[hidden email]> > wrote: > > > > > Agree. "fair" is more descriptive. > > > > > > Best Regards, > > > Ivan Rakov > > > > > > > > > On 11.05.2018 18:30, Dmitriy Govorukhin wrote: > > > > > >> Ivan, > > >> > > >> My suggestion "withFairAsync()". What do you think? > > >> > > >> On Fri, May 11, 2018 at 6:23 PM, Ivan Rakov <[hidden email]> > > >> wrote: > > >> > > >> I think, the best option from API side is to add decorating > > >>> withExplicitAsync() method. > > >>> We already have withKeepBinary, withExpiryPolicy and so on. > > >>> > > >>> Best Regards, > > >>> Ivan Rakov > > >>> > > >>> > > >>> On 11.05.2018 18:18, Dmitriy Govorukhin wrote: > > >>> > > >>> Vladimir, > > >>>> > > >>>> Should we create the new cache adapter or rework GridCacheAdapter? > > >>>> > > >>>> On Fri, May 11, 2018 at 5:52 PM, Vladimir Ozerov < > > [hidden email]> > > >>>> wrote: > > >>>> > > >>>> +1 > > >>>> > > >>>>> This would also be helpful for transactional SQL as it would allow > to > > >>>>> hide > > >>>>> network latency. But there is a problem - deadlocks. We need to > > inform > > >>>>> user > > >>>>> that this mode should be used with great care. > > >>>>> > > >>>>> On Fri, May 11, 2018 at 5:21 PM, Dmitriy Govorukhin < > > >>>>> [hidden email]> wrote: > > >>>>> > > >>>>> Hi Igniters, > > >>>>> > > >>>>>> I have a question. Why our async operation in not really async? > > >>>>>> > > >>>>>> GridCacheAdapter.syncOp has awaitLastFut(); this call wait last > > async > > >>>>>> operation completed. > > >>>>>> > > >>>>>> This means all async operation in one thread will be executed one > by > > >>>>>> one > > >>>>>> but not in parallel. Async operation is not async. > > >>>>>> > > >>>>>> Example for atomic cache > > >>>>>> > > >>>>>> f1=cache.getAsync(key1); > > >>>>>> f2=cache.getAsync(key2); > > >>>>>> > > >>>>>> f1 always will be complete before f2. > > >>>>>> > > >>>>>> I want to have the ability run multiple async operations in one > > >>>>>> thread. > > >>>>>> What do you think? > > >>>>>> > > >>>>>> Maybe we can add new cache adapter with fair async operations? > > >>>>>> > > >>>>>> > > >>>>>> > > > > > > |
On Fri, May 11, 2018 at 6:29 PM, Dmitry Pavlov <[hidden email]>
wrote: > IMO you can complete async operations one before another if these > operations are related to independent data. > > It is strange why Ignite users are not confused by current API. So I > support Dmitriy's G. suggestion. > Again, this is a solution looking for a problem. Nobody complains about this, so there really isn't any issue. There are so many other tasks we could focus on. Let's not fix what's not broken. D. |
Dmitriy S,
Why method named as "async" but does not work as async? This is misleading. getAllAsync() is a special case. Not always you can use getAllAsync() instead of multiple getAsync(). In this topic, I wanna discuss problem not only for the GET operation but also all async operation behavior in the one thread. In compute grid we can run multiple async compute operation in the one thread, so why we can not do this for cache? On Fri, May 11, 2018 at 8:33 PM, Dmitriy Setrakyan <[hidden email]> wrote: > On Fri, May 11, 2018 at 6:29 PM, Dmitry Pavlov <[hidden email]> > wrote: > > > IMO you can complete async operations one before another if these > > operations are related to independent data. > > > > It is strange why Ignite users are not confused by current API. So I > > support Dmitriy's G. suggestion. > > > > Again, this is a solution looking for a problem. Nobody complains about > this, so there really isn't any issue. There are so many other tasks we > could focus on. Let's not fix what's not broken. > > D. > |
On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin <
[hidden email]> wrote: > Dmitriy S, > > Why method named as "async" but does not work as async? This is misleading. > > getAllAsync() is a special case. Not always you can use getAllAsync() > instead > of multiple getAsync(). > In this topic, I wanna discuss problem not only for the GET operation but > also all async operation behavior in the one thread. > > In compute grid we can run multiple async compute operation in the one > thread, so why we can not do this for cache? Because it will break a lot of existing code and create bugs we cannot even predict at this point. I am not sure why has this become a problem. Is it preventing us from accomplishing some other task? If not, then I propose to drop it. D. |
Dmitriy S,
It is not broke existing code, because for use this ability you must use decorator "withFairSycn()". What about the argument of Vladimir? On Fri, May 11, 2018 at 8:41 PM, Dmitriy Setrakyan <[hidden email]> wrote: > On Fri, May 11, 2018 at 6:38 PM, Dmitriy Govorukhin < > [hidden email]> wrote: > > > Dmitriy S, > > > > Why method named as "async" but does not work as async? This is > misleading. > > > > getAllAsync() is a special case. Not always you can use getAllAsync() > > instead > > of multiple getAsync(). > > In this topic, I wanna discuss problem not only for the GET operation but > > also all async operation behavior in the one thread. > > > > In compute grid we can run multiple async compute operation in the one > > thread, so why we can not do this for cache? > > > Because it will break a lot of existing code and create bugs we cannot even > predict at this point. I am not sure why has this become a problem. Is it > preventing us from accomplishing some other task? If not, then I propose to > drop it. > > D. > |
On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin <
[hidden email]> wrote: > Dmitriy S, > > It is not broke existing code, because for use this ability you must use > decorator "withFairSycn()". > > What about the argument of Vladimir? > Here is Vladimir's quote: *This would also be helpful for transactional SQL as it would allow to hide**network latency. But there is a problem - deadlocks. We need to inform user* *that this mode should be used with great care. * I would rather not change anything instead of increasing the probability of deadlocks. This was the main reason for the current behavior to begin with. In my view, if something is needed for the transactional SQL, please add it internally. Let's not corrupt the public API by adding dangerous methods. D. |
Dmitriy S,
If it will be in the internal package, and only for internal usage, are you agree with changes? пт, 11 мая 2018 г., 21:12 Dmitriy Setrakyan <[hidden email]>: > On Fri, May 11, 2018 at 6:49 PM, Dmitriy Govorukhin < > [hidden email]> wrote: > > > Dmitriy S, > > > > It is not broke existing code, because for use this ability you must use > > decorator "withFairSycn()". > > > > What about the argument of Vladimir? > > > > Here is Vladimir's quote: > > > *This would also be helpful for transactional SQL as it would allow to > hide**network > latency. But there is a problem - deadlocks. We need to inform user* > *that this mode should be used with great care. * > > > I would rather not change anything instead of increasing the probability of > deadlocks. This was the main reason for the current behavior to begin with. > > In my view, if something is needed for the transactional SQL, please add it > internally. Let's not corrupt the public API by adding dangerous methods. > > D. > |
On Fri, May 11, 2018 at 7:23 PM, Dmitriy Govorukhin <
[hidden email]> wrote: > Dmitriy S, > > If it will be in the internal package, and only for internal usage, are you > agree with changes? > Yes, but please be careful not to create deadlocks for ourselves. Can you please close the ticket? D. |
I will edit IGNITE-8475, and remove all part that belong to the public api.
Is it acceptable for you? пт, 11 мая 2018 г., 21:29 Dmitriy Setrakyan <[hidden email]>: > On Fri, May 11, 2018 at 7:23 PM, Dmitriy Govorukhin < > [hidden email]> wrote: > > > Dmitriy S, > > > > If it will be in the internal package, and only for internal usage, are > you > > agree with changes? > > > > Yes, but please be careful not to create deadlocks for ourselves. > > Can you please close the ticket? > > D. > |
On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin <
[hidden email]> wrote: > I will edit IGNITE-8475, and remove all part that belong to the public api. > Is it acceptable for you? > Everything is acceptable, as long as the public API is safe :) |
Guys,
To build a great product we should be open minded and look to the future, not to the past. Dima raised very valid point - why async is not async? Current programming culture and demanding performance requirements pushes users towards reactive-style programming. I do not want my thread to ever be blocked. Instead, I want to send a number of concurrent commands and optionally subscribe to final result. So trully async API makes total sense to me. But personally, my primary interest in this area is SQL. Oracle is preparing new async driver. ADBA - async database access. It was presented on recent JavaOne [1]. It is under active development right now - juse weave through the mailing list [2]. Some prototypes are already there [3]. PostgreSQL community even started adopted it [4]! I am not pushing for immediate actions, but at least we should understand which way the wind is blowing. As a mid-term goals I would propose to finally remove thread ID from our PESSIMISTIC transactions to allow for suspend/resume in different threads. And as a next step I would think on adopting async cache and SQL APIs. Vladimir. [1] http://www.oracle.com/technetwork/database/application-development/jdbc/con1491-3961036.pdf [2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/ [3] https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ [4] https://github.com/pgjdbc/pgjdbc/issues/978 On Fri, May 11, 2018 at 9:48 PM, Dmitriy Setrakyan <[hidden email]> wrote: > On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin < > [hidden email]> wrote: > > > I will edit IGNITE-8475, and remove all part that belong to the public > api. > > Is it acceptable for you? > > > > Everything is acceptable, as long as the public API is safe :) > |
Vladimir,
In general I agree, but I do get greatly *close-minded* (pun intended) whenever users' code that worked for the past several years all of a sudden gets deadlocked after an upgrade. Making this feature optional is even worse and more confusing. In this case the best action is no action at all. BTW, would be interesting to find out how Oracle async driver behaves in this case. D. On Fri, May 11, 2018 at 8:29 PM, Vladimir Ozerov <[hidden email]> wrote: > Guys, > > To build a great product we should be open minded and look to the future, > not to the past. > > Dima raised very valid point - why async is not async? Current programming > culture and demanding performance requirements pushes users towards > reactive-style programming. I do not want my thread to ever be blocked. > Instead, I want to send a number of concurrent commands and optionally > subscribe to final result. So trully async API makes total sense to me. > > But personally, my primary interest in this area is SQL. Oracle is > preparing new async driver. ADBA - async database access. It was presented > on recent JavaOne [1]. It is under active development right now - juse > weave through the mailing list [2]. Some prototypes are already there [3]. > PostgreSQL community even started adopted it [4]! > > I am not pushing for immediate actions, but at least we should understand > which way the wind is blowing. As a mid-term goals I would propose to > finally remove thread ID from our PESSIMISTIC transactions to allow for > suspend/resume in different threads. And as a next step I would think on > adopting async cache and SQL APIs. > > Vladimir. > > [1] > http://www.oracle.com/technetwork/database/application-development/jdbc/ > con1491-3961036.pdf > [2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/ > [3] https://github.com/oracle/oracle-db-examples/tree/master/java/AoJ > [4] https://github.com/pgjdbc/pgjdbc/issues/978 > > On Fri, May 11, 2018 at 9:48 PM, Dmitriy Setrakyan <[hidden email]> > wrote: > > > On Fri, May 11, 2018 at 7:46 PM, Dmitriy Govorukhin < > > [hidden email]> wrote: > > > > > I will edit IGNITE-8475, and remove all part that belong to the public > > api. > > > Is it acceptable for you? > > > > > > > Everything is acceptable, as long as the public API is safe :) > > > |
Free forum by Nabble | Edit this page |