[GitHub] [ignite-3] vkulichenko opened a new pull request #12: IGNITE-13894 - Improve look of the CLI tool
vkulichenko opened a new pull request #12: URL: https://github.com/apache/ignite-3/pull/12 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-13894) Improve look of the CLI tool
Valentin Kulichenko created IGNITE-13894: Summary: Improve look of the CLI tool Key: IGNITE-13894 URL: https://issues.apache.org/jira/browse/IGNITE-13894 Project: Ignite Issue Type: Sub-task Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Need to go through all the commands and fix/improve from usability improvement. This includes the following: * Names of commands, options, and parameters. * Command output. * Text colors and styles. * etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Allowing commits to a released branch for documentation purposes
Hi Peter, Thanks for reminding the nuances. It's been a while since I contributed to the codebase. Ok, then I think nobody will object that the docs will always be published from a release branch such as ignite-2.9.1 and then we can commit to the branch directly if 2.9.1 needs to be updated. Wrote this down in the docs contribution process: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document#HowtoDocument-PublishingtotheWebsite - Denis On Mon, Dec 21, 2020 at 10:40 PM Petr Ivanov wrote: > Hi, Denis. > > > Apache Ignite as other projects on Apache is in fact released from TAG, > not BRANCH (although they are similar at that point). > Thus — it seems that there should be no problem to continue using branch > as docs sources for the same release as long as TAG stays intact. > > We just have to document the process as it is, so there are no questions > about why the branch moved forward after release. > And possibly add some checks (on TC, for instance), that the changes in > released branches are only about documentation, and do not touch other part > of the project. > > > > > On 22 Dec 2020, at 00:47, Denis Magda wrote: > > > > Igniters, > > > > After we release a version, we create a docs-specific branch out of the > > release branch for inevitable documentation improvements (feedback; > generic > > changes that are committed to the master, and the last published > version). > > For instance, once 2.9 was released from the "ignite-2.9" branch, we > > created the "ignite-2.9-docs" branch whose content is published on the > > website (https://ignite.apache.org/docs/2.9.0/). The only reason why > > "ignite-2.9-docs" is created is to follow an internally defined process > > that prohibits commits to an already released branch such as > "ignite-2.9". > > > > Can we remove this restriction, at least for documentation changes? We're > > approaching the 2.9.1 release. The 2.9.1 docs will be published from the > > "ignite-2.9.1" branch as the rest of the release artifacts. Then, over > > time, we'll be improving the pages and need to publish changes for ignite > > 2.9.1 on the website (until it stays the latest released version). We'd > > like to cherry-pick those changes to "ignite-2.9.1" and not to create > > another branch such as "ignite-2.9.1-docs" for that. > > > > > > - > > Denis > >
[jira] [Created] (IGNITE-13893) Optimize memory usage on export performance statistics to JSON
Amelchev Nikita created IGNITE-13893: Summary: Optimize memory usage on export performance statistics to JSON Key: IGNITE-13893 URL: https://issues.apache.org/jira/browse/IGNITE-13893 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Optimize memory usage on export performance statistics to JSON -- This message was sent by Atlassian Jira (v8.3.4#803005)
[MTCGA]: new failures in builds [5799985] 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 test failure in master-nightly GracefulShutdownTest.testThatExcludedNodeListWithinMetastoreCleanedUpAfterUpdatingFullMap https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5225331494018995786=%3Cdefault%3E=testDetails 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:37:26 22-12-2020
[jira] [Created] (IGNITE-13892) Improve log message of start/stop performance statistics collection
Amelchev Nikita created IGNITE-13892: Summary: Improve log message of start/stop performance statistics collection Key: IGNITE-13892 URL: https://issues.apache.org/jira/browse/IGNITE-13892 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Improve log message of start/stop performance statistics collection -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13890) Remove zip-file with web-resources from the jar
Amelchev Nikita created IGNITE-13890: Summary: Remove zip-file with web-resources from the jar Key: IGNITE-13890 URL: https://issues.apache.org/jira/browse/IGNITE-13890 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Remove zip-file with web-resources from the jar -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13891) Provide the ability to configure performance report
Amelchev Nikita created IGNITE-13891: Summary: Provide the ability to configure performance report Key: IGNITE-13891 URL: https://issues.apache.org/jira/browse/IGNITE-13891 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Provide the ability to configure performance report: - maximum top slow operations - histograms bounds -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13889) Remove web-resources from the source of the performance report
Amelchev Nikita created IGNITE-13889: Summary: Remove web-resources from the source of the performance report Key: IGNITE-13889 URL: https://issues.apache.org/jira/browse/IGNITE-13889 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Remove web-resources from the source of the performance report -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13888) Provide the utility to output performance statistics operations to the console
Amelchev Nikita created IGNITE-13888: Summary: Provide the utility to output performance statistics operations to the console Key: IGNITE-13888 URL: https://issues.apache.org/jira/browse/IGNITE-13888 Project: Ignite Issue Type: Sub-task Reporter: Amelchev Nikita Provide the utility to output performance statistics operations to the console (to integrate with the other cmd tools) -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] 3.0.0 Alpha release
Ivan, Yes, you are correct - no tables, caches, compute or any other major features will be available. Alpha releases are generally produced in the middle of the development process for internal testing. In my view, that's exactly what the upcoming release is, but let me know if you have a better naming in mind. -Val On Tue, Dec 22, 2020 at 1:56 AM Ivan Pavlukhin wrote: > Hi, > > Is it right that suggested Alpha will not be able to perform any > operations with data (tables, caches)? In that case Alpha naming > confuses me. Actually do not know how such kind of demo releases > should be attributed. > > 2020-12-21 20:42 GMT+03:00, Denis Magda : > > Certainly, the end of Jan is more realistic and reasonable. Let's talk > this > > out offline and then put a session on the virtual meetup's schedule. > > > > - > > Denis > > > > > > On Sun, Dec 20, 2020 at 4:35 PM Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > >> Hi Denis, > >> > >> Sure, that's a great idea! I'm thinking, however, that it makes sense to > >> take a pause after the release and let people try it out on their own so > >> that the experience is as close to real-life as possible. How about > >> closer > >> to the end of January? > >> > >> -Val > >> > >> On Fri, Dec 18, 2020 at 8:53 PM Denis Magda wrote: > >> > >> > Hi Val, > >> > > >> > That's the pace, I'll be happy to play with the alpha and share > >> > feedback. > >> > Also, what if we arrange a community gathering after the holidays to > >> > demonstrate what alpha does and get more details from the involved > >> > contributors on what's coming next? > >> > > >> > As for the release process, yes, that needs to be a formal vote as > long > >> as > >> > you're publishing artifacts to Maven and updating the website with > >> > references to the binaries and documentation pages. > >> > > >> > > >> > - > >> > Denis > >> > > >> > > >> > On Fri, Dec 18, 2020 at 6:13 PM Valentin Kulichenko < > >> > valentin.kuliche...@gmail.com> wrote: > >> > > >> > > Igniters, > >> > > > >> > > The repository for Ignite 3.x [1] was created less than a month ago, > >> and > >> > we > >> > > already have several merged pull requests. Many thanks to everyone > >> > involved > >> > > for the contributions! > >> > > > >> > > Currently, we have the following functionality available in the main > >> > > branch: > >> > > > >> > >- New configuration framework which is compatible with the HOCON > >> > format. > >> > >- The “ignite-runner” module, which currently incorporates the > >> > >aforementioned configuration framework and REST endpoints to > >> interact > >> > > with > >> > >the framework. > >> > >- The first version of the unified CLI tool. > >> > > > >> > > This set of features does not include any actual Ignite APIs. > >> > > However, > >> it > >> > > clearly demonstrates the basic mechanics of how the product will be > >> > > installed and upgraded, how the user will interact with it, etc. I > >> would > >> > > like to use this to gather feedback from the community in the early > >> > stages. > >> > > > >> > > To make sure the experience is as close to real life as possible, I > >> want > >> > to > >> > > deliver what we have as an alpha release, meaning that all the > >> > > required > >> > > binaries will be deployed on the website and in Maven. There will > >> > > also > >> be > >> > > some basic documentation describing how to install and use the > >> > > product. > >> > > This way, anyone will be able to download the product and try it > out. > >> > > > >> > > My main question here -- do we need a formal vote for such a build? > >> > > Or > >> it > >> > > can be treated as a release candidate? > >> > > > >> > > Any other thoughts? > >> > > > >> > > [1] https://github.com/apache/ignite-3 > >> > > > >> > > -Val > >> > > > >> > > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
[jira] [Created] (IGNITE-13887) Checkpoint write lock missed during snapshot operation
Maxim Muzafarov created IGNITE-13887:
Summary: Checkpoint write lock missed during snapshot operation
Key: IGNITE-13887
URL: https://issues.apache.org/jira/browse/IGNITE-13887
Project: Ignite
Issue Type: Bug
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
{code:java}
2020-12-22 16:15:21.243 [INFO
][exchange-worker-#163%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.s.SnapshotFutureTask]
Snapshot operation is scheduled on local node and will be handled by the
checkpoint listener [sctx=SnapshotFutureTask
[pageStore=GridCacheSharedManagerAdapter [starting=true, stop=false],
srcNodeId=4f43f04d-3ca8-4f00-9d91-017d6ef285cd, snpName=backup01, tmpSnpWork
Dir=/ssd/snp/backup01,
locBuff=java.lang.ThreadLocal$SuppliedThreadLocal@6dc562dc,
ioFactory=org.apache.ignite.internal.processors.cache.persistence.f
ile.RandomAccessFileIOFactory@6b9dab32,
cpEndFut=java.util.concurrent.CompletableFuture@4e6e4123[Not completed],
startedFut=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null, h
ash=2127381016], tmpConsIdDir=/ssd/snp/backup01/db/10_116_69_218_47500,
closeFut=null, err=null, started=true], topVer=AffinityTopologyVersion [topVer
=16, minorTopVer=4]]
2020-12-22 16:15:21.385
[ERROR][db-checkpoint-thread-#232%DPL_GRID%DplGridNodeName%][org.apache.ignite.Ignite]
Critical system error detected. Will be handled accordingly to configured handl
er [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]]
, failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
err=java.lang.AssertionError]]
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTask$PageStoreSerialWriter.(SnapshotFutureTask.java:819)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotFutureTask.onMarkCheckpointBegin(SnapshotFutureTask.java:466)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3915)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:3515)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:3404)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
2020-12-22 16:15:21.418 [WARN
][db-checkpoint-thread-#232%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.CacheDiagnosticManager]
Page locks dump:
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Metastorage limitations
Hello, Anton. Thanks for the answer! > Only maybe, it makes sense to remove such records (with all history) instead > of filtering them. I don’t think we should do this, by default. Imagine scenario #1: 1. Update the plugin to the next bugged version. Some class that is written to the metastore is lost. 2. Remove the key from the metastore to fix current deployment. 3. Deploy updated plugin We will lose plugin information from metastore on step #3. If we want to make metastore more reliable we should provide some command to remove keys from it. This will fix scenario #2 when we migrate from one Ignite deployment to another and some keys become unused. > 22 дек. 2020 г., в 17:39, Anton Kalashnikov написал(а): > >> How it differs from the current implementation? > There are no differences in implementation. But according to the original > topic, plugins or other external things can write to metastore their own > classes. I just said that according to current architecture it is not a good > idea to do that because these POJO's are not from the core. > >> Why do you think that «good» solution should exist for this kind of issue? > I don't think so. I just emphasize my concern about local filtering(the usage > of system property) in this solution because it can lead to different > behavior on different nodes. But perhaps you are right, and for such bug we > can use a such solution. > >> Maybe we should make metastore fully lazy, so any stored key will not be >> deserialized before it explicitly queried. > I approximately meant the same. We should think about that. > > In conclusion(my opinions): > > In the current design, inside of plugins(etc.) it makes sense to use only > primitives or POJO's from the core. (This is my answer to the original topic) > It makes sense to think about serialization by demand inside of metastorage > rather than in the discovery. > I have no good solution for resolving the bug with removed classes. Perhaps, > we can use Nikolay's fix. Only maybe, it makes sense to remove such records > (with all history) instead of filtering them. > > -- > Best regards, > Anton Kalashnikov > > > > 22.12.2020, 14:44, "Nikolay Izhikov" : >> Hello, Anton. >> >>> or use the POJO from the ignite core. >> >> How it differs from the current implementation? >> >>> As I can see you have tests only for one node but what happens if >>> different nodes have different filters? >> >> The error will happen. >> >> Please, don’t forget that we are talking about two scenarios: >> >> 1. Blocker bug - we delete some class that was written to metastore from the >> new version. >> 2. Migration between custom Ignite distributions where one of them has a >> custom class and the other doesn’t. >> >> It’s a very rare incident in my experience. >> >> Why do you think that «good» solution should exist for this kind of issue? >> I don’t think we should limit internal architecture to cover these cases. >> >> Maybe we should make metastore fully lazy, so any stored key will not be >> deserialized before it explicitly queried. >> >>> 22 дек. 2020 г., в 14:30, Anton Kalashnikov написал(а): >>> >>> Hello everyone, >>> >>> In my opinion, it is indeed better to limit storing to the metastore by >>> primitive type(map or list are also possible) or use the POJO from the >>> ignite core. >>> As Kirill correctly notice, right now, it is a problem not inside of the >>> distributed metastore but inside of discovery. >>> In fact, we can rewrite the sending metastore data in such a way that the >>> discovery would think that there is just a simple byte array which >>> shouldn't be deserialized. Right now, it understands that it is a >>> serialized java object and it tries to deserialize it after receiving it. >>> But this way requires more investigation about possible corner cases. >>> >>> Nikolay, I also don't sure that your fix handles metastorage history >>> correctly. >>> As I can see you have tests only for one node but what happens if >>> different nodes have different filters? >>> or if we need to send history to the joining node but some of the keys >>> don't pass the filter? >>> Maybe I wrong but in the first eye, it can lead to different >>> results/histories on different nodes which is a problem. >>> I just briefly looked at your PR(so maybe I didn't understand something), >>> I will try to do it more carefully at the nearest time. >>> >>> -- >>> Best regards, >>> Anton Kalashnikov >>> >>> 18.12.2020, 15:33, "Mekhanikov Denis" : Nikolay, Thanks for your reply! I encountered a similar case to what you've described in point #1. I used a private plugin that writes some information to the metastorage. After that I decided to get rid of that plugin, while the information had already been written to the metastorage. Following the approach that you described and implemented in the PR, I'll need
Re: Metastorage limitations
> How it differs from the current implementation? There are no differences in implementation. But according to the original topic, plugins or other external things can write to metastore their own classes. I just said that according to current architecture it is not a good idea to do that because these POJO's are not from the core. > Why do you think that «good» solution should exist for this kind of issue? I don't think so. I just emphasize my concern about local filtering(the usage of system property) in this solution because it can lead to different behavior on different nodes. But perhaps you are right, and for such bug we can use a such solution. > Maybe we should make metastore fully lazy, so any stored key will not be > deserialized before it explicitly queried. I approximately meant the same. We should think about that. In conclusion(my opinions): In the current design, inside of plugins(etc.) it makes sense to use only primitives or POJO's from the core. (This is my answer to the original topic) It makes sense to think about serialization by demand inside of metastorage rather than in the discovery. I have no good solution for resolving the bug with removed classes. Perhaps, we can use Nikolay's fix. Only maybe, it makes sense to remove such records (with all history) instead of filtering them. -- Best regards, Anton Kalashnikov 22.12.2020, 14:44, "Nikolay Izhikov" : > Hello, Anton. > >> or use the POJO from the ignite core. > > How it differs from the current implementation? > >> As I can see you have tests only for one node but what happens if different >> nodes have different filters? > > The error will happen. > > Please, don’t forget that we are talking about two scenarios: > > 1. Blocker bug - we delete some class that was written to metastore from the > new version. > 2. Migration between custom Ignite distributions where one of them has a > custom class and the other doesn’t. > > It’s a very rare incident in my experience. > > Why do you think that «good» solution should exist for this kind of issue? > I don’t think we should limit internal architecture to cover these cases. > > Maybe we should make metastore fully lazy, so any stored key will not be > deserialized before it explicitly queried. > >> 22 дек. 2020 г., в 14:30, Anton Kalashnikov написал(а): >> >> Hello everyone, >> >> In my opinion, it is indeed better to limit storing to the metastore by >> primitive type(map or list are also possible) or use the POJO from the >> ignite core. >> As Kirill correctly notice, right now, it is a problem not inside of the >> distributed metastore but inside of discovery. >> In fact, we can rewrite the sending metastore data in such a way that the >> discovery would think that there is just a simple byte array which shouldn't >> be deserialized. Right now, it understands that it is a serialized java >> object and it tries to deserialize it after receiving it. But this way >> requires more investigation about possible corner cases. >> >> Nikolay, I also don't sure that your fix handles metastorage history >> correctly. >> As I can see you have tests only for one node but what happens if different >> nodes have different filters? >> or if we need to send history to the joining node but some of the keys >> don't pass the filter? >> Maybe I wrong but in the first eye, it can lead to different >> results/histories on different nodes which is a problem. >> I just briefly looked at your PR(so maybe I didn't understand something), I >> will try to do it more carefully at the nearest time. >> >> -- >> Best regards, >> Anton Kalashnikov >> >> 18.12.2020, 15:33, "Mekhanikov Denis" : >>> Nikolay, >>> >>> Thanks for your reply! >>> >>> I encountered a similar case to what you've described in point #1. I used >>> a private plugin that writes some information to the metastorage. >>> After that I decided to get rid of that plugin, while the information had >>> already been written to the metastorage. >>> Following the approach that you described and implemented in the PR, I'll >>> need to work with the flag to ignore certain keys in the metastorage >>> forever. That's quite inconvenient. >>> Wouldn't it be better if we just limited the set of allowed types that can >>> be stored in the metastorage? Instead of a POJO, a Map will be accepted. >>> >>> Denis >>> >>> On 18.12.2020, 13:59, "ткаленко кирилл" wrote: >>> >>> Hello everybody! >>> >>> If you look at the stackTrace, the error is that deserialized objects >>> are being sent to listeners. >>> It may be more correct to send a raw arrays of bytes, and each plugin >>> will be able to process it if needed. >>> >>> 18.12.2020, 12:18, "Nikolay Izhikov" : >>> > Hello, Denis. >>> > >>> > It’s a known issue for me. >>> > Metastore is a private API, isn’t it? >>> > AFAICU it can occur for two reasons: >>> > >>> > * User migrates from custom
[GitHub] [ignite-3] kgusakov opened a new pull request #11: IGNITE-13782 Add reinit support for corrupted installation
kgusakov opened a new pull request #11: URL: https://github.com/apache/ignite-3/pull/11 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-13886) Change units of cache-related histograms to milliseconds
Denis Mekhanikov created IGNITE-13886: - Summary: Change units of cache-related histograms to milliseconds Key: IGNITE-13886 URL: https://issues.apache.org/jira/browse/IGNITE-13886 Project: Ignite Issue Type: Improvement Reporter: Denis Mekhanikov Ignite has different metrics that have the "histogram" type: * tx.nodeSystemTimeHistogram * tx.nodeUserTimeHistogram * pme.DurationHistogram * pme.CacheOperationsBlockedDurationHistogram * cache..GetTime * cache..PutTime * cache..RemoveTime * cache..CommitTime * cache..RollbackTime First four have buckets corresponding to the amount of time the operation took in milliseconds. Cache-related histograms are measured in nanoseconds, while it would be enough to use milliseconds there as well. It's hard to distinguish between 1 and 10 nanoseconds visually. The following set of buckets should be used: * 1 * 10 * 100 * 250 * 1000 The values are provided in milliseconds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13885) Investigate jraft implementation for Ignite3 replication module based on RAFT protocol.
Alexey Scherbakov created IGNITE-13885: -- Summary: Investigate jraft implementation for Ignite3 replication module based on RAFT protocol. Key: IGNITE-13885 URL: https://issues.apache.org/jira/browse/IGNITE-13885 Project: Ignite Issue Type: Task Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 3.0 Investigation points: # Ease of custom RPC implementation. # Threading model fit. # Liveness guaranties [1] # State machine overload safety. [1] https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Metastorage limitations
Hello, Anton. > or use the POJO from the ignite core. How it differs from the current implementation? > As I can see you have tests only for one node but what happens if different > nodes have different filters? The error will happen. Please, don’t forget that we are talking about two scenarios: 1. Blocker bug - we delete some class that was written to metastore from the new version. 2. Migration between custom Ignite distributions where one of them has a custom class and the other doesn’t. It’s a very rare incident in my experience. Why do you think that «good» solution should exist for this kind of issue? I don’t think we should limit internal architecture to cover these cases. Maybe we should make metastore fully lazy, so any stored key will not be deserialized before it explicitly queried. > 22 дек. 2020 г., в 14:30, Anton Kalashnikov написал(а): > > Hello everyone, > > In my opinion, it is indeed better to limit storing to the metastore by > primitive type(map or list are also possible) or use the POJO from the ignite > core. > As Kirill correctly notice, right now, it is a problem not inside of the > distributed metastore but inside of discovery. > In fact, we can rewrite the sending metastore data in such a way that the > discovery would think that there is just a simple byte array which shouldn't > be deserialized. Right now, it understands that it is a serialized java > object and it tries to deserialize it after receiving it. But this way > requires more investigation about possible corner cases. > > Nikolay, I also don't sure that your fix handles metastorage history > correctly. > As I can see you have tests only for one node but what happens if different > nodes have different filters? > or if we need to send history to the joining node but some of the keys don't > pass the filter? > Maybe I wrong but in the first eye, it can lead to different > results/histories on different nodes which is a problem. > I just briefly looked at your PR(so maybe I didn't understand something), I > will try to do it more carefully at the nearest time. > > -- > Best regards, > Anton Kalashnikov > > > > 18.12.2020, 15:33, "Mekhanikov Denis" : >> Nikolay, >> >> Thanks for your reply! >> >> I encountered a similar case to what you've described in point #1. I used a >> private plugin that writes some information to the metastorage. >> After that I decided to get rid of that plugin, while the information had >> already been written to the metastorage. >> Following the approach that you described and implemented in the PR, I'll >> need to work with the flag to ignore certain keys in the metastorage >> forever. That's quite inconvenient. >> Wouldn't it be better if we just limited the set of allowed types that can >> be stored in the metastorage? Instead of a POJO, a Map will be accepted. >> >> Denis >> >> On 18.12.2020, 13:59, "ткаленко кирилл" wrote: >> >> Hello everybody! >> >> If you look at the stackTrace, the error is that deserialized objects >> are being sent to listeners. >> It may be more correct to send a raw arrays of bytes, and each plugin >> will be able to process it if needed. >> >> 18.12.2020, 12:18, "Nikolay Izhikov" : >> > Hello, Denis. >> > >> > It’s a known issue for me. >> > Metastore is a private API, isn’t it? >> > AFAICU it can occur for two reasons: >> > >> > * User migrates from custom Ignite fork that has private improvements >> or plugins that write to the metastore. >> > * We have a blocker bug and just remove some internal class that can >> be written into metastore from distribution. >> > >> > I planned to fix it with some system flag. >> > During startup administrator just sets a list of the metastore items >> that should be ignored. >> > Please, take a look at the PR [1] >> > >> > WDYT? >> > >> >> it’s better to limit the metastorage with storing primitives only >> > >> > I think that ability to write object is very useful and should stay. >> > >> > [1] https://github.com/apache/ignite/pull/8221 >> > >> >> 18 дек. 2020 г., в 12:06, Mekhanikov Denis >> написал(а): >> >> >> >> Hi everyone! >> >> >> >> Ignite has a limitation that it can’t work with custom classes put >> into metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 >> >> If you put a POJO into the metastorage, then Ignite will try to >> deserialize it using the classes it finds on the classpath. If it can’t do >> the deserialization, then the node will fail. >> >> >> >> There is an opinion that the metastorage wasn’t design for a case >> when classes that can disappear from Ignite distribution. >> >> If we follow this path, then it’s better to limit the metastorage >> with storing primitives only, so that it’s impossible to occasionally put >> anything breaking. >> >> If a piece of configuration is put into
[jira] [Created] (IGNITE-13884) Merge docs into 2.9.1
Yaroslav Molochkov created IGNITE-13884: --- Summary: Merge docs into 2.9.1 Key: IGNITE-13884 URL: https://issues.apache.org/jira/browse/IGNITE-13884 Project: Ignite Issue Type: Bug Components: documentation Reporter: Yaroslav Molochkov Assignee: Yaroslav Molochkov -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Metastorage limitations
Hello everyone, In my opinion, it is indeed better to limit storing to the metastore by primitive type(map or list are also possible) or use the POJO from the ignite core. As Kirill correctly notice, right now, it is a problem not inside of the distributed metastore but inside of discovery. In fact, we can rewrite the sending metastore data in such a way that the discovery would think that there is just a simple byte array which shouldn't be deserialized. Right now, it understands that it is a serialized java object and it tries to deserialize it after receiving it. But this way requires more investigation about possible corner cases. Nikolay, I also don't sure that your fix handles metastorage history correctly. As I can see you have tests only for one node but what happens if different nodes have different filters? or if we need to send history to the joining node but some of the keys don't pass the filter? Maybe I wrong but in the first eye, it can lead to different results/histories on different nodes which is a problem. I just briefly looked at your PR(so maybe I didn't understand something), I will try to do it more carefully at the nearest time. -- Best regards, Anton Kalashnikov 18.12.2020, 15:33, "Mekhanikov Denis" : > Nikolay, > > Thanks for your reply! > > I encountered a similar case to what you've described in point #1. I used a > private plugin that writes some information to the metastorage. > After that I decided to get rid of that plugin, while the information had > already been written to the metastorage. > Following the approach that you described and implemented in the PR, I'll > need to work with the flag to ignore certain keys in the metastorage forever. > That's quite inconvenient. > Wouldn't it be better if we just limited the set of allowed types that can be > stored in the metastorage? Instead of a POJO, a Map will be accepted. > > Denis > > On 18.12.2020, 13:59, "ткаленко кирилл" wrote: > > Hello everybody! > > If you look at the stackTrace, the error is that deserialized objects are > being sent to listeners. > It may be more correct to send a raw arrays of bytes, and each plugin > will be able to process it if needed. > > 18.12.2020, 12:18, "Nikolay Izhikov" : > > Hello, Denis. > > > > It’s a known issue for me. > > Metastore is a private API, isn’t it? > > AFAICU it can occur for two reasons: > > > > * User migrates from custom Ignite fork that has private improvements > or plugins that write to the metastore. > > * We have a blocker bug and just remove some internal class that can be > written into metastore from distribution. > > > > I planned to fix it with some system flag. > > During startup administrator just sets a list of the metastore items > that should be ignored. > > Please, take a look at the PR [1] > > > > WDYT? > > > >> it’s better to limit the metastorage with storing primitives only > > > > I think that ability to write object is very useful and should stay. > > > > [1] https://github.com/apache/ignite/pull/8221 > > > >> 18 дек. 2020 г., в 12:06, Mekhanikov Denis > написал(а): > >> > >> Hi everyone! > >> > >> Ignite has a limitation that it can’t work with custom classes put > into metastorage: https://issues.apache.org/jira/browse/IGNITE-13642 > >> If you put a POJO into the metastorage, then Ignite will try to > deserialize it using the classes it finds on the classpath. If it can’t do > the deserialization, then the node will fail. > >> > >> There is an opinion that the metastorage wasn’t design for a case when > classes that can disappear from Ignite distribution. > >> If we follow this path, then it’s better to limit the metastorage with > storing primitives only, so that it’s impossible to occasionally put anything > breaking. > >> If a piece of configuration is put into the metastorage by a plugin, > then the plugin will be in charge of deserializing the configuration, and not > Ignite. > >> > >> Alternatively we can try to fix the metastorage and make it ignore > deserialization errors when they occur. > >> > >> What do you think? > >> > >> Denis
[community] Apache Ignite 2021 wallpapers for desktop & mobile
Hi Igniters! New wallpapers are already in our special repository [1]. Some of them you can also use as zoom background during the calls. GridGain DevRel team wishes you happy holidays! [1] https://github.com/apache/ignite-website/tree/master/images/wallpapers/2021 -- Cheers, Kseniya Devrel at GridGain Don't miss upcoming community events, join https://www.meetup.com/Apache-Ignite-Virtual-Meetup/
Re: [DISCUSS] Ignite 3.0 development approach
Pavel, thanks for explanation! 2020-12-22 13:34 GMT+03:00, Pavel Tupitsyn : > Ivan, it is the new GitHub default > > "On Oct. 1, 2020, any new repositories you create will use main as the > default branch, instead of master" [1] > > [1] > https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/ > > On Tue, Dec 22, 2020 at 1:12 PM Ivan Pavlukhin wrote: > >> Also I noticed that ignite-3 repository has "main" but not "master" >> branch. Who can shed light on this? Did not find an explanation in >> this thread. >> >> 2020-12-22 13:09 GMT+03:00, Ivan Pavlukhin : >> > I noticed some free-from commit messages in ignite-3 repository. I >> > think we should use ticket-based workflow and commit messages as >> > usual. >> > >> > [1] https://github.com/apache/ignite-3/commits/main >> > >> > 2020-12-21 10:55 GMT+03:00, Petr Ivanov : >> >> There is no problem to have both in new repository, if skilled >> enthusiast >> >> will take over that job. >> >> >> >> I guess we will stick to Maven for time being but development of >> >> Gradle-based building system can be done in parallel. >> >> I can even add corresponding development build configurations for >> >> TeamCity, >> >> or even introduce some kind of switch — so that we can test old and >> >> new >> >> build approaches and provide seamless transition if we agree on that. >> >> >> >>> On 19 Dec 2020, at 01:00, Valentin Kulichenko >> >>> wrote: >> >>> >> >>> Hi Ivan, >> >>> >> >>> There was a very brief discussion around this. Basically, it looks >> >>> like >> >>> switching from Maven to something else is not going to bring much >> value, >> >>> but at the same time will be quite demanding because the community >> >>> has >> >>> much >> >>> more experience with Maven. However, I would say that it is still >> >>> debatable at this point -- please feel free to share your thoughts on >> >>> this. >> >>> >> >>> -Val >> >>> >> >>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin >> >>> wrote: >> >>> >> Hi Igniters, >> >> Forgive me that I am not reading dev list carefully these days. Was >> it >> explicitly decided that Maven should be used as a build system for >> Ignite 3? As there is a new repository we possibly can update our >> build tools as well. What do you think? >> >> 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko < >> valentin.kuliche...@gmail.com>: >> > Hi Dmitriy, >> > >> > I don't think there is any reason for concern at this point. The >> community >> > agreed on the scope of the changes for 3.0 - it is described on >> > Wiki. >> > The >> > scope is quite big, so it is clear that 2.x and 3.x will have to >> exist >> > in >> > parallel for a significant amount of time, so we need a place where >> we >> can >> > merge the code for 3.x. Thus, I've created this new repo. We >> > already >> > have >> > multiple IEPs, as well as several contributors who are actively >> > involved >> in >> > development. Some of the first PRs were merged today. >> > >> > I didn't hear any objections since the repo was created. >> > >> > -Val >> > >> > On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov >> wrote: >> > >> >> Folks, I'm a little bit concerned about the simultaneous >> >> - existence of the repo https://github.com/apache/ignite-3 and PRs >> >> for >> >> that >> >> repo >> >> - and a couple of downvotes from PMC members. >> >> >> >> Is it all fine here? Was there any vote /discussion where it was >> >> discussed >> >> and consensus approved? What is the status of the ignite-3 repo? >> >> >> >> вт, 15 дек. 2020 г. в 17:30, Carbone, Adam >> >> > > : >> >> >> >>> 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" < >> ilya.kasnach...@gmail.com> >> >>> 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
Re: [DISCUSS] Ignite 3.0 development approach
Ivan, it is the new GitHub default "On Oct. 1, 2020, any new repositories you create will use main as the default branch, instead of master" [1] [1] https://www.zdnet.com/article/github-to-replace-master-with-main-starting-next-month/ On Tue, Dec 22, 2020 at 1:12 PM Ivan Pavlukhin wrote: > Also I noticed that ignite-3 repository has "main" but not "master" > branch. Who can shed light on this? Did not find an explanation in > this thread. > > 2020-12-22 13:09 GMT+03:00, Ivan Pavlukhin : > > I noticed some free-from commit messages in ignite-3 repository. I > > think we should use ticket-based workflow and commit messages as > > usual. > > > > [1] https://github.com/apache/ignite-3/commits/main > > > > 2020-12-21 10:55 GMT+03:00, Petr Ivanov : > >> There is no problem to have both in new repository, if skilled > enthusiast > >> will take over that job. > >> > >> I guess we will stick to Maven for time being but development of > >> Gradle-based building system can be done in parallel. > >> I can even add corresponding development build configurations for > >> TeamCity, > >> or even introduce some kind of switch — so that we can test old and new > >> build approaches and provide seamless transition if we agree on that. > >> > >>> On 19 Dec 2020, at 01:00, Valentin Kulichenko > >>> wrote: > >>> > >>> Hi Ivan, > >>> > >>> There was a very brief discussion around this. Basically, it looks like > >>> switching from Maven to something else is not going to bring much > value, > >>> but at the same time will be quite demanding because the community has > >>> much > >>> more experience with Maven. However, I would say that it is still > >>> debatable at this point -- please feel free to share your thoughts on > >>> this. > >>> > >>> -Val > >>> > >>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin > >>> wrote: > >>> > Hi Igniters, > > Forgive me that I am not reading dev list carefully these days. Was it > explicitly decided that Maven should be used as a build system for > Ignite 3? As there is a new repository we possibly can update our > build tools as well. What do you think? > > 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > > Hi Dmitriy, > > > > I don't think there is any reason for concern at this point. The > community > > agreed on the scope of the changes for 3.0 - it is described on Wiki. > > The > > scope is quite big, so it is clear that 2.x and 3.x will have to > exist > > in > > parallel for a significant amount of time, so we need a place where > we > can > > merge the code for 3.x. Thus, I've created this new repo. We already > > have > > multiple IEPs, as well as several contributors who are actively > > involved > in > > development. Some of the first PRs were merged today. > > > > I didn't hear any objections since the repo was created. > > > > -Val > > > > On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov > wrote: > > > >> Folks, I'm a little bit concerned about the simultaneous > >> - existence of the repo https://github.com/apache/ignite-3 and PRs > >> for > >> that > >> repo > >> - and a couple of downvotes from PMC members. > >> > >> Is it all fine here? Was there any vote /discussion where it was > >> discussed > >> and consensus approved? What is the status of the ignite-3 repo? > >> > >> вт, 15 дек. 2020 г. в 17:30, Carbone, Adam > >> > : > >> > >>> 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" < > ilya.kasnach...@gmail.com> > >>> 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 < > >>>
Re: [DISCUSS] Ignite 3.0 development approach
Also I noticed that ignite-3 repository has "main" but not "master" branch. Who can shed light on this? Did not find an explanation in this thread. 2020-12-22 13:09 GMT+03:00, Ivan Pavlukhin : > I noticed some free-from commit messages in ignite-3 repository. I > think we should use ticket-based workflow and commit messages as > usual. > > [1] https://github.com/apache/ignite-3/commits/main > > 2020-12-21 10:55 GMT+03:00, Petr Ivanov : >> There is no problem to have both in new repository, if skilled enthusiast >> will take over that job. >> >> I guess we will stick to Maven for time being but development of >> Gradle-based building system can be done in parallel. >> I can even add corresponding development build configurations for >> TeamCity, >> or even introduce some kind of switch — so that we can test old and new >> build approaches and provide seamless transition if we agree on that. >> >>> On 19 Dec 2020, at 01:00, Valentin Kulichenko >>> wrote: >>> >>> Hi Ivan, >>> >>> There was a very brief discussion around this. Basically, it looks like >>> switching from Maven to something else is not going to bring much value, >>> but at the same time will be quite demanding because the community has >>> much >>> more experience with Maven. However, I would say that it is still >>> debatable at this point -- please feel free to share your thoughts on >>> this. >>> >>> -Val >>> >>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin >>> wrote: >>> Hi Igniters, Forgive me that I am not reading dev list carefully these days. Was it explicitly decided that Maven should be used as a build system for Ignite 3? As there is a new repository we possibly can update our build tools as well. What do you think? 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > Hi Dmitriy, > > I don't think there is any reason for concern at this point. The community > agreed on the scope of the changes for 3.0 - it is described on Wiki. > The > scope is quite big, so it is clear that 2.x and 3.x will have to exist > in > parallel for a significant amount of time, so we need a place where we can > merge the code for 3.x. Thus, I've created this new repo. We already > have > multiple IEPs, as well as several contributors who are actively > involved in > development. Some of the first PRs were merged today. > > I didn't hear any objections since the repo was created. > > -Val > > On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov wrote: > >> Folks, I'm a little bit concerned about the simultaneous >> - existence of the repo https://github.com/apache/ignite-3 and PRs >> for >> that >> repo >> - and a couple of downvotes from PMC members. >> >> Is it all fine here? Was there any vote /discussion where it was >> discussed >> and consensus approved? What is the status of the ignite-3 repo? >> >> вт, 15 дек. 2020 г. в 17:30, Carbone, Adam >> : >> >>> 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 < >>> adam.carb...@bottomline.com>: >>> 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
Re: [DISCUSS] Ignite 3.0 development approach
I noticed some free-from commit messages in ignite-3 repository. I think we should use ticket-based workflow and commit messages as usual. [1] https://github.com/apache/ignite-3/commits/main 2020-12-21 10:55 GMT+03:00, Petr Ivanov : > There is no problem to have both in new repository, if skilled enthusiast > will take over that job. > > I guess we will stick to Maven for time being but development of > Gradle-based building system can be done in parallel. > I can even add corresponding development build configurations for TeamCity, > or even introduce some kind of switch — so that we can test old and new > build approaches and provide seamless transition if we agree on that. > >> On 19 Dec 2020, at 01:00, Valentin Kulichenko >> wrote: >> >> Hi Ivan, >> >> There was a very brief discussion around this. Basically, it looks like >> switching from Maven to something else is not going to bring much value, >> but at the same time will be quite demanding because the community has >> much >> more experience with Maven. However, I would say that it is still >> debatable at this point -- please feel free to share your thoughts on >> this. >> >> -Val >> >> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin >> wrote: >> >>> Hi Igniters, >>> >>> Forgive me that I am not reading dev list carefully these days. Was it >>> explicitly decided that Maven should be used as a build system for >>> Ignite 3? As there is a new repository we possibly can update our >>> build tools as well. What do you think? >>> >>> 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko < >>> valentin.kuliche...@gmail.com>: Hi Dmitriy, I don't think there is any reason for concern at this point. The >>> community agreed on the scope of the changes for 3.0 - it is described on Wiki. The scope is quite big, so it is clear that 2.x and 3.x will have to exist in parallel for a significant amount of time, so we need a place where we >>> can merge the code for 3.x. Thus, I've created this new repo. We already have multiple IEPs, as well as several contributors who are actively involved >>> in development. Some of the first PRs were merged today. I didn't hear any objections since the repo was created. -Val On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov >>> wrote: > Folks, I'm a little bit concerned about the simultaneous > - existence of the repo https://github.com/apache/ignite-3 and PRs for > that > repo > - and a couple of downvotes from PMC members. > > Is it all fine here? Was there any vote /discussion where it was > discussed > and consensus approved? What is the status of the ignite-3 repo? > > вт, 15 дек. 2020 г. в 17:30, Carbone, Adam > >>> : > >> 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 < >> adam.carb...@bottomline.com>: >> >>> 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
Re: [DISCUSS] Notifications for ignite-3 repository
Ticket was merged. Thanks to all participants. 2020-12-21 10:12 GMT+03:00, Ivan Pavlukhin : > Folks, > > I will merge the PR tomorrow if there is no objections. > > 2020-12-19 0:56 GMT+03:00, Valentin Kulichenko > : >> Folks, >> >> Can someone take a look at this PR? I'm generally OK with the change, but >> I'm not familiar with the mechanisms used here. >> >> -Val >> >> On Thu, Dec 17, 2020 at 11:16 PM Ivan Pavlukhin >> wrote: >> >>> Igniters, >>> >>> I noticed notifications about PRs in ignite-3 repository sent to >>> dev-list. I suppose we should configure notifications similar to main >>> ignite repository. I prepared a ticket [1] and PR for this. Please >>> review. >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-13875 >>> >>> -- >>> >>> Best regards, >>> Ivan Pavlukhin >>> >> > > > -- > > Best regards, > Ivan Pavlukhin > -- Best regards, Ivan Pavlukhin
[GitHub] [ignite-3] pavlukhin merged pull request #10: IGNITE-13875 Configure notifications for ignite-3 git repository
pavlukhin merged pull request #10: URL: https://github.com/apache/ignite-3/pull/10 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
Re: [DISCUSSION] 3.0.0 Alpha release
Hi, Is it right that suggested Alpha will not be able to perform any operations with data (tables, caches)? In that case Alpha naming confuses me. Actually do not know how such kind of demo releases should be attributed. 2020-12-21 20:42 GMT+03:00, Denis Magda : > Certainly, the end of Jan is more realistic and reasonable. Let's talk this > out offline and then put a session on the virtual meetup's schedule. > > - > Denis > > > On Sun, Dec 20, 2020 at 4:35 PM Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> Hi Denis, >> >> Sure, that's a great idea! I'm thinking, however, that it makes sense to >> take a pause after the release and let people try it out on their own so >> that the experience is as close to real-life as possible. How about >> closer >> to the end of January? >> >> -Val >> >> On Fri, Dec 18, 2020 at 8:53 PM Denis Magda wrote: >> >> > Hi Val, >> > >> > That's the pace, I'll be happy to play with the alpha and share >> > feedback. >> > Also, what if we arrange a community gathering after the holidays to >> > demonstrate what alpha does and get more details from the involved >> > contributors on what's coming next? >> > >> > As for the release process, yes, that needs to be a formal vote as long >> as >> > you're publishing artifacts to Maven and updating the website with >> > references to the binaries and documentation pages. >> > >> > >> > - >> > Denis >> > >> > >> > On Fri, Dec 18, 2020 at 6:13 PM Valentin Kulichenko < >> > valentin.kuliche...@gmail.com> wrote: >> > >> > > Igniters, >> > > >> > > The repository for Ignite 3.x [1] was created less than a month ago, >> and >> > we >> > > already have several merged pull requests. Many thanks to everyone >> > involved >> > > for the contributions! >> > > >> > > Currently, we have the following functionality available in the main >> > > branch: >> > > >> > >- New configuration framework which is compatible with the HOCON >> > format. >> > >- The “ignite-runner” module, which currently incorporates the >> > >aforementioned configuration framework and REST endpoints to >> interact >> > > with >> > >the framework. >> > >- The first version of the unified CLI tool. >> > > >> > > This set of features does not include any actual Ignite APIs. >> > > However, >> it >> > > clearly demonstrates the basic mechanics of how the product will be >> > > installed and upgraded, how the user will interact with it, etc. I >> would >> > > like to use this to gather feedback from the community in the early >> > stages. >> > > >> > > To make sure the experience is as close to real life as possible, I >> want >> > to >> > > deliver what we have as an alpha release, meaning that all the >> > > required >> > > binaries will be deployed on the website and in Maven. There will >> > > also >> be >> > > some basic documentation describing how to install and use the >> > > product. >> > > This way, anyone will be able to download the product and try it out. >> > > >> > > My main question here -- do we need a formal vote for such a build? >> > > Or >> it >> > > can be treated as a release candidate? >> > > >> > > Any other thoughts? >> > > >> > > [1] https://github.com/apache/ignite-3 >> > > >> > > -Val >> > > >> > >> > -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-13883) .NET: Performance: Refactor BinarySystemHandlers.TryReadSystemType to switch-case
Pavel Tupitsyn created IGNITE-13883:
---
Summary: .NET: Performance: Refactor
BinarySystemHandlers.TryReadSystemType to switch-case
Key: IGNITE-13883
URL: https://issues.apache.org/jira/browse/IGNITE-13883
Project: Ignite
Issue Type: Improvement
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
{{BinarySystemHandlers.TryReadSystemType}} is too clever with interfaces and
generics:
* Hard to understand and maintain
* Possibly causes overhead due to virtual method calls
Refactor to switch-case and check if performance improves.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
