master doesn't compile on jdk7

Hello, Igniters. I think current master broken for jdk7 by commit 1be77384122e41ce69db828e4432e56824c76f79 I can't compile it locally. And I see same error message in TC.

.Net client call tx,close in other thread

Hello, Igniters. I working on issue https://issues.apache.org/jira/browse/IGNITE-5712 I found that .Net client perform transaction operation(`tx.close()`) in thread that not owns transaction. So I can't include checks for threadId in my pull request. Is it a bug or a desirable behabiour? With

Re: .Net client call tx,close in other thread

yes, how can I reproduce it? > Can you prepare a branch where the test fails, so I can run it locally? > > Thanks, > Pavel > > On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков <nizhikov@gmail.com> > wrote: > > > Hello, Igniters. > > > > I working

Re: [VOTE] Apache Ignite 2.1.0 RC4

+1 2017-07-25 10:50 GMT+03:00 Vyacheslav Daradur : > +1 > > 2017-07-25 2:02 GMT+03:00 Valentin Kulichenko < > valentin.kuliche...@gmail.com > >: > > > +1 (binding) > > > > On Mon, Jul 24, 2017 at 6:39 AM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > > >

My first patch into Ignite

Hello, guys. Got my very first patch merged into master. I resolved IGNITE-2190 [1]. I add some warnings about inconsistent Ignite usage: BinaryMarshaller without ignite.withBinary(). Now users can resolve some issues just by carefully reading log. Thanks all the Ignite community and

ContinuousQueryWithTransformer implementation questions

Hello, Igniters. I'm working on IGNITE-425 [1] issue. I made a couple of changes in my branch [2] so I want to confirm that changes with community before moving forward: Text of issue: ``` Currently if updated entry passes the filter, it is sent to node initiated the query entirely. It would be

Re: .Net client call tx,close in other thread

017 at 7:36 PM, Pavel Tupitsyn < > > ptupit...@apache.org> > > > >>> wrote: > > > >>> > > > >>> I've reproduced the issue, it happens because in .NET we auto-close > > the > > > >>>> transaction > > > >&

Re: Make Teamcity Green Again

Hello, Igniters. Also ready to help to #MakeTeamcityGreenAgain ! 21 июля 2017 г. 12:56 PM пользователь "Vyacheslav Daradur" < daradu...@gmail.com> написал: > Hi guys. > > I vote for #MakeTeamcityGreenAgain. :-) > > FYI: it had been described and supported previously[1] > > After the completion

Re: IgniteUtils#currentTimeMillis

Hello, Dima. > Nickolay, could you please raise standalone ticket for U.currentTimeMillis () ? Yes, I can. > https://issues.apache.org/jira/browse/IGNITE-5963 I will try to make quick fix for issue without change Ignite core code. So fix will not depend to U.currentTimeMillis() implementation.

Re: IgniteUtils#currentTimeMillis

Vladimir, > There is nothing wrong with U.currentTimeMillis() at the moment. I think we can't rely on the return value for time measurement. Is it true? Is it OK for you? It very counterintuitive for me as newcomer. 2017-08-09 14:55 GMT+03:00 Vladimir Ozerov : > You

Re: IgniteUtils#currentTimeMillis

> > > > Nikolay, how long outdated value can be returned by method? > > > > ср, 9 авг. 2017 г. в 15:00, Николай Ижиков <nizhikov@gmail.com>: > > > > > Vladimir, > > > > > > > There is nothing wrong with U.currentTimeMillis()

Re: IgniteUtils#currentTimeMillis

urrent method implementation. 2017-08-09 15:45 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > On Wed, Aug 9, 2017 at 5:32 AM, Николай Ижиков <nizhikov@gmail.com> > wrote: > > > Vladimir, > > > > As far as I can understand behaviour of U.currentTim

#MakeTeamCityGreenAgain IGNITE-5866

