Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Nikolay, Alexey, First, the idea of the slim binary release and docker image was discussed openly on the dev-list [1]. Second, nobody talks about removing these modules from the product. The idea was to create an additional distribution which is much lighter than the current full package to reduce the size of the downloadable artifact and reduce the number of potential vulnerabilities in third-party libraries. The list of modules was chosen subjectively by the number of questions on the user-list, number third-party libraries (size) and vulnerabilities the module brings. Given that there are still questions, we are definitely not ready to release it in 2.8.0. Let's move discussion to the original thread? [1] http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Hello, Ilya. ignite-jta ignite-zookeeper Why you suggest to remove these modules? As far as I know, they are used in the real production environment. You can take this vide(in Russian) as an example - https://www.youtube.com/watch?v=GSi_C9_gQMc > 29 февр. 2020 г., в 08:22, Alexey Zinoviev > написал(а): > > I have no idea what is the slim package and why the Ml should be remove > from that. We doesnt discuss it before and it looks like very strange list > is not based on previos discussions > > Also, I see, that Ilya has outdated list of modules: we see here removed > tensorflow and missed New Spark 2.4 module. > > Ilya, please update the current list of modules from the Master and later I > share the thread/wiki with the previos discussion about removing package > and ignite extension process. > > > > > сб, 29 февр. 2020 г., 1:17 Maxim Muzafarov : > >> Ilya, >> >> >> Actually I don't remember that we've come to an agreement with the >> list of modules for "slim" distribution. AFAIR, those discussion still >> not finished. >> >> Also, why should we remove `ignite-ml` from current distribution? >> Alexey, should we? >> >> On Sat, 29 Feb 2020 at 00:38, Denis Magda wrote: >>> >>> Sounds reasonable to produce the slim package. Though, if it's time >>> consuming then we should target it to 2.8.1. >>> >>> - >>> Denis >>> >>> >>> On Fri, Feb 28, 2020 at 1:36 PM Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >>> wrote: >>> Hello! Are we doing a "slim" package for 2.8, though? There was a suggestion to remove the following modules from slim binary distribution: ignite-aop ignite-aws ignite-camel ignite-cassandra-serializers ignite-cassandra-store ignite-cloud ignite-direct-io ignite-flink ignite-flume ignite-gce ignite-jcl ignite-jms11 ignite-jta ignite-kafka ignite-mesos ignite-ml ignite-mqtt ignite-osgi ignite-osgi-karaf ignite-osgi-paxlogging ignite-rocketmq ignite-scalar ignite-scalar_2.10 ignite-spark ignite-ssh ignite-storm ignite-tensorflow ignite-twitter ignite-web ignite-yarn ignite-zeromq ignite-zookeeper Plus, remove benchmarks/ from slim package either. WDYT? Regards, -- Ilya Kasnacheev пт, 28 февр. 2020 г. в 19:57, Denis Magda : > Maxim, > > Finally, thanks a lot for starting the voting process! > > I've already cast my vote and want to bring up some issues that are >> not > blockers though: > > 1. Ignite technical documentation is not finished yet - @Artem Budnikov >is coordinating this process as well as > contributes to many open tickets. Even if the vote passes, the >> release > cannot be *announced* until the docs are finished. I would >> encourage > everyone involved in 2.8 docs creation to pull together, >> collaborate and > complete all the pending tickets throughout the next week. > 2. Missing API references for Node.JS, Python and PHP clients [1] >> - need > to be addressed at least for 2.8.1 since the problem is not new to 2.8. > > > [1] > > >> http://apache-ignite-developers.2346864.n4.nabble.com/Node-JS-PHP-Python-API-references-for-Ignite-2-8-release-td46097.html > - > Denis > > > On Fri, Feb 28, 2020 at 7:10 AM Maxim Muzafarov wrote: > >> Dear Community, >> >> >> Please use this thread for all non-voting, discussion, questions >> related to this 2.8.0-rc1 release. >> >> >> Cast your vote here: >> >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html >> > >>
Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
I have no idea what is the slim package and why the Ml should be remove from that. We doesnt discuss it before and it looks like very strange list is not based on previos discussions Also, I see, that Ilya has outdated list of modules: we see here removed tensorflow and missed New Spark 2.4 module. Ilya, please update the current list of modules from the Master and later I share the thread/wiki with the previos discussion about removing package and ignite extension process. сб, 29 февр. 2020 г., 1:17 Maxim Muzafarov : > Ilya, > > > Actually I don't remember that we've come to an agreement with the > list of modules for "slim" distribution. AFAIR, those discussion still > not finished. > > Also, why should we remove `ignite-ml` from current distribution? > Alexey, should we? > > On Sat, 29 Feb 2020 at 00:38, Denis Magda wrote: > > > > Sounds reasonable to produce the slim package. Though, if it's time > > consuming then we should target it to 2.8.1. > > > > - > > Denis > > > > > > On Fri, Feb 28, 2020 at 1:36 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > wrote: > > > > > Hello! > > > > > > Are we doing a "slim" package for 2.8, though? > > > > > > There was a suggestion to remove the following modules from slim binary > > > distribution: > > > > > > ignite-aop > > > ignite-aws > > > ignite-camel > > > ignite-cassandra-serializers > > > ignite-cassandra-store > > > ignite-cloud > > > ignite-direct-io > > > ignite-flink > > > ignite-flume > > > ignite-gce > > > ignite-jcl > > > ignite-jms11 > > > ignite-jta > > > ignite-kafka > > > ignite-mesos > > > ignite-ml > > > ignite-mqtt > > > ignite-osgi > > > ignite-osgi-karaf > > > ignite-osgi-paxlogging > > > ignite-rocketmq > > > ignite-scalar > > > ignite-scalar_2.10 > > > ignite-spark > > > ignite-ssh > > > ignite-storm > > > ignite-tensorflow > > > ignite-twitter > > > ignite-web > > > ignite-yarn > > > ignite-zeromq > > > ignite-zookeeper > > > > > > Plus, remove benchmarks/ from slim package either. > > > > > > WDYT? > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 28 февр. 2020 г. в 19:57, Denis Magda : > > > > > > > Maxim, > > > > > > > > Finally, thanks a lot for starting the voting process! > > > > > > > > I've already cast my vote and want to bring up some issues that are > not > > > > blockers though: > > > > > > > >1. Ignite technical documentation is not finished yet - @Artem > > > Budnikov > > > > is coordinating this process as well as > > > >contributes to many open tickets. Even if the vote passes, the > release > > > >cannot be *announced* until the docs are finished. I would > encourage > > > >everyone involved in 2.8 docs creation to pull together, > collaborate > > > and > > > >complete all the pending tickets throughout the next week. > > > >2. Missing API references for Node.JS, Python and PHP clients [1] > - > > > need > > > >to be addressed at least for 2.8.1 since the problem is not new to > > > 2.8. > > > > > > > > > > > > [1] > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Node-JS-PHP-Python-API-references-for-Ignite-2-8-release-td46097.html > > > > - > > > > Denis > > > > > > > > > > > > On Fri, Feb 28, 2020 at 7:10 AM Maxim Muzafarov > > > wrote: > > > > > > > > > Dear Community, > > > > > > > > > > > > > > > Please use this thread for all non-voting, discussion, questions > > > > > related to this 2.8.0-rc1 release. > > > > > > > > > > > > > > > Cast your vote here: > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html > > > > > > > > > > > > >
Re: Read through not working as expected in case of Replicated cache
Ivan, thanks for stepping in.
Prasad, is Ivan's assumption correct that you query the data with SQL under
the observed circumstances? My guess is that you were referring to the
key-value APIs as long as the issue is gone when the write-through is
enabled.
-
Denis
On Fri, Feb 28, 2020 at 2:30 PM Ivan Pavlukhin wrote:
> As I understand the thing here is in combination of read-through and
> SQL. SQL queries do not read from underlying storage when read-through
> is configured. And an observed result happens because query from a
> client node over REPLICATED cache picks random server node (kind of
> load-balancing) to retrieve data. Following happens in the described
> case:
> 1. Value is loaded to a cache from an underlying storage on a primary
> node when cache.get is called.
> 2. Query is executed multiple times and when the chose node is the
> primary node then the value is observed. On other nodes the value is
> absent.
>
> Actually, behavior for PARTITIONED cache is similar, but an
> inconsistency is not observed because SQL queries read data from the
> primary node there. If the primary node leaves a cluster then an SQL
> query will not see the value anymore. So, the same inconsistency will
> appear.
>
> Best regards,
> Ivan Pavlukhin
>
> пт, 28 февр. 2020 г. в 13:23, Prasad Bhalerao <
> prasadbhalerao1...@gmail.com>:
> >
> > Can someone please comment on this?
> >
> > On Wed, Feb 26, 2020 at 6:04 AM Denis Magda wrote:
> >
> > > Ignite Dev team,
> > >
> > > This sounds like an issue in our replicated cache implementation rather
> > > than an expected behavior. Especially, if partitioned caches don't have
> > > such a specificity.
> > >
> > > Who can explain why write-through needs to be enabled for replicated
> caches
> > > to reload an entry from an underlying database properly/consistently?
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Tue, Feb 25, 2020 at 5:11 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > I think this is by design. You may suggest edits on readme.io.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 24 февр. 2020 г. в 17:28, Prasad Bhalerao <
> > > > prasadbhalerao1...@gmail.com>:
> > > >
> > > >> Hi,
> > > >>
> > > >> Is this a bug or the cache is designed to work this way?
> > > >>
> > > >> If it is as-designed, can this behavior be updated in ignite
> > > >> documentation?
> > > >>
> > > >> Thanks,
> > > >> Prasad
> > > >>
> > > >> On Wed, Oct 30, 2019 at 7:19 PM Ilya Kasnacheev <
> > > >> ilya.kasnach...@gmail.com> wrote:
> > > >>
> > > >>> Hello!
> > > >>>
> > > >>> I have discussed this with fellow Ignite developers, and they say
> read
> > > >>> through for replicated cache would work where there is either:
> > > >>>
> > > >>> - writeThrough enabled and all changes do through it.
> > > >>> - database contents do not change for already read keys.
> > > >>>
> > > >>> I can see that neither is met in your case, so you can expect the
> > > >>> behavior that you are seeing.
> > > >>>
> > > >>> Regards,
> > > >>> --
> > > >>> Ilya Kasnacheev
> > > >>>
> > > >>>
> > > >>> вт, 29 окт. 2019 г. в 18:18, Akash Shinde :
> > > >>>
> > > I am using Ignite 2.6 version.
> > >
> > > I am starting 3 server nodes with a replicated cache and 1 client
> > > node.
> > > Cache configuration is as follows.
> > > Read-through true on but write-through is false. Load data by key
> is
> > > implemented as given below in cache-loader.
> > >
> > > Steps to reproduce issue:
> > > 1) Delete an entry from cache using IgniteCache.remove() method.
> > > (Entry
> > > is just removed from cache but present in DB as write-through is
> > > false)
> > > 2) Invoke IgniteCache.get() method for the same key in step 1.
> > > 3) Now query the cache from client node. Every invocation returns
> > > different results.
> > > Sometimes it returns reloaded entry, sometime returns the results
> > > without reloaded entry.
> > >
> > > Looks like read-through is not replicating the reloaded entry on
> all
> > > nodes in case of REPLICATED cache.
> > >
> > > So to investigate further I changed the cache mode to PARTITIONED
> and
> > > set the backup count to 3 i.e. total number of nodes present in
> > > cluster (to
> > > mimic REPLICATED behavior).
> > > This time it worked as expected.
> > > Every invocation returned the same result with reloaded entry.
> > >
> > > * private CacheConfiguration networkCacheCfg() {*
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *CacheConfiguration networkCacheCfg = new
> > > CacheConfiguration<>(CacheName.NETWORK_CACHE.name
> > > ());
> > > >>
Re: Read through not working as expected in case of Replicated cache
As I understand the thing here is in combination of read-through and
SQL. SQL queries do not read from underlying storage when read-through
is configured. And an observed result happens because query from a
client node over REPLICATED cache picks random server node (kind of
load-balancing) to retrieve data. Following happens in the described
case:
1. Value is loaded to a cache from an underlying storage on a primary
node when cache.get is called.
2. Query is executed multiple times and when the chose node is the
primary node then the value is observed. On other nodes the value is
absent.
Actually, behavior for PARTITIONED cache is similar, but an
inconsistency is not observed because SQL queries read data from the
primary node there. If the primary node leaves a cluster then an SQL
query will not see the value anymore. So, the same inconsistency will
appear.
Best regards,
Ivan Pavlukhin
пт, 28 февр. 2020 г. в 13:23, Prasad Bhalerao :
>
> Can someone please comment on this?
>
> On Wed, Feb 26, 2020 at 6:04 AM Denis Magda wrote:
>
> > Ignite Dev team,
> >
> > This sounds like an issue in our replicated cache implementation rather
> > than an expected behavior. Especially, if partitioned caches don't have
> > such a specificity.
> >
> > Who can explain why write-through needs to be enabled for replicated caches
> > to reload an entry from an underlying database properly/consistently?
> >
> > -
> > Denis
> >
> >
> > On Tue, Feb 25, 2020 at 5:11 AM Ilya Kasnacheev > >
> > wrote:
> >
> > > Hello!
> > >
> > > I think this is by design. You may suggest edits on readme.io.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 24 февр. 2020 г. в 17:28, Prasad Bhalerao <
> > > prasadbhalerao1...@gmail.com>:
> > >
> > >> Hi,
> > >>
> > >> Is this a bug or the cache is designed to work this way?
> > >>
> > >> If it is as-designed, can this behavior be updated in ignite
> > >> documentation?
> > >>
> > >> Thanks,
> > >> Prasad
> > >>
> > >> On Wed, Oct 30, 2019 at 7:19 PM Ilya Kasnacheev <
> > >> ilya.kasnach...@gmail.com> wrote:
> > >>
> > >>> Hello!
> > >>>
> > >>> I have discussed this with fellow Ignite developers, and they say read
> > >>> through for replicated cache would work where there is either:
> > >>>
> > >>> - writeThrough enabled and all changes do through it.
> > >>> - database contents do not change for already read keys.
> > >>>
> > >>> I can see that neither is met in your case, so you can expect the
> > >>> behavior that you are seeing.
> > >>>
> > >>> Regards,
> > >>> --
> > >>> Ilya Kasnacheev
> > >>>
> > >>>
> > >>> вт, 29 окт. 2019 г. в 18:18, Akash Shinde :
> > >>>
> > I am using Ignite 2.6 version.
> >
> > I am starting 3 server nodes with a replicated cache and 1 client
> > node.
> > Cache configuration is as follows.
> > Read-through true on but write-through is false. Load data by key is
> > implemented as given below in cache-loader.
> >
> > Steps to reproduce issue:
> > 1) Delete an entry from cache using IgniteCache.remove() method.
> > (Entry
> > is just removed from cache but present in DB as write-through is
> > false)
> > 2) Invoke IgniteCache.get() method for the same key in step 1.
> > 3) Now query the cache from client node. Every invocation returns
> > different results.
> > Sometimes it returns reloaded entry, sometime returns the results
> > without reloaded entry.
> >
> > Looks like read-through is not replicating the reloaded entry on all
> > nodes in case of REPLICATED cache.
> >
> > So to investigate further I changed the cache mode to PARTITIONED and
> > set the backup count to 3 i.e. total number of nodes present in
> > cluster (to
> > mimic REPLICATED behavior).
> > This time it worked as expected.
> > Every invocation returned the same result with reloaded entry.
> >
> > * private CacheConfiguration networkCacheCfg() {*
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *CacheConfiguration networkCacheCfg = new
> > CacheConfiguration<>(CacheName.NETWORK_CACHE.name
> > ());
> > networkCacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> > networkCacheCfg.setWriteThrough(false);
> > networkCacheCfg.setReadThrough(true);
> > networkCacheCfg.setRebalanceMode(CacheRebalanceMode.ASYNC);
> >
> > networkCacheCfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> > //networkCacheCfg.setBackups(3);
> > networkCacheCfg.setCacheMode(CacheMode.REPLICATED);
> > Factory storeFactory =
> > FactoryBuilder.factoryOf(NetworkDataCacheLoader.class);
> > networkCacheCfg.setCacheStoreFactory(storeFactory);
> > networkCacheCfg.setIndexedTypes(DefaultDataAffinityKey.class,
> > >>
Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Ilya, Actually I don't remember that we've come to an agreement with the list of modules for "slim" distribution. AFAIR, those discussion still not finished. Also, why should we remove `ignite-ml` from current distribution? Alexey, should we? On Sat, 29 Feb 2020 at 00:38, Denis Magda wrote: > > Sounds reasonable to produce the slim package. Though, if it's time > consuming then we should target it to 2.8.1. > > - > Denis > > > On Fri, Feb 28, 2020 at 1:36 PM Ilya Kasnacheev > wrote: > > > Hello! > > > > Are we doing a "slim" package for 2.8, though? > > > > There was a suggestion to remove the following modules from slim binary > > distribution: > > > > ignite-aop > > ignite-aws > > ignite-camel > > ignite-cassandra-serializers > > ignite-cassandra-store > > ignite-cloud > > ignite-direct-io > > ignite-flink > > ignite-flume > > ignite-gce > > ignite-jcl > > ignite-jms11 > > ignite-jta > > ignite-kafka > > ignite-mesos > > ignite-ml > > ignite-mqtt > > ignite-osgi > > ignite-osgi-karaf > > ignite-osgi-paxlogging > > ignite-rocketmq > > ignite-scalar > > ignite-scalar_2.10 > > ignite-spark > > ignite-ssh > > ignite-storm > > ignite-tensorflow > > ignite-twitter > > ignite-web > > ignite-yarn > > ignite-zeromq > > ignite-zookeeper > > > > Plus, remove benchmarks/ from slim package either. > > > > WDYT? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 28 февр. 2020 г. в 19:57, Denis Magda : > > > > > Maxim, > > > > > > Finally, thanks a lot for starting the voting process! > > > > > > I've already cast my vote and want to bring up some issues that are not > > > blockers though: > > > > > >1. Ignite technical documentation is not finished yet - @Artem > > Budnikov > > > is coordinating this process as well as > > >contributes to many open tickets. Even if the vote passes, the release > > >cannot be *announced* until the docs are finished. I would encourage > > >everyone involved in 2.8 docs creation to pull together, collaborate > > and > > >complete all the pending tickets throughout the next week. > > >2. Missing API references for Node.JS, Python and PHP clients [1] - > > need > > >to be addressed at least for 2.8.1 since the problem is not new to > > 2.8. > > > > > > > > > [1] > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Node-JS-PHP-Python-API-references-for-Ignite-2-8-release-td46097.html > > > - > > > Denis > > > > > > > > > On Fri, Feb 28, 2020 at 7:10 AM Maxim Muzafarov > > wrote: > > > > > > > Dear Community, > > > > > > > > > > > > Please use this thread for all non-voting, discussion, questions > > > > related to this 2.8.0-rc1 release. > > > > > > > > > > > > Cast your vote here: > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html > > > > > > > > >
Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Sounds reasonable to produce the slim package. Though, if it's time consuming then we should target it to 2.8.1. - Denis On Fri, Feb 28, 2020 at 1:36 PM Ilya Kasnacheev wrote: > Hello! > > Are we doing a "slim" package for 2.8, though? > > There was a suggestion to remove the following modules from slim binary > distribution: > > ignite-aop > ignite-aws > ignite-camel > ignite-cassandra-serializers > ignite-cassandra-store > ignite-cloud > ignite-direct-io > ignite-flink > ignite-flume > ignite-gce > ignite-jcl > ignite-jms11 > ignite-jta > ignite-kafka > ignite-mesos > ignite-ml > ignite-mqtt > ignite-osgi > ignite-osgi-karaf > ignite-osgi-paxlogging > ignite-rocketmq > ignite-scalar > ignite-scalar_2.10 > ignite-spark > ignite-ssh > ignite-storm > ignite-tensorflow > ignite-twitter > ignite-web > ignite-yarn > ignite-zeromq > ignite-zookeeper > > Plus, remove benchmarks/ from slim package either. > > WDYT? > > Regards, > -- > Ilya Kasnacheev > > > пт, 28 февр. 2020 г. в 19:57, Denis Magda : > > > Maxim, > > > > Finally, thanks a lot for starting the voting process! > > > > I've already cast my vote and want to bring up some issues that are not > > blockers though: > > > >1. Ignite technical documentation is not finished yet - @Artem > Budnikov > > is coordinating this process as well as > >contributes to many open tickets. Even if the vote passes, the release > >cannot be *announced* until the docs are finished. I would encourage > >everyone involved in 2.8 docs creation to pull together, collaborate > and > >complete all the pending tickets throughout the next week. > >2. Missing API references for Node.JS, Python and PHP clients [1] - > need > >to be addressed at least for 2.8.1 since the problem is not new to > 2.8. > > > > > > [1] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Node-JS-PHP-Python-API-references-for-Ignite-2-8-release-td46097.html > > - > > Denis > > > > > > On Fri, Feb 28, 2020 at 7:10 AM Maxim Muzafarov > wrote: > > > > > Dear Community, > > > > > > > > > Please use this thread for all non-voting, discussion, questions > > > related to this 2.8.0-rc1 release. > > > > > > > > > Cast your vote here: > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html > > > > > >
Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Hello! Are we doing a "slim" package for 2.8, though? There was a suggestion to remove the following modules from slim binary distribution: ignite-aop ignite-aws ignite-camel ignite-cassandra-serializers ignite-cassandra-store ignite-cloud ignite-direct-io ignite-flink ignite-flume ignite-gce ignite-jcl ignite-jms11 ignite-jta ignite-kafka ignite-mesos ignite-ml ignite-mqtt ignite-osgi ignite-osgi-karaf ignite-osgi-paxlogging ignite-rocketmq ignite-scalar ignite-scalar_2.10 ignite-spark ignite-ssh ignite-storm ignite-tensorflow ignite-twitter ignite-web ignite-yarn ignite-zeromq ignite-zookeeper Plus, remove benchmarks/ from slim package either. WDYT? Regards, -- Ilya Kasnacheev пт, 28 февр. 2020 г. в 19:57, Denis Magda : > Maxim, > > Finally, thanks a lot for starting the voting process! > > I've already cast my vote and want to bring up some issues that are not > blockers though: > >1. Ignite technical documentation is not finished yet - @Artem Budnikov > is coordinating this process as well as >contributes to many open tickets. Even if the vote passes, the release >cannot be *announced* until the docs are finished. I would encourage >everyone involved in 2.8 docs creation to pull together, collaborate and >complete all the pending tickets throughout the next week. >2. Missing API references for Node.JS, Python and PHP clients [1] - need >to be addressed at least for 2.8.1 since the problem is not new to 2.8. > > > [1] > > http://apache-ignite-developers.2346864.n4.nabble.com/Node-JS-PHP-Python-API-references-for-Ignite-2-8-release-td46097.html > - > Denis > > > On Fri, Feb 28, 2020 at 7:10 AM Maxim Muzafarov wrote: > > > Dear Community, > > > > > > Please use this thread for all non-voting, discussion, questions > > related to this 2.8.0-rc1 release. > > > > > > Cast your vote here: > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Please disregard previous message. I jumped into a wrong train. Best regards, Ivan Pavlukhin пт, 28 февр. 2020 г. в 22:52, Ivan Pavlukhin : > > I believe that some permissions are required to access a project with > release builds on TC. > > Best regards, > Ivan Pavlukhin > > пт, 28 февр. 2020 г. в 11:58, Pavel Tupitsyn : > > > > Sergey, can't confirm, those links work for me > > > > On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov > > wrote: > > > > > Hello, Maxim! > > > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > > > Igniters, > > > > > > > > > > > > I've prepared everything to start a vote. > > > > Are we ready to go on? > > > > > > > > > > > > I have uploaded a release candidate to: > > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > > > The following staging can be used for testing: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > > > > > TC [2] Compare w/ Previous Release > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > > > wrote: > > > > > > > > > > Maxim, > > > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > > I think we can proceed. > > > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > > > [1] > > > > > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > wrote: > > > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > > should be > > > > > > done soon. > > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > > master), and we can proceed. > > > > > > > > > > > > I had to fix both TC project and the build script. > > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > > > Can you also provide some details - which exactly artefacts should > > > I > > > > > > check on staging resource after the [1] suite execution? > > > > > > We are supposed to verify that NuGet packages are valid by > > > > > > installing > > > > them > > > > > > and starting Ignite. > > > > > > However, we added an automatic check recently: `Run NuGet > > > verification > > > > > > script` build step. > > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > > (scroll down to see versions and dates) > > > > > > > > > > > > [1] > > > > > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > wrote: > > > > > > > > > > > >> Pavel, > > > > > >> > > > > > >> > > > > > >> Thank you for your help. > > > > > >> Please, let me know when I can proceed with a vote preparation. > > > > > >> > > > > > >> > > > > > >> Can you also provide some details - which exactly artefacts should > > > > > >> I > > > > > >> check on staging resource after the [1] suite execution? > > > > > >> > > > > > >> [1] > > > > > >> > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > > > >> > > > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > > > >> wrote: > > > > > >> > > > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > > > >> > Investigating further, will get back to you later today. > > > > > >> > > > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > > > mmu...@apache.org > > > > > > > > > > >> wrote: > > > > > >> >> > > > > > >> >> Pavel, > > > > > >> >> > > > > > >> >> > > > > > >> >> Can you assist me with preparing NuGet staging according to the > > > > > >> >> release steps [1]? I've double-checked everything related to the > > > > build > > > > > >> >> but suite [2] for preparing nuget package still fails (sorry for > > > > > >> >> running it multiple times). > > > > > >> >> > > >
Re: [jira] [Created] (IGNITE-6530) Deadlock in checkpointReadLock method in GridCacheDatabaseSharedManager
I might have missed some context, but a side note:
> If current thread is write lock owner then it can't acquire read lock.
> RRWL doesn't allow upgrades or downgrades.
>From ReentrantReadWriteLock javadoc:
Reentrancy also allows downgrading from the write lock to a read lock,
by acquiring the write lock, then the read lock and then releasing the
write lock. However, upgrading from a read lock to the write lock is
not possible.
Best regards,
Ivan Pavlukhin
вт, 25 февр. 2020 г. в 22:05, Andrey Gura :
>
> Agree with Andrey and Slava.
>
> Your change could lead to exception in case when current thread does
> not own read lock.
>
> > Checking for a writе lock holding through method isHeldByCurrentThread is
> > not atomic, so there is no certainty that this thread still owns a write
> > lock.
>
> What do you mean when talk "method isHeldByCurrentThread is not
> atomic"? There is no need in any additional guarantees here because
> current thread always sees own changes and any other thread could not
> change thread reference if current thread is owner. Also current
> thread can't check lock owning and release lock concurrently.
>
> > I assume that a read lock was obtained and in this code we did not release
> > it.
>
> If current thread is write lock owner then it can't acquire read lock.
> RRWL doesn't allow upgrades or downgrades.
>
> Stack traces from JIRA issue don't point to deadlock. "Deadlock: true"
> means that JVM detected deadlock but it doesn't mean that exactly this
> threads in deadlock.
>
> On Tue, Feb 25, 2020 at 9:25 PM Andrey Mashenkov
> wrote:
> >
> > Write lock is an exclusive lock and no other threads can obtain read or
> > write lock while current thread holding write lock.
> >
> > Why you think checking for current thread is lock-owner is not atomic?
> > A thread that already holds a write lock has no needs to obtain read locks
> > unless it releases the write-lock.
> >
> > Your change can have serious impact.
> > Can you share a reproducer?
> >
> >
> > вт, 25 февр. 2020 г., 20:42 Дмитрий Горчаков <
> > dmitry.gorchakov.mu...@gmail.com>:
> >
> > > > Could you please describe in detail the issue you are trying to fix?
> > >
> > > I once got same deadlock on a productive in v2.7.5. New iteration of
> > > checkpoint could not start. Dump attached.
> > >
> > > > By the way, please take a look at
> > > GridCacheDatabaseSharedManager.checkpointReadLock:
> > >
> > > Thanks, I will look more closely at this check.
> > >
> > > > So, do we really need to unconditionally unlock the read lock at
> > > checkpointReadUnlock as you propose?
> > >
> > > Checking for a writе lock holding through method isHeldByCurrentThread is
> > > not atomic, so there is no certainty that this thread still owns a write
> > > lock.
> > > I assume that a read lock was obtained and in this code we did not release
> > > it.
> > >
> > > Thanks!
> > >
> > > вт, 25 февр. 2020 г. в 14:35, Вячеслав Коптилин > > >:
> > >
> > >> Hello Dmitry,
> > >>
> > >> To be honest, I don't quite understand the proposed fix. Could you please
> > >> describe in detail the issue you are trying to fix?
> > >> By the way, please take a look at
> > >> GridCacheDatabaseSharedManager.checkpointReadLock:
> > >>
> > >> @Override public void checkpointReadLock() {
> > >> if (checkpointLock.writeLock().isHeldByCurrentThread())
> > >> return;
> > >> ...
> > >> }
> > >>
> > >> In other words, the read lock is not acquired in case the write lock is
> > >> already held.
> > >> So, do we really need to unconditionally unlock the read lock at
> > >> checkpointReadUnlock as you propose?
> > >>
> > >> Thanks,
> > >> S.
> > >>
> > >> вт, 25 февр. 2020 г. в 13:32, Dmitry Gorchakov <
> > >> dmitry.gorchakov.mu...@gmail.com>:
> > >>
> > >> > This issue once reproduced in my productive with similar stack trace.
> > >> > During
> > >> > sources analysis I saw the use unsafe of method
> > >> > writeLock().isHeldByCurrentThread() for unlocking checkpoint. This may
> > >> > cause
> > >> > thread to starvation. Problem no longer appeared after local fix.
> > >> > I prepared pull request https://github.com/apache/ignite/pull/7445.
> > >> > Accept please jira issue to me and review my PR.
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> > >> >
> > >>
> > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
I believe that some permissions are required to access a project with release builds on TC. Best regards, Ivan Pavlukhin пт, 28 февр. 2020 г. в 11:58, Pavel Tupitsyn : > > Sergey, can't confirm, those links work for me > > On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov > wrote: > > > Hello, Maxim! > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've prepared everything to start a vote. > > > Are we ready to go on? > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > The following staging can be used for testing: > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > > > TC [2] Compare w/ Previous Release > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > > wrote: > > > > > > > > Maxim, > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > I think we can proceed. > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > [1] > > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > wrote: > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > should be > > > > > done soon. > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > master), and we can proceed. > > > > > > > > > > I had to fix both TC project and the build script. > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > Can you also provide some details - which exactly artefacts should > > I > > > > > check on staging resource after the [1] suite execution? > > > > > We are supposed to verify that NuGet packages are valid by installing > > > them > > > > > and starting Ignite. > > > > > However, we added an automatic check recently: `Run NuGet > > verification > > > > > script` build step. > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > (scroll down to see versions and dates) > > > > > > > > > > [1] > > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > wrote: > > > > > > > > > >> Pavel, > > > > >> > > > > >> > > > > >> Thank you for your help. > > > > >> Please, let me know when I can proceed with a vote preparation. > > > > >> > > > > >> > > > > >> Can you also provide some details - which exactly artefacts should I > > > > >> check on staging resource after the [1] suite execution? > > > > >> > > > > >> [1] > > > > >> > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > > >> > > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > > >> wrote: > > > > >> > > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > > >> > Investigating further, will get back to you later today. > > > > >> > > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > > mmu...@apache.org > > > > > > > > >> wrote: > > > > >> >> > > > > >> >> Pavel, > > > > >> >> > > > > >> >> > > > > >> >> Can you assist me with preparing NuGet staging according to the > > > > >> >> release steps [1]? I've double-checked everything related to the > > > build > > > > >> >> but suite [2] for preparing nuget package still fails (sorry for > > > > >> >> running it multiple times). > > > > >> >> > > > > >> >> I see some issues in the log which may be related to the file > > copy > > > in > > > > >> >> the build script which recently changed [4]. > > > > >> >> I'm still digging in, but anyway can you take a look and help? > > > > >> >> > > > > >> >> > > > > >> >> Step 2: > > > > >> >> Copy-Item : Cannot find path > > > > >> >> > > > > >> > > > > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'be
Re: [MTCGA]: new failures in builds [4974714] needs to be handled
Pavel, Good news! Best regards, Ivan Pavlukhin чт, 27 февр. 2020 г. в 16:34, Pavel Tupitsyn : > > Ivan, thank you, this is the answer: > > > it always fails when configured to run with Java 9 and higher > > Ignite can only be built with Java 8, and NuGet project includes Java build > step, which fails. > I've fixed TC settings to force Java 8 for `Platform .NET (NuGet)` project, > it seems to fix the issue. > > > 1. Does Ignite .NET work fine with java 9+? > Yes, it does > > On Thu, Feb 27, 2020 at 2:25 PM Ivan Pavlukhin wrote: > > > Currently have no idea about ODBC (what suite is assumed?). Comparison > > success and failed NuGet runs shows that it always fails when > > configured to run with Java 9 and higher. No answers so far, but some > > questions I do not know answers for: > > 1. Does Ignite .NET work fine with java 9+? > > 2. Is it possible that NuGet job was always executed with java 8 > > beforehand? > > > > Best regards, > > Ivan Pavlukhin > > > > вт, 18 февр. 2020 г. в 15:04, Igor Sapego : > > > > > > By the way, some ODBC tests became flaky about the same time as well. > > > May it be there is one root cause somewhere in SQL? > > > > > > Best Regards, > > > Igor > > > > > > > > > On Mon, Feb 17, 2020 at 9:36 PM Pavel Tupitsyn > > wrote: > > > > > > > I did a quick look some time ago, no idea what is going on, honestly. > > Tests > > > > became flaky for no apparent reason. > > > > I have this on my list, will investigate more. > > > > > > > > On Mon, Feb 17, 2020 at 8:43 PM Ivan Pavlukhin > > > > wrote: > > > > > > > > > Looks like something broke .NET NuGet tests [1] in the end of > > January. > > > > > Is anyone working on it? > > > > > > > > > > [1] > > > > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E&mode=builds > > > > > > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > пт, 31 янв. 2020 г. в 21:56, : > > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > I've detected some new issue on TeamCity to be handled. You are > > more > > > > > than welcomed to help. > > > > > > > > > > > > If your changes can lead to this failure(s): We're grateful that > > you > > > > > were a volunteer to make the contribution to this project, but things > > > > > change and you may no longer be able to finalize your contribution. > > > > > > Could you respond to this email and indicate if you wish to > > continue > > > > > and fix test failures or step down and some committer may revert you > > > > commit. > > > > > > > > > > > > *Recently contributed test failed in master NuGet.ComputeTest > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-3754909490222985251&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *New test failure in master NLogTest.TestIgniteStartup > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-557824718061284584&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *Recently contributed test failed in master NuGet.AspNetTest > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4468304894809184645&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *New test failure in master StartupTest.TestApacheIgniteExe > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-5187257231705167662&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *New test failure in master > > > > > EntityFrameworkCacheTest.TestStartupPutGet > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=4190667585576620977&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *New test failure in master StartupTest.TestSpringConfig > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6904015716462020548&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *New test failure in master StartupTest.TestCodeConfig > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-702135655943708515&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *Recently contributed test failed in master NuGet.CacheTest > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=6551101028080942383&branch=%3Cdefault%3E&tab=testDetails > > > > > > > > > > > > *New test failure in master Log4NetTest.TestIgniteStartup > > > > > > > > > > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4358661632507505081&branch=%3Cdefault%3E&tab=testDetails > > > > > > Changes may lead to failure were done by > > > > > > - aleksei scherbakov > > > > > https://ci.ignite.apache.org/viewModification.html?modId=897229 > > > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Hello, Petr, Can we share these suites [1] [2] to the whole community, for instance, in read-only mode? I think they are helpful for testing\checking the release by each community member. TC [Check RC: Licenses, compile, chksum] [1] https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv TC [2] Compare w/ Previous Release [2] https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv On Fri, 28 Feb 2020 at 16:41, Maxim Muzafarov wrote: > > Sergey, > > > It seems these links ([4] Check RC: Licenses, compile, checksum) [1] > is only accessed for users included into the release group on the > TeamCity. > Sorry for not mentioned it before. > > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > On Thu, 27 Feb 2020 at 23:17, Sergey Antonov > wrote: > > > > Hello, Maxim! > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've prepared everything to start a vote. > > > Are we ready to go on? > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > The following staging can be used for testing: > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > > > TC [2] Compare w/ Previous Release > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn wrote: > > > > > > > > Maxim, > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > I think we can proceed. > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > [1] > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > wrote: > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > should be > > > > > done soon. > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > master), and we can proceed. > > > > > > > > > > I had to fix both TC project and the build script. > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > Can you also provide some details - which exactly artefacts should I > > > > > check on staging resource after the [1] suite execution? > > > > > We are supposed to verify that NuGet packages are valid by installing > > > them > > > > > and starting Ignite. > > > > > However, we added an automatic check recently: `Run NuGet verification > > > > > script` build step. > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > (scroll down to see versions and dates) > > > > > > > > > > [1] > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > wrote: > > > > > > > > > >> Pavel, > > > > >> > > > > >> > > > > >> Thank you for your help. > > > > >> Please, let me know when I can proceed with a vote preparation. > > > > >> > > > > >> > > > > >> Can you also provide some details - which exactly artefacts should I > > > > >> check on staging resource after the [1] suite execution? > > > > >> > > > > >> [1] > > > > >> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > > >> > > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > > >> wrote: > > > > >> > > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > > >> > Investigating further, will get back to you later today. > > > > >> > > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov > > > > > > > >> wrote: > > > > >> >> > > > > >> >> Pavel, > > > > >> >> > > > > >> >> > > > > >> >> Can you assist me wit
[jira] [Created] (IGNITE-12730) Streaming blocking threads
Marinko created IGNITE-12730: Summary: Streaming blocking threads Key: IGNITE-12730 URL: https://issues.apache.org/jira/browse/IGNITE-12730 Project: Ignite Issue Type: Bug Components: streaming Affects Versions: 2.7.6 Reporter: Marinko What is the proper way to load 5 mil records without getting any messages that the stripe worker threads are blocked doing their job. The records are initially added to the thread based queue. So it's up to ignite to handle it properly. Is there any suggestion to load a big amount of data? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12729) LT.warn() method ignores passed exception
Andrey N. Gura created IGNITE-12729:
---
Summary: LT.warn() method ignores passed exception
Key: IGNITE-12729
URL: https://issues.apache.org/jira/browse/IGNITE-12729
Project: Ignite
Issue Type: Improvement
Reporter: Andrey N. Gura
{{GridLogThrottle.warn()}} method ignores and doesn't log {{Throwable}}
parameter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim, I get 404 code for all TC links [1][2][3] in your email, not only TC [Check RC: Licenses, compile, chksum]. [1] [1] https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv [2] https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv [3] https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv пт, 28 февр. 2020 г. в 16:41, Maxim Muzafarov : > Sergey, > > > It seems these links ([4] Check RC: Licenses, compile, checksum) [1] > is only accessed for users included into the release group on the > TeamCity. > Sorry for not mentioned it before. > > > [1] > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > On Thu, 27 Feb 2020 at 23:17, Sergey Antonov > wrote: > > > > Hello, Maxim! > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've prepared everything to start a vote. > > > Are we ready to go on? > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > The following staging can be used for testing: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > > > TC [2] Compare w/ Previous Release > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > wrote: > > > > > > > > Maxim, > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > I think we can proceed. > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > [1] > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > wrote: > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > should be > > > > > done soon. > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > master), and we can proceed. > > > > > > > > > > I had to fix both TC project and the build script. > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > Can you also provide some details - which exactly artefacts > should I > > > > > check on staging resource after the [1] suite execution? > > > > > We are supposed to verify that NuGet packages are valid by > installing > > > them > > > > > and starting Ignite. > > > > > However, we added an automatic check recently: `Run NuGet > verification > > > > > script` build step. > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > (scroll down to see versions and dates) > > > > > > > > > > [1] > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > wrote: > > > > > > > > > >> Pavel, > > > > >> > > > > >> > > > > >> Thank you for your help. > > > > >> Please, let me know when I can proceed with a vote preparation. > > > > >> > > > > >> > > > > >> Can you also provide some details - which exactly artefacts > should I > > > > >> check on staging resource after the [1] suite execution? > > > > >> > > > > >> [1] > > > > >> > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > > >> > > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn < > ptupit...@apache.org> > > > > >> wrote: > > > > >> > > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > > >> > Investigating further, will get back to you later today. > > > > >> > > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > mmu...@apache.org > > > > > > > > >> wrote: > > > > >> >> > > > > >> >>
Re: [DISCUSSION] Release Apache Ignite 2.8.0 RC1
Maxim, Finally, thanks a lot for starting the voting process! I've already cast my vote and want to bring up some issues that are not blockers though: 1. Ignite technical documentation is not finished yet - @Artem Budnikov is coordinating this process as well as contributes to many open tickets. Even if the vote passes, the release cannot be *announced* until the docs are finished. I would encourage everyone involved in 2.8 docs creation to pull together, collaborate and complete all the pending tickets throughout the next week. 2. Missing API references for Node.JS, Python and PHP clients [1] - need to be addressed at least for 2.8.1 since the problem is not new to 2.8. [1] http://apache-ignite-developers.2346864.n4.nabble.com/Node-JS-PHP-Python-API-references-for-Ignite-2-8-release-td46097.html - Denis On Fri, Feb 28, 2020 at 7:10 AM Maxim Muzafarov wrote: > Dear Community, > > > Please use this thread for all non-voting, discussion, questions > related to this 2.8.0-rc1 release. > > > Cast your vote here: > > http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html >
Re: [VOTE] Release Apache Ignite 2.8.0 RC1
+1 (binding) Downloaded, started a cluster, ran several examples pulling Maven artifacts from the staging. - Denis On Fri, Feb 28, 2020 at 7:09 AM Maxim Muzafarov wrote: > Dear Community, > > > I have uploaded a release candidate to: > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > The following staging can be used for testing: > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > Tag with name 2.8.0-rc1 created: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > Release 2.8 contains a lot of changes, please refer to the RELEASE_NOTES: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.8 > > Complete list of resolved issues: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8%20and%20status%20%3D%20Resolved%20and%20resolution%20%3D%20Fixed%20order%20by%20updated > > DEVNOTES > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.8 > > > Additional checks have been performed (available for users included > into the release group on TeamCity). > > TC [Check RC: Licenses, compile, chksum] > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > TC [3] Build & Upload Nuget Staging Packages > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > TC [2] Compare w/ Previous Release > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > The vote is formal, see voting guidelines > https://www.apache.org/foundation/voting.html > > +1 - to accept Apache Ignite 2.8.0-rc1 > 0 - don't care either way > -1 - DO NOT accept Apache Ignite Ignite 2.8.0-rc1 (explain why) > > See notes on how to verify release here > https://www.apache.org/info/verification.html > and > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification > > The vote will hold for 72 hours and will end on March 2-nd 2020 15:10 UTC > > https://www.timeanddate.com/countdown/generic?iso=20200302T181010&p0=166&msg=%5BVOTE%5D+Release+Apache+Ignite+2.8.0+RC1&font=sanserif >
[jira] [Created] (IGNITE-12728) The cache#putAllAsync method does not collect statistics
Amelchev Nikita created IGNITE-12728:
Summary: The cache#putAllAsync method does not collect statistics
Key: IGNITE-12728
URL: https://issues.apache.org/jira/browse/IGNITE-12728
Project: Ignite
Issue Type: Bug
Reporter: Amelchev Nikita
Assignee: Amelchev Nikita
The cache#putAllAsync method does not collect statistics.
The reproducer for {{GridCacheAbstractMetricsSelfTest}}:
{noformat}
@Test
public void testPutAllAsyncAvgTime() throws Exception {
IgniteCache cache = grid(0).cache(DEFAULT_CACHE_NAME);
assertEquals(0.0, cache.localMetrics().getAveragePutTime(), 0.0);
assertEquals(0, cache.localMetrics().getCachePuts());
Map values = new HashMap<>();
values.put(1, 1);
values.put(2, 2);
values.put(3, 3);
IgniteFuture fut = cache.putAllAsync(values);
fut.get();
assertTrue(waitForCondition(() ->
cache.localMetrics().getAveragePutTime() > 0, 30_000));
assertEquals(values.size(), cache.localMetrics().getCachePuts());
}
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[DISCUSSION] Release Apache Ignite 2.8.0 RC1
Dear Community, Please use this thread for all non-voting, discussion, questions related to this 2.8.0-rc1 release. Cast your vote here: http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Release-Apache-Ignite-2-8-0-RC1-td46140.html
[VOTE] Release Apache Ignite 2.8.0 RC1
Dear Community, I have uploaded a release candidate to: https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ The following staging can be used for testing: https://repository.apache.org/content/repositories/orgapacheignite-1474/ Tag with name 2.8.0-rc1 created: https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 Release 2.8 contains a lot of changes, please refer to the RELEASE_NOTES: https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=ignite-2.8 Complete list of resolved issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8%20and%20status%20%3D%20Resolved%20and%20resolution%20%3D%20Fixed%20order%20by%20updated DEVNOTES https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.8 Additional checks have been performed (available for users included into the release group on TeamCity). TC [Check RC: Licenses, compile, chksum] https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv TC [3] Build & Upload Nuget Staging Packages https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv TC [2] Compare w/ Previous Release https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv The vote is formal, see voting guidelines https://www.apache.org/foundation/voting.html +1 - to accept Apache Ignite 2.8.0-rc1 0 - don't care either way -1 - DO NOT accept Apache Ignite Ignite 2.8.0-rc1 (explain why) See notes on how to verify release here https://www.apache.org/info/verification.html and https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-P5.VotingonReleaseandReleaseVerification The vote will hold for 72 hours and will end on March 2-nd 2020 15:10 UTC https://www.timeanddate.com/countdown/generic?iso=20200302T181010&p0=166&msg=%5BVOTE%5D+Release+Apache+Ignite+2.8.0+RC1&font=sanserif
Re: MetaStorage key length limitations and Cache Metrics configuration
Ivan, I also don't think this issue is a blocker for 2.8 as it affects only experimental functionality and only in special cases. Removing key length limitations in MetaStorage seems more strategic approach to me but depending on how we decide to approach it (as a local fix or as part of a broader improvement of MetaStorage internal implementation) we may target it to 2.8.1 or 2.9. In the latter case it makes sense to implement key length validation [1] and include it to 2.8.1 to prevent user from making destructive actions. Otherwise if we decide to implement [2] earlier and remove this pesky limitation in 2.8.1 then I'm fine with closing [1] with "Won't fix" resolution. Does it make sense to you? [1] https://issues.apache.org/jira/browse/IGNITE-12721 [2] https://issues.apache.org/jira/browse/IGNITE-12726 On Fri, Feb 28, 2020 at 4:18 PM Maxim Muzafarov wrote: > Ivan, > > > This issue doesn't seem to be a blocker for 2.8 release from my point of > view. > I think we definitely will have such bugs in future and 2.8.1 is our > goal for them. > > Please, let me know if we should wait for the fix and include it exactly > in 2.8. > > On Fri, 28 Feb 2020 at 15:40, Nikolay Izhikov wrote: > > > > Igniters, > > > > I think we can replace cache name with the cache id. > > This should solve issue with the length limitation. > > > > What do you think? > > > > > 28 февр. 2020 г., в 15:32, Ivan Bessonov > написал(а): > > > > > > Hello Igniters, > > > > > > we have an issue in master branch and in the upcoming 2.8 release that > > > related to new metrics functionality implemented in [1]. You can't use > new > > > "configureHistogramMetric" and "configureHitRateMetric" configuration > > > methods on caches with long names. My estimation shows that cache with > 30 > > > characters in its name will shut down your whole cluster with failure > > > handler if > > > you try to change metrics configuration for it using one of those > methods. > > > > > > Initially we wanted to merge [2] to show a valid error message instead > of > > > failing > > > the cluster, but it wasn't in plans for 2.8 because we didn't know > that it > > > clashes > > > with [1]. > > > > > > I created issue [3] with plans of removing MetaStorage key length > > > limitations, but > > > it requires some thoughtful MetaStorageTree reworkings. I mean that it > > > can't be > > > done in only a few days. > > > > > > What do you think? Does this issue affect 2.8 release? AFAIK new > metrics are > > > experimental and they can have some known issues. Feel free to ask me > for > > > more > > > details if it's needed. > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11987 > > > [2] https://issues.apache.org/jira/browse/IGNITE-12721 > > > [3] https://issues.apache.org/jira/browse/IGNITE-12726 > > > > > > -- > > > Sincerely yours, > > > Ivan Bessonov > > >
[jira] [Created] (IGNITE-12727) BYOK support
Moti Nisenson-Ken created IGNITE-12727: -- Summary: BYOK support Key: IGNITE-12727 URL: https://issues.apache.org/jira/browse/IGNITE-12727 Project: Ignite Issue Type: Wish Reporter: Moti Nisenson-Ken Transparent Data Encryption currently works with all keys being held by Ignite. It would be preferable if a Key Wrapping/Unwrapping facility (e.g. Azure Key Vault, IBM Key Protect) could be configured on a per-cache basis. By default the wrapper/unwrapper can just be pas-thru and return the key material as received. Additionally, unwrapping should be able to give a new "storage format" key (in case the underlying root keys have been rotated) which Ignite would then store in place of the original stored wrapped key. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Sergey, It seems these links ([4] Check RC: Licenses, compile, checksum) [1] is only accessed for users included into the release group on the TeamCity. Sorry for not mentioned it before. [1] https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv On Thu, 27 Feb 2020 at 23:17, Sergey Antonov wrote: > > Hello, Maxim! > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > Igniters, > > > > > > I've prepared everything to start a vote. > > Are we ready to go on? > > > > > > I have uploaded a release candidate to: > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > The following staging can be used for testing: > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > Tag with name 2.8.0-rc1 created: > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > TC [3] Build & Upload Nuget Staging Packages > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > TC [2] Compare w/ Previous Release > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn wrote: > > > > > > Maxim, > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > I think we can proceed. > > > > > > Thank you and sorry for the broken build. > > > > > > [1] > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > wrote: > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > should be > > > > done soon. > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > master), and we can proceed. > > > > > > > > I had to fix both TC project and the build script. > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > Can you also provide some details - which exactly artefacts should I > > > > check on staging resource after the [1] suite execution? > > > > We are supposed to verify that NuGet packages are valid by installing > > them > > > > and starting Ignite. > > > > However, we added an automatic check recently: `Run NuGet verification > > > > script` build step. > > > > So the only thing to check is that new package appears on MyGet [1] > > > > (scroll down to see versions and dates) > > > > > > > > [1] > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > wrote: > > > > > > > >> Pavel, > > > >> > > > >> > > > >> Thank you for your help. > > > >> Please, let me know when I can proceed with a vote preparation. > > > >> > > > >> > > > >> Can you also provide some details - which exactly artefacts should I > > > >> check on staging resource after the [1] suite execution? > > > >> > > > >> [1] > > > >> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > >> > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > >> wrote: > > > >> > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > >> > Investigating further, will get back to you later today. > > > >> > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov > > > > > >> wrote: > > > >> >> > > > >> >> Pavel, > > > >> >> > > > >> >> > > > >> >> Can you assist me with preparing NuGet staging according to the > > > >> >> release steps [1]? I've double-checked everything related to the > > build > > > >> >> but suite [2] for preparing nuget package still fails (sorry for > > > >> >> running it multiple times). > > > >> >> > > > >> >> I see some issues in the log which may be related to the file copy > > in > > > >> >> the build script which recently changed [4]. > > > >> >> I'm still digging in, but anyway can you take a look and help? > > > >> >> > > > >> >> > > > >> >> Step 2: > > > >> >> Copy-Item : Cannot find path > > > >> >> > > > >> > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because > > > >> >> it does not exist. > > > >> >> > > > >> >> Step 3: > > > >> >> Cannot find path > > > >> >> > > > >> > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite
Re: MetaStorage key length limitations and Cache Metrics configuration
Ivan, This issue doesn't seem to be a blocker for 2.8 release from my point of view. I think we definitely will have such bugs in future and 2.8.1 is our goal for them. Please, let me know if we should wait for the fix and include it exactly in 2.8. On Fri, 28 Feb 2020 at 15:40, Nikolay Izhikov wrote: > > Igniters, > > I think we can replace cache name with the cache id. > This should solve issue with the length limitation. > > What do you think? > > > 28 февр. 2020 г., в 15:32, Ivan Bessonov написал(а): > > > > Hello Igniters, > > > > we have an issue in master branch and in the upcoming 2.8 release that > > related to new metrics functionality implemented in [1]. You can't use new > > "configureHistogramMetric" and "configureHitRateMetric" configuration > > methods on caches with long names. My estimation shows that cache with 30 > > characters in its name will shut down your whole cluster with failure > > handler if > > you try to change metrics configuration for it using one of those methods. > > > > Initially we wanted to merge [2] to show a valid error message instead of > > failing > > the cluster, but it wasn't in plans for 2.8 because we didn't know that it > > clashes > > with [1]. > > > > I created issue [3] with plans of removing MetaStorage key length > > limitations, but > > it requires some thoughtful MetaStorageTree reworkings. I mean that it > > can't be > > done in only a few days. > > > > What do you think? Does this issue affect 2.8 release? AFAIK new metrics are > > experimental and they can have some known issues. Feel free to ask me for > > more > > details if it's needed. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11987 > > [2] https://issues.apache.org/jira/browse/IGNITE-12721 > > [3] https://issues.apache.org/jira/browse/IGNITE-12726 > > > > -- > > Sincerely yours, > > Ivan Bessonov >
Re: MetaStorage key length limitations and Cache Metrics configuration
Igniters, I think we can replace cache name with the cache id. This should solve issue with the length limitation. What do you think? > 28 февр. 2020 г., в 15:32, Ivan Bessonov написал(а): > > Hello Igniters, > > we have an issue in master branch and in the upcoming 2.8 release that > related to new metrics functionality implemented in [1]. You can't use new > "configureHistogramMetric" and "configureHitRateMetric" configuration > methods on caches with long names. My estimation shows that cache with 30 > characters in its name will shut down your whole cluster with failure > handler if > you try to change metrics configuration for it using one of those methods. > > Initially we wanted to merge [2] to show a valid error message instead of > failing > the cluster, but it wasn't in plans for 2.8 because we didn't know that it > clashes > with [1]. > > I created issue [3] with plans of removing MetaStorage key length > limitations, but > it requires some thoughtful MetaStorageTree reworkings. I mean that it > can't be > done in only a few days. > > What do you think? Does this issue affect 2.8 release? AFAIK new metrics are > experimental and they can have some known issues. Feel free to ask me for > more > details if it's needed. > > > [1] https://issues.apache.org/jira/browse/IGNITE-11987 > [2] https://issues.apache.org/jira/browse/IGNITE-12721 > [3] https://issues.apache.org/jira/browse/IGNITE-12726 > > -- > Sincerely yours, > Ivan Bessonov
MetaStorage key length limitations and Cache Metrics configuration
Hello Igniters, we have an issue in master branch and in the upcoming 2.8 release that related to new metrics functionality implemented in [1]. You can't use new "configureHistogramMetric" and "configureHitRateMetric" configuration methods on caches with long names. My estimation shows that cache with 30 characters in its name will shut down your whole cluster with failure handler if you try to change metrics configuration for it using one of those methods. Initially we wanted to merge [2] to show a valid error message instead of failing the cluster, but it wasn't in plans for 2.8 because we didn't know that it clashes with [1]. I created issue [3] with plans of removing MetaStorage key length limitations, but it requires some thoughtful MetaStorageTree reworkings. I mean that it can't be done in only a few days. What do you think? Does this issue affect 2.8 release? AFAIK new metrics are experimental and they can have some known issues. Feel free to ask me for more details if it's needed. [1] https://issues.apache.org/jira/browse/IGNITE-11987 [2] https://issues.apache.org/jira/browse/IGNITE-12721 [3] https://issues.apache.org/jira/browse/IGNITE-12726 -- Sincerely yours, Ivan Bessonov
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Guys, can somebody check those links from TC account different from @ apache.org domain? пт, 28 февр. 2020 г. в 11:58, Pavel Tupitsyn : > Sergey, can't confirm, those links work for me > > On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov > > wrote: > > > Hello, Maxim! > > > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > > > Igniters, > > > > > > > > > I've prepared everything to start a vote. > > > Are we ready to go on? > > > > > > > > > I have uploaded a release candidate to: > > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > > > The following staging can be used for testing: > > > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > > > Tag with name 2.8.0-rc1 created: > > > > > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > > > TC [2] Compare w/ Previous Release > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > > wrote: > > > > > > > > Maxim, > > > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > > I think we can proceed. > > > > > > > > Thank you and sorry for the broken build. > > > > > > > > [1] > > > > > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > wrote: > > > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > > should be > > > > > done soon. > > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > > master), and we can proceed. > > > > > > > > > > I had to fix both TC project and the build script. > > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > > > Can you also provide some details - which exactly artefacts > should > > I > > > > > check on staging resource after the [1] suite execution? > > > > > We are supposed to verify that NuGet packages are valid by > installing > > > them > > > > > and starting Ignite. > > > > > However, we added an automatic check recently: `Run NuGet > > verification > > > > > script` build step. > > > > > So the only thing to check is that new package appears on MyGet [1] > > > > > (scroll down to see versions and dates) > > > > > > > > > > [1] > > > > > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > wrote: > > > > > > > > > >> Pavel, > > > > >> > > > > >> > > > > >> Thank you for your help. > > > > >> Please, let me know when I can proceed with a vote preparation. > > > > >> > > > > >> > > > > >> Can you also provide some details - which exactly artefacts > should I > > > > >> check on staging resource after the [1] suite execution? > > > > >> > > > > >> [1] > > > > >> > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > > >> > > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn < > ptupit...@apache.org> > > > > >> wrote: > > > > >> > > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > > >> > Investigating further, will get back to you later today. > > > > >> > > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > > mmu...@apache.org > > > > > > > > >> wrote: > > > > >> >> > > > > >> >> Pavel, > > > > >> >> > > > > >> >> > > > > >> >> Can you assist me with preparing NuGet staging according to the > > > > >> >> release steps [1]? I've double-checked everything related to > the > > > build > > > > >> >> but suite [2] for preparing nuget package still fails (sorry > for > > > > >> >> running it multiple times). > > > > >> >> > > > > >> >> I see some issues in the log which may be related to the file > > copy > > > in > > > > >> >> the build script which recently changed [4]. > > > > >> >> I'm still digging in, but anyway can you take a look and help? > > > > >> >> > > > > >> >> > > > > >> >> Step 2: > > > > >> >> Copy-Item : Cannot find path > > > > >> >> > > > > >> > > > > > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\
[jira] [Created] (IGNITE-12726) Cache names can't be used as part of DistributedMetaStorage keys
Ivan Bessonov created IGNITE-12726: -- Summary: Cache names can't be used as part of DistributedMetaStorage keys Key: IGNITE-12726 URL: https://issues.apache.org/jira/browse/IGNITE-12726 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov Issue was discovered during the implementation of IGNITE-12721. Here's a shot version of the description: * local MetaStorage can't handle keys that have more than 64 bytes in their "byte[]" representation. Since DistributedMetaStorage uses it and adds some specific prefixes on top, we have a strict limit on the key length. Just to be clear - it just won't work, IGNITE-12721 only adds a valid exception and meaningful error message to the API. Recently IGNITE-11987 from [IEP-35] has been merged to master and 2.8 release branch, and it does exactly whats written in the title - adds cache name as a part of the key. So, if you use long cache name in, for example, test called "org.apache.ignite.internal.metric.MetricsConfigurationTest#testConfigRemovedOnCacheRemove", you'll get AssertionErrors in log. By "long" I mean about 50 symbols. This should not happen. I see two options here: * leave everything as it is and change keys format; * modify MetaStorage so that it can handle longer keys. I prefer this one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: NodeOrder in GridCacheVersion
Prasad, The current version in the entry is checked agains the version which was read from the very same entry, so with absence of concurrent updates the version will be the same. >From your description, I think there might be a concurrent read for the key that you clear which loads the value on primary node with a different version. Then, the read happening inside transaction always reads the value from backup which leads to a permanent version mismatch; I reproduced this scenario locally. The -DIGNITE_READ_LOAD_BALANCING=false fixes the issue at a price of disabling read load balancing. I will create a ticket for the issue shortly, perhaps someone from the community will pick it up.
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Maxim, I checked the links - looks we are all set! чт, 27 февр. 2020 г. в 23:17, Sergey Antonov : > Hello, Maxim! > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > Igniters, > > > > > > I've prepared everything to start a vote. > > Are we ready to go on? > > > > > > I have uploaded a release candidate to: > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > The following staging can be used for testing: > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > Tag with name 2.8.0-rc1 created: > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > TC [2] Compare w/ Previous Release > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > wrote: > > > > > > Maxim, > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > I think we can proceed. > > > > > > Thank you and sorry for the broken build. > > > > > > [1] > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > wrote: > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > should be > > > > done soon. > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > master), and we can proceed. > > > > > > > > I had to fix both TC project and the build script. > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > Can you also provide some details - which exactly artefacts should > I > > > > check on staging resource after the [1] suite execution? > > > > We are supposed to verify that NuGet packages are valid by installing > > them > > > > and starting Ignite. > > > > However, we added an automatic check recently: `Run NuGet > verification > > > > script` build step. > > > > So the only thing to check is that new package appears on MyGet [1] > > > > (scroll down to see versions and dates) > > > > > > > > [1] > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > wrote: > > > > > > > >> Pavel, > > > >> > > > >> > > > >> Thank you for your help. > > > >> Please, let me know when I can proceed with a vote preparation. > > > >> > > > >> > > > >> Can you also provide some details - which exactly artefacts should I > > > >> check on staging resource after the [1] suite execution? > > > >> > > > >> [1] > > > >> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > >> > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > >> wrote: > > > >> > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > >> > Investigating further, will get back to you later today. > > > >> > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > mmu...@apache.org > > > > > > >> wrote: > > > >> >> > > > >> >> Pavel, > > > >> >> > > > >> >> > > > >> >> Can you assist me with preparing NuGet staging according to the > > > >> >> release steps [1]? I've double-checked everything related to the > > build > > > >> >> but suite [2] for preparing nuget package still fails (sorry for > > > >> >> running it multiple times). > > > >> >> > > > >> >> I see some issues in the log which may be related to the file > copy > > in > > > >> >> the build script which recently changed [4]. > > > >> >> I'm still digging in, but anyway can you take a look and help? > > > >> >> > > > >> >> > > > >> >> Step 2: > > > >> >> Copy-Item : Cannot find path > > > >> >> > > > >> > > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because > > > >> >> it does not exist. > > > >> >> > > > >> >> Step 3: > > > >> >> Cannot find path > > > >> >> > > > >> > > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core\bin\Release\Apache.Ignite.Core.dll' > > > >> >> because it does not exist. > > > >> >> At > > > >> > > > C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\build.ps1:283 > > > >> >> char:47 > > > >> >> > > > >> >> pack: invalid argumen
Re: Read through not working as expected in case of Replicated cache
Can someone please comment on this?
On Wed, Feb 26, 2020 at 6:04 AM Denis Magda wrote:
> Ignite Dev team,
>
> This sounds like an issue in our replicated cache implementation rather
> than an expected behavior. Especially, if partitioned caches don't have
> such a specificity.
>
> Who can explain why write-through needs to be enabled for replicated caches
> to reload an entry from an underlying database properly/consistently?
>
> -
> Denis
>
>
> On Tue, Feb 25, 2020 at 5:11 AM Ilya Kasnacheev >
> wrote:
>
> > Hello!
> >
> > I think this is by design. You may suggest edits on readme.io.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 24 февр. 2020 г. в 17:28, Prasad Bhalerao <
> > prasadbhalerao1...@gmail.com>:
> >
> >> Hi,
> >>
> >> Is this a bug or the cache is designed to work this way?
> >>
> >> If it is as-designed, can this behavior be updated in ignite
> >> documentation?
> >>
> >> Thanks,
> >> Prasad
> >>
> >> On Wed, Oct 30, 2019 at 7:19 PM Ilya Kasnacheev <
> >> ilya.kasnach...@gmail.com> wrote:
> >>
> >>> Hello!
> >>>
> >>> I have discussed this with fellow Ignite developers, and they say read
> >>> through for replicated cache would work where there is either:
> >>>
> >>> - writeThrough enabled and all changes do through it.
> >>> - database contents do not change for already read keys.
> >>>
> >>> I can see that neither is met in your case, so you can expect the
> >>> behavior that you are seeing.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> вт, 29 окт. 2019 г. в 18:18, Akash Shinde :
> >>>
> I am using Ignite 2.6 version.
>
> I am starting 3 server nodes with a replicated cache and 1 client
> node.
> Cache configuration is as follows.
> Read-through true on but write-through is false. Load data by key is
> implemented as given below in cache-loader.
>
> Steps to reproduce issue:
> 1) Delete an entry from cache using IgniteCache.remove() method.
> (Entry
> is just removed from cache but present in DB as write-through is
> false)
> 2) Invoke IgniteCache.get() method for the same key in step 1.
> 3) Now query the cache from client node. Every invocation returns
> different results.
> Sometimes it returns reloaded entry, sometime returns the results
> without reloaded entry.
>
> Looks like read-through is not replicating the reloaded entry on all
> nodes in case of REPLICATED cache.
>
> So to investigate further I changed the cache mode to PARTITIONED and
> set the backup count to 3 i.e. total number of nodes present in
> cluster (to
> mimic REPLICATED behavior).
> This time it worked as expected.
> Every invocation returned the same result with reloaded entry.
>
> * private CacheConfiguration networkCacheCfg() {*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *CacheConfiguration networkCacheCfg = new
> CacheConfiguration<>(CacheName.NETWORK_CACHE.name
> ());
> networkCacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> networkCacheCfg.setWriteThrough(false);
> networkCacheCfg.setReadThrough(true);
> networkCacheCfg.setRebalanceMode(CacheRebalanceMode.ASYNC);
>
> networkCacheCfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> //networkCacheCfg.setBackups(3);
> networkCacheCfg.setCacheMode(CacheMode.REPLICATED);
> Factory storeFactory =
> FactoryBuilder.factoryOf(NetworkDataCacheLoader.class);
> networkCacheCfg.setCacheStoreFactory(storeFactory);
> networkCacheCfg.setIndexedTypes(DefaultDataAffinityKey.class,
> NetworkData.class);networkCacheCfg.setSqlIndexMaxInlineSize(65);
> RendezvousAffinityFunction affinityFunction = new
> RendezvousAffinityFunction();
> affinityFunction.setExcludeNeighbors(false);
> networkCacheCfg.setAffinity(affinityFunction);
> networkCacheCfg.setStatisticsEnabled(true); //
> networkCacheCfg.setNearConfiguration(nearCacheConfiguration());
> return
> networkCacheCfg; }*
>
> @Override
> public V load(K k) throws CacheLoaderException {
> V value = null;
> DataSource dataSource = springCtx.getBean(DataSource.class);
> try (Connection connection = dataSource.getConnection();
> PreparedStatement statement =
> connection.prepareStatement(loadByKeySql)) {
> //statement.setObject(1, k.getId());
> setPreparedStatement(statement,k);
> try (ResultSet rs = statement.executeQuery()) {
> if (rs.next()) {
> value = rowMapper.mapRow(rs, 0);
> }
> }
> } catch (SQLException e) {
>
> throw new CacheLoaderException(e.getMessage(), e);
> }
>
>
Re: Task is ready for review
Hi Artsiom, I replied in the ticket [1]. [1] https://issues.apache.org/jira/browse/IGNITE-12610 Best regards, Ivan Pavlukhin ср, 26 февр. 2020 г. в 19:04, Artsiom Panko : > > Hello everyone. Task 12610 > (https://issues.apache.org/jira/browse/IGNITE-12610) is ready for review >
Re: NodeOrder in GridCacheVersion
Hi,
* How do you ensure that there are no concurrent updates on the keys?
[Prasad]: The cache for which it is failing is kind of bootstrap cache
which changes very rarely. I made sure that I was the only one working on
this system while debugging the issue.
The cache for which it is failing is REPLICATED cache. Read through is
enabled and Write through is disabled. Whenever I get an update message for
these caches from different system, I update an entry in my cache using
following steps.
1. First Remove an entry from the cache using cache.remove() method.
2. Read the entry from cache using cache().get method, which reads the data
from oracle db using read through approach.
* How many retry attempts did you run?
[Prasad] I retried the transaction 8-10 times.
* Are your caches in-memory with eviction policy?
[Prasad] Yes, caches are in-memory but without eviction policy. I am using
Oracle DB as a third party persistence. Ignite native persistence is
disabled.
* Do you have TTL enabled for either of the caches?
[Prasad]: No, I have not set TTL.
* Do you have a 3rd-party persistence and read-through and write-through
enabled for either of the caches?
[Prasad]: Yes, I have 3rd Party persistence. I have read-through caches but
for all read-through caches write through is disabled. The write-through is
disabled for some caches as I am not the owner of these tables. I also have
Write through caches but for all such caches read-through is disabled. At
this moment I do not have any cache where read-through and write-through
both are enabled. I reload the all my caches using cache loaders.
* Can you check if the issue reproduces if you set
-DIGNITE_READ_LOAD_BALANCING=false system property?
[Prasad]: Sure will try to reproduce this using this parameter. But the
problem is this happens intermittently.
As per the following code, serReadVer is the GridCache version of
transaction co-ordinator node which it compares with grid cache version of
other nodes.
So as per your explanation, nodeOrder is unique number assigned to each
node joins the grid. So each node in cluster will have a different
nodeOrder. If this is the case then "serReadVer.equals(ver)" will always
return false.
Please correct me if I am wrong. I just trying to understand the code.
This will help me to identify the issue.
*public boolean checkSerializableReadVersion(GridCacheVersion
serReadVer)throws GridCacheEntryRemovedException {
lockEntry();try {checkObsolete();*
*if (!serReadVer.equals(ver)) {boolean empty =
isStartVersion() || deletedUnlocked();*
*if
(serReadVer.equals(IgniteTxEntry.SER_READ_EMPTY_ENTRY_VER))
return empty;else if
(serReadVer.equals(IgniteTxEntry.SER_READ_NOT_EMPTY_VER))
return !empty;return false;}return
true;}finally {unlockEntry();}}*
Thanks,
Prasad
On Fri, Feb 28, 2020 at 2:24 PM Alexey Goncharuk
wrote:
> Prasad,
>
>
>> Can you please answer following questions?
>> 1) The significance of the nodeOrder w.r.t Grid and cache?
>>
> Node order is a unique integer assigned to a node when the node joins
> grid. The node order is included into GridCacheVersion to disambiguate
> versions generated on different nodes that happen to have the same local
> version order.
>
>> 2) When does it change?
>>
> Node order does not change during the node lifetime. If two versions have
> different node order, it means that the versions were generated on
> different nodes.
>
>> 3) How it is important w.r.t. transaction?
>>
> GridCacheVersion is used to detect concurrent read-write conflicts as I
> described in the previous message, as well as for data rebalance.
>
>> 4) Inside transaction I am reading and modifying Replicated as well as
>> Partitioned cache. What I observed is this fails for Replicated cache. As
>> workaround, I have moved the code which reads Replicated cache out of
>> transaction block. Is it allowed to read and modify both replicated and
>> Partitioned cache i.e. use both Replicated and Partitioned?
>>
> Yes, this is perfectly fine to update replicated and transactional caches
> inside one transaction.
>
> From the debug output that you provided we can infer that the version of
> both entries have changed for both caches before transaction prepare phase.
> I would back up Alexei here:
> * How do you ensure that there are no concurrent updates on the keys?
> * How many retry attempts did you run?
> * Are your caches in-memory with eviction policy?
> * Do you have TTL enabled for either of the caches?
> * Do you have a 3rd-party persistence and read-through and write-through
> enabled for either of the caches?
> * Can you check if the issue reproduces if you set
> -DIGNITE_READ_LOAD_BALANCING=false system property?
>
> --AG
>
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
I guest those links on CI are visible to only Release Manager, mostly PMCs from Apache Ignite. > On 28 Feb 2020, at 11:58, Pavel Tupitsyn wrote: > > Sergey, can't confirm, those links work for me > > On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov > wrote: > >> Hello, Maxim! >> >> All your links to ci.ignite.apache.org/ return 404 http code. It's okay? >> >> чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : >> >>> Igniters, >>> >>> >>> I've prepared everything to start a vote. >>> Are we ready to go on? >>> >>> >>> I have uploaded a release candidate to: >>> https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ >>> https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ >>> >>> The following staging can be used for testing: >>> https://repository.apache.org/content/repositories/orgapacheignite-1474/ >>> >>> Tag with name 2.8.0-rc1 created: >>> >>> >> https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 >>> >>> >>> TC [Check RC: Licenses, compile, chksum] >>> >>> >> https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv >>> >>> TC [3] Build & Upload Nuget Staging Packages >>> >>> >> https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv >>> >>> TC [2] Compare w/ Previous Release >>> >>> >> https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv >>> >>> On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn >> wrote: Maxim, Fixes are in ignite-2.8 now, and builds have passed [1]. I think we can proceed. Thank you and sorry for the broken build. [1] >>> >> https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn >>> wrote: > I'm running a final check in branch ignite-2.8-dotnet-build-fix, >>> should be > done soon. > After that I'll merge the changes into ignite-2.8 (and backport to > master), and we can proceed. > > I had to fix both TC project and the build script. > There were a few regressions introduced by various recent changes. > >> Can you also provide some details - which exactly artefacts should >> I > check on staging resource after the [1] suite execution? > We are supposed to verify that NuGet packages are valid by installing >>> them > and starting Ignite. > However, we added an automatic check recently: `Run NuGet >> verification > script` build step. > So the only thing to check is that new package appears on MyGet [1] > (scroll down to see versions and dates) > > [1] > >>> >> https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov >>> wrote: > >> Pavel, >> >> >> Thank you for your help. >> Please, let me know when I can proceed with a vote preparation. >> >> >> Can you also provide some details - which exactly artefacts should I >> check on staging resource after the [1] suite execution? >> >> [1] >> >>> >> https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages >> >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn >> wrote: >>> >>> Maxim, I did a quick fix for the script, but it did not work. >>> Investigating further, will get back to you later today. >>> >>> On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < >> mmu...@apache.org >> wrote: Pavel, Can you assist me with preparing NuGet staging according to the release steps [1]? I've double-checked everything related to the >>> build but suite [2] for preparing nuget package still fails (sorry for running it multiple times). I see some issues in the log which may be related to the file >> copy >>> in the build script which recently changed [4]. I'm still digging in, but anyway can you take a look and help? Step 2: Copy-Item : Cannot find path >> >>> >> 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because it does not exist. Step 3: Cannot find path >> >>> >> 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core\bin\Release\Apache.Ignite.Core.dll' because it does not exist. At >> >>> >> C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\build.ps1:283
RE: Apache Ignite 2.8 RELEASE [Time, Scope, Manager] [I]
Classification: For internal use only Hi, I can confirm. I also see: 404 You do not have enough permissions to access project with internal id: project20 i.e for this link: https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv Kind regards, Sergey Kosarev -Original Message- From: Pavel Tupitsyn [mailto:ptupit...@apache.org] Sent: 28 February 2020 11:58 To: dev Subject: Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager] Sergey, can't confirm, those links work for me On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov wrote: > Hello, Maxim! > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > Igniters, > > > > > > I've prepared everything to start a vote. > > Are we ready to go on? > > > > > > I have uploaded a release candidate to: > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > The following staging can be used for testing: > > https://repository.apache.org/content/repositories/orgapacheignite-1 > > 474/ > > > > Tag with name 2.8.0-rc1 created: > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8 > abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId= > ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=build > ResultsDiv > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId= > ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResul > tsDiv > > > > TC [2] Compare w/ Previous Release > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId= > ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=build > ResultsDiv > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > wrote: > > > > > > Maxim, > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > I think we can proceed. > > > > > > Thank you and sorry for the broken build. > > > > > > [1] > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJav > a8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > > > > wrote: > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > should be > > > > done soon. > > > > After that I'll merge the changes into ignite-2.8 (and backport > > > > to master), and we can proceed. > > > > > > > > I had to fix both TC project and the build script. > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > Can you also provide some details - which exactly artefacts > > > > > should > I > > > > check on staging resource after the [1] suite execution? > > > > We are supposed to verify that NuGet packages are valid by > > > > installing > > them > > > > and starting Ignite. > > > > However, we added an automatic check recently: `Run NuGet > verification > > > > script` build step. > > > > So the only thing to check is that new package appears on MyGet > > > > [1] (scroll down to see versions and dates) > > > > > > > > [1] > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache. > Ignite > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > > > > > wrote: > > > > > > > >> Pavel, > > > >> > > > >> > > > >> Thank you for your help. > > > >> Please, let me know when I can proceed with a vote preparation. > > > >> > > > >> > > > >> Can you also provide some details - which exactly artefacts > > > >> should I check on staging resource after the [1] suite execution? > > > >> > > > >> [1] > > > >> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteRel > easeJava8_PrepareVote3BuildNuGetPackages > > > >> > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > >> > > > >> wrote: > > > >> > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > >> > Investigating further, will get back to you later today. > > > >> > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > mmu...@apache.org > > > > > > >> wrote: > > > >> >> > > > >> >> Pavel, > > > >> >> > > > >> >> > > > >> >> Can you assist me with preparing NuGet staging according to > > > >> >> the release steps [1]? I've double-checked everything > > > >> >> related to the > > build > > > >> >> but suite [2] for preparing nuget package still fails (sorry > > > >> >> for running it multiple times). > > > >> >> > > > >> >> I see some issues in the log which may be related to the > > > >> >> file > copy > > in > > > >> >> the build script which recently changed [4]. > > > >> >> I'm still digging in, but anyway can you take a look and help? > > > >> >> > > >
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Sergey, can't confirm, those links work for me On Thu, Feb 27, 2020 at 11:17 PM Sergey Antonov wrote: > Hello, Maxim! > > All your links to ci.ignite.apache.org/ return 404 http code. It's okay? > > чт, 27 февр. 2020 г. в 19:06, Maxim Muzafarov : > > > Igniters, > > > > > > I've prepared everything to start a vote. > > Are we ready to go on? > > > > > > I have uploaded a release candidate to: > > https://dist.apache.org/repos/dist/dev/ignite/2.8.0-rc1/ > > https://dist.apache.org/repos/dist/dev/ignite/packages_2.8.0-rc1/ > > > > The following staging can be used for testing: > > https://repository.apache.org/content/repositories/orgapacheignite-1474/ > > > > Tag with name 2.8.0-rc1 created: > > > > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=commit;h=341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 > > > > > > TC [Check RC: Licenses, compile, chksum] > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085462&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum&tab=buildResultsDiv > > > > TC [3] Build & Upload Nuget Staging Packages > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085460&buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages&tab=buildResultsDiv > > > > TC [2] Compare w/ Previous Release > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=5085458&buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency&tab=buildResultsDiv > > > > On Wed, 26 Feb 2020 at 22:44, Pavel Tupitsyn > wrote: > > > > > > Maxim, > > > > > > Fixes are in ignite-2.8 now, and builds have passed [1]. > > > I think we can proceed. > > > > > > Thank you and sorry for the broken build. > > > > > > [1] > > > > > > https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages/5083539?buildTab=overview > > > > > > On Wed, Feb 26, 2020 at 8:46 PM Pavel Tupitsyn > > wrote: > > > > > > > I'm running a final check in branch ignite-2.8-dotnet-build-fix, > > should be > > > > done soon. > > > > After that I'll merge the changes into ignite-2.8 (and backport to > > > > master), and we can proceed. > > > > > > > > I had to fix both TC project and the build script. > > > > There were a few regressions introduced by various recent changes. > > > > > > > > > Can you also provide some details - which exactly artefacts should > I > > > > check on staging resource after the [1] suite execution? > > > > We are supposed to verify that NuGet packages are valid by installing > > them > > > > and starting Ignite. > > > > However, we added an automatic check recently: `Run NuGet > verification > > > > script` build step. > > > > So the only thing to check is that new package appears on MyGet [1] > > > > (scroll down to see versions and dates) > > > > > > > > [1] > > > > > > > https://www.myget.org/feed/apache-ignite-staging/package/nuget/Apache.Ignite > > > > > > > > > > > > On Wed, Feb 26, 2020 at 7:42 PM Maxim Muzafarov > > wrote: > > > > > > > >> Pavel, > > > >> > > > >> > > > >> Thank you for your help. > > > >> Please, let me know when I can proceed with a vote preparation. > > > >> > > > >> > > > >> Can you also provide some details - which exactly artefacts should I > > > >> check on staging resource after the [1] suite execution? > > > >> > > > >> [1] > > > >> > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages > > > >> > > > >> On Wed, 26 Feb 2020 at 10:46, Pavel Tupitsyn > > > >> wrote: > > > >> > > > > >> > Maxim, I did a quick fix for the script, but it did not work. > > > >> > Investigating further, will get back to you later today. > > > >> > > > > >> > On Tue, Feb 25, 2020 at 10:10 PM Maxim Muzafarov < > mmu...@apache.org > > > > > > >> wrote: > > > >> >> > > > >> >> Pavel, > > > >> >> > > > >> >> > > > >> >> Can you assist me with preparing NuGet staging according to the > > > >> >> release steps [1]? I've double-checked everything related to the > > build > > > >> >> but suite [2] for preparing nuget package still fails (sorry for > > > >> >> running it multiple times). > > > >> >> > > > >> >> I see some issues in the log which may be related to the file > copy > > in > > > >> >> the build script which recently changed [4]. > > > >> >> I'm still digging in, but anyway can you take a look and help? > > > >> >> > > > >> >> > > > >> >> Step 2: > > > >> >> Copy-Item : Cannot find path > > > >> >> > > > >> > > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core.dll'because > > > >> >> it does not exist. > > > >> >> > > > >> >> Step 3: > > > >> >> Cannot find path > > > >> >> > > > >> > > > 'C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\Apache.Ignite.Core\bin\Release\Apache.Ignite.Core.dll' > > > >> >> because it does not exist. > > > >> >> At > > > >> > > > C:\BuildAgent\work\3722fcb3466a49e6\src\modules\platforms\dotnet\build.ps1:283 > > > >> >> char:47 > > > >> >> > > > >> >> pack: invalid ar
Re: NodeOrder in GridCacheVersion
Prasad, > Can you please answer following questions? > 1) The significance of the nodeOrder w.r.t Grid and cache? > Node order is a unique integer assigned to a node when the node joins grid. The node order is included into GridCacheVersion to disambiguate versions generated on different nodes that happen to have the same local version order. > 2) When does it change? > Node order does not change during the node lifetime. If two versions have different node order, it means that the versions were generated on different nodes. > 3) How it is important w.r.t. transaction? > GridCacheVersion is used to detect concurrent read-write conflicts as I described in the previous message, as well as for data rebalance. > 4) Inside transaction I am reading and modifying Replicated as well as > Partitioned cache. What I observed is this fails for Replicated cache. As > workaround, I have moved the code which reads Replicated cache out of > transaction block. Is it allowed to read and modify both replicated and > Partitioned cache i.e. use both Replicated and Partitioned? > Yes, this is perfectly fine to update replicated and transactional caches inside one transaction. >From the debug output that you provided we can infer that the version of both entries have changed for both caches before transaction prepare phase. I would back up Alexei here: * How do you ensure that there are no concurrent updates on the keys? * How many retry attempts did you run? * Are your caches in-memory with eviction policy? * Do you have TTL enabled for either of the caches? * Do you have a 3rd-party persistence and read-through and write-through enabled for either of the caches? * Can you check if the issue reproduces if you set -DIGNITE_READ_LOAD_BALANCING=false system property? --AG
