Re: Cache operations performance metrics
I think they are very useful. пн, 16 дек. 2019 г. в 10:51, Николай Ижиков : > Hello, Alexei. > > Thanks for the link on the ticket, lableled it with the IEP-35 label. > What do you think about proposed metrics set? > > > 16 дек. 2019 г., в 10:29, Alexei Scherbakov < > alexey.scherbak...@gmail.com> написал(а): > > > > Nikolay, > > > > What about batch operations? > > > > For messages processing the ticket does exist and even has an > > implementation from before new metrics API times [1] > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10418 > > > > пн, 16 дек. 2019 г. в 10:12, Николай Ижиков : > > > >> Hello, Igniters. > >> > >> I want to provide the user answers to the following question: "How cache > >> API operations perform?" > >> It seems, we need to implements metrics for basic cache API operations > >> like get, put, remove for it. > >> > >> I think we should provide the following metrics: > >> > >> * `get`, `put`, `remove` time histograms. Measured for API calls on the > >> caller node side. > >>Implemented in [1], commit [2]. > >> > >> * `commit`, `rollback` time histograms. Measured for API calls on the > >> caller node side [3]. > >> > >> * histograms that measure the time of processing `get`, `put`, `remove`, > >> `commit`, `rollback` messages on affinity nodes(primary and backups). > >>Ticket doesn't exist for it. > >> > >> What do you think? > >> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12219 > >> [2] > >> > https://github.com/apache/ignite/commit/e66bbef97b2cef73a533ce8a506ec479852cb364 > >> [3] https://issues.apache.org/jira/browse/IGNITE-12450 > >> > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > -- Best regards, Alexei Scherbakov
[jira] [Created] (IGNITE-12452) Dump pages from checkpointBuffer in upper priority.
Stanilovsky Evgeny created IGNITE-12452: --- Summary: Dump pages from checkpointBuffer in upper priority. Key: IGNITE-12452 URL: https://issues.apache.org/jira/browse/IGNITE-12452 Project: Ignite Issue Type: Improvement Components: data structures Affects Versions: 2.7.6 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Current default throttling algorithm make throttling enable decision basing on checkpoint buffer full fill, in this approach possible long throttling waiting pauses. I suggest to dump pages in upper priority in this case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Cache 6 suite is broken
An update. After increasing NetworkTimeout [1] the test passes rarely [2]. [1] https://github.com/apache/ignite/pull/7142/files [2] https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=pull%2F7142%2Fhead&buildTypeTab=overview пн, 16 дек. 2019 г. в 09:07, Ivan Pavlukhin : > > Hi, > > I noticied that Cache 6 suite finishes badly (exit code 137) almost > everytime [1] on master. It started recently. A problematic test > inside is IgniteCache150ClientsTest. I made some attempts to fix the > test (including reverting recent commits), but had no luck. And a hard > part here is that I do not know whether the issue was caused by code > changes or it is infrastructural one. My best attempt was increasing > NetworkTimeout in test IgniteConfiguration [2]. After that the suite > was able to finish, but IgniteCache150ClientsTest failed. Also, the > problematic test seems so flaky, there are many failures in history. > > Do not have any really good solution in my mind. I see following options: > 1. Use workaround in PR [2]. > 2. Ignore test and dig deeper in scope of a separate ticket. > > What do you think? > > [1] > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache6?branch=%3Cdefault%3E&buildTypeTab=overview > [2] https://github.com/apache/ignite/pull/7142/files > -- > Best regards, > Ivan Pavlukhin -- Best regards, Ivan Pavlukhin
Re: [ANNOUNCE] New committer: Aleksei Scherbakov
Aleksei, my congratulations! сб, 14 дек. 2019 г. в 10:50, Zhenya Stanilovsky : > > Big deal and huge responsibility. > > Congrats Aleksei! > > > Hello Ignite Community, > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > Aleksei Scherbakov to become a committer and we are pleased to announce > > that he has accepted. > > > > Aleksei investigated and fixed a lot of critical issues. Seems, > > everybody's > > familiar with "partitions counters" fix > > https://issues.apache.org/jira/browse/IGNITE-10078 solved huge > > data loss issue. On top of that, Aleksei recently finished Data > > Consistency > > wiki: https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > It will definitely help newcomers in better understanding of product > > internals. > > > > Being a committer enables easier contribution to the project since there > > is > > no need to go via the patch submission process. This should enable better > > productivity. > > > > Aleksei, thank you! > > > > Best Regards, > > Dmitriy Pavlov > > on behalf of Apache Ignite PMC -- Best regards, Ivan Pavlukhin
[jira] [Created] (IGNITE-12453) Transaction operations metrics on affinity nodes
Amelchev Nikita created IGNITE-12453: Summary: Transaction operations metrics on affinity nodes Key: IGNITE-12453 URL: https://issues.apache.org/jira/browse/IGNITE-12453 Project: Ignite Issue Type: New Feature Reporter: Amelchev Nikita Assignee: Amelchev Nikita We should add histogram metrics that measure cache operations times on affinity nodes: - get - put - remove - commit - rollback -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Cache operations performance metrics
I think these metrics are useful. I have prepared PR [1] for commit and rollback histograms. [2] Nikolay, could you take a look, please? If you do not mind, I will try to add affinity-nodes cache metrics: >> * histograms that measure the time of processing `get`, `put`, `remove`, >> `commit`, `rollback` messages on affinity nodes(primary and backups). Ticket >> doesn't exist for it. I have filed a ticket for it. [3] [1] https://github.com/apache/ignite/pull/7141 [2] https://issues.apache.org/jira/browse/IGNITE-12450 [3] https://issues.apache.org/jira/browse/IGNITE-12453 пн, 16 дек. 2019 г. в 11:07, Alexei Scherbakov : > > I think they are very useful. > > пн, 16 дек. 2019 г. в 10:51, Николай Ижиков : > > > Hello, Alexei. > > > > Thanks for the link on the ticket, lableled it with the IEP-35 label. > > What do you think about proposed metrics set? > > > > > 16 дек. 2019 г., в 10:29, Alexei Scherbakov < > > alexey.scherbak...@gmail.com> написал(а): > > > > > > Nikolay, > > > > > > What about batch operations? > > > > > > For messages processing the ticket does exist and even has an > > > implementation from before new metrics API times [1] > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-10418 > > > > > > пн, 16 дек. 2019 г. в 10:12, Николай Ижиков : > > > > > >> Hello, Igniters. > > >> > > >> I want to provide the user answers to the following question: "How cache > > >> API operations perform?" > > >> It seems, we need to implements metrics for basic cache API operations > > >> like get, put, remove for it. > > >> > > >> I think we should provide the following metrics: > > >> > > >> * `get`, `put`, `remove` time histograms. Measured for API calls on the > > >> caller node side. > > >>Implemented in [1], commit [2]. > > >> > > >> * `commit`, `rollback` time histograms. Measured for API calls on the > > >> caller node side [3]. > > >> > > >> * histograms that measure the time of processing `get`, `put`, `remove`, > > >> `commit`, `rollback` messages on affinity nodes(primary and backups). > > >>Ticket doesn't exist for it. > > >> > > >> What do you think? > > >> > > >> [1] https://issues.apache.org/jira/browse/IGNITE-12219 > > >> [2] > > >> > > https://github.com/apache/ignite/commit/e66bbef97b2cef73a533ce8a506ec479852cb364 > > >> [3] https://issues.apache.org/jira/browse/IGNITE-12450 > > >> > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > > -- > > Best regards, > Alexei Scherbakov -- Best wishes, Amelchev Nikita
[jira] [Created] (IGNITE-12454) Cache stop, destroy and clear status metrics
Ilya Shishkov created IGNITE-12454: -- Summary: Cache stop, destroy and clear status metrics Key: IGNITE-12454 URL: https://issues.apache.org/jira/browse/IGNITE-12454 Project: Ignite Issue Type: Improvement Components: cache Reporter: Ilya Shishkov In case of long lasting data removing processes, for example, stopping of big caches, particularly if highly uneven data distribution across partitions takes place, it would be perfect to have a tool, providing monitoring of cache data removal progress. I suppose, it should be metrics, representing status of caches stop, destroy and clear processes. This metrics should be available at least via JMX, and should be periodically printed into logs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12455) Calcite integration. Partition pruning.
Igor Seliverstov created IGNITE-12455: - Summary: Calcite integration. Partition pruning. Key: IGNITE-12455 URL: https://issues.apache.org/jira/browse/IGNITE-12455 Project: Ignite Issue Type: Improvement Reporter: Igor Seliverstov In scope of fragment info calculation we're able to prune partitions on the basis of filter condition, query parameters, affinity and tables distribution. This optimization may dramatically reduce query execution time/needed resources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: When Cache Metrics are switched on (statisticsEnabled = true) the empty cache events arrive to the client nodes
Hi Roman,
Thank you for reporting this! I looked into and on my machine I was
able to receive events on client-handler node but exception occurred
in the local listener! In a following line:
System.out.println("Received event [evt=" + evt.name() + ",
cacheName=" + evt.cacheName() + ", key=" + evt.key().toString());
This indeed looks like a weird bug. Event appears broken after
deserialization on a listener side after it is received from a server.
пт, 13 дек. 2019 г. в 12:24, :
>
> Hi Community,
>
> I’d like to ask you about the following behavior of Apache Ignite:
>
>
> If we want to react on some PUT or READ cache operations first of all we need
> to turn on the appropriate cache events on the server node and catch those
> events on the client nodes using remote approach with two listeners. It works
> well until we switch on statisticsEnabled on the server node, it will lead to
> the situation when we get empty CacheEvent objects.
>
> The example that demonstrates this issue is in the attachments. This example
> is consists of three nodes: 1 server node with cache and 2 clients. One
> client is filling the cache and the second one is listening PUT operations.
> When we turn on Cache Metrics on the server node:
> cacheConfig.setStatisticsEnabled(true); in EventServerCache.java we get empty
> events (Sometimes CacheEvent objects with null fields. Sometimes there are no
> events at all)
>
> My suppose is there is some Exception in GridCacheEventManager.addEvent()
> when Cache Metrics is turned on.
>
> catch (Exception e) {
> if
> (!cctx.cacheObjectContext().kernalContext().cacheObjects().isBinaryEnabled(cctx.config()))
> throw e; if (log.isDebugEnabled())
> log.debug("Failed to unmarshall cache object value for the event
> notification: " + e);
>
> if (!forceKeepBinary)
> LT.warn(log, "Failed to unmarshall cache object value for the event
> notification " +
> "(all further notifications will keep binary object format).");
>
> forceKeepBinary = true;
>
> key0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(key, true, false);
>
> val0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(newVal, true, false);
>
> oldVal0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(oldVal, true,
> false);
>
> }
>
> Can public this point in JIRA?
>
> Best regards,
>
> T-Systems RUS
> Point of Production
> Roman Koriakov
> Software Developer
> Kirova 11, Voronezh, Russia
> Tel: + 7 473 200 15 30
> E-mail: roman.koria...@t-systems.com
> http://www.t-systems.com>
>
> > http://www.t-systems.com>>:
>
> >
>
> >
>
> >
>
> > > Hi everyone,
>
> >
>
> > > I'd like to participate in this project!
>
> >
>
> > >
>
> >
>
> > > Best regards,
>
> >
>
> > >
>
> >
>
> > > T-Systems RUS
>
> >
>
> > > Point of Production
>
> >
>
> > > Roman Koriakov
>
> >
>
> > > Software Developer
>
> >
>
> > > Kirova 11, Voronezh, Russia
>
> >
>
> > > Tel: + 7 473 200 15 30
>
> >
>
> > > E-mail:
> > > roman.koria...@t-systems.com
>
> >
> > >>
>
> >
>
> > > http://www.t-systems.com
>
> > http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>
> >
>
> > >
>
> >
>
> > >
>
> >
--
Best regards,
Ivan Pavlukhin
Re: When Cache Metrics are switched on (statisticsEnabled = true) the empty cache events arrive to the client nodes
Hello!
Is there a chance you are using Zk?
I believe it's https://issues.apache.org/jira/browse/IGNITE-6564
Regards,
--
Ilya Kasnacheev
пт, 13 дек. 2019 г. в 12:24, :
> Hi Community,
>
> I’d like to ask you about the following behavior of Apache Ignite:
>
>
> If we want to react on some PUT or READ cache operations first of all we
> need to turn on the appropriate cache events on the server node and catch
> those events on the client nodes using remote approach with two listeners.
> It works well until we switch on statisticsEnabled on the server node, it
> will lead to the situation when we get empty CacheEvent objects.
>
> The example that demonstrates this issue is in the attachments. This
> example is consists of three nodes: 1 server node with cache and 2
> clients. One client is filling the cache and the second one is listening
> PUT operations. When we turn on Cache Metrics on the server node:
> cacheConfig.setStatisticsEnabled(true); in EventServerCache.java we get
> empty events (Sometimes CacheEvent objects with null fields. Sometimes
> there are no events at all)
>
> My suppose is there is some Exception in GridCacheEventManager.addEvent()
> when Cache Metrics is turned on.
>
> catch (Exception e) {
> if
> (!cctx.cacheObjectContext().kernalContext().cacheObjects().isBinaryEnabled(cctx.config()))
> throw e; if (log.isDebugEnabled())
> log.debug("Failed to unmarshall cache object value for the event
> notification: " + e);
>
> if (!forceKeepBinary)
> LT.warn(log, "Failed to unmarshall cache object value for the event
> notification " +
> "(all further notifications will keep binary object
> format).");
>
> forceKeepBinary = true;
>
> key0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(key, true, false);
>
> val0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(newVal, true,
> false);
>
> oldVal0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(oldVal, true,
> false);
>
> }
>
> Can public this point in JIRA?
>
> Best regards,
>
> T-Systems RUS
> Point of Production
> Roman Koriakov
> Software Developer
> Kirova 11, Voronezh, Russia
> Tel: + 7 473 200 15 30
> E-mail: roman.koria...@t-systems.com
> http://www.t-systems.com >>
>
> > http://www.t-systems.com http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>
> >
>
> >
>
> >
>
> > -Original Message-
>
> > From: Ilya Kasnacheev ilya.kasnach...@gmail.com>>
>
> > Sent: Thursday, December 12, 2019 5:25 PM
>
> > To: dev mailto:dev@ignite.apache.org>>
>
> > Subject: Re: joining
>
> >
>
> >
>
> >
>
> > Hello!
>
> >
>
> >
>
> >
>
> > I will need an Apache JIRA username to add you to contributors. Can you
>
> > provide it?
>
> >
>
> >
>
> >
>
> > Regards,
>
> >
>
> > --
>
> >
>
> > Ilya Kasnacheev
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > чт, 12 дек. 2019 г. в 17:20,
> > roman.koria...@t-systems.com>>:
>
> >
>
> >
>
> >
>
> > > Hi everyone,
>
> >
>
> > > I'd like to participate in this project!
>
> >
>
> > >
>
> >
>
> > > Best regards,
>
> >
>
> > >
>
> >
>
> > > T-Systems RUS
>
> >
>
> > > Point of Production
>
> >
>
> > > Roman Koriakov
>
> >
>
> > > Software Developer
>
> >
>
> > > Kirova 11, Voronezh, Russia
>
> >
>
> > > Tel: + 7 473 200 15 30
>
> >
>
> > > E-mail: roman.koria...@t-systems.com roman.koria...@t-systems.com 3cmailto:roman.koria...@t-systems.com>
>
> > 3cmailto:roman.koria...@t-systems.com
>
> > >>
>
> >
>
> > > http://www.t-systems.com http://www.t-systems.com%3chttp:/www.t-systems.ru/%3c>
>
> > http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
Re: [ANNOUNCE] New committer: Aleksei Scherbakov
Aleksei, Congratulations! You definitely deserve it. пн, 16 дек. 2019 г. в 14:42, Ivan Pavlukhin : > Aleksei, my congratulations! > > сб, 14 дек. 2019 г. в 10:50, Zhenya Stanilovsky >: > > > > Big deal and huge responsibility. > > > > Congrats Aleksei! > > > > > Hello Ignite Community, > > > > > > The Project Management Committee (PMC) for Apache Ignite has invited > > > Aleksei Scherbakov to become a committer and we are pleased to announce > > > that he has accepted. > > > > > > Aleksei investigated and fixed a lot of critical issues. Seems, > > > everybody's > > > familiar with "partitions counters" fix > > > https://issues.apache.org/jira/browse/IGNITE-10078 solved huge > > > data loss issue. On top of that, Aleksei recently finished Data > > > Consistency > > > wiki: > https://cwiki.apache.org/confluence/display/IGNITE/Data+consistency > > > It will definitely help newcomers in better understanding of product > > > internals. > > > > > > Being a committer enables easier contribution to the project since > there > > > is > > > no need to go via the patch submission process. This should enable > better > > > productivity. > > > > > > Aleksei, thank you! > > > > > > Best Regards, > > > Dmitriy Pavlov > > > on behalf of Apache Ignite PMC > > > > -- > Best regards, > Ivan Pavlukhin >
Re: joining
Prashant, What brought you to Ignite folks? Do you already use it internally and would like to improve contributing? - Denis On Sun, Dec 15, 2019 at 11:48 PM Prashant Rahulkar < prashantrahul...@gmail.com> wrote: > Hello Dmitriy , > > Thanks for your clarification, definitely our employee will contribute with > riEquaiton.com official mail id. > > > Thanks, > Prashant Rahulkar. > > On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov wrote: > > > Hi Prashant, > > > > Thank you for your interest in Apache Ignite. And I hope the Ignite > > community would be glad to work with new contributors. > > > > Just one note: A company can not contribute to an Apache project, but > your > > employee(s) can contribute as an individual. Similar is true for > > management, an employee can be a member of PMC, but the project is > managed > > not by companies but only by the project management committee. > > > > Sincerely, > > Dmitriy Pavlov > > > > сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar < > prashantrahul...@gmail.com > > >: > > > > > Hello Everyone, > > > I have started software firm in India, with complete motivation to > focus > > on > > > open source technologies, so as a part of company policy we will star > to > > > contribute in this project with our company name. > > > > > > > > > Thanks, > > > PrashantR. > > > > > > > > -- > ~ Rahul >
Re: When Cache Metrics are switched on (statisticsEnabled = true) the empty cache events arrive to the client nodes
I also checked the reproducer with current master. It seems that the
problem is fixed there.
пн, 16 дек. 2019 г. в 19:36, Ilya Kasnacheev :
>
> Hello!
>
> Is there a chance you are using Zk?
>
> I believe it's https://issues.apache.org/jira/browse/IGNITE-6564
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 13 дек. 2019 г. в 12:24, :
>
> > Hi Community,
> >
> > I’d like to ask you about the following behavior of Apache Ignite:
> >
> >
> > If we want to react on some PUT or READ cache operations first of all we
> > need to turn on the appropriate cache events on the server node and catch
> > those events on the client nodes using remote approach with two listeners.
> > It works well until we switch on statisticsEnabled on the server node, it
> > will lead to the situation when we get empty CacheEvent objects.
> >
> > The example that demonstrates this issue is in the attachments. This
> > example is consists of three nodes: 1 server node with cache and 2
> > clients. One client is filling the cache and the second one is listening
> > PUT operations. When we turn on Cache Metrics on the server node:
> > cacheConfig.setStatisticsEnabled(true); in EventServerCache.java we get
> > empty events (Sometimes CacheEvent objects with null fields. Sometimes
> > there are no events at all)
> >
> > My suppose is there is some Exception in GridCacheEventManager.addEvent()
> > when Cache Metrics is turned on.
> >
> > catch (Exception e) {
> > if
> > (!cctx.cacheObjectContext().kernalContext().cacheObjects().isBinaryEnabled(cctx.config()))
> > throw e; if (log.isDebugEnabled())
> > log.debug("Failed to unmarshall cache object value for the event
> > notification: " + e);
> >
> > if (!forceKeepBinary)
> > LT.warn(log, "Failed to unmarshall cache object value for the event
> > notification " +
> > "(all further notifications will keep binary object
> > format).");
> >
> > forceKeepBinary = true;
> >
> > key0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(key, true, false);
> >
> > val0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(newVal, true,
> > false);
> >
> > oldVal0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(oldVal, true,
> > false);
> >
> > }
> >
> > Can public this point in JIRA?
> >
> > Best regards,
> >
> > T-Systems RUS
> > Point of Production
> > Roman Koriakov
> > Software Developer
> > Kirova 11, Voronezh, Russia
> > Tel: + 7 473 200 15 30
> > E-mail: roman.koria...@t-systems.com
> > http://www.t-systems.com > > >>
> >
> > > http://www.t-systems.com > http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
> >
> > >
> >
> > >
> >
> > >
> >
> > > -Original Message-
> >
> > > From: Ilya Kasnacheev > ilya.kasnach...@gmail.com>>
> >
> > > Sent: Thursday, December 12, 2019 5:25 PM
> >
> > > To: dev mailto:dev@ignite.apache.org>>
> >
> > > Subject: Re: joining
> >
> > >
> >
> > >
> >
> > >
> >
> > > Hello!
> >
> > >
> >
> > >
> >
> > >
> >
> > > I will need an Apache JIRA username to add you to contributors. Can you
> >
> > > provide it?
> >
> > >
> >
> > >
> >
> > >
> >
> > > Regards,
> >
> > >
> >
> > > --
> >
> > >
> >
> > > Ilya Kasnacheev
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > чт, 12 дек. 2019 г. в 17:20, >
> > > roman.koria...@t-systems.com>>:
> >
> > >
> >
> > >
> >
> > >
> >
> > > > Hi everyone,
> >
> > >
> >
> > > > I'd like to participate in this project!
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > Best regards,
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > T-Systems RUS
> >
> > >
> >
> > > > Point of Production
> >
> > >
> >
> > > > Roman Koriakov
> >
> > >
> >
> > > > Software Developer
> >
> > >
> >
> > > > Kirova 11, Voronezh, Russia
> >
> > >
> >
> > > > Tel: + 7 473 200 15 30
> >
> > >
> >
> > > > E-mail: roman.koria...@t-systems.com > roman.koria...@t-systems.com > 3cmailto:roman.koria...@t-systems.com>
> >
> > >
RIEquation.com : Would like to be a part of the team.
Hello All, We are startup company and would like to start contribute in this project. So would like to request to do add this mail id in jira account. Thanks, Prashant R | CTO RIEquaiton.com Pune, India
Re: RIEquation.com : Would like to be a part of the team.
Hello Prashant, Please create a personal account(s) in JIRA and list the IDs here. We'll add the contributors to the contributors' list. Could you also tell a little bit more about your company and how it's related to Ignite? Do you already use it or incorporate it and sell it as part of the business? Unfortunately, I can't open the website. Please also check how to contribute and collaborate pages: https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute https://cwiki.apache.org/confluence/display/IGNITE/How+to+Collaborate - Denis On Mon, Dec 16, 2019 at 12:06 PM wrote: > Hello All, > > We are startup company and would like to start contribute in this > project. So would like to request to do add this mail id in jira > account. > > Thanks, > Prashant R | CTO > RIEquaiton.com > Pune, India >
Re: Ignite meetup at Google Headquarters on Dec 18th
Just a reminder for those who live/work nearby. We've already got 200 registrations for in-memory computing essentials talk across Silicon Valley JUG and in-memory computing groups. We're running out of chairs but still have a few left, join! - Denis On Mon, Dec 9, 2019 at 1:52 AM Denis Magda wrote: > Igniters, > > This month we united with Silicon Valley Java User Group and we'll be > repeating In-Memory Computing Essentials for Software Engineers session at > Google HQ. > > Come over to meet in person, a lot of coding and practical examples. RSVP > using our local group below (and attend it to not miss future gatherings): > https://www.meetup.com/Bay-Area-In-Memory-Computing/events/267050035/ > > - > Denis >
Re: joining
Hello Denis, We are planning to migrate to Apache Ignite, we have created POC for our system with Ignite and working well so want to contribute in development. Thanks, Prashant Rahulkar. On Tue, 17 Dec 2019 at 01:25, Denis Magda wrote: > Prashant, > > What brought you to Ignite folks? Do you already use it internally and > would like to improve contributing? > > - > Denis > > > On Sun, Dec 15, 2019 at 11:48 PM Prashant Rahulkar < > prashantrahul...@gmail.com> wrote: > > > Hello Dmitriy , > > > > Thanks for your clarification, definitely our employee will contribute > with > > riEquaiton.com official mail id. > > > > > > Thanks, > > Prashant Rahulkar. > > > > On Sat, 14 Dec 2019 at 18:34, Dmitriy Pavlov wrote: > > > > > Hi Prashant, > > > > > > Thank you for your interest in Apache Ignite. And I hope the Ignite > > > community would be glad to work with new contributors. > > > > > > Just one note: A company can not contribute to an Apache project, but > > your > > > employee(s) can contribute as an individual. Similar is true for > > > management, an employee can be a member of PMC, but the project is > > managed > > > not by companies but only by the project management committee. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > сб, 14 дек. 2019 г. в 05:27, Prashant Rahulkar < > > prashantrahul...@gmail.com > > > >: > > > > > > > Hello Everyone, > > > > I have started software firm in India, with complete motivation to > > focus > > > on > > > > open source technologies, so as a part of company policy we will star > > to > > > > contribute in this project with our company name. > > > > > > > > > > > > Thanks, > > > > PrashantR. > > > > > > > > > > > > > -- > > ~ Rahul > > > -- ~ Rahul
Re: Ignite meetup at Google Headquarters on Dec 18th
Hello Denis, We are from remote place, we would also like to attend the session. Is there any chance for us to connect by conference. Thanks, Prashant Rahulkar. On Tue, 17 Dec 2019 at 04:46, Denis Magda wrote: > Just a reminder for those who live/work nearby. > > We've already got 200 registrations for in-memory computing essentials talk > across Silicon Valley JUG and in-memory computing groups. We're running out > of chairs but still have a few left, join! > > - > Denis > > > On Mon, Dec 9, 2019 at 1:52 AM Denis Magda wrote: > > > Igniters, > > > > This month we united with Silicon Valley Java User Group and we'll be > > repeating In-Memory Computing Essentials for Software Engineers session > at > > Google HQ. > > > > Come over to meet in person, a lot of coding and practical examples. RSVP > > using our local group below (and attend it to not miss future > gatherings): > > https://www.meetup.com/Bay-Area-In-Memory-Computing/events/267050035/ > > > > - > > Denis > > > -- ~ Rahul
[jira] [Created] (IGNITE-12456) Cluster Data Store gets Corrupted for Load test
Ravi Kumar Powli created IGNITE-12456: - Summary: Cluster Data Store gets Corrupted for Load test Key: IGNITE-12456 URL: https://issues.apache.org/jira/browse/IGNITE-12456 Project: Ignite Issue Type: Bug Components: general Affects Versions: 2.7 Reporter: Ravi Kumar Powli Fix For: 2.8 Attachments: default-config.xml We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery.we are into AWS cloud environmnet with Microservice model with 8 microservices.we are using Ignte for session data store.While performaing load test we are facing data grid issues if the number of clients reached 40 , Once data grid got currepted we will lost the session store data and Application will not respond due to session data also currepted and all the instances will auto scaled down to intial size 8.We need to restart Apache Ignite to make the Application up.Please find the atatched Apache Ignite Configuration for your reference. Apache Ignite Version : 2.7.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12457) Cache 6 test suite fails with exit code 137
Ivan Pavlukhin created IGNITE-12457: --- Summary: Cache 6 test suite fails with exit code 137 Key: IGNITE-12457 URL: https://issues.apache.org/jira/browse/IGNITE-12457 Project: Ignite Issue Type: Bug Reporter: Ivan Pavlukhin Assignee: Ivan Pavlukhin Recently Cache 6 test suite started failing with uplesantly with exit code 137. Whole suite fails with no details about passed and failed tests. IgniteCache150ClientsTest seems to be a root cause. -- This message was sent by Atlassian Jira (v8.3.4#803005)