Hello, Igniters. Alexey Goncharuk just merged my fix of IGNITE-5866 to master. I fix filter in MetadataJob for `cache.context().queries().sqlMetadata()` function It means that 4 other tests become green: JettyRestProcessorSignedSelfTest#testMetatdataLocal

GridVersionSelfTest.testVersions #MakeTeamCityGreenAgain

Hello, Igniters. `GridVersionSelfTest.testVersions` fails for a long time: http://ci.ignite.apache.org/project.html?tab=testDetails=Ignite20Tests=2028128591644736718=10 In current master it muted by IGNITE-5413. But IGNITE-5413 is resolved now. Test muted by Sergey Chugunov in

IgniteUtils#currentTimeMillis

Hello, Igniters. I found unusual implementation of IgniteUtils#currentTimeMillis function. Method is not simple proxy to System.currentTimeMillis Instead it read static variable which updated by dedicated thread:

Re: IgniteUtils#currentTimeMillis

ons to use System.currentTimeMillis() in the way it used for now? 2017-08-07 18:42 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > Hello, Igniters. > > I found unusual implementation of IgniteUtils#currentTimeMillis function. > Method is not simple proxy to System.currentTimeMil

request for a contributor permissions

Hello, guys. I want to join to development of ignite. This guide tells me to request contributor permissions. https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute So can you give me such permissions? I review easy tickets for a 2.1. release. IGNITE-2190 - seems interesting.

Re: DiscoverySpi#setDataExchange returns concrete implementation

Hello. Here is pull request for this issue: https://github.com/apache/ignite/pull/2022 2017-05-26 13:16 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: > Hi Nick! Good catch. Please go ahead and submit a patch. > > --Yakov > > 2017-05-26 13:09 GMT+03:00 Николай Ижиков &l

Re: DiscoverySpi#setDataExchange returns concrete implementation

Thanks Yakov. I moved IGNITE-5321 to resolved state. Is that right? 2017-05-29 17:24 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: > Merged. Thanks for contribution, Nick. Please also see my edits. > > --Yakov > > 2017-05-28 19:29 GMT+03:00 Николай Ижиков <nizhikov

DiscoverySpi#setDataExchange returns concrete implementation

Hello, guys. public interface DiscoverySpi extends IgniteSpi { TcpDiscoverySpi setDataExchange(DiscoverySpiDataExchange var1); TcpDiscoverySpi setMetricsProvider(DiscoveryMetricsProvider var1); ... } Two methods of DiscoverySpi returns concrete implementation. I think we should

Re: ContinuousQueryWithTransformer implementation questions - 2

Guys. I'm new in the project so can someone more experienced tell me: What's is wrong with the current implementation of ContinuousQuery? 1. initialQuery is useless - OK, understood. What else is wrong? 2017-09-12 20:02 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > Vova, >

Re: MVCC configuration

Hello, Semyon! > It seems we need introduce special 'dedicated mvcc coordinator' node role How will Ignite handle "mvcc coordinator" fail? What will happen with if coordinator fails in the middle of a transaction? Could tx be committed or rollbacked? Will we have some user notification if

Re: ContinuousQueryWithTransformer implementation questions - 2

API at 3.0. 2) Current API is bad, and, yes, my changes make it a little bit complicated. But, complication minimized as possible and profit much bigger that complication. 2017-09-18 17:39 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > Vladimir, > > Here is a short summar

Re: ContinuousQueryWithTransformer implementation questions - 2

ladimir. > > On Mon, Sep 18, 2017 at 4:04 PM, Николай Ижиков <nizhikov@gmail.com> > wrote: > > > Igniters, > > > > I discussed API of ContinuousQuery and ContinuousQueryWithTransformer > with > > Anton Vinogradov one more time. > > > >

Re: ContinuousQueryWithTransformer implementation questions - 2

