[jira] [Created] (IGNITE-13861) Add logical/physical reads checks to existing tests
Amelchev Nikita created IGNITE-13861: Summary: Add logical/physical reads checks to existing tests Key: IGNITE-13861 URL: https://issues.apache.org/jira/browse/IGNITE-13861 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Assignee: Amelchev Nikita Add logical/physical reads checks to existing tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13860) Provide the tool to build cluster performance report
Amelchev Nikita created IGNITE-13860: Summary: Provide the tool to build cluster performance report Key: IGNITE-13860 URL: https://issues.apache.org/jira/browse/IGNITE-13860 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Assignee: Amelchev Nikita Provide the tool to build cluster performance report -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [5791268] needs to be handled
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. *New Critical Failure in master Platform .NET (Long Running) https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetLongRunning?branch=%3Cdefault%3E Changes may lead to failure were done by - denis magda https://ci.ignite.apache.org/viewModification.html?modId=912182 - denis magda https://ci.ignite.apache.org/viewModification.html?modId=912178 - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 05:51:02 16-12-2020
[MTCGA]: new failures in builds [5790819] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master Cache (Restarts) 1 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 02:21:05 16-12-2020
Re: Move WAL archive cleanup from checkpoint to rollover
Kirill, thanks for adding motivation to the issue description. On Wed, Dec 9, 2020 at 5:24 PM Andrey Gura wrote: > > Kiriill, > > Issue description contains the following: > > > At the moment, WAL archive is cleared at the end of the checkpoint, which > > does not seem correct and needs to be moved > > Could you please explain why existing behavior is not correct. It > seems that it is not enough motivation for change. > > On Wed, Dec 9, 2020 at 5:05 PM vbm wrote: > > > > Hi Kirill Tkalenko, > > > > Is there any relation to rate of ingestion of data to ignite ? > > > > We had seen the issue of WAL growing infinitely recently in our K8s cluster. > > We were ingesting data at around 2Mbps. > > In other clusters where we did not have such a fast ingestion of data, this > > issue was not observed. > > > > > > Regards, > > Vishwas > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: [DISCUSSION] Unified Configuration for Ignite 3.0
Thanks, Sergey! Looks good to me. -Val On Tue, Dec 15, 2020 at 12:12 AM Sergey Chugunov wrote: > Val, > > Your comments make total sense to me, I've fixed them and updated pull > request. Please take a look at my code when you have time. > > I also added a port range configuration to enable starting multiple > instances of ignite without specifying port manually for each instance. > > -- > Best Regards, > Sergey Chugunov > > On Sat, Dec 12, 2020 at 3:20 AM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > > > Hi Sergey, > > > > Thanks for doing this. > > > > It looks like PR #5 is already under review, so I guess it will be merged > > soon. I would really love to see that, because the configuration > framework > > is one of the foundational components - we need it to continue building > > Ignite 3.0. > > > > As for PR #6, it looks a little raw, but I believe we need it to connect > > the configuration framework with the CLI tool that is also pending for > the > > merge, is this correct? If that's the case, I think it's OK to merge this > > code as a separate module, with an understanding that it will change > > significantly down the road. I would do a couple of changes though: > > > >1. Get rid of "simplistic-ignite" naming, as it's a little confusing. > >Even though it's more of a prototype at this point, it should be clear > > what > >the module is responsible for. Can we rename it to "ignite-runner" or > >something along those lines? > >2. Update the output - I don't like that it prints out the > >Javalin's banner and messages. I suggest replacing this with some very > >basic Ignite logging: an entry showing the version of Ignite; an entry > >indicating that the REST protocol is enabled on a certain port; an > entry > >that the process is successfully started. This is just to make sure > that > >anyone who plays with it understands what's going on. > > > > Any objections? > > > > -Val > > > > On Fri, Dec 11, 2020 at 9:53 AM Sergey Chugunov < > sergey.chugu...@gmail.com > > > > > wrote: > > > > > Hello Igniters, > > > > > > I would like to present two pull requests [1], [2] with basic > > > implementation of IEP-55 for Unified Configuration [3] and IEP-63 REST > > API > > > for Unified Configuration [4]. > > > > > > The main goal of these PRs is to present and discuss a new approach for > > > preparing and managing Ignite configuration in a more robust and > > convenient > > > way than it was before. > > > > > > These PRs cover basic aspects of configuration but other steps for > > > developing functionality are already defined; ticket IGNITE-13511 [5] > > > summarizes work to do. > > > > > > In a nutshell proposed approach to configuration is as follows: > > > > > > We want to declare configuration with POJO-based schemas that are > concise > > > and contain all important information about validation and how > different > > > pieces of configuration relate to each other. > > > When schemas are marked with annotations annotation processor enters > the > > > game and generates most of boilerplate code thus freeing users from > > writing > > > it by hand. > > > > > > REST API module from [2] contains an example of managing configuration > > and > > > exposing it to external tools like a Unified CLI tool presented in [6]. > > > > > > [1] https://github.com/apache/ignite-3/pull/5 > > > [2] https://github.com/apache/ignite-3/pull/6 > > > [3] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration > > > [4] > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-63%3A+REST+API+module+to+integrate+new+modular+architecture+and+management > > > [5] https://issues.apache.org/jira/browse/IGNITE-13511 > > > [6] > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Unified-CLI-tool-td50618.html > > > > > >
[MTCGA]: new failures in builds [5790744] needs to be handled
Hi Igniters, I've detected some new issue on TeamCity to be handled. You are more than welcomed to help. *New Critical Failure in master-nightly MVCC Cache 7 https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_MvccCache7?branch=%3Cdefault%3E No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 21:51:05 15-12-2020
Re: [VOTE] Release Apache Ignite 2.9.1 RC1
Hi Yaroslav, Do we need to update documentation? - Denis On Mon, Dec 14, 2020 at 11:34 PM Yaroslav Molochkov wrote: > Dear Community, > > I have uploaded release candidate to > https://dist.apache.org/repos/dist/dev/ignite/2.9.1-rc1/ > https://dist.apache.org/repos/dist/dev/ignite/packages_2.9.1-rc1/ > > The following staging can be used for testing: > https://repository.apache.org/content/repositories/orgapacheignite-1490/ > > Tag name is 2.9.1-rc1: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.9.1-rc1 > > 2.9.1 changes: > * Added support to graceful shutdown for ZookeeperDiscoverySpi > * Added System view for binary metadata > * Added System view for metastorage items > * Added RebalancingPartitionsTotal metrics > * Improved checkpoint concurrent behaviour > * Fixed critical system error when unregister a JMX bean > * Fixed IgniteCache#isClosed() returns false on server node even if the > cache had been closed before > * Fixed inability to eagerly remove expired cache entries > * Fixed partial index rebuild issue in case indexed cache contains > different datatypes > * Fixed local metastorage system view error if unmarshallable values > present > * Fixed deadlock between grid-timeout-worker and a thread opening a > communication connection > * Fixed deadlock in IgniteServiceProcessor > * Fixed issue when rebalance future might hang in no final state though all > partitions are owned > * Fixed issue when scan query fails with an assertion error: Unexpected row > key > * Fixed issue with archiving and enabled wal compaction setting on server > restart > * Fixed NPE during Cassandra Store initialization with PRIMITIVE strategy > * Fixed synchronization problems when different classloaders are used for > deployment of same class > * Fixed exception on SQL caches when client reconnect > * Fixed deadlock on multiple cache delete > * Fixed NPE in IgniteServiceProcessor when destroying a cache > * Fixed issue when DurableBackgroundTask can abandon incomplete task > * Fixed issue related to cache interceptor deserialization on client nodes > * Fixed issue when control.sh doesn't start if JMX port was set > * Fixed issue when ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return > invalid node as coordinator > * Fixed issue when valid blocking section in GridNioWorker and > GridNioClientWorker leads to false positive blocking thread detection > * Fixed several logging issues > * Fixed issue when exchange worker, waiting for new task from queue, > considered as blocked > * Fixed incorrect topology snapshot logger output about coordinator change > * Fixed slowdown during node initialization > * Fixed incorrect usage of Class.isAssignableFrom in SystemViewLocal and > SystemViewMBean classes > * Fixed several concurrent metrics issues > * Fixed issue related to incorrect work of predicates (< and >) in where > clause with compound primary key > * Removed unnecessary dependency to curator-client from and improved > ZookeeperDiscoverySpi > * Removed unnecessary failure trace in IgnitionEx > * Fixed issue when thin client connect/disconnect during topology update > may lead to partition divergence in ignite-sys-cache > * Fixed issue when thin client silently closes channel after inactivity > * Fixed unsupported protocol version exception when getting cache > configuration from Java thin client > * Fixed thin driver reports incorrect property names > * Updated JDBC metadata to match actual capabilities > * Improved slow Enum serialization > * Fixed issue when deserializing IBinaryObject containing an IBinaryObject > field fails > * Fixed issue TransactionImpl finalizer can crash the process > * Fixed child processes become zombies when persistence is used with > direct-io on Linux > * Added Windows support to CMake build system > * Fixed issue when odbc-example loses values if run with 1 additional node > > RELEASE NOTES: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;hb=ignite-2.9.1 > > Complete list of resolved issues: > > https://issues.apache.org/jira/browse/IGNITE-13770?jql=project%20%3D%20IGNITE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%202.9.1 > > DEVNOTES > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.9.1 > > The vote is formal, see voting guidelines > https://www.apache.org/foundation/voting.html > > +1 - to accept Apache Ignite 2.9.1-rc1 > 0 - don't care either way > -1 - DO NOT accept Apache Ignite Ignite 2.9.1-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 > > This vote will be open for at least 3 days till Fri Dec 18, 10:30 am UTC. > > https://www.timeanddate.com/countdown/generic?iso=20201218T1030=166=cursive >
[jira] [Created] (IGNITE-13859) .NET: Build scripts and instructions cleanup
Pavel Tupitsyn created IGNITE-13859: --- Summary: .NET: Build scripts and instructions cleanup Key: IGNITE-13859 URL: https://issues.apache.org/jira/browse/IGNITE-13859 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn The one and only build script is *build.ps1*. * Remove *build-mono.sh* - Ignite does not work properly under Mono * Change *build.sh* to delegate to *build.ps1* same way as *build.bat* does * Update *build.ps1* to work by default on Linux/macOS: instead of looking for Mono msbuild, simply skip .NET Framework build part and print a warning along the lines of ".NET Core build succeeded. Full Ignite.NET build requires Windows and .NET Framework 4.x.". Using msbuild from Mono produces incorrect results anyway. * Update README files accordingly -- This message was sent by Atlassian Jira (v8.3.4#803005)
[ANNOUNCE] Java 11 is target version for Ignite 3.0 development
Igniters, JFYI According to discussion [1] there are no any objections to usage of Java 11 for Ignite 3 development as target Java language and platform version. So pom.xml for Ignite 3 is already updated. 1. http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Java-11-for-Ignite-3-0-development-td50534.html
[jira] [Created] (IGNITE-13858) Enabling near cache on a client node may lead to blocking eviction on server nodes
Vyacheslav Koptilin created IGNITE-13858: Summary: Enabling near cache on a client node may lead to blocking eviction on server nodes Key: IGNITE-13858 URL: https://issues.apache.org/jira/browse/IGNITE-13858 Project: Ignite Issue Type: Bug Affects Versions: 2.9, 2.8, 2.9.1 Reporter: Vyacheslav Koptilin When Native Persistence is off, creating near-cache on client node enforces (to be more accurate, near-cache entries) to maintain a list client node ids (aka readers) per-entry basis. Unfortunately, this list is not cleaned even though the eviction policy is configured on the near cache. Moreover, such entries cannot be evicted on the server-side, with corresponding pages, and this may lead to hanging cache operations. Originally discussed at user-list: http://apache-ignite-users.70518.x6.nabble.com/Apache-Ignite-Clientside-NearCache-and-Serverside-Eviction-blocking-cluster-tt34645.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
I don't believe Java 7 was LTS, and I hope that others will have upgraded long before that. If that is the release timeframe for 3.0, then I suppose that would makes sense, I would still doubt that people would be going newer than java 11, just my opinion of what I'm seeing. Regards ~adam Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies Office: 603-501-6446 | Mobile: 603-570-8418 www.bottomline.com On 12/15/20, 4:25 AM, "Ilya Kasnacheev" wrote: Hello! I guess Ignite 3.0 will be ready for production use somewhere in 2022, realistically. By that time, Java 8 will be long enough out of support so that most companies will actually forbid its use, WRT vulnerabilities et all. After all we have managed to upgrade from Java 7 to Java 8 and only got a minor amount of complaints. Regards, -- Ilya Kasnacheev пн, 14 дек. 2020 г. в 19:06, Carbone, Adam : > So just one bit to consider... Are there features that you need to use in > these newer versions of java? Or are we just updating to stay current? The > reason I ask is that there are still lots of people in an enterprise space > that are beholden to having to support legacy JAVAEE supported applications > on Websphere, Weblogic, Redhat, etc... and the organizations that use those > platforms are slow to move... Most of them are still on Java8 > > So as a platform I think a strong consideration needs to be towards having > the broadest possible support profile until it becomes an impediment to > doing things that the platform needs. So far I haven't seen huge things in > the newer versions of java that are must haves ( a few exceptions are > things that would be really nice to take advantage of ). > > I think that apache commons has taken the right approach by staying on > java 8 giving the largest possible user base. > > Even standardizing on java 11 would have to make us reconsider Ignite as > the platform we are using, we are not so invested in it as of now, even > though we have big plans to leverage it. Just because we aren't sure when > we are going to be able to upgrade from java8. It has support through 2022, > so I imagine that is when we will be discussing that. > > Regards > > ~Adam > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > Bottomline Technologies > Office: 603-501-6446 | Mobile: 603-570-8418 > www.bottomline.com > > > > On 11/24/20, 7:38 AM, "Alexey Zinoviev" wrote: > > Java 15 is better, VarHandles, ForeignMemory access and so on. > > In both cases, I support the Java version 11 and higher for the > development! > > вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov < > andrey.mashen...@gmail.com>: > > > Let's add maven plugins for sanity checks at the early stage. > > I've created a ticket for this [1]. > > > > Also, I've found initial pom.xml has a target version Java 8. > > Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 > in > > Ignite 3.0? > > > > [1] > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/IGNITE-13751__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKAO2Ejs8$ > > > > On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Folks, > > > > > > I went ahead and created the repository [1]. I also configured a > TeamCity > > > project [2] that runs all available JUnit tests on every PR > creation or > > > update. It also sends the status update to GitHub so that it's > reflected > > in > > > the PR itself so that we can do merges directly from GitHub. Basic > steps > > to > > > make a change are described on the Wiki page [3]. > > > > > > Let me know if you have any questions. > > > > > > [1] > https://urldefense.com/v3/__https://github.com/apache/ignite-3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKIq24lxF$ > > > [2] > https://urldefense.com/v3/__https://ci.ignite.apache.org/project/ignite3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKFGL_oJx$ > > > [3] > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0*ApacheIgnite3.0-DevelopmentProcess__;Kysj!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKNhWzQ0s$ > > > > > > -Val > > > > > > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko < > > > valentin.kuliche...@gmail.com> wrote: > > >
Re: [VOTE] Release Apache Ignite 2.9.1 RC1
Hello! +1 (binding) Checked that dotnet & C++ build from source. (NB it's not obvious what to do next when dotnet node is built, but it's the same in 2.9.0) Checked that dotnet & C++ node starts from a slim binary. Checked that deb package installs & service starts. Checked sqlline from slim assembly together with that node. Checked that rpm package installs (docker fedora:latest) Checked that the version of slim & source packages is 2.9.1 Regards, -- Ilya Kasnacheev вт, 15 дек. 2020 г. в 10:34, Yaroslav Molochkov : > Dear Community, > > I have uploaded release candidate to > https://dist.apache.org/repos/dist/dev/ignite/2.9.1-rc1/ > https://dist.apache.org/repos/dist/dev/ignite/packages_2.9.1-rc1/ > > The following staging can be used for testing: > https://repository.apache.org/content/repositories/orgapacheignite-1490/ > > Tag name is 2.9.1-rc1: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.9.1-rc1 > > 2.9.1 changes: > * Added support to graceful shutdown for ZookeeperDiscoverySpi > * Added System view for binary metadata > * Added System view for metastorage items > * Added RebalancingPartitionsTotal metrics > * Improved checkpoint concurrent behaviour > * Fixed critical system error when unregister a JMX bean > * Fixed IgniteCache#isClosed() returns false on server node even if the > cache had been closed before > * Fixed inability to eagerly remove expired cache entries > * Fixed partial index rebuild issue in case indexed cache contains > different datatypes > * Fixed local metastorage system view error if unmarshallable values > present > * Fixed deadlock between grid-timeout-worker and a thread opening a > communication connection > * Fixed deadlock in IgniteServiceProcessor > * Fixed issue when rebalance future might hang in no final state though all > partitions are owned > * Fixed issue when scan query fails with an assertion error: Unexpected row > key > * Fixed issue with archiving and enabled wal compaction setting on server > restart > * Fixed NPE during Cassandra Store initialization with PRIMITIVE strategy > * Fixed synchronization problems when different classloaders are used for > deployment of same class > * Fixed exception on SQL caches when client reconnect > * Fixed deadlock on multiple cache delete > * Fixed NPE in IgniteServiceProcessor when destroying a cache > * Fixed issue when DurableBackgroundTask can abandon incomplete task > * Fixed issue related to cache interceptor deserialization on client nodes > * Fixed issue when control.sh doesn't start if JMX port was set > * Fixed issue when ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return > invalid node as coordinator > * Fixed issue when valid blocking section in GridNioWorker and > GridNioClientWorker leads to false positive blocking thread detection > * Fixed several logging issues > * Fixed issue when exchange worker, waiting for new task from queue, > considered as blocked > * Fixed incorrect topology snapshot logger output about coordinator change > * Fixed slowdown during node initialization > * Fixed incorrect usage of Class.isAssignableFrom in SystemViewLocal and > SystemViewMBean classes > * Fixed several concurrent metrics issues > * Fixed issue related to incorrect work of predicates (< and >) in where > clause with compound primary key > * Removed unnecessary dependency to curator-client from and improved > ZookeeperDiscoverySpi > * Removed unnecessary failure trace in IgnitionEx > * Fixed issue when thin client connect/disconnect during topology update > may lead to partition divergence in ignite-sys-cache > * Fixed issue when thin client silently closes channel after inactivity > * Fixed unsupported protocol version exception when getting cache > configuration from Java thin client > * Fixed thin driver reports incorrect property names > * Updated JDBC metadata to match actual capabilities > * Improved slow Enum serialization > * Fixed issue when deserializing IBinaryObject containing an IBinaryObject > field fails > * Fixed issue TransactionImpl finalizer can crash the process > * Fixed child processes become zombies when persistence is used with > direct-io on Linux > * Added Windows support to CMake build system > * Fixed issue when odbc-example loses values if run with 1 additional node > > RELEASE NOTES: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;hb=ignite-2.9.1 > > Complete list of resolved issues: > > https://issues.apache.org/jira/browse/IGNITE-13770?jql=project%20%3D%20IGNITE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%202.9.1 > > DEVNOTES > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.9.1 > > The vote is formal, see voting guidelines > https://www.apache.org/foundation/voting.html > > +1 - to accept Apache Ignite 2.9.1-rc1 > 0 - don't care either way > -1 - DO NOT accept Apache Ignite Ignite 2.9.1-rc1 (explain why) > > See notes on how to verify release
Re: [VOTE] Release Apache Ignite 2.9.1 RC1
+1 (binding) (Built Ignite.NET from sources, started from binary package, checked examples) On Tue, Dec 15, 2020 at 10:34 AM Yaroslav Molochkov wrote: > Dear Community, > > I have uploaded release candidate to > https://dist.apache.org/repos/dist/dev/ignite/2.9.1-rc1/ > https://dist.apache.org/repos/dist/dev/ignite/packages_2.9.1-rc1/ > > The following staging can be used for testing: > https://repository.apache.org/content/repositories/orgapacheignite-1490/ > > Tag name is 2.9.1-rc1: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=tag;h=refs/tags/2.9.1-rc1 > > 2.9.1 changes: > * Added support to graceful shutdown for ZookeeperDiscoverySpi > * Added System view for binary metadata > * Added System view for metastorage items > * Added RebalancingPartitionsTotal metrics > * Improved checkpoint concurrent behaviour > * Fixed critical system error when unregister a JMX bean > * Fixed IgniteCache#isClosed() returns false on server node even if the > cache had been closed before > * Fixed inability to eagerly remove expired cache entries > * Fixed partial index rebuild issue in case indexed cache contains > different datatypes > * Fixed local metastorage system view error if unmarshallable values > present > * Fixed deadlock between grid-timeout-worker and a thread opening a > communication connection > * Fixed deadlock in IgniteServiceProcessor > * Fixed issue when rebalance future might hang in no final state though all > partitions are owned > * Fixed issue when scan query fails with an assertion error: Unexpected row > key > * Fixed issue with archiving and enabled wal compaction setting on server > restart > * Fixed NPE during Cassandra Store initialization with PRIMITIVE strategy > * Fixed synchronization problems when different classloaders are used for > deployment of same class > * Fixed exception on SQL caches when client reconnect > * Fixed deadlock on multiple cache delete > * Fixed NPE in IgniteServiceProcessor when destroying a cache > * Fixed issue when DurableBackgroundTask can abandon incomplete task > * Fixed issue related to cache interceptor deserialization on client nodes > * Fixed issue when control.sh doesn't start if JMX port was set > * Fixed issue when ZookeeperDiscoverySpiMBeanImpl#getCoordinator can return > invalid node as coordinator > * Fixed issue when valid blocking section in GridNioWorker and > GridNioClientWorker leads to false positive blocking thread detection > * Fixed several logging issues > * Fixed issue when exchange worker, waiting for new task from queue, > considered as blocked > * Fixed incorrect topology snapshot logger output about coordinator change > * Fixed slowdown during node initialization > * Fixed incorrect usage of Class.isAssignableFrom in SystemViewLocal and > SystemViewMBean classes > * Fixed several concurrent metrics issues > * Fixed issue related to incorrect work of predicates (< and >) in where > clause with compound primary key > * Removed unnecessary dependency to curator-client from and improved > ZookeeperDiscoverySpi > * Removed unnecessary failure trace in IgnitionEx > * Fixed issue when thin client connect/disconnect during topology update > may lead to partition divergence in ignite-sys-cache > * Fixed issue when thin client silently closes channel after inactivity > * Fixed unsupported protocol version exception when getting cache > configuration from Java thin client > * Fixed thin driver reports incorrect property names > * Updated JDBC metadata to match actual capabilities > * Improved slow Enum serialization > * Fixed issue when deserializing IBinaryObject containing an IBinaryObject > field fails > * Fixed issue TransactionImpl finalizer can crash the process > * Fixed child processes become zombies when persistence is used with > direct-io on Linux > * Added Windows support to CMake build system > * Fixed issue when odbc-example loses values if run with 1 additional node > > RELEASE NOTES: > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob;f=RELEASE_NOTES.txt;hb=ignite-2.9.1 > > Complete list of resolved issues: > > https://issues.apache.org/jira/browse/IGNITE-13770?jql=project%20%3D%20IGNITE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%202.9.1 > > DEVNOTES > > https://gitbox.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=ignite-2.9.1 > > The vote is formal, see voting guidelines > https://www.apache.org/foundation/voting.html > > +1 - to accept Apache Ignite 2.9.1-rc1 > 0 - don't care either way > -1 - DO NOT accept Apache Ignite Ignite 2.9.1-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 > > This vote will be open for at least 3 days till Fri Dec 18, 10:30 am UTC. > > https://www.timeanddate.com/countdown/generic?iso=20201218T1030=166=cursive >
[GitHub] [ignite-3] kgusakov opened a new pull request #8: IGNITE-13857 Update java version to 11
kgusakov opened a new pull request #8: URL: https://github.com/apache/ignite-3/pull/8 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IGNITE-13857) Update Ignite-3.0 java to 11 version
Kirill Gusakov created IGNITE-13857: --- Summary: Update Ignite-3.0 java to 11 version Key: IGNITE-13857 URL: https://issues.apache.org/jira/browse/IGNITE-13857 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Assignee: Kirill Gusakov According to discussion [http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Java-11-for-Ignite-3-0-development-td50534.html] we should update java version in ignite-3 repo to 11 version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13856) Superlinear performance of DirectByteBufferStreamImplV2.writeMessage(msg, writer)
Ilya Kazakov created IGNITE-13856:
-
Summary: Superlinear performance of
DirectByteBufferStreamImplV2.writeMessage(msg, writer)
Key: IGNITE-13856
URL: https://issues.apache.org/jira/browse/IGNITE-13856
Project: Ignite
Issue Type: Improvement
Components: binary
Affects Versions: 2.9
Reporter: Ilya Kazakov
Assignee: Ilya Kazakov
Attachments: LongStringSQL.java
{code:java}
@Override public void writeMessage(Message msg, MessageWriter writer) {
if (msg != null) {
if (buf.hasRemaining()) {
try {
writer.beforeInnerMessageWrite()
writer.setCurrentWriteClass(msg.getClass());
lastFinished = msg.writeTo(buf, writer);
}
finally {
writer.afterInnerMessageWrite(lastFinished);
}
}
}
}{code}
It is going to do multiple invocations of msg.writeTo(). If msg is
GridH2String, it will to val.getBytes() on every invocation of writeTo(),
leading to spiking of CPU and RAM usage.
We should change this module to make sure that all serialization happens only
once.
Reproducer is attached. If we increase string size in 10 times, then the
execution time increases more than 10 times.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13855) Integration with micrometer.io as part of integration with spring-boot
Tanmay Ambre created IGNITE-13855:
-
Summary: Integration with micrometer.io as part of integration
with spring-boot
Key: IGNITE-13855
URL: https://issues.apache.org/jira/browse/IGNITE-13855
Project: Ignite
Issue Type: Wish
Components: general
Affects Versions: 2.9
Reporter: Tanmay Ambre
hi,
I run Ignite server nodes as Spring-boot applications. We use actuator,
micrometer and prometheus meter registries for monitoring.
I implemented a new MetricExporterSpi to push metrics as gauges in micrometer.
So that we can easily monitor the metrics using our prometheus-grafana
dashboards. However, the problem is the MetricExporterSpi never gets attached.
Reason for that is as follows:
# I use an xml file to configure ignite.
# After I do Ignition.start(configFilePath) - I perform
ignite.configuration().setMetricExporterSpi(). - however, after this call the
spiStart method of the MetricExporterSpi is not called.
# If I configure ExporterSpi in the ignite config xml file - the exporterSpi
lifecycle methods are invoked as part of Ignition.start(). But then I can't
inject the micrometer registry in my custom ExporterSpi.
# If i call the spi.start() manually - it doesnt work because the
setReadOnlyMetricRegistry is not invoked.
Any suggestions? I can use Opencensus - and then export metrics to Prometheus -
however - this would require me to start a HTTP Server inside ignite. This can
be become cumbersome when deployed in container mode (on K8S, Openshift, etc).
Code of my IgniteConfig is shown below
{quote}@Configuration
public class IgniteConfig
{
@Autowired
ApplicationConfig applicationConfig;
@Autowired
MicrometerMetricsExporterSpi mmes;
@Bean
public Ignite ignite()
{
Ignite igniteInstance =
Ignition.start(applicationConfig.getIgniteConfig().getConfigFile());
MetricExporterSpi[] metricSpis =
igniteInstance.configuration().getMetricExporterSpi();
igniteInstance.configuration().setMetricExporterSpi(mmes);
if (applicationConfig.getIgniteConfig().isAutoActivateCluster())
{
igniteInstance.cluster().state(ClusterState.ACTIVE);
}
return igniteInstance;
}
}{quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [DISCUSS] Ignite 3.0 development approach
Hello! I guess Ignite 3.0 will be ready for production use somewhere in 2022, realistically. By that time, Java 8 will be long enough out of support so that most companies will actually forbid its use, WRT vulnerabilities et all. After all we have managed to upgrade from Java 7 to Java 8 and only got a minor amount of complaints. Regards, -- Ilya Kasnacheev пн, 14 дек. 2020 г. в 19:06, Carbone, Adam : > So just one bit to consider... Are there features that you need to use in > these newer versions of java? Or are we just updating to stay current? The > reason I ask is that there are still lots of people in an enterprise space > that are beholden to having to support legacy JAVAEE supported applications > on Websphere, Weblogic, Redhat, etc... and the organizations that use those > platforms are slow to move... Most of them are still on Java8 > > So as a platform I think a strong consideration needs to be towards having > the broadest possible support profile until it becomes an impediment to > doing things that the platform needs. So far I haven't seen huge things in > the newer versions of java that are must haves ( a few exceptions are > things that would be really nice to take advantage of ). > > I think that apache commons has taken the right approach by staying on > java 8 giving the largest possible user base. > > Even standardizing on java 11 would have to make us reconsider Ignite as > the platform we are using, we are not so invested in it as of now, even > though we have big plans to leverage it. Just because we aren't sure when > we are going to be able to upgrade from java8. It has support through 2022, > so I imagine that is when we will be discussing that. > > Regards > > ~Adam > > Adam Carbone | Director of Innovation – Intelligent Platform Team | > Bottomline Technologies > Office: 603-501-6446 | Mobile: 603-570-8418 > www.bottomline.com > > > > On 11/24/20, 7:38 AM, "Alexey Zinoviev" wrote: > > Java 15 is better, VarHandles, ForeignMemory access and so on. > > In both cases, I support the Java version 11 and higher for the > development! > > вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov < > andrey.mashen...@gmail.com>: > > > Let's add maven plugins for sanity checks at the early stage. > > I've created a ticket for this [1]. > > > > Also, I've found initial pom.xml has a target version Java 8. > > Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 > in > > Ignite 3.0? > > > > [1] > https://urldefense.com/v3/__https://issues.apache.org/jira/browse/IGNITE-13751__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKAO2Ejs8$ > > > > On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Folks, > > > > > > I went ahead and created the repository [1]. I also configured a > TeamCity > > > project [2] that runs all available JUnit tests on every PR > creation or > > > update. It also sends the status update to GitHub so that it's > reflected > > in > > > the PR itself so that we can do merges directly from GitHub. Basic > steps > > to > > > make a change are described on the Wiki page [3]. > > > > > > Let me know if you have any questions. > > > > > > [1] > https://urldefense.com/v3/__https://github.com/apache/ignite-3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKIq24lxF$ > > > [2] > https://urldefense.com/v3/__https://ci.ignite.apache.org/project/ignite3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKFGL_oJx$ > > > [3] > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0*ApacheIgnite3.0-DevelopmentProcess__;Kysj!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKNhWzQ0s$ > > > > > > -Val > > > > > > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko < > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > Thanks, guys. It looks like we are much closer to the consensus > now. I > > > > totally on board with the plan, but I would also like to address > the > > > > short-term needs. As I've already mentioned earlier, there are > several > > > > active IEPs, but we still don't have even a preliminary technical > > process > > > > for working on these IEPs. I believe this might be frustrating > for the > > > > folks who would like to commit code. > > > > > > > > The scope we agreed on is quite big, and it will surely take > > significant > > > > time to implement all the changes and stabilize them. Therefore, > it's > > > clear > > > > to me that we will have to maintain 2.x and 3.x in parallel for > quite > > > some > > > > time - this needs to be addressed somehow. I'm convinced that > having a > > > > separate repo is the ONLY way
Re: [DISCUSSION] Unified Configuration for Ignite 3.0
Val, Your comments make total sense to me, I've fixed them and updated pull request. Please take a look at my code when you have time. I also added a port range configuration to enable starting multiple instances of ignite without specifying port manually for each instance. -- Best Regards, Sergey Chugunov On Sat, Dec 12, 2020 at 3:20 AM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Sergey, > > Thanks for doing this. > > It looks like PR #5 is already under review, so I guess it will be merged > soon. I would really love to see that, because the configuration framework > is one of the foundational components - we need it to continue building > Ignite 3.0. > > As for PR #6, it looks a little raw, but I believe we need it to connect > the configuration framework with the CLI tool that is also pending for the > merge, is this correct? If that's the case, I think it's OK to merge this > code as a separate module, with an understanding that it will change > significantly down the road. I would do a couple of changes though: > >1. Get rid of "simplistic-ignite" naming, as it's a little confusing. >Even though it's more of a prototype at this point, it should be clear > what >the module is responsible for. Can we rename it to "ignite-runner" or >something along those lines? >2. Update the output - I don't like that it prints out the >Javalin's banner and messages. I suggest replacing this with some very >basic Ignite logging: an entry showing the version of Ignite; an entry >indicating that the REST protocol is enabled on a certain port; an entry >that the process is successfully started. This is just to make sure that >anyone who plays with it understands what's going on. > > Any objections? > > -Val > > On Fri, Dec 11, 2020 at 9:53 AM Sergey Chugunov > > wrote: > > > Hello Igniters, > > > > I would like to present two pull requests [1], [2] with basic > > implementation of IEP-55 for Unified Configuration [3] and IEP-63 REST > API > > for Unified Configuration [4]. > > > > The main goal of these PRs is to present and discuss a new approach for > > preparing and managing Ignite configuration in a more robust and > convenient > > way than it was before. > > > > These PRs cover basic aspects of configuration but other steps for > > developing functionality are already defined; ticket IGNITE-13511 [5] > > summarizes work to do. > > > > In a nutshell proposed approach to configuration is as follows: > > > > We want to declare configuration with POJO-based schemas that are concise > > and contain all important information about validation and how different > > pieces of configuration relate to each other. > > When schemas are marked with annotations annotation processor enters the > > game and generates most of boilerplate code thus freeing users from > writing > > it by hand. > > > > REST API module from [2] contains an example of managing configuration > and > > exposing it to external tools like a Unified CLI tool presented in [6]. > > > > [1] https://github.com/apache/ignite-3/pull/5 > > [2] https://github.com/apache/ignite-3/pull/6 > > [3] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration > > [4] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-63%3A+REST+API+module+to+integrate+new+modular+architecture+and+management > > [5] https://issues.apache.org/jira/browse/IGNITE-13511 > > [6] > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Unified-CLI-tool-td50618.html > > >
Re: Removing MVCC public API
+1 Best regards, Alexander вт, 15 дек. 2020 г. в 10:59, Konstantin Orlov : > +1 > > -- > Regards, > Konstantin Orlov > Software Engineer, St. Petersburg > +7 (921) 445-65-75 > https://www.gridgain.com > Powered by Apache® Ignite™ > > > >
