Re: TC Bot triggers Run-All using a random JDK version
JDK 12 both Oracle and Open + JDK 13 Open early access builds.
May be suites require additional configuration — I can do this quick.
> On 14 May 2019, at 23:43, Dmitriy Pavlov wrote:
>
> Is Java 12 available on all TeamCity agents?
>
> вт, 14 мая 2019 г. в 23:21, Petr Ivanov :
>
>> How about adding JDK 12 to this list?
>> Or it is a bit prematurely for now?
>>
>>> On 14 May 2019, at 21:02, Dmitriy Pavlov wrote:
>>>
>>> Hi Petr,
>>>
>>> Thank you for your reply. Almost the same term (tag) is used by Bot
>>> internally when the Java version is displayed. So from point of view of
>>> Bot's usability tags are not necessary. From the point of view of main TC
>>> UI - may be.
>>>
>>> About selection options, it is configured at TC Bot server in the main
>>> Bot's config file - branches.json (section is below). Maybe/someday it
>> will
>>> be configured in the UI or taken from TC settings, but now selection
>>> options are duplicated there.
>>>
>>> Sincerely,
>>> Dmitriy Pavlov
>>>
>>> {
>>> "id": "master-nightly",
>>> "chains": [
>>> {
>>> "serverId": "apache",
>>> "suiteId": "IgniteTests24Java8_RunAllNightly",
>>> "branchForRest": "\u003cdefault\u003e",
>>> "triggerBuild": true,
>>> /* Triggering quiet period in minutes. Protects from too-often
>>> triggering in case build is too fast, e.g. compilation failure. */
>>> "triggerBuildQuietPeriod": 30,
>>> /** List of build parameters should be specified for triggering
>>> build. Each parameter should have name and may have randomly selected
>>> or fixed value. */
>>> "triggerParameters": [
>>> {
>>> name: "reverse.dep.*.env.JAVA_HOME",
>>> randomValue: true,
>>> "selection": [
>>> {value:"%env.JDK_ORA_18%", label:"JDK8"},
>>> {value:"%env.JDK_ORA_9%", label:"JDK9"},
>>> {value:"%env.JDK_ORA_10%", label:"JDK10"},
>>> {value:"%env.JDK_OPEN_11%", label:"JDK11"}
>>> ]
>>> }
>>> ]
>>> }
>>> ]
>>>
>>> }
>>>
>>> чт, 9 мая 2019 г. в 20:12, Petr Ivanov :
>>>
I can make builds autotag itself with used JDK.
Also - from what JDKs does randomiser choose?
> On 9 May 2019, at 12:56, Dmitriy Pavlov wrote:
>
> Hi Igniters,
>
> For your information, Apache Ignite TeamCity bot now triggers run all
> (nightly) using some available JDK version (random each time). Used JDK
is
> saved in the Bot DB and is shown at UI (see below).
>
> Next step could be changing the flakyness detection algorithm in the
>> Bot
to
> analyze run history using only a particular Java version.
>
> Sincerely,
> Dmitriy Pavlov
>
> PDS (Compatibility) [ tests 5 ] JDK8
> ⚂ IgniteCompatibilityBasicTestSuite:
>
>> PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_2
> (fail
> rate 28,2%)
> ⚂ IgniteCompatibilityBasicTestSuite:
> FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_2 (fail
rate
> 22,7%)
>
> Cache (Restarts) 1 [ tests 0 TIMEOUT , Exit Code ] JDK11 1 running
Critical
> F.R.: 12,5%
> Thread Dump
>>
>>
Re: TC Bot triggers Run-All using a random JDK version
Is Java 12 available on all TeamCity agents?
вт, 14 мая 2019 г. в 23:21, Petr Ivanov :
> How about adding JDK 12 to this list?
> Or it is a bit prematurely for now?
>
> > On 14 May 2019, at 21:02, Dmitriy Pavlov wrote:
> >
> > Hi Petr,
> >
> > Thank you for your reply. Almost the same term (tag) is used by Bot
> > internally when the Java version is displayed. So from point of view of
> > Bot's usability tags are not necessary. From the point of view of main TC
> > UI - may be.
> >
> > About selection options, it is configured at TC Bot server in the main
> > Bot's config file - branches.json (section is below). Maybe/someday it
> will
> > be configured in the UI or taken from TC settings, but now selection
> > options are duplicated there.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > {
> > "id": "master-nightly",
> > "chains": [
> >{
> > "serverId": "apache",
> > "suiteId": "IgniteTests24Java8_RunAllNightly",
> > "branchForRest": "\u003cdefault\u003e",
> > "triggerBuild": true,
> > /* Triggering quiet period in minutes. Protects from too-often
> > triggering in case build is too fast, e.g. compilation failure. */
> > "triggerBuildQuietPeriod": 30,
> > /** List of build parameters should be specified for triggering
> > build. Each parameter should have name and may have randomly selected
> > or fixed value. */
> > "triggerParameters": [
> >{
> > name: "reverse.dep.*.env.JAVA_HOME",
> > randomValue: true,
> > "selection": [
> >{value:"%env.JDK_ORA_18%", label:"JDK8"},
> >{value:"%env.JDK_ORA_9%", label:"JDK9"},
> >{value:"%env.JDK_ORA_10%", label:"JDK10"},
> >{value:"%env.JDK_OPEN_11%", label:"JDK11"}
> > ]
> >}
> > ]
> >}
> > ]
> >
> > }
> >
> > чт, 9 мая 2019 г. в 20:12, Petr Ivanov :
> >
> >> I can make builds autotag itself with used JDK.
> >>
> >> Also - from what JDKs does randomiser choose?
> >>
> >>> On 9 May 2019, at 12:56, Dmitriy Pavlov wrote:
> >>>
> >>> Hi Igniters,
> >>>
> >>> For your information, Apache Ignite TeamCity bot now triggers run all
> >>> (nightly) using some available JDK version (random each time). Used JDK
> >> is
> >>> saved in the Bot DB and is shown at UI (see below).
> >>>
> >>> Next step could be changing the flakyness detection algorithm in the
> Bot
> >> to
> >>> analyze run history using only a particular Java version.
> >>>
> >>> Sincerely,
> >>> Dmitriy Pavlov
> >>>
> >>> PDS (Compatibility) [ tests 5 ] JDK8
> >>> ⚂ IgniteCompatibilityBasicTestSuite:
> >>>
> >>
> PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_2
> >>> (fail
> >>> rate 28,2%)
> >>> ⚂ IgniteCompatibilityBasicTestSuite:
> >>> FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_2 (fail
> >> rate
> >>> 22,7%)
> >>>
> >>> Cache (Restarts) 1 [ tests 0 TIMEOUT , Exit Code ] JDK11 1 running
> >> Critical
> >>> F.R.: 12,5%
> >>>Thread Dump
> >>
> >>
>
>
Re: TC Bot triggers Run-All using a random JDK version
How about adding JDK 12 to this list?
Or it is a bit prematurely for now?
> On 14 May 2019, at 21:02, Dmitriy Pavlov wrote:
>
> Hi Petr,
>
> Thank you for your reply. Almost the same term (tag) is used by Bot
> internally when the Java version is displayed. So from point of view of
> Bot's usability tags are not necessary. From the point of view of main TC
> UI - may be.
>
> About selection options, it is configured at TC Bot server in the main
> Bot's config file - branches.json (section is below). Maybe/someday it will
> be configured in the UI or taken from TC settings, but now selection
> options are duplicated there.
>
> Sincerely,
> Dmitriy Pavlov
>
> {
> "id": "master-nightly",
> "chains": [
>{
> "serverId": "apache",
> "suiteId": "IgniteTests24Java8_RunAllNightly",
> "branchForRest": "\u003cdefault\u003e",
> "triggerBuild": true,
> /* Triggering quiet period in minutes. Protects from too-often
> triggering in case build is too fast, e.g. compilation failure. */
> "triggerBuildQuietPeriod": 30,
> /** List of build parameters should be specified for triggering
> build. Each parameter should have name and may have randomly selected
> or fixed value. */
> "triggerParameters": [
>{
> name: "reverse.dep.*.env.JAVA_HOME",
> randomValue: true,
> "selection": [
>{value:"%env.JDK_ORA_18%", label:"JDK8"},
>{value:"%env.JDK_ORA_9%", label:"JDK9"},
>{value:"%env.JDK_ORA_10%", label:"JDK10"},
>{value:"%env.JDK_OPEN_11%", label:"JDK11"}
> ]
>}
> ]
>}
> ]
>
> }
>
> чт, 9 мая 2019 г. в 20:12, Petr Ivanov :
>
>> I can make builds autotag itself with used JDK.
>>
>> Also - from what JDKs does randomiser choose?
>>
>>> On 9 May 2019, at 12:56, Dmitriy Pavlov wrote:
>>>
>>> Hi Igniters,
>>>
>>> For your information, Apache Ignite TeamCity bot now triggers run all
>>> (nightly) using some available JDK version (random each time). Used JDK
>> is
>>> saved in the Bot DB and is shown at UI (see below).
>>>
>>> Next step could be changing the flakyness detection algorithm in the Bot
>> to
>>> analyze run history using only a particular Java version.
>>>
>>> Sincerely,
>>> Dmitriy Pavlov
>>>
>>> PDS (Compatibility) [ tests 5 ] JDK8
>>> ⚂ IgniteCompatibilityBasicTestSuite:
>>>
>> PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_2
>>> (fail
>>> rate 28,2%)
>>> ⚂ IgniteCompatibilityBasicTestSuite:
>>> FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_2 (fail
>> rate
>>> 22,7%)
>>>
>>> Cache (Restarts) 1 [ tests 0 TIMEOUT , Exit Code ] JDK11 1 running
>> Critical
>>> F.R.: 12,5%
>>>Thread Dump
>>
>>
Re: TC Bot triggers Run-All using a random JDK version
Hi Petr,
Thank you for your reply. Almost the same term (tag) is used by Bot
internally when the Java version is displayed. So from point of view of
Bot's usability tags are not necessary. From the point of view of main TC
UI - may be.
About selection options, it is configured at TC Bot server in the main
Bot's config file - branches.json (section is below). Maybe/someday it will
be configured in the UI or taken from TC settings, but now selection
options are duplicated there.
Sincerely,
Dmitriy Pavlov
{
"id": "master-nightly",
"chains": [
{
"serverId": "apache",
"suiteId": "IgniteTests24Java8_RunAllNightly",
"branchForRest": "\u003cdefault\u003e",
"triggerBuild": true,
/* Triggering quiet period in minutes. Protects from too-often
triggering in case build is too fast, e.g. compilation failure. */
"triggerBuildQuietPeriod": 30,
/** List of build parameters should be specified for triggering
build. Each parameter should have name and may have randomly selected
or fixed value. */
"triggerParameters": [
{
name: "reverse.dep.*.env.JAVA_HOME",
randomValue: true,
"selection": [
{value:"%env.JDK_ORA_18%", label:"JDK8"},
{value:"%env.JDK_ORA_9%", label:"JDK9"},
{value:"%env.JDK_ORA_10%", label:"JDK10"},
{value:"%env.JDK_OPEN_11%", label:"JDK11"}
]
}
]
}
]
}
чт, 9 мая 2019 г. в 20:12, Petr Ivanov :
> I can make builds autotag itself with used JDK.
>
> Also - from what JDKs does randomiser choose?
>
> > On 9 May 2019, at 12:56, Dmitriy Pavlov wrote:
> >
> > Hi Igniters,
> >
> > For your information, Apache Ignite TeamCity bot now triggers run all
> > (nightly) using some available JDK version (random each time). Used JDK
> is
> > saved in the Bot DB and is shown at UI (see below).
> >
> > Next step could be changing the flakyness detection algorithm in the Bot
> to
> > analyze run history using only a particular Java version.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > PDS (Compatibility) [ tests 5 ] JDK8
> > ⚂ IgniteCompatibilityBasicTestSuite:
> >
> PersistenceBasicCompatibilityTest.testNodeStartByOldVersionPersistenceData_2_2
> > (fail
> > rate 28,2%)
> > ⚂ IgniteCompatibilityBasicTestSuite:
> > FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_2 (fail
> rate
> > 22,7%)
> >
> > Cache (Restarts) 1 [ tests 0 TIMEOUT , Exit Code ] JDK11 1 running
> Critical
> > F.R.: 12,5%
> > Thread Dump
>
>
[jira] [Created] (IGNITE-11852) Assertion errors when changing PME coordinator to locally joining node
Pavel Kovalenko created IGNITE-11852:
Summary: Assertion errors when changing PME coordinator to locally
joining node
Key: IGNITE-11852
URL: https://issues.apache.org/jira/browse/IGNITE-11852
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.7, 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
Fix For: 2.8
When PME coordinator changed to locally joining node several assertion errors
may occur:
1. When some other joining nodes finished PME:
{noformat}
[13:49:58] (err) Failed to notify listener:
o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1...@27296181java.lang.AssertionError:
AffinityTopologyVersion [topVer=2, minorTopVer=0]
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$11.applyx(CacheAffinitySharedManager.java:1546)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager$11.applyx(CacheAffinitySharedManager.java:1535)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.lambda$forAllRegisteredCacheGroups$e0a6939d$1(CacheAffinitySharedManager.java:1281)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10929)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10831)
at
org.apache.ignite.internal.util.IgniteUtils.doInParallel(IgniteUtils.java:10811)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.forAllRegisteredCacheGroups(CacheAffinitySharedManager.java:1280)
at
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onLocalJoin(CacheAffinitySharedManager.java:1535)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.processFullMessage(GridDhtPartitionsExchangeFuture.java:4189)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onBecomeCoordinator(GridDhtPartitionsExchangeFuture.java:4731)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.access$3400(GridDhtPartitionsExchangeFuture.java:145)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:4622)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture$8$1$1.apply(GridDhtPartitionsExchangeFuture.java:4611)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:466)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:281)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:143)
at
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:44)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:398)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:346)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:334)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:510)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:489)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:455)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.InitNewCoordinatorFuture.onMessage(InitNewCoordinatorFuture.java:253)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onReceiveSingleMessage(GridDhtPartitionsExchangeFuture.java:2731)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processSinglePartitionUpdate(GridCachePartitionExchangeManager.java:1917)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1300(GridCachePartitionExchangeManager.java:162)
at
[jira] [Created] (IGNITE-11851) Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch
Ivan Fedotov created IGNITE-11851: - Summary: Cache does not exist after first IgniteContinuousQueryConfigVariationsSuite tests batch Key: IGNITE-11851 URL: https://issues.apache.org/jira/browse/IGNITE-11851 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov IgniteContinuousQueryConfigVariationsSuite tests are generated dynamically. The first batch (12 tests) runs without problems, but on next batches we got an exception - default cache does not exist and we can not invoke unrwap() method on it [1]. It seems that cache is destroyed after the first batch and is not created on the next one. [1] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11850) Missing check atomicity mode on null
Ivan Fedotov created IGNITE-11850: - Summary: Missing check atomicity mode on null Key: IGNITE-11850 URL: https://issues.apache.org/jira/browse/IGNITE-11850 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov In IgniteCacheConfigVariationsFullApiTest#testGetOutTx test fail occurs. getAtomicityMode() method can return null, but test scenario does not take it into consideration. Default cache atomicity mode must be used in case if getAtomicityMode() returns null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11849) Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest
Ivan Fedotov created IGNITE-11849: - Summary: Specify CacheStore in IgniteCacheReadThroughEvictionSelfTest Key: IGNITE-11849 URL: https://issues.apache.org/jira/browse/IGNITE-11849 Project: Ignite Issue Type: Bug Reporter: Ivan Fedotov Assignee: Ivan Fedotov According to the test scenario after expiration entry must be present in IgniteCache - it will be loaded from CacheStore. It is necessary to specify CacheStore in node config. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [IEP-35] Monitoring & Profiling. Proof of concept
Ticket for IEP.Phase1 created - https://issues.apache.org/jira/browse/IGNITE-11848 В Пн, 13/05/2019 в 18:06 +0300, Nikolay Izhikov пишет: > Hello, Igniters. > > We have discussed this IEP [1] with Alexey Goncharyuk, Anton Vinogradov, > Andrey Gura, Alexey Scherbakov and Pavel Kovalenko. > > Issues to address: > > 1. Study experience of following libs, tools: > * OpenTracing > * OpenSensus > * DropWizard > > 2. Support histogram sensor: Sensor that collects values that gets into > predefined segments > > 3. Use more widely used naming(like in OpenSensus?) > > 4. Consider the usage of OpenSensus as a default implementation for local > metric storage. > > 5. To measure the performance penalty for metrics for 5_000 caches. > > 6. Some metrics should be part of public API and others are not(may be > changed/removed in release without warnings). > > My plan for Phase #1 is the following: > > 1. Address the issues. > 2. Prepare public API > 3. Prepare PR for monitoring subsystem + existing metrics rewritten with it. > 4. Prepare a PR with lists of each user API. > 5. Collect feedback for a #4. > 6. Design a log exposer. Consider the usage of JFR format or some other > widely used, tool compatible format. > > [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=112820392 > > В Чт, 02/05/2019 в 14:02 +0300, Nikolay Izhikov пишет: > > Hello, Maxim. > > > > > How will be recorded throughput sensor values which will require an > > > interval for the rate calculations? > > > > I answered to this question in IEP "Design principles": > > > > ``` > > Sensors should contain only raw values. No aggregation of numeric metrics > > on Ignite side. > > Min, max, avg and other functions are the matter of an external monitoring > > system. > > ``` > > > > Throughput is a function `(S(t2) - S(t1))/(t2-t1)` > > where S(t) is the sensor value in some point of time t. > > > > Seems, throughput calculation is a responsibility of an external system. > > > > What do you think? > > > > > It seems to me that we can add an additional parameter of > > > `sensitivityLevel` to provide for the user a flexible sensor control > > > (e.g., INFO, WARN, NOTICE, DEBUG). > > > > For now, I think that all sensors and lists will be very(very!) lightweight. > > So, we should be able to disable/enable it's, for sure. > > > > But, we should turn off and turn on the whole Ignite subsystem > > for the case we have strong performance limitations for a particular > > workload. > > > > So, we have two "level" of monitoring - INFO and DEBUG(for profiling: > > IEP-35 - Phase 3). > > For example, AFAIK we can't disable current SQL system views(Why should we?) > > > > В Вт, 30/04/2019 в 14:33 +0300, Maxim Muzafarov пишет: > > > Hello Nikolay, > > > > > > I've looked through your PRs changes. > > > > > > > Sensors > > > > > > How will be recorded throughput sensor values which will require an > > > interval for the rate calculations? Do we have such an example? For > > > instance, getAllocationRate() or getEvictionRate(). These metrics are > > > out of the scope of current PoC and IEP as they are not related to the > > > user metrics, but it is a good example of a particular metric type. > > > > > > It seems to me that we can add an additional parameter of > > > `sensitivityLevel` to provide for the user a flexible sensor control > > > (e.g., INFO, WARN, NOTICE, DEBUG). > > > > > > It also seems that for the sensors getValue() the completely > > > functional java approach can be used. Am I right? > > > > > > On Mon, 29 Apr 2019 at 11:44, Nikolay Izhikov wrote: > > > > > > > > Hello, Vyacheslav. > > > > > > > > Thanks for the feedback! > > > > > > > > > HttpExposer with Jetty's dependencies should be detached> from the > > > > > core module. > > > > > > > > Agreed. module hierarchy is the essence of the next steps. > > > > For now it just a proof of my ideas for Ignite monitoring we can > > > > discuss. > > > > > > > > > I like your approach with 'wrapper' for monitored objects, like don't > > > > > like using 'ServiceConfiguration' directly as a monitored object for > > > > > services > > > > > > > > Agreed in general. > > > > Seems, choosing the right data to expose is the matter of separate > > > > discussion for each Ignite entities. > > > > I've planned to file tickets for each entity so anyone interested can > > > > share his vision in it. > > > > > > > > > In my opinion, each sensor should have a timestamp. > > > > > > > > I'm not sure that *every* sensor should have directly associated > > > > timestamp. > > > > Seems, we should support sensors without timestamp for a current > > > > monitoring numbers at least. > > > > > > > > > Also, it'd be great to have an ability to store a list of a fixed > > > > > size> of last N sensors > > > > > > > > What use-cases do you know for such sensors? > > > > We have plans to support fixed size lists to show "Last N SQL
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan F., Agree with referring tickets in @Ignore annotation. Currently I have no access to a computer. Will be able to look at updated PR next week. Sent from my iPhone > On 14 May 2019, at 10:55, Ivan Fedotov wrote: > > Ivan P., > I managed with IgniteConfigVariationsAbstractTest - now subclasses enable > [1]. > I ignored all the failed tests that were mentioned in our conversation. If > you don't mind, I can create appropriate tickets and mention them in Ignore > annotation. > > [1] https://github.com/apache/ignite/pull/6434/files > > ср, 1 мая 2019 г. в 15:29, Павлухин Иван : > >> Ivan F., >> >> I think that it is better to enable IgniteConfigVariationsAbstractTest >> subclasses first, so no new broken tests will appear. After that we >> can fix IgniteConfigVariationsAbstractTest subclasses one by one in >> separate ticket(s). >> >> вт, 30 апр. 2019 г. в 13:23, Ivan Fedotov : >>> >>> Ivan R., Ivan P., thank you for the suggestions, I took a look at them. >>> >>> According to checking CacheAtomicityMode on null in >>> IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure >>> that checking should proceed on test level? May be it will be better to >>> make default cache value in case if cc.getAtomicityMode() == null >>> in CacheConfiguration constructor [1]? >>> >>> Also let me suggest one minor change according cache specification in >>> IgniteCacheReadThroughEvictionSelfTest. The same logic is used in >>> GridCacheAbstractSelfTest#cacheConfiguration [2]. >>> I think we can excract this code block in a separate static methods >>> (initCacheConfig, for example) in IgniteCacheReadThroughEvictionSelfTest >> and >>> invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig and >>> GridCacheAbstractSelfTest#cacheConfiguration methods. >>> >>> In addition, I want to draw your attention to >>> IgniteContinuousQueryConfigVariationsSuite test runs [3]. >>> CacheContinuousQueryVariationsTest are generated dynamically. >>> The first batch (12 tests) works fine, but on the next runs we got NPE in >>> IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does >> not >>> exist and we can not >>> invoke unwrap() on this [4]. >>> Seems that the problem is in >>> >> IgniteCacheConfigVariationsAbstractTest#beforeTestsStarted/afterTestsStopped >>> methods, cache is not properly created (or already existed cache is >>> destroyed). >>> >>> By the way, should I resolve these issues in the context of IGNITE-11708 >> or >>> create a separate ticket(s)? >>> >>> [1] >>> >> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java#L434 >>> [2] >>> >> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheAbstractSelfTest.java#L235 >>> [3] >>> >> https://ci.ignite.apache.org/viewLog.html?buildId=3701865=IgniteTests24Java8_RunAllNightly >>> [4] >>> >> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212 >>> >>> пт, 26 апр. 2019 г. в 18:01, Ivan Rakov : >>> Ivan P., Good catch, thanks. I was wrong, test scenario is correct. The problem was in atomicityMode() method - it could have returned null (which was okay >> for config generation, but wasn't expected in the test code). Please take a look at tx_out_test_fixed.patch (attached to IGNITE-11708). To sum it up, both issues should be fixed now. Best Regards, Ivan Rakov > On 26.04.2019 14:40, Павлухин Иван wrote: > Ivan R., > > As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does > not expect lock/unlock events due to line: > if (atomicityMode() == ATOMIC) > return lockEvtCnt.get() == 0; > > Could you please elaborate? > > пт, 26 апр. 2019 г. в 13:32, Ivan Rakov : >> Ivan, >> >> Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test >> scenario assumes that even after expiration entry will be present in >> IgniteCache as per it will be loaded from CacheStore. However, >> CacheStore is not specified in node config. I've added patch that >> enables cache store factory, please check IGNITE-11708 attachments. >> Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* >> tests: >> from my point of view, test scenarios make no sense. We perform >> get() >> operation from ATOMIC caches and expect that entries will be >> locked. I >> don't understand why we should lock entries on ATOMIC get, >> therefore I >> suppose to remove part of code where we listen and check >> EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. >> >> Best Regards, >> Ivan Rakov >> >>> On 17.04.2019 22:05, Ivan Rakov wrote: >>> Hi Ivan, >>> >>> I've checked your branch. Seems like these
[jira] [Created] (IGNITE-11848) [IEP-35] Monitoring Phase 1
Nikolay Izhikov created IGNITE-11848: Summary: [IEP-35] Monitoring Phase 1 Key: IGNITE-11848 URL: https://issues.apache.org/jira/browse/IGNITE-11848 Project: Ignite Issue Type: Task Affects Versions: 2.7 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.8 Umbrella ticket for the IEP-35. Monitoring and profiling. Phase 1 should include: * NextGen monitoring subsystem implementation to manage ** metrics ** lists ** exporters * JMX, SQLView, Log exporters * Migration of existing metrics to new manager * Lists for all Ignite user API -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[Discussion] Documentation process improvement: Release notes
Hi Igniters, During the preparation of release candidate 2.7.5, I’ve missed the development of Release notes for it, and this caused delay for a vote. I want to suggest simple changes in our documentation process. Some time ago Artem B. proposed similar for the doc, but I would like to adapt it for release notes. Let us - Enrich Ignite flags with 'Release Notes required' flag (default is, as always, true) - Add field 'Release Notes' to Ignite project. All tickets with empty Release Notes fields but with flag set may be checked with contributor if it needs to be mentioned in RELEASE_NOTES.txt. If we agree on these changes, I’ll ask infra to add these fields in 3 days. Sincerely, Dmitriy Pavlov
[jira] [Created] (IGNITE-11847) Change note on the capacity planning page about memory usage
Evgenii Zhuravlev created IGNITE-11847: -- Summary: Change note on the capacity planning page about memory usage Key: IGNITE-11847 URL: https://issues.apache.org/jira/browse/IGNITE-11847 Project: Ignite Issue Type: Bug Reporter: Evgenii Zhuravlev https://apacheignite.readme.io/docs/capacity-planning#calculating-memory-usage It says that "Apache Ignite will typically add around 200 bytes overhead to each entry.", but it's not true, I think it was applicable only for 1.x versions, where everything was stored in heap -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfigVariationsAbstractTest subclasses do not run
Ivan P., I managed with IgniteConfigVariationsAbstractTest - now subclasses enable [1]. I ignored all the failed tests that were mentioned in our conversation. If you don't mind, I can create appropriate tickets and mention them in Ignore annotation. [1] https://github.com/apache/ignite/pull/6434/files ср, 1 мая 2019 г. в 15:29, Павлухин Иван : > Ivan F., > > I think that it is better to enable IgniteConfigVariationsAbstractTest > subclasses first, so no new broken tests will appear. After that we > can fix IgniteConfigVariationsAbstractTest subclasses one by one in > separate ticket(s). > > вт, 30 апр. 2019 г. в 13:23, Ivan Fedotov : > > > > Ivan R., Ivan P., thank you for the suggestions, I took a look at them. > > > > According to checking CacheAtomicityMode on null in > > IgniteCacheConfigVariationsAbstractTest#atomicityMode - are you sure > > that checking should proceed on test level? May be it will be better to > > make default cache value in case if cc.getAtomicityMode() == null > > in CacheConfiguration constructor [1]? > > > > Also let me suggest one minor change according cache specification in > > IgniteCacheReadThroughEvictionSelfTest. The same logic is used in > > GridCacheAbstractSelfTest#cacheConfiguration [2]. > > I think we can excract this code block in a separate static methods > > (initCacheConfig, for example) in IgniteCacheReadThroughEvictionSelfTest > and > > invoke it in IgniteCacheReadThroughEvictionSelfTest#variationConfig and > > GridCacheAbstractSelfTest#cacheConfiguration methods. > > > > In addition, I want to draw your attention to > > IgniteContinuousQueryConfigVariationsSuite test runs [3]. > > CacheContinuousQueryVariationsTest are generated dynamically. > > The first batch (12 tests) works fine, but on the next runs we got NPE in > > IgniteCacheConfigVariationsAbstractTest#afterTest - default cache does > not > > exist and we can not > > invoke unwrap() on this [4]. > > Seems that the problem is in > > > IgniteCacheConfigVariationsAbstractTest#beforeTestsStarted/afterTestsStopped > > methods, cache is not properly created (or already existed cache is > > destroyed). > > > > By the way, should I resolve these issues in the context of IGNITE-11708 > or > > create a separate ticket(s)? > > > > [1] > > > https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/configuration/CacheConfiguration.java#L434 > > [2] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/GridCacheAbstractSelfTest.java#L235 > > [3] > > > https://ci.ignite.apache.org/viewLog.html?buildId=3701865=IgniteTests24Java8_RunAllNightly > > [4] > > > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L212 > > > > пт, 26 апр. 2019 г. в 18:01, Ivan Rakov : > > > > > Ivan P., > > > > > > Good catch, thanks. > > > > > > I was wrong, test scenario is correct. The problem was in > > > atomicityMode() method - it could have returned null (which was okay > for > > > config generation, but wasn't expected in the test code). > > > Please take a look at tx_out_test_fixed.patch (attached to > > > IGNITE-11708). To sum it up, both issues should be fixed now. > > > > > > Best Regards, > > > Ivan Rakov > > > > > > On 26.04.2019 14:40, Павлухин Иван wrote: > > > > Ivan R., > > > > > > > > As I can see IgniteCacheConfigVariationsFullApiTest#testGetOutTx does > > > > not expect lock/unlock events due to line: > > > > if (atomicityMode() == ATOMIC) > > > > return lockEvtCnt.get() == 0; > > > > > > > > Could you please elaborate? > > > > > > > > пт, 26 апр. 2019 г. в 13:32, Ivan Rakov : > > > >> Ivan, > > > >> > > > >> Seems like IgniteCacheReadThroughEvictionSelfTest is broken. Test > > > >> scenario assumes that even after expiration entry will be present in > > > >> IgniteCache as per it will be loaded from CacheStore. However, > > > >> CacheStore is not specified in node config. I've added patch that > > > >> enables cache store factory, please check IGNITE-11708 attachments. > > > >> Regarding IgniteCacheConfigVariationsFullApiTest#testGetOutTx* > tests: > > > >> from my point of view, test scenarios make no sense. We perform > get() > > > >> operation from ATOMIC caches and expect that entries will be > locked. I > > > >> don't understand why we should lock entries on ATOMIC get, > therefore I > > > >> suppose to remove part of code where we listen and check > > > >> EVT_CACHE_OBJECT_LOCKED/UNLOCKED events. > > > >> > > > >> Best Regards, > > > >> Ivan Rakov > > > >> > > > >> On 17.04.2019 22:05, Ivan Rakov wrote: > > > >>> Hi Ivan, > > > >>> > > > >>> I've checked your branch. Seems like these tests fail due to real > > > >>> issue in functionality. > > > >>> I'll take a look. > > > >>> > > > >>> Best Regards, > > > >>> Ivan Rakov > > > >>> > > > >>> On 17.04.2019 13:54, Ivan Fedotov wrote: > > > Hi,