Igniters, I discussed API of ContinuousQuery and ContinuousQueryWithTransformer with Anton Vinogradov one more time. Since users who use regular ContinuousQuery already knows pros. and cons of using initialQuery and to not to complicate API more and more until 3.0 we agreed that best choice is

Re: Integration of Spark and Ignite. Prototype.

; RDBMS cases. > > > > 2. If Spark community is reluctant let’s include the module in > > ignite-spark integration. > > > > — > > Denis > > > > > On Sep 25, 2017, at 11:14 AM, Николай Ижиков <nizhikov@gmail.com> > > wrote: > > &g

Re: Integration of Spark and Ignite. Prototype.

18:45 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > Hello, guys. > > Which version of Spark do we want to use? > > 1. Currently, Ignite depends on Spark 2.1.0. > > * Can be run on JDK 7. > * Still supported: 2.1.2 will be released soon. > &

Spark+Ignite SQL syntax proposal

Hello, guys. I’m working on IGNITE-3084 [1] “Spark Data Frames Support in Apache Ignite” and have a proposal to discuss. I want to provide a consistent way to query Ignite key-value caches from Spark SQL engine. To implement it I have to determine java class for the key and value. It required

Re: Spark+Ignite SQL syntax proposal

of syntax which is > > very confusing. Main use case for data frames is SQL, so let's > concentrate > > on it. We should use Ignite's SQL engine capabilities as much as > possible. > > If we see other use cases down the road, we can always support them. > > > >

Re: Spark+Ignite SQL syntax proposal

re trying to solve with this syntax? > > -Val > > On Thu, Oct 5, 2017 at 7:05 AM, Николай Ижиков <nizhikov@gmail.com> > wrote: > > > Hello, guys. > > > > I’m working on IGNITE-3084 [1] “Spark Data Frames Support in Apache > Ignite” > > and h

Re: Integration of Spark and Ignite. Prototype.

little swamped lately. I will do my best to > review the code this week. > > -Val > > On Mon, Oct 9, 2017 at 11:48 AM, Николай Ижиков <nizhikov@gmail.com> > wrote: > >> Hello, Valentin. >> >> Did you have a chance to look at my changes? >> >>

Re: Integration of Spark and Ignite. Prototype.

t; Ignite files on spark worker nodes. > > What do you mean? I see code like: > > spark.sparkContext.addJar(MAVEN_HOME + > "/org/apache/ignite/ignite-core/2.3.0-SNAPSHOT/ignite- > core-2.3.0-SNAPSHOT.jar") > > On Mon, Oct 16, 2017 at 5:22 PM, Николай Ижиков <nizhi

Re: Integration of Spark and Ignite. Prototype.

? > > On Tue, Oct 17, 2017 at 2:25 PM, Николай Ижиков <nizhikov@gmail.com> > wrote: > > > Hello, Anton. > > > > An example you provide is a path to a master *local* file. > > These libraries are added to the classpath for each remote node r

Re: [VOTE] Apache Ignite 2.2.0 RC1

+1 2017-09-11 16:31 GMT+03:00 Anton Vinogradov : > Igniters, > > We have uploaded a 2.2.0 release candidate to > https://dist.apache.org/repos/dist/dev/ignite/2.2.0-rc1/ > > Git tag name is > 2.2.0-rc1 > > This release includes the following changes: > > Ignite: > *

Re: Deprecate IgniteCache.query(Query, IgniteClosure<T,R>)

+1 from me as I proposed similar design in my implementation of ContinuousQueryWithTransformer [1] https://issues.apache.org/jira/browse/IGNITE-425 2017-09-11 17:13 GMT+03:00 Vladimir Ozerov : > Igniters, > > We have that very strange method, which accepts transformer. It

Re: ContinuousQueryWithTransformer implementation questions - 2

Hello, Vladimir. class ContinuousQueryCacheEntryListener implements CacheEntryListener { ContinuousQueryRemoteFilter rmtFilter; ContinuousQueryRemoteTransformer rmtTransformer; ContinuousQueryLocalCallback locCb; } I think class you proposed should be separated in two because of

