Please a reviewer for the case IGNITE-12518
Dear community, I made modifications to the module rest-http. It works correctly. Is possible if anybody take my case for the review? The modifications are: Support for webpages (test with jsf and primefaces), support for root context. Support to JaxWS with RI version. Support for access to Ignite database with JNDI and basic connection pooling' Se despide Atentamente, *Luis Arce Martínez*Licenciado e Ingeniero en Informática y Gestión 09-57861903 Linkedin: https://cl.linkedin.com/in/luisalejandroarcemartinez
[jira] [Created] (IGNITE-12526) WAL file archiver logging bug
Mykhaylo Stepanov created IGNITE-12526:
--
Summary: WAL file archiver logging bug
Key: IGNITE-12526
URL: https://issues.apache.org/jira/browse/IGNITE-12526
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 2.7.6
Reporter: Mykhaylo Stepanov
WAL file archive logs null if instance name not set. Example output:
{noformat}
2020/01/10 20:42:58.355 [wal-file-archiver%null-#84] INFO Copied file{noformat}
Check for null instance name should be added in FileWriteAheadLogManager.java
{code:java}
private FileArchiver(SegmentAware segmentAware, IgniteLogger log) throws
IgniteCheckedException {
super(cctx.igniteInstanceName(), "wal-file-archiver%" +
cctx.igniteInstanceName(), log,
cctx.kernalContext().workersRegistry());
init(segmentAware);
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: AWS EBS Discovery: Contributor Wanted
Excellent, thanks for finding time for that. Ping us if you have any questions/suggestions and would like to expedite the review process. - Denis On Fri, Jan 10, 2020 at 9:28 AM Emmanouil Gkatziouras wrote: > Hi Denis, > > More than happy to help. > Will get into context and see what I can do for this one. > > Kind regards, > Emmanouil > > *Emmanouil Gkatziouras* > https://egkatzioura.com/ | > https://www.linkedin.com/in/gkatziourasemmanouil/ > https://github.com/gkatzioura > > > On Fri, 10 Jan 2020 at 17:24, Denis Magda wrote: > >> Folks, >> >> We paid a little attention to this contribution and presently can't merge >> it due to some conflicts. Is anybody interested to take over, resolve >> conflicts and complete the contribution? >> >> Emmanouil, considering your expert knowledge of cloud environments, that >> might be interesting for you. >> >> - >> Denis >> >
AWS EBS Discovery: Contributor Wanted
Folks, We paid a little attention to this contribution and presently can't merge it due to some conflicts. Is anybody interested to take over, resolve conflicts and complete the contribution? Emmanouil, considering your expert knowledge of cloud environments, that might be interesting for you. - Denis
Re: Ignite Evolution Direction: short questionary
Ivan, That's right, 78 Ignite practitioners took part in the poll. As for this feedback below, *Apache Ignite was close to a drop-in replacement technology for a* *home grown memory-centric data grid used in a legacy product which* *allowed us to concentrate on building more customer value rather than* *infrastructure.* this happens frequently; Ignite is still primarily used as an in-memory caching and compute layer for existing services, APIs and databases. Companies inject Ignite in their solutions, load a lot of data, scale and access with SQL, compute, etc. A sort of in-memory data management platform or integration hub if to use the terms of technology analysts. - Denis On Fri, Jan 10, 2020 at 12:56 AM Ivan Pavlukhin wrote: > Denis, > > Great! Am I getting it right that there was about 80 respondents? > > чт, 9 янв. 2020 г. в 22:14, Denis Magda : > > > > Ignite dev community, > > > > I've closed the questionary and here is raw anonymous data for > > your reference: > > > https://docs.google.com/document/d/1Rkc82GkNlsVrwXxQgFd8RgFNV_qVwuMhmzaQV2W9ccI/edit?usp=sharing > > > > Overall, Ignite is continued to be used heavely for caching > > scenarios (services, DBs, APIs) with increasing usage of SQL and native > > persistence. Usability and technical issues are mentioned in relation to > > these two components. Plus, a plenty of other useful thoughts and > > suggestions. > > > > - > > Denis > > > > > > On Wed, Dec 4, 2019 at 2:51 PM Denis Magda wrote: > > > > > Folks, > > > > > > There are many ongoing conversations and activities on the list > related to > > > Ignite's evolution (modularization, 3.0, full-text search support, > etc.). > > > > > > I'm suggesting to ask our broader user community to contribute by > sharing > > > short feedback and discuss results in several weeks: > > > > > > > https://docs.google.com/forms/d/e/1FAIpQLSdUveEVXer3lpkyiqfFw4175TvZzGHUOS4snPfnkO0NDku0eQ/viewform > > > > > > Ultimately, the project is being developed for the purpose and it will > be > > > right to hear back from those who put Ignite in prod. Please check the > > > questionary and suggest any changes. It should be short and compact. > We'll > > > send it to the user list and can publish it on the Ignite website. > > > > > > - > > > Denis > > > > > > > -- > Best regards, > Ivan Pavlukhin >
Apache Ignite Training
Good day, We have an enquiry from our customer for training on Apache Ignite at Mumbai - India. I am looking out for support on the same. Please advise. Thank you, Nelson D'souza Span Labs B209-210, Sagar Tech Plaza Opp. Hotel Chakra Sakinaka, Andheri East Mumbai - 400 072 Cell # 91 9820187132 Website: www.spanlabs.in Description: Description: C:\Users\Nelson\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\SNQE9BGM\PicsArt_12-23-01 42 37.jpg
[jira] [Created] (IGNITE-12525) Spring boot starter
Nikolay Izhikov created IGNITE-12525: Summary: Spring boot starter Key: IGNITE-12525 URL: https://issues.apache.org/jira/browse/IGNITE-12525 Project: Ignite Issue Type: Improvement Components: spring Affects Versions: 2.7.6 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.9 To improve user experience with Ignite we should provide an ignite-spring-boot-starter like many of other projects do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Partition reserve/release asymmetry
Everything is fine. Merged to master branch. On Fri, Jan 10, 2020 at 9:48 AM Anton Vinogradov wrote: > >> Does the issue reproduce in > >> subsequent runs? > Unfortunately no. > We performed 30+ runs without "success". > > >> I think we can add an assertion to > >> GridDhtLocalPartition#destroy() method to check that reservations is 0 > Ok, I will check and merge in case of success. > Created the Issue to handle this [1]. > > [1] https://issues.apache.org/jira/browse/IGNITE-12524 > > On Thu, Jan 9, 2020 at 1:46 PM Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > >> Hello Anton, >> >> Thanks for digging into this. The logic with checking the >> reservations count seems fishy to me as well, so I have no objections with >> the suggested change. This "if" statement does not answer why the >> partition >> was being destroyed during the commit, though. Does the issue reproduce in >> subsequent runs? >> >> The logic around reserve/release seems ok to me, however, the >> eviction/renting code looks overly complicated, perhaps, there is a bug >> somewhere there? I think we can add an assertion to >> GridDhtLocalPartition#destroy() method to check that reservations is 0 >> when >> this method is called (there is a check for EVICTED state already there) >> >> --AG >> >> чт, 9 янв. 2020 г. в 09:45, Anton Vinogradov : >> >> > Folks, >> > Yardstick run (opt-serial-put-get-1-backup) failed with interesting >> > exception: >> > Critical system error detected. Will be handled accordingly to >> configured >> > handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, >> > super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet >> > [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], >> > failureCtx=FailureContext [type=CRITICAL_ERROR, err=class >> > o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a >> > transaction has produced runtime exception]] >> > class >> > >> org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException: >> > Committing a transaction has produced runtime exception >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1452) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxFinishRequest(IgniteTxHandler.java:1375) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$600(IgniteTxHandler.java:123) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:241) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$7.apply(IgniteTxHandler.java:239) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109) >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) >> > at >> > >> > >> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1843) >> > at >> > >> > >> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1468) >> > at >> > >> > >> org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229) >> > at >> > >> > >> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365) >> > at >> > >> > >> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:555) >> > at >> > >> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) >> > at java.lang.Thread.run(Thread.java:748) >> > Caused by: java.lang.IllegalStateException: Tree is being concurrently >> > destroyed: tx-p-470##CacheData >> > at >> > >> > >> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.checkDestroyed(BPlusTree.java:1011) >> > at >> > >> > >>
Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Ivan, if i correctly understand, you suggest additional «expiremental» stuff only for hiding already leaked RO interface ? poor approach as for me. >Folks, > >Some thoughts: >* Releasing an API with known fallacies sounds really bad thing to me. >It can have a negative consequences for a whole project for years. My >opinion here that we should resolve the problem with this API somehow >before release. >* We can mark cluster read-only API (without enum) as experimental and >change the API in e.g. 2.8.1. >* We can try to exclude read-only API from 2.8 at all. > >What do you think? > >пт, 10 янв. 2020 г. в 11:20, Alex Plehanov < plehanov.a...@gmail.com >: >> >> Guys, >> >> There is also an issue with cluster activation by thin clients. This >> feature (.NET thin client API change and protocol change) was added by [1] >> without any discussion on dev-list. Sergey's patch [2] deprecate methods >> "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but didn't do >> this for thin clients. If we want to include IGNITE-12225 to 2.8 we also >> should not forget about thin client changes, since it will be strange if we >> introduce some methods to thin client API and protocol and in the same >> Ignite version deprecate these methods for servers and thick clients. >> >> [1]: https://issues.apache.org/jira/browse/IGNITE-11709 >> [2]: https://issues.apache.org/jira/browse/IGNITE-12225 >> >> >> пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky < arzamas...@mail.ru.invalid >> >: >> >> > >> > >> > Agree with Nikolay, -1 from me, too. >> > >> > >Hello, Igniters. >> > > >> > >I’m -1 to include the read-only patch to 2.8. >> > >I think we shouldn’t accept any patches to 2.8 except bug fixes for >> > blockers and major issues. >> > > >> > >Guys, we don’t release Apache Ignite for 13 months! >> > >We should focus on the release and make it ASAP. >> > > >> > >We can’t extend the scope anymore. >> > > >> > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < antonovserge...@gmail.com > >> > написал(а): >> > >> >> > >> Hello, Maxim! >> > >> >> > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files >> > >> changed. >> > >> Yes, PR is huge, but I wrote a lot of new tests and reworked already >> > >> presented. Changes in product code are minimal - only 30 changed files >> > in >> > >> /src/main/ part. And most of them are new control.sh commands and >> > >> configuration. >> > >> >> > >>> Do we have customer requests for this feature or maybe users who are >> > >> waiting for exactly that ENUM values exactly in 2.8 release (not the >> > 2.8.1 >> > >> for instance)? >> > >> Can we introduce in new features in maintanance release (2.8.1)? Cluster >> > >> read-only mode will be new feature, if we remove IgniteCluster#readOnly >> > in >> > >> 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and >> > >> move ticket [1] to 2.8.1 release. >> > >> >> > >>> Do we have extended test results report (on just only TC.Bot green >> > visa) >> > >> on this feature to be sure that we will not add any blocker issues to >> > the >> > >> release? >> > >> I'm preparing patch for 2.8 release and I will get new TC Bot visa vs >> > >> release branch. >> > >> >> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >> >> > >> >> > >> >> > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org >: >> > >> >> > >>> Folks, >> > >>> >> > >>> >> > >>> Let me remind you that we are working on the 2.8 release branch >> > >>> stabilization currently (please, keep it in mind). >> > >>> >> > >>> >> > >>> Do we have a really STRONG reason for adding such a change [1] to the >> > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 >> > >>> −2,038, 111 files changed. >> > >>> Do we have customer requests for this feature or maybe users who are >> > >>> waiting for exactly that ENUM values exactly in 2.8 release (not the >> > >>> 2.8.1 for instance)? >> > >>> Can we just simply remove IgniteCluster#readOnly to eliminate any >> > >>> backward compatibility issues between 2.8 and 2.9 releases? >> > >>> Do we have extended test results report (on just only TC.Bot green >> > >>> visa) on this feature to be sure that we will not add any blocker >> > >>> issues to the release? For instance, on pre-production environment. >> > >>> >> > >>> I'd like to notice that we also have more than enough the release >> > >>> blocker issues [3] which are still `in progress` and such a release >> > >>> run becomes endless. Such changes without strong reasons looks too >> > >>> scary for me a special after scope and code freeze dates. >> > >>> >> > >>> Please, dispel my doubts. >> > >>> >> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >>> [2] https://github.com/apache/ignite/pull/7194 >> > >>> [3] >> > >>> >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation >> > ) >> > >>> >> > >>> On Thu, 9 Jan 2020
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, what we do with control.sh commands? We can't set experimental annotation on those commands. пт, 10 янв. 2020 г., 17:47 Alexey Zinoviev : > Support the idea with the annotation > > пт, 10 янв. 2020 г., 13:11 Вячеслав Коптилин : > > > Hello, > > > > * We can mark cluster read-only API (without enum) as experimental and > > > change the API in e.g. 2.8.1. > > > * We can try to exclude read-only API from 2.8 at all. > > > > both approaches look good to me. > > > > By the way, I think it would be a good idea to introduce a new > annotation - > > @IgniteExperimental for instance, > > The package, class or method that is marked by @IgniteExperimental should > > clearly state that this API, class or method can be changed or removed > in a > > future release. > > > > Thanks, > > S. > > > > пт, 10 янв. 2020 г. в 13:02, Ilya Kasnacheev >: > > > > > Hello! > > > > > > I think the third option (exclude publicly-accessible API) is > preferable. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 10 янв. 2020 г. в 12:26, Ivan Pavlukhin : > > > > > > > Folks, > > > > > > > > Some thoughts: > > > > * Releasing an API with known fallacies sounds really bad thing to > me. > > > > It can have a negative consequences for a whole project for years. My > > > > opinion here that we should resolve the problem with this API somehow > > > > before release. > > > > * We can mark cluster read-only API (without enum) as experimental > and > > > > change the API in e.g. 2.8.1. > > > > * We can try to exclude read-only API from 2.8 at all. > > > > > > > > What do you think? > > > > > > > > пт, 10 янв. 2020 г. в 11:20, Alex Plehanov >: > > > > > > > > > > Guys, > > > > > > > > > > There is also an issue with cluster activation by thin clients. > This > > > > > feature (.NET thin client API change and protocol change) was added > > by > > > > [1] > > > > > without any discussion on dev-list. Sergey's patch [2] deprecate > > > methods > > > > > "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but > > > didn't > > > > do > > > > > this for thin clients. If we want to include IGNITE-12225 to 2.8 we > > > also > > > > > should not forget about thin client changes, since it will be > strange > > > if > > > > we > > > > > introduce some methods to thin client API and protocol and in the > > same > > > > > Ignite version deprecate these methods for servers and thick > clients. > > > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > > > > > [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > > > > > > > > > > пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Agree with Nikolay, -1 from me, too. > > > > > > > > > > > > >Hello, Igniters. > > > > > > > > > > > > > >I’m -1 to include the read-only patch to 2.8. > > > > > > >I think we shouldn’t accept any patches to 2.8 except bug fixes > > for > > > > > > blockers and major issues. > > > > > > > > > > > > > >Guys, we don’t release Apache Ignite for 13 months! > > > > > > >We should focus on the release and make it ASAP. > > > > > > > > > > > > > >We can’t extend the scope anymore. > > > > > > > > > > > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < > > > > antonovserge...@gmail.com > > > > > > > написал(а): > > > > > > >> > > > > > > >> Hello, Maxim! > > > > > > >> > > > > > > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 > files > > > > > > >> changed. > > > > > > >> Yes, PR is huge, but I wrote a lot of new tests and reworked > > > already > > > > > > >> presented. Changes in product code are minimal - only 30 > changed > > > > files > > > > > > in > > > > > > >> /src/main/ part. And most of them are new control.sh commands > > and > > > > > > >> configuration. > > > > > > >> > > > > > > >>> Do we have customer requests for this feature or maybe users > > who > > > > are > > > > > > >> waiting for exactly that ENUM values exactly in 2.8 release > (not > > > the > > > > > > 2.8.1 > > > > > > >> for instance)? > > > > > > >> Can we introduce in new features in maintanance release > (2.8.1)? > > > > Cluster > > > > > > >> read-only mode will be new feature, if we remove > > > > IgniteCluster#readOnly > > > > > > in > > > > > > >> 2.8 release. If all ok with that, lets remove > > > > IgniteCluster#readOnly and > > > > > > >> move ticket [1] to 2.8.1 release. > > > > > > >> > > > > > > >>> Do we have extended test results report (on just only TC.Bot > > > green > > > > > > visa) > > > > > > >> on this feature to be sure that we will not add any blocker > > issues > > > > to > > > > > > the > > > > > > >> release? > > > > > > >> I'm preparing patch for 2.8 release and I will get new TC Bot > > visa > > > > vs > > > > > > >> release branch. > > > > > > >> > > > > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Support the idea with the annotation пт, 10 янв. 2020 г., 13:11 Вячеслав Коптилин : > Hello, > > * We can mark cluster read-only API (without enum) as experimental and > > change the API in e.g. 2.8.1. > > * We can try to exclude read-only API from 2.8 at all. > > both approaches look good to me. > > By the way, I think it would be a good idea to introduce a new annotation - > @IgniteExperimental for instance, > The package, class or method that is marked by @IgniteExperimental should > clearly state that this API, class or method can be changed or removed in a > future release. > > Thanks, > S. > > пт, 10 янв. 2020 г. в 13:02, Ilya Kasnacheev : > > > Hello! > > > > I think the third option (exclude publicly-accessible API) is preferable. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 10 янв. 2020 г. в 12:26, Ivan Pavlukhin : > > > > > Folks, > > > > > > Some thoughts: > > > * Releasing an API with known fallacies sounds really bad thing to me. > > > It can have a negative consequences for a whole project for years. My > > > opinion here that we should resolve the problem with this API somehow > > > before release. > > > * We can mark cluster read-only API (without enum) as experimental and > > > change the API in e.g. 2.8.1. > > > * We can try to exclude read-only API from 2.8 at all. > > > > > > What do you think? > > > > > > пт, 10 янв. 2020 г. в 11:20, Alex Plehanov : > > > > > > > > Guys, > > > > > > > > There is also an issue with cluster activation by thin clients. This > > > > feature (.NET thin client API change and protocol change) was added > by > > > [1] > > > > without any discussion on dev-list. Sergey's patch [2] deprecate > > methods > > > > "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but > > didn't > > > do > > > > this for thin clients. If we want to include IGNITE-12225 to 2.8 we > > also > > > > should not forget about thin client changes, since it will be strange > > if > > > we > > > > introduce some methods to thin client API and protocol and in the > same > > > > Ignite version deprecate these methods for servers and thick clients. > > > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > > > > [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > > > > > > > пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky > > > > > > >: > > > > > > > > > > > > > > > > > > > Agree with Nikolay, -1 from me, too. > > > > > > > > > > >Hello, Igniters. > > > > > > > > > > > >I’m -1 to include the read-only patch to 2.8. > > > > > >I think we shouldn’t accept any patches to 2.8 except bug fixes > for > > > > > blockers and major issues. > > > > > > > > > > > >Guys, we don’t release Apache Ignite for 13 months! > > > > > >We should focus on the release and make it ASAP. > > > > > > > > > > > >We can’t extend the scope anymore. > > > > > > > > > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < > > > antonovserge...@gmail.com > > > > > > написал(а): > > > > > >> > > > > > >> Hello, Maxim! > > > > > >> > > > > > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > > > > > >> changed. > > > > > >> Yes, PR is huge, but I wrote a lot of new tests and reworked > > already > > > > > >> presented. Changes in product code are minimal - only 30 changed > > > files > > > > > in > > > > > >> /src/main/ part. And most of them are new control.sh commands > and > > > > > >> configuration. > > > > > >> > > > > > >>> Do we have customer requests for this feature or maybe users > who > > > are > > > > > >> waiting for exactly that ENUM values exactly in 2.8 release (not > > the > > > > > 2.8.1 > > > > > >> for instance)? > > > > > >> Can we introduce in new features in maintanance release (2.8.1)? > > > Cluster > > > > > >> read-only mode will be new feature, if we remove > > > IgniteCluster#readOnly > > > > > in > > > > > >> 2.8 release. If all ok with that, lets remove > > > IgniteCluster#readOnly and > > > > > >> move ticket [1] to 2.8.1 release. > > > > > >> > > > > > >>> Do we have extended test results report (on just only TC.Bot > > green > > > > > visa) > > > > > >> on this feature to be sure that we will not add any blocker > issues > > > to > > > > > the > > > > > >> release? > > > > > >> I'm preparing patch for 2.8 release and I will get new TC Bot > visa > > > vs > > > > > >> release branch. > > > > > >> > > > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > >> > > > > > >> > > > > > >> > > > > > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org > > >: > > > > > >> > > > > > >>> Folks, > > > > > >>> > > > > > >>> > > > > > >>> Let me remind you that we are working on the 2.8 release branch > > > > > >>> stabilization currently (please, keep it in mind). > > > > > >>> > > > > > >>> > > > > > >>> Do we have a really STRONG reason for adding such a change [1] > to > > > the > > > > > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple > +5,517 > > > > > >>> −2,038, 111 files changed.
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello, * We can mark cluster read-only API (without enum) as experimental and > change the API in e.g. 2.8.1. > * We can try to exclude read-only API from 2.8 at all. both approaches look good to me. By the way, I think it would be a good idea to introduce a new annotation - @IgniteExperimental for instance, The package, class or method that is marked by @IgniteExperimental should clearly state that this API, class or method can be changed or removed in a future release. Thanks, S. пт, 10 янв. 2020 г. в 13:02, Ilya Kasnacheev : > Hello! > > I think the third option (exclude publicly-accessible API) is preferable. > > Regards, > -- > Ilya Kasnacheev > > > пт, 10 янв. 2020 г. в 12:26, Ivan Pavlukhin : > > > Folks, > > > > Some thoughts: > > * Releasing an API with known fallacies sounds really bad thing to me. > > It can have a negative consequences for a whole project for years. My > > opinion here that we should resolve the problem with this API somehow > > before release. > > * We can mark cluster read-only API (without enum) as experimental and > > change the API in e.g. 2.8.1. > > * We can try to exclude read-only API from 2.8 at all. > > > > What do you think? > > > > пт, 10 янв. 2020 г. в 11:20, Alex Plehanov : > > > > > > Guys, > > > > > > There is also an issue with cluster activation by thin clients. This > > > feature (.NET thin client API change and protocol change) was added by > > [1] > > > without any discussion on dev-list. Sergey's patch [2] deprecate > methods > > > "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but > didn't > > do > > > this for thin clients. If we want to include IGNITE-12225 to 2.8 we > also > > > should not forget about thin client changes, since it will be strange > if > > we > > > introduce some methods to thin client API and protocol and in the same > > > Ignite version deprecate these methods for servers and thick clients. > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > > > [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > > > > пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky > > > > >: > > > > > > > > > > > > > > > Agree with Nikolay, -1 from me, too. > > > > > > > > >Hello, Igniters. > > > > > > > > > >I’m -1 to include the read-only patch to 2.8. > > > > >I think we shouldn’t accept any patches to 2.8 except bug fixes for > > > > blockers and major issues. > > > > > > > > > >Guys, we don’t release Apache Ignite for 13 months! > > > > >We should focus on the release and make it ASAP. > > > > > > > > > >We can’t extend the scope anymore. > > > > > > > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < > > antonovserge...@gmail.com > > > > > написал(а): > > > > >> > > > > >> Hello, Maxim! > > > > >> > > > > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > > > > >> changed. > > > > >> Yes, PR is huge, but I wrote a lot of new tests and reworked > already > > > > >> presented. Changes in product code are minimal - only 30 changed > > files > > > > in > > > > >> /src/main/ part. And most of them are new control.sh commands and > > > > >> configuration. > > > > >> > > > > >>> Do we have customer requests for this feature or maybe users who > > are > > > > >> waiting for exactly that ENUM values exactly in 2.8 release (not > the > > > > 2.8.1 > > > > >> for instance)? > > > > >> Can we introduce in new features in maintanance release (2.8.1)? > > Cluster > > > > >> read-only mode will be new feature, if we remove > > IgniteCluster#readOnly > > > > in > > > > >> 2.8 release. If all ok with that, lets remove > > IgniteCluster#readOnly and > > > > >> move ticket [1] to 2.8.1 release. > > > > >> > > > > >>> Do we have extended test results report (on just only TC.Bot > green > > > > visa) > > > > >> on this feature to be sure that we will not add any blocker issues > > to > > > > the > > > > >> release? > > > > >> I'm preparing patch for 2.8 release and I will get new TC Bot visa > > vs > > > > >> release branch. > > > > >> > > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > > >> > > > > >> > > > > >> > > > > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org > >: > > > > >> > > > > >>> Folks, > > > > >>> > > > > >>> > > > > >>> Let me remind you that we are working on the 2.8 release branch > > > > >>> stabilization currently (please, keep it in mind). > > > > >>> > > > > >>> > > > > >>> Do we have a really STRONG reason for adding such a change [1] to > > the > > > > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > > > > >>> −2,038, 111 files changed. > > > > >>> Do we have customer requests for this feature or maybe users who > > are > > > > >>> waiting for exactly that ENUM values exactly in 2.8 release (not > > the > > > > >>> 2.8.1 for instance)? > > > > >>> Can we just simply remove IgniteCluster#readOnly to eliminate any > > > > >>> backward compatibility issues between 2.8 and 2.9 releases? > > > > >>> Do we have extended test
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello! I think the third option (exclude publicly-accessible API) is preferable. Regards, -- Ilya Kasnacheev пт, 10 янв. 2020 г. в 12:26, Ivan Pavlukhin : > Folks, > > Some thoughts: > * Releasing an API with known fallacies sounds really bad thing to me. > It can have a negative consequences for a whole project for years. My > opinion here that we should resolve the problem with this API somehow > before release. > * We can mark cluster read-only API (without enum) as experimental and > change the API in e.g. 2.8.1. > * We can try to exclude read-only API from 2.8 at all. > > What do you think? > > пт, 10 янв. 2020 г. в 11:20, Alex Plehanov : > > > > Guys, > > > > There is also an issue with cluster activation by thin clients. This > > feature (.NET thin client API change and protocol change) was added by > [1] > > without any discussion on dev-list. Sergey's patch [2] deprecate methods > > "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but didn't > do > > this for thin clients. If we want to include IGNITE-12225 to 2.8 we also > > should not forget about thin client changes, since it will be strange if > we > > introduce some methods to thin client API and protocol and in the same > > Ignite version deprecate these methods for servers and thick clients. > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > > [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > > > > пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky > > >: > > > > > > > > > > > Agree with Nikolay, -1 from me, too. > > > > > > >Hello, Igniters. > > > > > > > >I’m -1 to include the read-only patch to 2.8. > > > >I think we shouldn’t accept any patches to 2.8 except bug fixes for > > > blockers and major issues. > > > > > > > >Guys, we don’t release Apache Ignite for 13 months! > > > >We should focus on the release and make it ASAP. > > > > > > > >We can’t extend the scope anymore. > > > > > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < > antonovserge...@gmail.com > > > > написал(а): > > > >> > > > >> Hello, Maxim! > > > >> > > > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > > > >> changed. > > > >> Yes, PR is huge, but I wrote a lot of new tests and reworked already > > > >> presented. Changes in product code are minimal - only 30 changed > files > > > in > > > >> /src/main/ part. And most of them are new control.sh commands and > > > >> configuration. > > > >> > > > >>> Do we have customer requests for this feature or maybe users who > are > > > >> waiting for exactly that ENUM values exactly in 2.8 release (not the > > > 2.8.1 > > > >> for instance)? > > > >> Can we introduce in new features in maintanance release (2.8.1)? > Cluster > > > >> read-only mode will be new feature, if we remove > IgniteCluster#readOnly > > > in > > > >> 2.8 release. If all ok with that, lets remove > IgniteCluster#readOnly and > > > >> move ticket [1] to 2.8.1 release. > > > >> > > > >>> Do we have extended test results report (on just only TC.Bot green > > > visa) > > > >> on this feature to be sure that we will not add any blocker issues > to > > > the > > > >> release? > > > >> I'm preparing patch for 2.8 release and I will get new TC Bot visa > vs > > > >> release branch. > > > >> > > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > >> > > > >> > > > >> > > > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org >: > > > >> > > > >>> Folks, > > > >>> > > > >>> > > > >>> Let me remind you that we are working on the 2.8 release branch > > > >>> stabilization currently (please, keep it in mind). > > > >>> > > > >>> > > > >>> Do we have a really STRONG reason for adding such a change [1] to > the > > > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > > > >>> −2,038, 111 files changed. > > > >>> Do we have customer requests for this feature or maybe users who > are > > > >>> waiting for exactly that ENUM values exactly in 2.8 release (not > the > > > >>> 2.8.1 for instance)? > > > >>> Can we just simply remove IgniteCluster#readOnly to eliminate any > > > >>> backward compatibility issues between 2.8 and 2.9 releases? > > > >>> Do we have extended test results report (on just only TC.Bot green > > > >>> visa) on this feature to be sure that we will not add any blocker > > > >>> issues to the release? For instance, on pre-production environment. > > > >>> > > > >>> I'd like to notice that we also have more than enough the release > > > >>> blocker issues [3] which are still `in progress` and such a release > > > >>> run becomes endless. Such changes without strong reasons looks too > > > >>> scary for me a special after scope and code freeze dates. > > > >>> > > > >>> Please, dispel my doubts. > > > >>> > > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > > >>> [2] https://github.com/apache/ignite/pull/7194 > > > >>> [3] > > > >>> > > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Folks, Some thoughts: * Releasing an API with known fallacies sounds really bad thing to me. It can have a negative consequences for a whole project for years. My opinion here that we should resolve the problem with this API somehow before release. * We can mark cluster read-only API (without enum) as experimental and change the API in e.g. 2.8.1. * We can try to exclude read-only API from 2.8 at all. What do you think? пт, 10 янв. 2020 г. в 11:20, Alex Plehanov : > > Guys, > > There is also an issue with cluster activation by thin clients. This > feature (.NET thin client API change and protocol change) was added by [1] > without any discussion on dev-list. Sergey's patch [2] deprecate methods > "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but didn't do > this for thin clients. If we want to include IGNITE-12225 to 2.8 we also > should not forget about thin client changes, since it will be strange if we > introduce some methods to thin client API and protocol and in the same > Ignite version deprecate these methods for servers and thick clients. > > [1]: https://issues.apache.org/jira/browse/IGNITE-11709 > [2]: https://issues.apache.org/jira/browse/IGNITE-12225 > > > пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky >: > > > > > > > Agree with Nikolay, -1 from me, too. > > > > >Hello, Igniters. > > > > > >I’m -1 to include the read-only patch to 2.8. > > >I think we shouldn’t accept any patches to 2.8 except bug fixes for > > blockers and major issues. > > > > > >Guys, we don’t release Apache Ignite for 13 months! > > >We should focus on the release and make it ASAP. > > > > > >We can’t extend the scope anymore. > > > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < antonovserge...@gmail.com > > > написал(а): > > >> > > >> Hello, Maxim! > > >> > > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > > >> changed. > > >> Yes, PR is huge, but I wrote a lot of new tests and reworked already > > >> presented. Changes in product code are minimal - only 30 changed files > > in > > >> /src/main/ part. And most of them are new control.sh commands and > > >> configuration. > > >> > > >>> Do we have customer requests for this feature or maybe users who are > > >> waiting for exactly that ENUM values exactly in 2.8 release (not the > > 2.8.1 > > >> for instance)? > > >> Can we introduce in new features in maintanance release (2.8.1)? Cluster > > >> read-only mode will be new feature, if we remove IgniteCluster#readOnly > > in > > >> 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and > > >> move ticket [1] to 2.8.1 release. > > >> > > >>> Do we have extended test results report (on just only TC.Bot green > > visa) > > >> on this feature to be sure that we will not add any blocker issues to > > the > > >> release? > > >> I'm preparing patch for 2.8 release and I will get new TC Bot visa vs > > >> release branch. > > >> > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > >> > > >> > > >> > > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org >: > > >> > > >>> Folks, > > >>> > > >>> > > >>> Let me remind you that we are working on the 2.8 release branch > > >>> stabilization currently (please, keep it in mind). > > >>> > > >>> > > >>> Do we have a really STRONG reason for adding such a change [1] to the > > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > > >>> −2,038, 111 files changed. > > >>> Do we have customer requests for this feature or maybe users who are > > >>> waiting for exactly that ENUM values exactly in 2.8 release (not the > > >>> 2.8.1 for instance)? > > >>> Can we just simply remove IgniteCluster#readOnly to eliminate any > > >>> backward compatibility issues between 2.8 and 2.9 releases? > > >>> Do we have extended test results report (on just only TC.Bot green > > >>> visa) on this feature to be sure that we will not add any blocker > > >>> issues to the release? For instance, on pre-production environment. > > >>> > > >>> I'd like to notice that we also have more than enough the release > > >>> blocker issues [3] which are still `in progress` and such a release > > >>> run becomes endless. Such changes without strong reasons looks too > > >>> scary for me a special after scope and code freeze dates. > > >>> > > >>> Please, dispel my doubts. > > >>> > > >>> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > > >>> [2] https://github.com/apache/ignite/pull/7194 > > >>> [3] > > >>> > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation > > ) > > >>> > > >>> On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev < zaleslaw@gmail.com > > > > > >>> wrote: > > > > +1 > > > > чт, 9 янв. 2020 г. в 18:52, Sergey Antonov < > > antonovserge...@gmail.com >: > > > > > +1 > > > > > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch > > >>> will be > > > at 13 Jan > >
Re: Ignite Evolution Direction: short questionary
Quite interesting (IMHO): * Apache Ignite was close to a drop in replacement technology for a home grown memory centric data grid used in a legacy product which allowed us to concentrate on building more customer value rather than infrastructure. * Don't let the core grow to big, concentrate on the core features and make them the best there is * Would be great to have (1) a Python-Notebook type environment with Java for the Ignite ML functions, perhaps on the Web Console? Also (2) easier cluster-management with (semi)-automatic / self-healing recovery from segmented node conditions? пт, 10 янв. 2020 г. в 11:56, Ivan Pavlukhin : > > Denis, > > Great! Am I getting it right that there was about 80 respondents? > > чт, 9 янв. 2020 г. в 22:14, Denis Magda : > > > > Ignite dev community, > > > > I've closed the questionary and here is raw anonymous data for > > your reference: > > https://docs.google.com/document/d/1Rkc82GkNlsVrwXxQgFd8RgFNV_qVwuMhmzaQV2W9ccI/edit?usp=sharing > > > > Overall, Ignite is continued to be used heavely for caching > > scenarios (services, DBs, APIs) with increasing usage of SQL and native > > persistence. Usability and technical issues are mentioned in relation to > > these two components. Plus, a plenty of other useful thoughts and > > suggestions. > > > > - > > Denis > > > > > > On Wed, Dec 4, 2019 at 2:51 PM Denis Magda wrote: > > > > > Folks, > > > > > > There are many ongoing conversations and activities on the list related to > > > Ignite's evolution (modularization, 3.0, full-text search support, etc.). > > > > > > I'm suggesting to ask our broader user community to contribute by sharing > > > short feedback and discuss results in several weeks: > > > > > > https://docs.google.com/forms/d/e/1FAIpQLSdUveEVXer3lpkyiqfFw4175TvZzGHUOS4snPfnkO0NDku0eQ/viewform > > > > > > Ultimately, the project is being developed for the purpose and it will be > > > right to hear back from those who put Ignite in prod. Please check the > > > questionary and suggest any changes. It should be short and compact. We'll > > > send it to the user list and can publish it on the Ignite website. > > > > > > - > > > Denis > > > > > > > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
Re: Ignite Evolution Direction: short questionary
Denis, Great! Am I getting it right that there was about 80 respondents? чт, 9 янв. 2020 г. в 22:14, Denis Magda : > > Ignite dev community, > > I've closed the questionary and here is raw anonymous data for > your reference: > https://docs.google.com/document/d/1Rkc82GkNlsVrwXxQgFd8RgFNV_qVwuMhmzaQV2W9ccI/edit?usp=sharing > > Overall, Ignite is continued to be used heavely for caching > scenarios (services, DBs, APIs) with increasing usage of SQL and native > persistence. Usability and technical issues are mentioned in relation to > these two components. Plus, a plenty of other useful thoughts and > suggestions. > > - > Denis > > > On Wed, Dec 4, 2019 at 2:51 PM Denis Magda wrote: > > > Folks, > > > > There are many ongoing conversations and activities on the list related to > > Ignite's evolution (modularization, 3.0, full-text search support, etc.). > > > > I'm suggesting to ask our broader user community to contribute by sharing > > short feedback and discuss results in several weeks: > > > > https://docs.google.com/forms/d/e/1FAIpQLSdUveEVXer3lpkyiqfFw4175TvZzGHUOS4snPfnkO0NDku0eQ/viewform > > > > Ultimately, the project is being developed for the purpose and it will be > > right to hear back from those who put Ignite in prod. Please check the > > questionary and suggest any changes. It should be short and compact. We'll > > send it to the user list and can publish it on the Ignite website. > > > > - > > Denis > > -- Best regards, Ivan Pavlukhin
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, There is also an issue with cluster activation by thin clients. This feature (.NET thin client API change and protocol change) was added by [1] without any discussion on dev-list. Sergey's patch [2] deprecate methods "IgniteCluster.active(boolean)" and "IgniteCluster.active()", but didn't do this for thin clients. If we want to include IGNITE-12225 to 2.8 we also should not forget about thin client changes, since it will be strange if we introduce some methods to thin client API and protocol and in the same Ignite version deprecate these methods for servers and thick clients. [1]: https://issues.apache.org/jira/browse/IGNITE-11709 [2]: https://issues.apache.org/jira/browse/IGNITE-12225 пт, 10 янв. 2020 г. в 10:24, Zhenya Stanilovsky : > > > Agree with Nikolay, -1 from me, too. > > >Hello, Igniters. > > > >I’m -1 to include the read-only patch to 2.8. > >I think we shouldn’t accept any patches to 2.8 except bug fixes for > blockers and major issues. > > > >Guys, we don’t release Apache Ignite for 13 months! > >We should focus on the release and make it ASAP. > > > >We can’t extend the scope anymore. > > > >> 10 янв. 2020 г., в 04:29, Sergey Antonov < antonovserge...@gmail.com > > написал(а): > >> > >> Hello, Maxim! > >> > >>> This PR [2] doesn't look a very simple +5,517 −2,038, 111 files > >> changed. > >> Yes, PR is huge, but I wrote a lot of new tests and reworked already > >> presented. Changes in product code are minimal - only 30 changed files > in > >> /src/main/ part. And most of them are new control.sh commands and > >> configuration. > >> > >>> Do we have customer requests for this feature or maybe users who are > >> waiting for exactly that ENUM values exactly in 2.8 release (not the > 2.8.1 > >> for instance)? > >> Can we introduce in new features in maintanance release (2.8.1)? Cluster > >> read-only mode will be new feature, if we remove IgniteCluster#readOnly > in > >> 2.8 release. If all ok with that, lets remove IgniteCluster#readOnly and > >> move ticket [1] to 2.8.1 release. > >> > >>> Do we have extended test results report (on just only TC.Bot green > visa) > >> on this feature to be sure that we will not add any blocker issues to > the > >> release? > >> I'm preparing patch for 2.8 release and I will get new TC Bot visa vs > >> release branch. > >> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > >> > >> > >> > >> чт, 9 янв. 2020 г. в 19:38, Maxim Muzafarov < mmu...@apache.org >: > >> > >>> Folks, > >>> > >>> > >>> Let me remind you that we are working on the 2.8 release branch > >>> stabilization currently (please, keep it in mind). > >>> > >>> > >>> Do we have a really STRONG reason for adding such a change [1] to the > >>> ignite-2.8 branch? This PR [2] doesn't look a very simple +5,517 > >>> −2,038, 111 files changed. > >>> Do we have customer requests for this feature or maybe users who are > >>> waiting for exactly that ENUM values exactly in 2.8 release (not the > >>> 2.8.1 for instance)? > >>> Can we just simply remove IgniteCluster#readOnly to eliminate any > >>> backward compatibility issues between 2.8 and 2.9 releases? > >>> Do we have extended test results report (on just only TC.Bot green > >>> visa) on this feature to be sure that we will not add any blocker > >>> issues to the release? For instance, on pre-production environment. > >>> > >>> I'd like to notice that we also have more than enough the release > >>> blocker issues [3] which are still `in progress` and such a release > >>> run becomes endless. Such changes without strong reasons looks too > >>> scary for me a special after scope and code freeze dates. > >>> > >>> Please, dispel my doubts. > >>> > >>> [1] https://issues.apache.org/jira/browse/IGNITE-12225 > >>> [2] https://github.com/apache/ignite/pull/7194 > >>> [3] > >>> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.8#ApacheIgnite2.8-Unresolvedissues(notrelatedtodocumentation > ) > >>> > >>> On Thu, 9 Jan 2020 at 19:01, Alexey Zinoviev < zaleslaw@gmail.com > > > >>> wrote: > > +1 > > чт, 9 янв. 2020 г. в 18:52, Sergey Antonov < > antonovserge...@gmail.com >: > > > +1 > > > > I'm preparing patch for 2.8 branch now. TC Bot visa for 2.8 branch > >>> will be > > at 13 Jan > > > > чт, 9 янв. 2020 г., 21:06 Ivan Pavlukhin < vololo...@gmail.com >: > > > >> +1 > >> > >> чт, 9 янв. 2020 г. в 16:38, Ivan Rakov < ivan.glu...@gmail.com >: > >>> > >>> Maxim M. and anyone who is interested, > >>> > >>> I suggest to include this fix to 2.8 release: > >>> https://issues.apache.org/jira/browse/IGNITE-12225 > >>> Basically, it's a result of the following discussion: > >>> > >> > > > >>> > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Single-point-in-API-for-changing-cluster-state-td43665.html > >>> > >>> The fix affects public API: IgniteCluster#readOnly methods that > >>> work > > with >