Re: ContinuousQueryWithTransformer implementation questions - 2

Vova > I propose to deprecate current continuous queries and develop new API. > This should not break anything. If the community agrees that *whole* continuous query API is bad - it OK. Let's develop new API. But developing new public API and implementing it is a very long process. One can see

Re: ContinuousQueryWithTransformer implementation questions - 2

Yakov. > 2. In a new class we still have initial query which uses types which is questionable. After some discussion with a colleague, I think I got your point. If I understand your question right: Why does someone want to execute an initial query that returns ? If one use

Default CacheConfiguration instance can't be serialized

Hello, Guys. I found that CacheConfiguration which implements Serializable contains not serializable fields by default. CacheConfiguration -> affMapper -> CacheDefaultBinaryAffinityKeyMapper -> proc -> CacheObjectBinaryProcessorImpl. Is this a bug or I miss something? Simple reproducer: ```

Integration of Spark and Ignite. Prototype.

Hello, guys. Currently, I’m working on integration between Spark and Ignite [1]. For now, I implement following: * Ignite DataSource implementation(IgniteRelationProvider) * DataFrame support for Ignite SQL table. * IgniteCatalog implementation for a transparent resolving of ignites

Re: ContinuousQueryWithTransformer implementation questions - 2

Yakov, Anton, thank you! 2017-09-04 15:16 GMT+03:00 Yakov Zhdanov : > Well, let's leave it as is for now, since I don't see any easy way to > consistently solve this. > > --Yakov > -- Nikolay Izhikov nizhikov@gmail.com

Re: ContinuousQueryWithTransformer implementation questions - 2

Hello, Yakov. I made a bit of investigation about your proposal of handling filter and transformer exceptions: 1. If we cancel continuous query from remote node user can't know it. There is no public API to check "Is continuous query still alive?". The only consequence of canceling query

Re: ContinuousQueryWithTransformer implementation questions - 2

; ScanQuery, let's reuse it. Please, have a look > at IgniteCache#query(org.apache.ignite.cache.query.Query, > org.apache.ignite.lang.IgniteClosure<T,R>) method. It looks more pretty > for > me. Any objections? > > Thanks, > Nikolay > > On Mon, Sep 4, 2017 at 3:22

Re: ContinuousQueryWithTransformer implementation questions - 2

Hello, guys. Anton, Yakov, can you, please, share your wisdom, and make final review of IGNITE-425 Task: https://issues.apache.org/jira/browse/IGNITE-425 PR: https://github.com/apache/ignite/pull/2372 2017-09-18 18:33 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > So, resuming:

Re: Integration of Spark and Ignite. Prototype.

on Ignite side? I thought we decided not to support this, no? Or this is something else? Thanks! -Val On Tue, Oct 17, 2017 at 4:40 AM, Anton Vinogradov < avinogra...@gridgain.com> wrote: Sounds awesome. I'll try to review API & tests this week. Val, Your review still required :) On Tue, Oct 17, 2017 at 2:36

Re: TC issues. IGNITE-3084. Spark Data Frame API

7042 28.11.2017 03:33, Valentin Kulichenko пишет: Hi Nikolay, Please see my responses inline. -Val On Fri, Nov 24, 2017 at 2:55 AM, Николай Ижиков <nizhikov@gmail.com <mailto:nizhikov@gmail.com>> wrote: Hello, guys. I have some issues on TC with my PR [1] for IGNITE-30

Optimization of SQL queries from Spark Data Frame to Ignite

Hello, guys. I have implemented basic support of Spark Data Frame API [1], [2] for Ignite. Spark provides API for a custom strategy to optimize queries from spark to underlying data source(Ignite). The goal of optimization(obvious, just to be on the same page): Minimize data transfer between

TC issues. IGNITE-3084. Spark Data Frame API

Hello, guys. I have some issues on TC with my PR [1] for IGNITE-3084(Spark Data Frame API). Can you, please, help me: 1. `Ignite RDD spark 2_10` - Currently this build runs with following profiles: `-Plgpl,examples,scala-2.10,-clean-libs,-release` [2] That means `scala` profile is activated

Re: Integration of Spark and Ignite. Prototype.

Please, see updated PR - https://github.com/apache/ignite/pull/2742 2017-10-18 20:02 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: Hello, Valentin. My answers is below. Dmitry, do we need to move discussion to Jira? 1. Why do we have org.apache.spark.sql.ignite package in our codebase?

Re: TC issues. IGNITE-3084. Spark Data Frame API

understanding is that Spark related suites are successfully executed there, so is there an issue? -Val On Tue, Nov 28, 2017 at 2:42 AM, Николай Ижиков <nizhikov@gmail.com <mailto:nizhikov@gmail.com>> wrote: Hello, Valentin. Added '-Dscala-2.10' to the build config.

Re: Optimization of SQL queries from Spark Data Frame to Ignite

is and it seems like another > separate discussion. > > -Val > > On Tue, Nov 28, 2017 at 9:54 AM, Николай Ижиков <nizhikov@gmail.com> > wrote: > > > Hello, guys. > > > > I have implemented basic support of Spark Data Frame API [1], [2] for > > Igni

Re: Optimization of SQL queries from Spark Data Frame to Ignite

be used as regular data source in > > this case, and probably it's possible to implement some optimizations > here > > as well. However, I never investigated this and it seems like another > > separate discussion. > > > > -Val > > > > On Tue, Nov

Re: TC issues. IGNITE-3084. Spark Data Frame API

pgrade to 2.2.0? Then I'm not sure we should upgrade in the first place, or at least we should consider not dropping previous version yet. I sent a message to the original thread about upgrade, let's decide there and then come back to this issue. -Val On Tue, Nov 28, 2017 at 8:08 PM, Николай

Re: TC issues. IGNITE-3084. Spark Data Frame API

t 11:28 PM, Николай Ижиков <nizhikov@gmail.com <mailto:nizhikov@gmail.com>> wrote: Valentin, > Oh, so this is because of upgrade to 2.2.0? Yes, we should upgrade spark module to jdk1.8 because switching to spark 2.2.0. > least we should consider not d

Re: TC issues. IGNITE-3084. Spark Data Frame API

Valentin, Now it's run OK. Thank you. 30.11.2017 23:41, Valentin Kulichenko пишет: Nikolay, Please try once again. -Val On Thu, Nov 30, 2017 at 11:43 AM, Николай Ижиков <nizhikov@gmail.com <mailto:nizhikov@gmail.com>> wrote: Valentin, Thank you, but your

Re: Optimization of SQL queries from Spark Data Frame to Ignite

e353* to get better understanding on how this was implemented. Vladimir. On Wed, Nov 29, 2017 at 2:01 PM, Николай Ижиков <nizhikov@gmail.com> wrote: Hello, Vladimir. partition pruning is already implemented in Ignite, so there is no need to do this on your own. Spark work with pa

Re: Integration of Spark and Ignite. Prototype.

? > >> Let’s > >> >> concentrate on this first and handle the strategy support as a > separate > >> >> JIRA task. Agree? > >> >> > >> >> — > >> >> Denis > >> >> > >> >>> On Nov 27, 2017, at 3:47 PM

Re: Conflicting cross-version suffixes in: org.scalatest:scalatest, com.twitter:chill, org.apache.spark:spark-unsafe, org.apache.spark:spark-tags

Hello, Denis. I know about this issue. I can try to fix it. But, seems that ticket assigned to you, currently. Let me know if you need some kind of help. 2017-11-08 18:17 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > Привет. > > Я знаю об этой проблеме. Натолкн

Re: Test failure on build

; 2017-10-24 16:03 GMT+03:00 Николай Ижиков <nizhikov@gmail.com>: > > > Hello, Michael. > > > > Did you run commands described in docs? > > > > https://ignite.apache.org/community/contribute.html > > > > ``` > > # Build project. > >

Re: Test failure on build

Hello, Michael. Did you run commands described in docs? https://ignite.apache.org/community/contribute.html ``` # Build project. $ mvn clean package -DskipTests # Run Apache RAT $ mvn clean validate -Pcheck-licenses ``` Can you provide command you run and detailed stack trace you got?

Re: Integration of Spark and Ignite. Prototype.

t; needed? It looks like we can directly provide the configuration file; if >>> IgniteSparkSession really requires IgniteContext, it can create it by >>> itself under the hood. Actually, I think it makes sense to create a >>> builder >>> similar to SparkSession.b

Re: Joining node validation failure event.

I think we also should provide the reason why join failed. > 3 дек. 2019 г., в 12:22, Ivan Pavlukhin написал(а): > > Mikhail, > > So, I suppose there should be ordering guarantees that listener is > registered before first validation failure can occur. Hope > GridComponent#onKernalStart is the

Re: Joining node validation failure event.

but needed only for a particular extension (plugin). > > вт, 3 дек. 2019 г. в 12:31, Николай Ижиков : >> >> I think we also should provide the reason why join failed. >> >>> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin написал(а): >>> >>> Mikhail, >&g

[TeamCIty] Issues with the disc space

Hello, Igniters. Looks like we have an issues with the TC agents disc space [1] Can someone take a look? [1] https://ci.ignite.apache.org/viewLog.html?buildId=4809938=buildResultsDiv=IgniteTests24Java8_PlatformCPPLinuxClang

Re: [ANNOUNCE] 4 December 2019, the 2.8 RELEASE brach creation

Thank for the leading release, Maxim. Keep going! > 4 дек. 2019 г., в 20:29, Alexey Zinoviev написал(а): > > Great, many thanks to your job > > ср, 4 дек. 2019 г., 19:05 Maxim Muzafarov : > >> Igniters, >> >> >> 1. The release branch created: ignite-2.8 >> 2. The list of unresolved issues

BinaryObject API confuses users

Hello, Igniters. We have confusing API in `BinaryObjectBuilder` class. The code below leads to the `ClassCastException` The cause is java method resolution rules [1] > There may be more than one such method, in which case the most specific one > is chosen I suggest to deprecate

Re: BinaryObject API confuses users

u are getting at, can we call it "setFieldNested" instead > or something like that? > > setBinaryField is confusing because we're not passing anything especially > binary, just a nested BinaryObjectBuilder. > > Regards, > -- > Ilya Kasnacheev > > > пт

Re: BinaryObject API confuses users

o create nested binary >> objects, i.e., ones with non-flat structure. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> пт, 6 дек. 2019 г. в 13:45, Николай Ижиков : >> >>> Hello, Ilya. >>> >>> I don’t get your point >>&

Re: Cache operations performance metrics

ng 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 ans

Cache operations performance metrics

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`

Re: The Spark 2.4 support

Hello, Alexey. Can we somehow highlight changes in Spark-2.4 module comparing to 2.3 one? For now the changes look too huge for me (+11,681 −1). Are we sure we want to add those huge piece of code to support two versions? Can we extract unchanged parts(based on spark public API) and keep them in

Re: Thin client: compute support

Hello, Igniters. I think we should support full compute API for the thin clients(at least for the java clients) I think our roadmap should be the following: 1. Execution existing compute tasks by id (as Alex suggested). 2. Deploy and execution arbitrary compute tasks from the java thin client

[MEETUP] 03.12.2019 Moscow

Hello, Igniters. Join us on Ignite meetup! There will be cool old fashioned geeky Ignite talks and a "round table" discussion about Ignite future. It will happen on *December 3 in Moscow* and will be hosted by Sberbank near the subway Kutuzovskaya. Topics: * Ignite affinity function. *

Re: Data consistency essentials explained

Hello, Alex. I think we should improve article formatting - code highlight, fonts, etc. For now, it’s very hard to read it. Can you, please, do it? > 28 нояб. 2019 г., в 09:25, Ivan Pavlukhin написал(а): > > Alexei, > > Many thanks for that article! Really nice that now we have a document >

JDK11. ML module. Compilation error.

Hello, guys. We have a compile error under Java11 in ML module. Can someone take a look? ``` sbt-izhikov-nv:~/src/ignite:[master]$ mvn -version Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T18:06:16+03:00) Maven home: /Users/sbt-izhikov-nv/bin/apache-maven-3.6.2 Java

Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]

Good news, Anton! Thanks for your work on PME feature! > 19 дек. 2019 г., в 21:00, Anton Vinogradov написал(а): > > Folks, > "2.8 + cherrypicked pme-free switch" vs "2.8" check finished, no blockers > found. >

Re: Cache operations performance metrics

ache 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.

Re: Cache operations performance metrics

l cache operation. We have more questions then answers. > >> On the other hand - if `PuTime` increased - then we know for sure, all >> operation executing `put` becomes slower. > > Of course not :) See above. > > On Fri, Dec 20, 2019 at 3:20 PM Николай Ижиков wrote: >

Re: Cache operations performance metrics

sting metrics discussed many > times. No one can explain this metrics to users because it requires > too many additional knowledge about internals. And metric value > itself depends on many aspects of internals. It leads to impossibility > of interpretation. And it's good time to remov

Re: Cache operations performance metrics

PI operations. > >> Why do you think these approaches should exclude one another? > > Because one of them is useless. > > On Fri, Dec 20, 2019 at 1:43 PM Николай Ижиков wrote: >> >> Hello, Andrey. >> >>> Where the sense in this value? I explained wh

Re: Discovery-based services deployment guarantees question

Alexey, are you sure, you are testing new service framework? Is yes - you definitely should file a bug. > 23 дек. 2019 г., в 17:02, Alexey Goncharuk > написал(а): > > Igniters, > > I have a question based on one of my recent tests debugging. > > The test is related to Ignite services. I

Re: Internal classes are exposed in public API

ernal-classes-are-exposed-in-public-API-tp45146p45185.html > > > On Wed, Jan 22, 2020 at 5:21 PM Николай Ижиков wrote: >> >> Hello, Igniters. >> >> * IGNITE-12552: Move ReadOnlyMetricRegistry to public API merged to the >> master and cherry-picked to the

Re: Internal classes are exposed in public API

API intentions - What we want to gain with it? What is our focus? >> 2. Simple, minimal example of API main interfaces and desired usages. > > All this already described at [1]. You also can take a look on PR (see > MetricSource implementations, there are complex and simple ones). >

Re: Internal classes are exposed in public API

ntal API to the > already existing experimental API? Just to making API more > experimental? As I told already it is commit for commit and doesn't > bring any value but brings some inconvenience to me (e.g. merge > problems). > > BTW, does it exist issue about marking IEP-35 API's

Ignite-spring-boot-autoconfigurer

Hello, Igniters. During Ignite meetup I took part in there was a request from the users. They propose to create a custom spring boot autoconfigurer module for Ignite. This module should provide a smooth injection of Ignite to any spring-boot application. I've implemented a tiny straightforward

[DISCUSSION] API to KILL any user started computation

Hello, Igniters. As you may know, we put a lot of effort to improve Ignite metric and diagnostic API. We have created the following API: * Metric manager * System view manager As far as I know, we would have tracing capabilities soon. I think it's time to take the next step. We should

Re: Internal classes are exposed in public API

d name' to the new metric name? I think deprecation of > the public API may be a bit harsh in this case. > > чт, 16 янв. 2020 г. в 16:44, Николай Ижиков : > >> Hello, Alexey. >> >>> * DataRegionMetric public interface is deprecated, however, the >> suggested re

Re: Internal classes are exposed in public API

Hello, Alexey. > * DataRegionMetric public interface is deprecated, however, the suggested > replacement class GridMetricsManager is internal and cannot be acquired by a > user. This makes impossible for the user to fix their code to not use > deprecated API May be it’s not clear text here.

Re: Ignite-spring-boot-autoconfigurer

1-Migrate-Flume-module-to-ignite-extensions-td45010.html > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html > > - > Denis > > > On Sat, Jan 11, 2020 at 10:44 AM

Re: Internal classes are exposed in public API

acade on Ignite interface and add an ability to obtain a metric value > through this facade, not through an exporter. This would be a > straightforward replacement for all old metrics interfaces. > > чт, 16 янв. 2020 г. в 17:13, Николай Ижиков : > >> Ticket to export MetricRegistry

Re: Internal classes are exposed in public API

Ticket to export MetricRegistry to the public API created - https://issues.apache.org/jira/browse/IGNITE-12552 > 16 янв. 2020 г., в 16:58, Николай Ижиков написал(а): > > Do you propose to keep these interfaces forever? > >> 16 янв. 2020 г., в 16:52, Alexey Goncha

Re: [DISCUSSION] API to KILL any user started computation

r local > node specific operation. This invocations not register anywhere and > can't be tracked and killed. > > Unfortunately, the same is valid for some jobs in sense of infinite or > non-interruptible operations. > > On Wed, Jan 15, 2020 at 9:30 PM Николай Ижиков wrote: >&g

Master compilation error

Hello. Igniters. Master build fails: https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead [13:37:02][Step 3/4] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile

Re: Internal classes are exposed in public API

ers. This IEP is a great initiative and you both have already done a >>>> tremendous job by developing, architecting and reviewing changes. Just be >>>> respectful. Nobody is trying to block the feature from being released. >>>> Everyone would be glad to tap into improvem

Re: Internal classes are exposed in public API

283 > 21 янв. 2020 г., в 17:51, Николай Ижиков написал(а): > > Hello, Igniters. > > Alexey approved my PR [1] regarding fixing public API for metric exporters. > I’m waiting for a bot visa and merge this PR. > > As we discussed, the metrics API will be marked with Ignit

Re: Ignite-spring-boot-autoconfigurer

se let me know if you have any feedback. > > Regards, > Saikat > > On Mon, Jan 20, 2020 at 2:42 PM Николай Ижиков wrote: > >> Hello, Saikat. >> >> Thanks, for feedback. >> >> I raised a PR [1] to `ignite-extensions`. >> >>

Re: Internal classes are exposed in public API

onitoring interface, I >> would need to do >> JmxMetricExporterSpi metrics = >> (JmxMetricExporterSpi)ignite.configuration().getMetricExporterSpi()[0]; >> which is too verbose and fragile if someone changes configuration (say, >> inserts another SPI to the first position)

Re: Internal classes are exposed in public API

metric value in my > code as an Ignite user? > > var ignite = Ignition.ignite(); > var totalAllocatedPages = ???; > > On Fri, Jan 17, 2020 at 12:47 AM Николай Ижиков wrote: > >> Hello, Pavel. >> >>> there should be an obvious public API to retrieve met

Re: Ignite-spring-boot-autoconfigurer

64.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html >> [2] >> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html >> >> - >> Denis >> &

Re: Internal classes are exposed in public API

Alex. OK, I may leverage your experience and create pure Java API. Ticket [1] created. But, personally, I don’t agree with you. Ignite has dozens of the API that theoretically have a usage scenario, but in real-world have 0 custom implementation and usages. Moreover, many APIs that were

  1   2   >