[jira] [Created] (IGNITE-8956) Javadoc Warnings:core/src/main/java/org/apache/ignite/internal/processors/cache/WalStateManager.java:1271: warning - @inheritDoc used but check() does not override or im
kcheng.mvp created IGNITE-8956: -- Summary: Javadoc Warnings:core/src/main/java/org/apache/ignite/internal/processors/cache/WalStateManager.java:1271: warning - @inheritDoc used but check() does not override or implement any method. Key: IGNITE-8956 URL: https://issues.apache.org/jira/browse/IGNITE-8956 Project: Ignite Issue Type: Bug Reporter: kcheng.mvp Checked the history, seems it's caused by the checkin for https://issues.apache.org/jira/browse/IGNITE-8827 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4327: Ignite-8955
GitHub user EdShangGG opened a pull request: https://github.com/apache/ignite/pull/4327 Ignite-8955 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8955-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4327.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4327 commit 6e733771eb4b159cae739d0a2cc9e9c1b1069210 Author: EdShangGG Date: 2018-07-07T00:48:26Z Deadlock on eviction Signed-off-by: EdShangGG commit 45322b987c782a4ad6b9328442d746099246b4d7 Author: EdShangGG Date: 2018-07-07T00:49:29Z IGNITE-8955 Signed-off-by: EdShangGG commit 47c2ce1329b51f11738fefe766d7b9b8c209ef6d Author: EdShangGG Date: 2018-07-06T20:38:20Z IGNITE-8955 Signed-off-by: EdShangGG (cherry picked from commit 29a3e21) Signed-off-by: EdShangGG ---
Review for IGNITE-8880: Add setIgnite() in SpringCacheManager and SpringTransactionManager
Igniters, Please review my changes. That's a simple change, a setter method was added. Thanks, Amir
[GitHub] ignite pull request #4326: IGNITE-8880: Add setIgnite() in SpringCacheManage...
GitHub user amirakhmedov opened a pull request: https://github.com/apache/ignite/pull/4326 IGNITE-8880: Add setIgnite() in SpringCacheManager and SpringTransact⦠â¦ionManager You can merge this pull request into a Git repository by running: $ git pull https://github.com/amirakhmedov/ignite IGNITE-8880 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4326.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4326 commit 364d9b3071d01c40fba19c9443a278aa2c44c8c8 Author: Amir Akhmedov Date: 2018-07-06T23:16:01Z IGNITE-8880: Add setIgnite() in SpringCacheManager and SpringTransactionManager ---
[GitHub] ignite pull request #4325: IGNITE-8869: Exclude daemon's nodes from Exchange...
GitHub user ivandasch opened a pull request: https://github.com/apache/ignite/pull/4325 IGNITE-8869: Exclude daemon's nodes from ExchangeLatch. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ivandasch/ignite ignite-8869-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4325.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4325 commit b9f0494e13159bd200bc305ddb793fd97ff41bd6 Author: Ivan Daschinskiy Date: 2018-07-06T21:34:02Z IGNITE-8869: Exclude daemon's nodes from ExchangeLatch. ---
Re: Add cluster (de)activation events IGNITE-8376
What is the difference between a lifecycle even and regular events? On Fri, Jul 6, 2018 at 12:25 AM, Evgenii Zhuravlev wrote: > I've linked them as duplicates, however, one ticket suggests to add > Lifecycle events, while another is for adding our simple events > from EventType > > Evgenii > > 2018-07-06 1:10 GMT+03:00 Dmitriy Setrakyan : > > > On Thu, Jul 5, 2018 at 1:55 AM, Evgenii Zhuravlev < > > e.zhuravlev...@gmail.com> > > wrote: > > > > > Guys, > > > > > > Do we really need events for activation/deactivation? We already have a > > > ticket for implementation lifecycle events for it: > > > https://issues.apache.org/jira/browse/IGNITE-5427, won't it be enough? > > > > > > > Hm... I think these two tickets are duplicates of one another, no? > > >
Re: IgniteConfiguration, toString(), @GridToStringInclude
Can we print out the configuration to a separate file? Moreover, I think we should also print out the configuration differences between nodes, whenever new nodes join topology. D. On Fri, Jul 6, 2018 at 6:51 AM, Ilya Kasnacheev wrote: > Hello! > > I was working on https://issues.apache.org/jira/browse/IGNITE-8935 to > avoid > default toString() implementations in classes reachable from > IgniteConfiguration, which we print on start-up. > > I have discovered that by default we avoid printing arrays and collections. > We only print those when marked with @GridToStringInclude. This to avoid > serializing endless auto-generated lists I suppose. > > And I was thinking of going through IgniteConfiguration and friends, > marking some user-specified collections @GridToStringInclude so that they > show up in toString(). The most notorious one will be > IgniteConfiguration.cacheConfigurations. > > What's your take on this one? On one hand, cache configurations are of > tremendous significance to anybody debugging Ignite, or troubleshooting > user cases on e.g. userlist. > On other hand, some people have configurations with thousands of caches and > might be not completely happy with several megabytes of log within a single > line. > > Should I mark caches configurations (and also service configurations, and > others) with @GridToStringInclude or not? I think that the only place where > it gets printed is once on the start when IGNITE_QUIET is false. > > I will defer doing that until aforementioned ticket is merged, so please > take a look at it if you're interested. > > Regards, > > -- > Ilya Kasnacheev >
[jira] [Created] (IGNITE-8955) Checkpoint can't get write lock if massive eviction on node start started
Eduard Shangareev created IGNITE-8955: - Summary: Checkpoint can't get write lock if massive eviction on node start started Key: IGNITE-8955 URL: https://issues.apache.org/jira/browse/IGNITE-8955 Project: Ignite Issue Type: Bug Reporter: Eduard Shangareev Many sys-threads start eviction and start being throttled, so they couldn't proceed because of it, while checkpoint couldn't start because they hold checkpoint read lock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts
Stan, Can you explain the semantics of both parameters? How do they behave when set on client or on server? -Val On Fri, Jul 6, 2018 at 6:12 AM Stanislav Lukyanov wrote: > We could just use failureDetectionTimeout all the time I guess. > The only benefit of clientFailureDetectionTimeout is that it may allow > clients to be slower/on a slower network than servers. > > Do you think it isn’t worth to have a separate setting just for that? > > Thanks, > Stan > > From: Valentin Kulichenko > Sent: 5 июля 2018 г. 18:16 > To: dev@ignite.apache.org > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > TcpCommunicationSpitimeouts > > Stan, > > What is the purpose of clientFailureDetectionTimeout? Why can't we just > always use failureDetectionTimeout? Is there any difference between these > two timeouts? > > -Val > > > > On Wed, Jul 4, 2018 at 7:00 AM Stanislav Lukyanov > wrote: > > > Hi, > > > > I’ve updated the proposed documentation update with a description of > > metricsUpdateFrequency and a detailed description of > > failureDetectionTimeout and clientFailureDetectionTimeout relations. The > > draft is attached to https://issues.apache.org/jira/browse/IGNITE-7704. > > > > It seems that relation between failureDetectionTimeout and > > clientFailureDetectionTimeout is currently too tricky and should also be > > changed in future. > > The problem is that in a server-client connection the server will use > > clientFailureDetectionTimeout but client will use > failureDetectionTimeout. > > In other words, clients ignore clientFailureDetectionTimeout and just use > > failureDetectionTimeout. Because of that, one has to provide different > > values of failureDetectionTimeout in server and client configs which > seems > > confusing and inconvenient. > > So I’d like to add one more point to my earlier proposal: > > > > 5. Always use clientFailureDetectionTimeout on clients instead of > > failureDetectionTimeout > > *What*: change code to use clientFailureDetectionTimeout on clients > > *When*: update code and readme.io docs in 2.7 > > > > Thanks, > > Stan > > > > From: Valentin Kulichenko > > Sent: 30 мая 2018 г. 19:09 > > To: dev@ignite.apache.org > > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > > TcpCommunicationSpitimeouts > > > > Stan, > > > > Looks like you suggest to only change the default. If so, it's OK. But > > let's not change the behavior of these timeouts for the case they are > > explicitly set in config. > > > > Thanks, > > Val > > > > On Wed, May 30, 2018 at 1:06 AM, Stanislav Lukyanov < > > stanlukya...@gmail.com> > > wrote: > > > > > On networkTimeout: no, we don’t have anything like that in > > > TcpCommunicationSpi. > > > > > > On socketWriteTimeout: > > > First, its semantic is very close to TcpDicsoverySpi.socketTimeout > (with > > > the exception that communication uses NIO), and the latter defaults to > > > failureDetectionTimeout, > > > so I think it would help to avoid confusion. > > > Second, I think we can’t deprecate something without an alternative > that > > > would work for most users. > > > On the other hand, if we do default socketWriteTimeout to > > > failureDetectionTimeout then we reach a pretty decent API state > > > where one only needs two properties in IgniteConfiguration neither of > > > which we’re considering for deprecation and removal in 3.0. > > > > > > Stan > > > > > > From: Valentin Kulichenko > > > Sent: 29 мая 2018 г. 22:17 > > > To: dev@ignite.apache.org > > > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > > > TcpCommunicationSpitimeouts > > > > > > Stan, > > > > > > OK, I got confused a little :) > > > > > > I do agree that TcpDiscoverySpi.networkTimeout should inherit from > > > IgniteConfiguration.networkTImeout if not set explicitly. Do we have > the > > > same setting for TcpCommunicationSpi, BTW? If yes, behavior should be > > > consistent. > > > > > > As for TcpCommunicationSpi.socketWriteTimeout, I'm not sure why you > want > > > to > > > change its behavior. Can we just deprecate it and eventually remove, > just > > > as we plan to do for all timeouts from #2? > > > > > > -Val > > > > > > On Tue, May 29, 2018 at 3:50 AM, Stanislav Lukyanov < > > > stanlukya...@gmail.com> > > > wrote: > > > > > > > Val, > > > > > > > > Which timeouts do you mean? > > > > > > > > In #2 I don’t propose to change behavior. > > > > > > > > I propose to change behavior for a couple of settings in #3 though. > > > > I believe the correct approach here would be to target the behavior > > > change > > > > for 2.6, > > > > but keep in mind that we’ll need to carefully analyze the impact > before > > > > actually making the changes. > > > > > > > > Thanks, > > > > Stan > > > > > > > > From: Valentin Kulichenko > > > > Sent: 29 мая 2018 г. 0:57 > > > > To: dev@ignite.apache.org > > > > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > > > > TcpCommunicationSpitimeouts > > > > > > > > Hi Stan, > > > > > > > > I'm 100% for this activity, however I don't think we
[GitHub] ignite pull request #4302: IGNITE-8904 Check rebalance config on consistency
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4302 ---
[GitHub] ignite pull request #4324: IGNITE-8946 AssertionError can occur during relea...
GitHub user glukos opened a pull request: https://github.com/apache/ignite/pull/4324 IGNITE-8946 AssertionError can occur during release of WAL history th⦠â¦at was reserved for historical rebalance You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8946 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4324.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4324 commit 0e1d72a90847c3f8131c626a430fd315da9f0c7e Author: Ivan Rakov Date: 2018-07-06T18:10:01Z IGNITE-8946 AssertionError can occur during release of WAL history that was reserved for historical rebalance ---
Re: .NET tests fail on Linux - need help with TeamCity
Pavel, The only newtonsoft.json found are /usr/share/dotnet/sdk/NuGetFallbackFolder/newtonsoft.json (versions 9.0.1 and 10.0.1) and /usr/share/dotnet/store/x64/netcoreapp2.0/newtonsoft.json (version 10.0.1). There is nothing in .nuget/packages. The sizes of corresponding Newtonsoft.Json.dll are as follows: 625K :: /usr/share/dotnet/sdk/NuGetFallbackFolder/newtonsoft.json/10.0.1/lib/netstandard1.3/Newtonsoft.Json.dll 1.8M :: /usr/share/dotnet/store/x64/netcoreapp2.0/newtonsoft.json/10.0.1/lib/netstandard1.3/Newtonsoft.Json.dll I’m not sure I should move the /usr/share based directories for tests but if it the case, I can do it carefully. BTW, on the agent where all tests are passed the same file exists as aforementioned ones, no obvious differences. > On 6 Jul 2018, at 12:15, Pavel Tupitsyn wrote: > > Petr, > > - Get the sources > - cd modules/platforms/dotnet/Apache.Ignite.Core.Tests.DotNetCore > - dotnet build > > You should get a warning "warning MSB3246: Resolved file has a bad image, > no metadata, or is otherwise inaccessible. Image is too small." > If you do, go ahead: > > - cd ~/.nuget/packages/newtonsoft.json > - let me know which versions are there and what are the sizes > of lib/netstandard1.3/Newtonsoft.Json.dll files in them > - delete the whole newtonsoft.json directory and try the build again, will > it fail? > > Thanks, > Pavel > > On Thu, Jul 5, 2018 at 11:38 AM Petr Ivanov wrote: > >> I can. >> >> >> Can you prepare reproduce steps so that I’ll be able to pinpoint the >> problem faster, please? >> >> >>> On 5 Jul 2018, at 11:25, Pavel Tupitsyn wrote: >>> >>> Igniters, >>> >>> I need help with TeamCity. >>> .NET Linux Tests [1] fail for a very weird reason: >>> Newtonsoft.Json.dll seems to be corrupted or empty " *Image is too >> small.* >>> ". >>> I tried adding a step to clean NuGet caches, but it does not help. >>> >>> On my Ubuntu box tests pass. And there were no changes to .NET lately, so >>> this failure seems to be TC-related only. >>> >>> Can someone with TeamCity agent access help me with this and check where >>> that file comes from and what does it look like? >>> >>> Thanks, >>> Pavel >>> >>> [1] >>> >> https://ci.ignite.apache.org/viewLog.html?buildId=1454493=buildResultsDiv=IgniteTests24Java8_PlatformNetCoreLinux >> >>
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
Eventually, everything is green! https://ci.ignite.apache.org/viewLog.html?buildId=1462771=buildResultsDiv=IgniteTests24Java8_RunBasicTests thank you all very much! -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[jira] [Created] (IGNITE-8954) Rebalance has restarted fully after reassigning missing partitions
Sergey Kosarev created IGNITE-8954: -- Summary: Rebalance has restarted fully after reassigning missing partitions Key: IGNITE-8954 URL: https://issues.apache.org/jira/browse/IGNITE-8954 Project: Ignite Issue Type: Bug Affects Versions: 2.5 Reporter: Sergey Kosarev *Rebalance finished with missing partitions* : 2018-07-06 00:59:16.118[INFO ][sys-#718%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander] Completed (final) rebalancing [fromNode=e1ee8729-8a6f-479e-9f39-614605d3147f, cacheOrGroup=CACHEGROUP_PARTICLE_union-module_com.sbt.aep.dpl.dictionaries.SubDiv, topology=AffinityTopologyVersion [topVer=344, minorTopVer=1], time=61 ms] 2018-07-06 00:59:16.118[INFO ][sys-#718%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander] Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=CACHEGROUP_PARTICLE_union-module_com.sbt.aep.dpl.dictionaries.SubDiv], topVer=AffinityTopologyVersion [topVer=344, minorTopVer=1], rebalanceId=453] 2018-07-06 00:59:16.118[INFO ][sys-#718%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander] Reassigning partitions that were missed: [10240, 12291, 11781, 11270, 11783, 10247, 12295, 12296, 9737, 12810, 11275, 10251, 12303, 11794, 11285, 10774, 10777, 11292, 10270, 12323, 11812, 10279, 12841, 9769, 10794, 10282, 10283, 12844, 11827, 9779, 11830, 12856, 10301, 9791, 11840, 12868, 10312, 11336, 9803, 10834, 11858, 12371, 10328, 11353, 10331, 12891, 12892, 10845, 12384, 11875, 12905, 10346, 11373, 10862, 9840, 10866, 10355, 10356, 12404, 12405, 12918, 11895, 11896, 10872, 10360, 11384, 9849, 9850, 11387, 10875, 10368, 12933, 10376, 10890, 11403, 10893, 12431, 11407, 10384, 12433, 11923, 10900, 9877, 11413, 9878, 11927, 12952, 10906, 11418, 10394, 11931, 10395, 11419, 9885, 11934, 10912, 11937, 11425, 11426, 12966, 10412, 12975, 12464, 10929, 12978, 11954, 10931, 11956, 9910, 10935, 11967, 12992, 10437, 11974, 9928, 13000, 10440, 12489, 11977, 9931, 10445, 11469, 10960, 10962, 11475, 10968, 11994, 10459, 13020, 11484, 12509, 10975, 10465, 10468, 9957, 10981, 13039, 9969, 12018, 11506, 13044, 13047, 11000, 9978, 11516, 12540, 12541, 12542, 11519, 12032, 11009, 11522, 12037, 12549, 12550, 10503, 12039, 12040, 13066, 10509, 11533, 12047, 13071, 13073, 12562, 10514, 11026, 12050, 10005, 10518, 11033, 13081, 11548, 13087, 12064, 13092, 11044, 10021, 12583, 10537, 11561, 10538, 11564, 10543, 10546, 13106, 10034, 10038, 12088, 11065, 10558, 11070, 13118, 11075, 12611, 10054, 11078, 12616, 11081, 11082, 10571, 10059, 13135, 11088, 11602, 12116, 10584, 13145, 11610, 10587, 13149, 12638, 13152, 12128, 12641, 10081, 12130, 12131, 12643, 10598, 12134, 10086, 13160, 10089, 11626, 10602, 13166, 10094, 12142, 13167, 10096, 10608, 10610, 10612, 12662, 13175, 10106, 11131, 12164, 12166, 13190, 10631, 10121, 10128, 12177, 11158, 12185, 11161, 13210, 10650, 11675, 11166, 12711, 11176, 10152, 11688, 10665, 11691, 10667, 11181, 12207, 13231, 10673, 12721, 11701, 10166, 10168, 12732, 10685, 10173, 11709, 1, 12223, 10687, 12737, 11716, 13259, 11211, 12236, 11725, 12749, 10190, 11728, 10707, 13273, 10201, 12250, 12762, 11741, 13279, 10207, 11231, 11744, 10208, 10721, 11745, 12260, 12776, 12777, 12270, 13294, 12272, 10739, 11763, 12276, 10230, 11254, 11767, 9724, 10239, 12799, 12287] 2018-07-06 00:59:16.118[INFO ][sys-#718%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander] [REB] Done as missed CACHEGROUP_PARTICLE_union-module_com.sbt.aep.dpl.dictionaries.SubDiv, parts=[10059, 10173, 10190, 10279, 1 2131, 12166], dir=[topVer=(344, 1), idx=4, sup=10.124.128.195:47500] 2018-07-06 00:59:16.118[INFO ][sys-#718%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander] [REB] Stop demand CACHEGROUP_PARTICLE_union-module_com.sbt.aep.dpl.dictionaries.SubDiv, futDone=true, topCh=false,dir=[topVer=( 344, 1), idx=4, sup=10.124.128.195:47500] *And then restarted again:* 2018-07-06 00:59:17.657[INFO ][exchange-worker-#152%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager] Rebalancing scheduled [order=[ignite-sys-cache, BGP_Locks_auto-transact, CACHEGROUP_PARTICLE_union-module_com.sbt.acquiring.processing.entities.dictionaries.PublishedDepTerBank, ,CACHEGROUP_PARTICLE_union-module_com.sbt.aep.dpl.dictionaries.SubDiv, ...]] 2018-07-06 00:59:17.657[INFO ][exchange-worker-#152%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.GridCachePartitionExchangeManager] Rebalancing started [top=null, evt=DISCOVERY_CUSTOM_EVT, node=60221959-ecd9-42af-b3b9-99a9b0fdceea] 2018-07-06 00:59:17.657[INFO ][exchange-worker-#152%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.d.d.p.GridDhtPartitionDemander] Starting rebalancing [grp=ignite-sys-cache, mode=SYNC, fromNode=8dabf12b-2872-4b88-be14-6a66b16146e9, nodeConsId=10.124.128.199:47500,
[GitHub] ignite pull request #4323: Ignite 8322 fix
GitHub user oleg-ostanin opened a pull request: https://github.com/apache/ignite/pull/4323 Ignite 8322 fix You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8322-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4323.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4323 commit b6037c37cdc34ca8f964b7af30835b2474ca9db2 Author: oleg-ostanin Date: 2018-06-18T07:17:36Z IGNITE-8322 changed default value for preloading option to 'false' commit 9b6571bdfab8fb0f6b64c9f502437091347e Author: oleg-ostanin Date: 2018-06-19T07:24:51Z IGNITE-8322 changed data region name setting logic commit 362309ba3fc3b670b0e95828dd2758c9d10e36b7 Author: oleg-ostanin Date: 2018-06-19T09:55:14Z IGNITE-8322 added data region name log output commit 6f6f9089dd88d3a22d0563fd6558ef1b4823bfab Author: oleg-ostanin Date: 2018-06-19T10:04:26Z IGNITE-8322 added data reg. cfg array checking commit 96c156ceef8bb941ab833994f816efd7babec821 Author: oleg-ostanin Date: 2018-07-02T13:27:46Z fixed Loader class commit d83facc28d75db63aeec58a6f1eed1ff71d95290 Author: oleg-ostanin Date: 2018-07-06T07:28:15Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-8322-fix ---
Re: Stable/experimental releases
Hi Dmitry, I think maintenance release is fine only if they will include ONLY fixes. This will allow to release more frequently, so we do not have to wait when collect some number of fixes to make a next major version. So each major release could be named as experimental, and maintenance - stable. Thanks! 06.07.2018 16:47, Dmitry Pavlov пишет: Hi Igniters, here I will extremely appreciate vision from community members invoved into release. What is simpler, support 2.7-EA- or 2.7.x? Taking into account Teamcity state, it is quite honest to have experimental releases to underline that - a lot of new code introduced - and probably new feateure will be more stable in later release. WDYT? Sincerely, Dmitriy Pavlov чт, 5 июл. 2018 г. в 17:53, Vladimir Ozerov : Hi Dmitriy, AFAIK we have an idea to introduce maintenance releases for Ignite. E.g. 2.6.0 - features, 2.6.1+ - stabilization. This seems to be more standard and flexible approach. чт, 5 июля 2018 г. в 17:39, Dmitry Karachentsev < dkarachent...@gridgain.com : Hi igniters! Following our discussions about emergency releases I see that here might be applied new way for doing releases. Like it was for Linux or like it is for Ubuntu. I mean do interleaving releases: first is experimental with newest features and second - with bug fixes ONLY. For example, odd version number is unstable and even is stable: 2.5 introduces a lot of new features, when 2.6 brings more stability to product. Pros: 1. User always has a choice what to choose: cutting edge technology or release that has less problems. 2. It will be much easier to add more effort to make TC green again, as fixes are not mixed with features. 3. We may spend more time on prepare stable release and do more rigorous testing. 4. Stable release may keep 100% compatibility to previous release (not always, of course) to make it easier to migrate and take important bug fixes without introducing a new ones. 5. Not all users will fall in critical issues, in other words, only some group of users will try to use unstable release with experimental features. Cons: 1. Necessity of keeping two branches simultaneous: master and stable release. Migrate fixes between branches. 2. Less users could report about found issues, as consequence of item #5 from pros. 3. A bit more complex release procedure??? I think it's common and right way to create a less buggy product. What do you think? Thanks!
RE: Move CacheStore::loadCache to a separate interface
Not really, extracting a method to a superinterface is a fully compatible change. There won’t be any compatibility issues because of this (disregarding possible bugs, of course ;) ). In any case, I’m not planning to fix it right away – this isn’t anywhere near critical or urgent, obviously. I think it would be a nice newbie ticket. Stan From: Dmitry Pavlov Sent: 6 июля 2018 г. 16:25 To: dev@ignite.apache.org Subject: Re: Move CacheStore::loadCache to a separate interface As far as I understand we should to wait 3.0, shouldn't we? пт, 6 июл. 2018 г. в 16:17, Stanislav Lukyanov : > Hi Igniters, > > I’ve just created a ticket to move CacheStore::loadCache to a separate > interface: > https://issues.apache.org/jira/browse/IGNITE-8952 > In short, this is to provide a way to only implement loadCache without > messing with other methods CacheStore implements. More details are in the > JIRA. > I believe this would make the API a bit cleaner than it is right now. > > This is a small change, I just wanted to highlight it on the dev-list as > it’s a proposed adjustment to a very old core API. > Feel free to comment here or in JIRA. > > Thanks, > Stan >
IgniteConfiguration, toString(), @GridToStringInclude
Hello! I was working on https://issues.apache.org/jira/browse/IGNITE-8935 to avoid default toString() implementations in classes reachable from IgniteConfiguration, which we print on start-up. I have discovered that by default we avoid printing arrays and collections. We only print those when marked with @GridToStringInclude. This to avoid serializing endless auto-generated lists I suppose. And I was thinking of going through IgniteConfiguration and friends, marking some user-specified collections @GridToStringInclude so that they show up in toString(). The most notorious one will be IgniteConfiguration.cacheConfigurations. What's your take on this one? On one hand, cache configurations are of tremendous significance to anybody debugging Ignite, or troubleshooting user cases on e.g. userlist. On other hand, some people have configurations with thousands of caches and might be not completely happy with several megabytes of log within a single line. Should I mark caches configurations (and also service configurations, and others) with @GridToStringInclude or not? I think that the only place where it gets printed is once on the start when IGNITE_QUIET is false. I will defer doing that until aforementioned ticket is merged, so please take a look at it if you're interested. Regards, -- Ilya Kasnacheev
[jira] [Created] (IGNITE-8953) Test fail: Bind address already in use(TcpDiscoverySpiFailureTimeoutSelfTest)
Anton Kalashnikov created IGNITE-8953: - Summary: Test fail: Bind address already in use(TcpDiscoverySpiFailureTimeoutSelfTest) Key: IGNITE-8953 URL: https://issues.apache.org/jira/browse/IGNITE-8953 Project: Ignite Issue Type: Test Reporter: Anton Kalashnikov During execution beforeTestsStarted in TcpDiscoverySpiFailureTimeoutSelfTest, TcpDiscoverySpiSelfTest, registration of MBean server failed with error "Bind address already in use" but tests continue to execute because try-catch block. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Stable/experimental releases
Hi Igniters, here I will extremely appreciate vision from community members invoved into release. What is simpler, support 2.7-EA- or 2.7.x? Taking into account Teamcity state, it is quite honest to have experimental releases to underline that - a lot of new code introduced - and probably new feateure will be more stable in later release. WDYT? Sincerely, Dmitriy Pavlov чт, 5 июл. 2018 г. в 17:53, Vladimir Ozerov : > Hi Dmitriy, > > AFAIK we have an idea to introduce maintenance releases for Ignite. E.g. > 2.6.0 - features, 2.6.1+ - stabilization. > > This seems to be more standard and flexible approach. > > чт, 5 июля 2018 г. в 17:39, Dmitry Karachentsev < > dkarachent...@gridgain.com > >: > > > Hi igniters! > > > > Following our discussions about emergency releases I see that here might > > be applied new way for doing releases. Like it was for Linux or like it > > is for Ubuntu. I mean do interleaving releases: first is experimental > > with newest features and second - with bug fixes ONLY. > > > > For example, odd version number is unstable and even is stable: 2.5 > > introduces a lot of new features, when 2.6 brings more stability to > > product. > > > > Pros: > > > > 1. User always has a choice what to choose: cutting edge technology or > > release that has less problems. > > > > 2. It will be much easier to add more effort to make TC green again, as > > fixes are not mixed with features. > > > > 3. We may spend more time on prepare stable release and do more rigorous > > testing. > > > > 4. Stable release may keep 100% compatibility to previous release (not > > always, of course) to make it easier to migrate and take important bug > > fixes without introducing a new ones. > > > > 5. Not all users will fall in critical issues, in other words, only some > > group of users will try to use unstable release with experimental > features. > > > > Cons: > > > > 1. Necessity of keeping two branches simultaneous: master and stable > > release. Migrate fixes between branches. > > > > 2. Less users could report about found issues, as consequence of item #5 > > from pros. > > > > 3. A bit more complex release procedure??? > > > > I think it's common and right way to create a less buggy product. > > > > What do you think? > > > > Thanks! > > > > > > >
Re: Why GridCacheEvictionManager always use cfg.getEvictionPolicy/cfg.getEvictionPolicyFactory even there is NearEvictionPolicy configured?
Hi,
Is this question related to some contribution? If not, probably user@ list
is better place to ask, even if question is advanced. Community members
monitors user list, so even advanced question can find asnwer there.
Dev@ list is intended for discussions related to particular contributions,
PRs, tickests, test failures, proposed changes, development infra, etc.
Sincerely,
Dmitriy Pavlov
чт, 5 июл. 2018 г. в 7:21, kcheng.mvp :
> As the method
> *org.apache.ignite.internal.processors.cache.GridCacheAdapter#isNear*
> always
> returns false, it will make the near cache eviction policy don't take
> effect. Here is the code from
>
> *org.apache.ignite.internal.processors.cache.GridCacheEvictionManager#start0*.
> is this an expected behavior ?
> ==
> CacheConfiguration cfg = cctx.config();
>
> if (cctx.isNear()) {
> plc =
> (cfg.getNearConfiguration().getNearEvictionPolicyFactory()
> != null) ?
>
>
> (EvictionPolicy)cfg.getNearConfiguration().getNearEvictionPolicyFactory().create()
> :
> cfg.getNearConfiguration().getNearEvictionPolicy();
> }
> else if (cfg.getEvictionPolicyFactory() != null)
> plc = (EvictionPolicy)cfg.getEvictionPolicyFactory().create();
> else
> plc = cfg.getEvictionPolicy();
>
> plcEnabled = plc != null;
>
> filter = cfg.getEvictionFilter();
> ==
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
Re: Move CacheStore::loadCache to a separate interface
As far as I understand we should to wait 3.0, shouldn't we? пт, 6 июл. 2018 г. в 16:17, Stanislav Lukyanov : > Hi Igniters, > > I’ve just created a ticket to move CacheStore::loadCache to a separate > interface: > https://issues.apache.org/jira/browse/IGNITE-8952 > In short, this is to provide a way to only implement loadCache without > messing with other methods CacheStore implements. More details are in the > JIRA. > I believe this would make the API a bit cleaner than it is right now. > > This is a small change, I just wanted to highlight it on the dev-list as > it’s a proposed adjustment to a very old core API. > Feel free to comment here or in JIRA. > > Thanks, > Stan >
Move CacheStore::loadCache to a separate interface
Hi Igniters, I’ve just created a ticket to move CacheStore::loadCache to a separate interface: https://issues.apache.org/jira/browse/IGNITE-8952 In short, this is to provide a way to only implement loadCache without messing with other methods CacheStore implements. More details are in the JIRA. I believe this would make the API a bit cleaner than it is right now. This is a small change, I just wanted to highlight it on the dev-list as it’s a proposed adjustment to a very old core API. Feel free to comment here or in JIRA. Thanks, Stan
Re: Clusterwide settings validation
Guys, I created ticket for config params validation - https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment. Yakov Zhdanov www.gridgain.com 2018-07-04 10:51 GMT+03:00 Andrew Medvedev : > Hi Nikolay > > No, we have been beaten by > https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20% > 22rebalanceThreadPoolSize%22 > it is not checked on start > > Utility I mean check > org.apache.ignite.configuration.IgniteConfiguration and children > > On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov > wrote: > > Hello, Andrew. > > > > Can you clarify your question? > > > > What checks do you mean, exactly? > > Do you mean internal Ignite checks or user-provided checks? > > > > Ignite checks configuration consistency on node start [1]. > > > > Ignite do have consistency check for a joining node. Take a look at [2] > and all of it children. > > > > [1] https://github.com/apache/ignite/blob/master/modules/ > core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825 > > [2] https://github.com/apache/ignite/blob/master/modules/ > core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153 > > > > В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет: > >> Hello everybody > >> > >> Our company has lots of nodes in cluster, and we have seen some > >> problems with inconsistent settings on nodes clusterwide. To help us > >> with this, we made an utility to check consistency of settings on > >> running cluster, but it is a hack, better ways seems to be settings > >> validation by each node itself on start/joining topology/etc.. > >> > >> 1) Is his needed? > >> 2) Have the implementation details been discussed somewhere? > >> > >> Cheers >
RE: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts
We could just use failureDetectionTimeout all the time I guess. The only benefit of clientFailureDetectionTimeout is that it may allow clients to be slower/on a slower network than servers. Do you think it isn’t worth to have a separate setting just for that? Thanks, Stan From: Valentin Kulichenko Sent: 5 июля 2018 г. 18:16 To: dev@ignite.apache.org Subject: Re: IgniteConfiguration, TcpDiscoverySpi, TcpCommunicationSpitimeouts Stan, What is the purpose of clientFailureDetectionTimeout? Why can't we just always use failureDetectionTimeout? Is there any difference between these two timeouts? -Val On Wed, Jul 4, 2018 at 7:00 AM Stanislav Lukyanov wrote: > Hi, > > I’ve updated the proposed documentation update with a description of > metricsUpdateFrequency and a detailed description of > failureDetectionTimeout and clientFailureDetectionTimeout relations. The > draft is attached to https://issues.apache.org/jira/browse/IGNITE-7704. > > It seems that relation between failureDetectionTimeout and > clientFailureDetectionTimeout is currently too tricky and should also be > changed in future. > The problem is that in a server-client connection the server will use > clientFailureDetectionTimeout but client will use failureDetectionTimeout. > In other words, clients ignore clientFailureDetectionTimeout and just use > failureDetectionTimeout. Because of that, one has to provide different > values of failureDetectionTimeout in server and client configs which seems > confusing and inconvenient. > So I’d like to add one more point to my earlier proposal: > > 5. Always use clientFailureDetectionTimeout on clients instead of > failureDetectionTimeout > *What*: change code to use clientFailureDetectionTimeout on clients > *When*: update code and readme.io docs in 2.7 > > Thanks, > Stan > > From: Valentin Kulichenko > Sent: 30 мая 2018 г. 19:09 > To: dev@ignite.apache.org > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > TcpCommunicationSpitimeouts > > Stan, > > Looks like you suggest to only change the default. If so, it's OK. But > let's not change the behavior of these timeouts for the case they are > explicitly set in config. > > Thanks, > Val > > On Wed, May 30, 2018 at 1:06 AM, Stanislav Lukyanov < > stanlukya...@gmail.com> > wrote: > > > On networkTimeout: no, we don’t have anything like that in > > TcpCommunicationSpi. > > > > On socketWriteTimeout: > > First, its semantic is very close to TcpDicsoverySpi.socketTimeout (with > > the exception that communication uses NIO), and the latter defaults to > > failureDetectionTimeout, > > so I think it would help to avoid confusion. > > Second, I think we can’t deprecate something without an alternative that > > would work for most users. > > On the other hand, if we do default socketWriteTimeout to > > failureDetectionTimeout then we reach a pretty decent API state > > where one only needs two properties in IgniteConfiguration neither of > > which we’re considering for deprecation and removal in 3.0. > > > > Stan > > > > From: Valentin Kulichenko > > Sent: 29 мая 2018 г. 22:17 > > To: dev@ignite.apache.org > > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > > TcpCommunicationSpitimeouts > > > > Stan, > > > > OK, I got confused a little :) > > > > I do agree that TcpDiscoverySpi.networkTimeout should inherit from > > IgniteConfiguration.networkTImeout if not set explicitly. Do we have the > > same setting for TcpCommunicationSpi, BTW? If yes, behavior should be > > consistent. > > > > As for TcpCommunicationSpi.socketWriteTimeout, I'm not sure why you want > > to > > change its behavior. Can we just deprecate it and eventually remove, just > > as we plan to do for all timeouts from #2? > > > > -Val > > > > On Tue, May 29, 2018 at 3:50 AM, Stanislav Lukyanov < > > stanlukya...@gmail.com> > > wrote: > > > > > Val, > > > > > > Which timeouts do you mean? > > > > > > In #2 I don’t propose to change behavior. > > > > > > I propose to change behavior for a couple of settings in #3 though. > > > I believe the correct approach here would be to target the behavior > > change > > > for 2.6, > > > but keep in mind that we’ll need to carefully analyze the impact before > > > actually making the changes. > > > > > > Thanks, > > > Stan > > > > > > From: Valentin Kulichenko > > > Sent: 29 мая 2018 г. 0:57 > > > To: dev@ignite.apache.org > > > Subject: Re: IgniteConfiguration, TcpDiscoverySpi, > > > TcpCommunicationSpitimeouts > > > > > > Hi Stan, > > > > > > I'm 100% for this activity, however I don't think we should change the > > > behavior of timeouts you listed in #2 - this can lead to unexpected > > > behavior for users who already use them. I would just deprecate them > and > > > eventually remove. > > > > > > -Val > > > > > > On Mon, May 28, 2018 at 1:29 PM, Stanislav Lukyanov < > > > stanlukya...@gmail.com> > > > wrote: > > > > > > > Hi folks, > > > > > > > > It looks like we stopped half-way with this activity. I’d like to > pick > > it > > > > up. > > > > >
[jira] [Created] (IGNITE-8952) Move CacheStore::loadCache to a separate interface
Stanislav Lukyanov created IGNITE-8952: -- Summary: Move CacheStore::loadCache to a separate interface Key: IGNITE-8952 URL: https://issues.apache.org/jira/browse/IGNITE-8952 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov 3rd party persistence has three way of interacting with the backing storage: - JCache's CacheLoader methods for read-through - JCache's CacheWriter methods for write-through - Ignite's CacheStore::loadCache for bulk cache preloading Usually, one just uses a CacheStore implementation and provides a no-op implementation for the methods that are not needed (e.g. no-op implementation for write() if write-through isn't used). However, this adds certain redundancy. In particular, if a user only wants cache preloading (loadCache()) but no read-through or write-through, they will need to provide a bunch of these no-op methods, which can seem messy. Instead, it would be nice to move loadCache() method to a separate interface, say CachePreloader. This way we'll have 4 interfaces: - JCache's CacheLoader for read-through - JCache's CacheWriter for write-through - Ignite's CachePreloader for loadCache() - Ignite's CacheStore for all three together One can either choose any combination of loader, writer and preloader, OR set the store. The task is to - extract CacheStore::loadCache into a new interface CachePreloader - add CacheConfiguration::setCachePreloader - make sure that setCachePreloader works alone or in combination with loader and writer, and doesn't work with store -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Cases of using AffinityAssignment.clientEventChange method
Hi Maxim,
Thank you for your efforts to finding this out. I also didn't find any
usages, so I agree here.
I'm going to commit this by lazy consensus if no-one objects within the
next three days.
Sincerely,
Dmitriy Pavlov
чт, 5 июл. 2018 г. в 12:56, Maxim Muzafarov :
> Hello everyone,
>
> Suppose clientEventChange method is useless and have confusing name.
>
> I'm suggesting to remove it as not used. I've filed issue for it:
>
> https://issues.apache.org/jira/browse/IGNITE-8936
>
>
> чт, 28 июн. 2018 г. в 16:53, Maxim Muzafarov :
>
> > Hi Igniters,
> >
> > Recently I've faced with AffinityAssignment.clientEventChange() method
> and
> > not completly sure about the range of its applicability. The javadoc says
> > "return {@code True} if related discovery event did not cause affinity
> > assignment change and this assignment is just reference to the previous
> > one."
> >
> > Three facts about it:
> > 1) Method is the part of internal Ignite API
> > 2) It is not used anywhere in Ignite project code
> > 3) "clientEventChage" confusing name for this method. "true" value can be
> > set not only by client-related events (e.g. cacheChangeRequest,
> > affinityChangeRequest etc.).
> >
> > I've prepared diagram when it has "TRUE" value [1].
> >
> > * Question #1 * When and for what cases we can use returned value of this
> > method?
> > * Question #2 * Can it be removed? My suggestion is to keep internal API
> > as simple as possible.
> >
> >
> > [1] https://image.ibb.co/cW6Mx8/Client_Event_Change_1.png
> >
>
[jira] [Created] (IGNITE-8951) Need to validate nodes configuration across cluster and warn on different parameters value
Yakov Zhdanov created IGNITE-8951:
-
Summary: Need to validate nodes configuration across cluster and
warn on different parameters value
Key: IGNITE-8951
URL: https://issues.apache.org/jira/browse/IGNITE-8951
Project: Ignite
Issue Type: Task
Reporter: Yakov Zhdanov
On node start, node should output in its logs the list of parameters havnig
values different from values on remote node. This should be skipped for
parameters that are always different e.g. host name, node ID or IP, however
should be an option to include parameters from default ignore list as well.
Another requrement is that the intended output may be fully supressed by
setting sysmem property -DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true
It seems that the implementation approach should be similar to performance
suggestions Ignite currently has.
The output may be as following
{noformat}
Local node has different configuration comparted to remote nodes for
paramenters (fix if possible). To disable, set
-DIGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK=true
^-- rebalanceThreadPoolSize [locNodeVal=4, rmtNodeId=X1X1, rmtNodeVal=8]
^-- commSpi.selectorsCnt [locNodeVal=2, rmtNodeId=Y1Y1, rmtNodeVal=4]
^-- commSpi.selectorsCnt [locNodeVal=2, rmtNodeId=Z1Z1, rmtNodeVal=8]
{noformat}
All components should add messages to {{cfgConsistencyRegister}} on startup and
then all differences should be output in one step.
If node aborts startup due to any problem differences collected so far should
be output to logs.
If there are more than 1 value for some config parameter among remote nodes
then all distinct options should be output (see {{commSpi.selectorsCnt}} in the
example above).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Ignite 2.6 emergency release suggestion
Igniters, Ignite version still 2.6.0-SNAPSHOT at master, It should be changed to 2.7.0-SNAPSHOT since we relocated 2.6 to a special branch. Some issues affecting backward compatibility can not be merged while version not incremented. ср, 4 июл. 2018 г. в 20:59, Andrey Gura : > Igniters, > > I've moved IGNITE-8780 [1] issue to the next release. It can't be > merged to AI 2.6 because it has many other dependent commits. > > [1] https://issues.apache.org/jira/browse/IGNITE-8780 > On Wed, Jul 4, 2018 at 6:05 PM Ivan Rakov wrote: > > > > Andrey, thanks! > > > > I've cherry-picked the fixes to ignite-2.6 branch. > > > > Best Regards, > > Ivan Rakov > > > > On 04.07.2018 16:26, Andrey Gura wrote: > > > Ivan, > > > > > > I agree to include this fixes into AI 2.6 release. Please, feel free > to merge. > > > On Wed, Jul 4, 2018 at 4:08 PM Ivan Rakov > wrote: > > >> Igniters, > > >> > > >> Do we still have chance to extend 2.6 scope? > > >> > > >> I propose to include two more tickets into 2.6: > > >> https://issues.apache.org/jira/browse/IGNITE-8769 > > >> https://issues.apache.org/jira/browse/IGNITE-8910 > > >> > > >> We had data races in our free lists implementation. Fixes prevent > > >> possibility of AssertionError during cache operation, which may lead > to > > >> hangs and data inconsistency. > > >> > > >> Best Regards, > > >> Ivan Rakov > > >> > > >> > > >> On 27.06.2018 18:56, Dmitry Pavlov wrote: > > >>> Nikolay, thank you for such fast reaction. Tests are passing now. > > >>> > > >>> ср, 27 июн. 2018 г. в 17:28, Nikolay Izhikov : > > >>> > > Hello, Dmitriy. > > > > I fixed this issue, already. > > Please, check it. > > > > В Ср, 27/06/2018 в 16:55 +0300, Dmitry Pavlov пишет: > > > Hi Denis, > > > > > > currently anyway we have TC issue came from spark version > migrations. > > > > > > I also currently experiencing challenges with my local environment > setup. > > > So I guess we have day or two to wait this fix. > > > > > > Sincerely. > > > Dmitriy Pavlov > > > > > > ср, 27 июн. 2018 г. в 16:05, Denis Magda : > > > > > >> May I ask when? The current status of the ticket is not clear. > > >> > > >> -- > > >> Denis > > >> > > >> On Wed, Jun 27, 2018 at 7:27 AM Spider (Alexey) < > > spiderru5...@gmail.com> > > >> wrote: > > >> > > >>> Yes, it will be in the release 2.6 > > >>> > > 27 июня 2018 г., в 14:15, Dmitry Pavlov > > >>> написал(а): > > Hi Igniters, > > > > I've returned https://issues.apache.org/jira/browse/IGNITE-8780 > > to the > > scope because it was initially discussed to be in this reselase. > > > > Alexey Stelmak, could you please confirm fix could be ready > soon? > > > > Also I've cherry-picked javadoc fix. > > > > Sincerely, > > Dmitriy Pavlov > > > > вт, 26 июн. 2018 г. в 20:33, Denis Magda : > > >
[GitHub] ignite pull request #4322: IGNITE-8950 More informative file validation chec...
GitHub user zstan opened a pull request: https://github.com/apache/ignite/pull/4322 IGNITE-8950 More informative file validation check message You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8950 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4322.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4322 commit 893591a4f07ee7ccbc3bb2190d56d371d28e993f Author: Evgeny Stanilovskiy Date: 2018-07-06T12:50:06Z IGNITE-8950 More informative file validation check message ---
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
No. I am investigating your case in dedicated agent. > On 6 Jul 2018, at 15:43, Pavel Tupitsyn wrote: > > I see that some .NET Linux builds are now green. > Petr, have you done anything other than reboot? > > On Fri, Jul 6, 2018 at 3:05 PM Petr Ivanov wrote: > >> Agents rebooted >> >> >> >>> On 6 Jul 2018, at 14:09, kcheng.mvp wrote: >>> >>> In the console of TeamCity, I noticed some message >>> >>> >>> Some dependencies of this build are hanging: … Platform .NET (Core >> Linux), >>> build #1094 >>> >>> >>> it's hanging about 20 hours. is there anyway to cancel or stop it? >>> >>> >>> >>> -- >>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> >>
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
I see that some .NET Linux builds are now green. Petr, have you done anything other than reboot? On Fri, Jul 6, 2018 at 3:05 PM Petr Ivanov wrote: > Agents rebooted > > > > > On 6 Jul 2018, at 14:09, kcheng.mvp wrote: > > > > In the console of TeamCity, I noticed some message > > > > > > Some dependencies of this build are hanging: … Platform .NET (Core > Linux), > > build #1094 > > > > > > it's hanging about 20 hours. is there anyway to cancel or stop it? > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > >
[jira] [Created] (IGNITE-8950) Need to have more informative output info while database files check operation.
Stanilovsky Evgeny created IGNITE-8950: -- Summary: Need to have more informative output info while database files check operation. Key: IGNITE-8950 URL: https://issues.apache.org/jira/browse/IGNITE-8950 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.5 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Fix For: 2.7 "Failed to verify store file ..." messages have no file path info. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8949) Unexpected exception after node restart during rebalance.
Alexei Scherbakov created IGNITE-8949:
-
Summary: Unexpected exception after node restart during rebalance.
Key: IGNITE-8949
URL: https://issues.apache.org/jira/browse/IGNITE-8949
Project: Ignite
Issue Type: Bug
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
I've got:
{noformat}
Caused by: org.apache.ignite.IgniteCheckedException: Failed to process invalid
partitions response (remote node reported invalid partitions but remote
topology version does not differ from local)
{noformat}
during implicit get tx.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8948) Allow checking of LOGGING status via SQL/JDBC
Ilya Kasnacheev created IGNITE-8948:
---
Summary: Allow checking of LOGGING status via SQL/JDBC
Key: IGNITE-8948
URL: https://issues.apache.org/jira/browse/IGNITE-8948
Project: Ignite
Issue Type: New Feature
Components: jdbc, sql
Reporter: Ilya Kasnacheev
It is now possible to enable/disable WAL via ALTER TABLE tblName
{LOGGING|NOLOGGING};
However, it's not possible to check current LOGGING status. It is desired that
this is available.
The suggested method is via [JDBC metadata
table|https://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html#getTables(java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String[])]
info: right now we return null as REMARKS, but we could return the WITH "..."
string in REMARKS. Which will allow more introspection to JDBC clients. We
could store this line somewhere, or reconstruct it from scratch. And, we can
allow WITH "logging={true|false}" and return the current logging status in the
same fashion.
The problem here is that non-JDBC SQL clients still can't do that. So maybe we
need a dedicated statements for this eventually.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
Agents rebooted > On 6 Jul 2018, at 14:09, kcheng.mvp wrote: > > In the console of TeamCity, I noticed some message > > > Some dependencies of this build are hanging: … Platform .NET (Core Linux), > build #1094 > > > it's hanging about 20 hours. is there anyway to cancel or stop it? > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
In the console of TeamCity, I noticed some message Some dependencies of this build are hanging: … Platform .NET (Core Linux), build #1094 it's hanging about 20 hours. is there anyway to cancel or stop it? -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[GitHub] ignite pull request #4321: IGNITE-7366. Code review reaction
GitHub user ivandasch opened a pull request: https://github.com/apache/ignite/pull/4321 IGNITE-7366. Code review reaction You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7366 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4321.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4321 commit 2398cf3a5c9a91eaf15336cd5699a2f83e588bbc Author: pereslegin-pa Date: 2018-03-01T07:56:09Z IGNITE-7366 Fixed ready topology await on merge exchanges. commit 106e14af5df94826f9daa2c4de700dc32383d273 Author: Ivan Daschinskiy Date: 2018-07-06T08:38:23Z Merge remote-tracking branch 'origin/master' into ignite-7366 commit 399c68adb38a0bfed4a83552d1db74850030c7a5 Author: Ivan Daschinskiy Date: 2018-07-06T09:44:44Z IGNITE-7366: Code review reaction. ---
Re: .NET tests fail on Linux - need help with TeamCity
Petr, - Get the sources - cd modules/platforms/dotnet/Apache.Ignite.Core.Tests.DotNetCore - dotnet build You should get a warning "warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Image is too small." If you do, go ahead: - cd ~/.nuget/packages/newtonsoft.json - let me know which versions are there and what are the sizes of lib/netstandard1.3/Newtonsoft.Json.dll files in them - delete the whole newtonsoft.json directory and try the build again, will it fail? Thanks, Pavel On Thu, Jul 5, 2018 at 11:38 AM Petr Ivanov wrote: > I can. > > > Can you prepare reproduce steps so that I’ll be able to pinpoint the > problem faster, please? > > > > On 5 Jul 2018, at 11:25, Pavel Tupitsyn wrote: > > > > Igniters, > > > > I need help with TeamCity. > > .NET Linux Tests [1] fail for a very weird reason: > > Newtonsoft.Json.dll seems to be corrupted or empty " *Image is too > small.* > > ". > > I tried adding a step to clean NuGet caches, but it does not help. > > > > On my Ubuntu box tests pass. And there were no changes to .NET lately, so > > this failure seems to be TC-related only. > > > > Can someone with TeamCity agent access help me with this and check where > > that file comes from and what does it look like? > > > > Thanks, > > Pavel > > > > [1] > > > https://ci.ignite.apache.org/viewLog.html?buildId=1454493=buildResultsDiv=IgniteTests24Java8_PlatformNetCoreLinux > >
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
Hi Pavel, Sure, I didn't understood that problem is the same with already discussed. пт, 6 июл. 2018 г. в 12:01, Pavel Tupitsyn : > Dmitry, see my reply above. I will provide steps to Petr in that other > thread. > > On Fri, Jul 6, 2018 at 12:00 PM Dmitry Pavlov > wrote: > > > Hi, > > > > Unfortunately this problem also occurs in master, so for now everything > we > > can do now it is to Ignore it for PR and handle it as part of Make > TeamCity > > Green Again activity. > > > > Igniters, who can assist in fixing this issue: > > Testhost process exited with error: Unhandled Exception: > > System.BadImageFormatException: Could not load file or assembly > > 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, > > PublicKeyToken=30ad4fe6b2a6aeed'. An attempt was made to load a program > > with an incorrect format. > >at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main(String[] > > args) > > Test Run Aborted. > > ..Process exited with code 1 > > ? > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 6 июл. 2018 г. в 8:52, kcheng.mvp : > > > > > I have triggered my tests many times on TeamCity. every time I get the > > same > > > result. > > > > > > Platform .NET (Core Linux) pull/4300/head #1109 Exit code 1 > (new) > > > > > > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests > > > . > > > > > > I checked the history of 'Platform .NET (Core Linux) ' and found there > > are > > > many other build also runs into the same result. > > > > > > > > > > > > > > > > > > -- > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > >
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
Dmitry, see my reply above. I will provide steps to Petr in that other thread. On Fri, Jul 6, 2018 at 12:00 PM Dmitry Pavlov wrote: > Hi, > > Unfortunately this problem also occurs in master, so for now everything we > can do now it is to Ignore it for PR and handle it as part of Make TeamCity > Green Again activity. > > Igniters, who can assist in fixing this issue: > Testhost process exited with error: Unhandled Exception: > System.BadImageFormatException: Could not load file or assembly > 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, > PublicKeyToken=30ad4fe6b2a6aeed'. An attempt was made to load a program > with an incorrect format. >at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main(String[] > args) > Test Run Aborted. > ..Process exited with code 1 > ? > > Sincerely, > Dmitriy Pavlov > > пт, 6 июл. 2018 г. в 8:52, kcheng.mvp : > > > I have triggered my tests many times on TeamCity. every time I get the > same > > result. > > > > Platform .NET (Core Linux) pull/4300/head #1109 Exit code 1 (new) > > > > > > > https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests > > . > > > > I checked the history of 'Platform .NET (Core Linux) ' and found there > are > > many other build also runs into the same result. > > > > > > > > > > > > -- > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > >
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
Hi, Unfortunately this problem also occurs in master, so for now everything we can do now it is to Ignore it for PR and handle it as part of Make TeamCity Green Again activity. Igniters, who can assist in fixing this issue: Testhost process exited with error: Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. An attempt was made to load a program with an incorrect format. at Microsoft.VisualStudio.TestPlatform.TestHost.Program.Main(String[] args) Test Run Aborted. ..Process exited with code 1 ? Sincerely, Dmitriy Pavlov пт, 6 июл. 2018 г. в 8:52, kcheng.mvp : > I have triggered my tests many times on TeamCity. every time I get the same > result. > > Platform .NET (Core Linux) pull/4300/head #1109 Exit code 1 (new) > > > https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests > . > > I checked the history of 'Platform .NET (Core Linux) ' and found there are > many other build also runs into the same result. > > > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
Re: Platform .NET (Core Linux) Exit code 1 (new) On TeamCity
Yes, this is being discussed in [1] [1] http://apache-ignite-developers.2346864.n4.nabble.com/NET-tests-fail-on-Linux-need-help-with-TeamCity-td32235.html On Fri, Jul 6, 2018 at 8:52 AM kcheng.mvp wrote: > I have triggered my tests many times on TeamCity. every time I get the same > result. > > Platform .NET (Core Linux) pull/4300/head #1109 Exit code 1 (new) > > > https://ci.ignite.apache.org/viewLog.html?buildId=1460429=buildResultsDiv=IgniteTests24Java8_RunBasicTests > . > > I checked the history of 'Platform .NET (Core Linux) ' and found there are > many other build also runs into the same result. > > > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
[GitHub] ignite pull request #4320: IGNITE-8944 - TcpDiscoverySpi: set connection che...
GitHub user dkarachentsev opened a pull request: https://github.com/apache/ignite/pull/4320 IGNITE-8944 - TcpDiscoverySpi: set connection check frequency to fixe⦠â¦d value You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8944 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4320.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4320 commit f316865b950e4322c783d8cf0e6ec02686f60cd4 Author: dkarachentsev Date: 2018-07-06T08:54:04Z IGNITE-8944 - TcpDiscoverySpi: set connection check frequency to fixed value ---
Re: Ignite as distributed file storage
Pavel,
I do not think it is a good idea to delay discussions and decisions.
Because it puts your efforts at risk being not accepted by community in the
end. Our ultimate goal is not having as much features as possible, but to
have a consistent product which is easy to understand and use. Having both
IGFS and another one "not-IGFS" which is in fact the same IGFS but with
different name is not a good idea, because it would cause more harm than
value.
Approaches which seems reasonable to me:
1) Integrate your ideas into IGFS, which is really flexible in how to
process data and where to store it. PROXY mode is not a "crutch" as you
said, but a normal mode which was used in real deployments.
2) Replace IGFS with your solution but with clear explanation how it is
better than IGFS and why we need to drop thousands lines of battle-tested
code with something new, what does virtually the same thing
3) Just drop IGFS from the product, and do not implement any replacement at
all - personally, I am all for this decision.
If you want I can guide you through IGFS architecture so that we better
understand what should be done to integrate your ideas into it.
Lat, but not least - we need objective facts why proposed solution is
better in terms of performance - concrete use cases and performance numbers
(or at least estimations).
On Fri, Jul 6, 2018 at 1:45 AM Pavel Kovalenko wrote:
> Vladimir,
>
> I just want to add to my words, that we can implement BLOB storage and
> then, if community really wants it, we can adapt this storage to use as
> underlying file system in IGFS. But IGFS shouldn't be entry point for BLOB
> storage. I think this conclusion can satisfy both of us.
>
> 2018-07-06 0:47 GMT+03:00 Pavel Kovalenko :
>
> > Vladimir,
> >
> > I didn't say that it stores data in on-heap, I said that it performs a
> lot
> > of operations with byte[] arrays in on-heap as I see in , which will lead
> > to frequent GCs and unnecessary data copying.
> > "But the whole idea around mmap sounds like premature optimisation to me"
> > - this is not premature optimisation, this is on of the key performance
> > features. E.g. Apache Kafka wouldn't be so fast and extremely performant
> > without zero-copy.
> > If we can do better, why not just do it? Especially if it costs nothing
> > for us (This is OS level).
> > As I said in my first message, our end target is handling video and
> > streaming, copying every chunk of it to on-heap userspace then to offheap
> > and then to disk is unacceptable.
> > You ask me to implement almost anything using just IGFS interface, why we
> > need to do that? Proxy mode looks like crutch, to support replication and
> > possibility to have some data in-memory I need to write again a lot of
> > stuff.
> > Let's finally leave IGFS alone and wait for IEP.
> >
> >
> > 2018-07-06 0:01 GMT+03:00 Vladimir Ozerov :
> >
> >> Pavel,
> >>
> >> IGFS doesn't enforce you to have block in heap. What you suggest can be
> >> achieved with IGFS as follows:
> >> 1) Disable caching, so data cache is not used ("PROXY" mode)
> >> 2) Implement IgniteFileSystem interface which operates on abstract
> streams
> >>
> >> But the whole idea around mmap sounds like premature optimisation to
> me. I
> >> conducted a number of experiments with IGFS on large Hadoop workload.
> Even
> >> with old AI 1.x architecture, where everything was stored onheap, I
> never
> >> had an issue with GC. The key point is that IGFS operates on large
> (64Kb)
> >> data blocks, so even with 100Gb full of these blocks you will have
> >> relatively small number of objects and normal GC pauses. Additional
> memory
> >> copying is not an issue either in most workloads in distributed systems,
> >> because most of the time is spent on IO and internal synchronization
> >> anyway.
> >>
> >> Do you have specific scenario when you observed long GC pauses with GC
> or
> >> serious performance degradation with IGFS?
> >>
> >> Even if we agree that mmap usage is a critical piece, all we need is to
> >> implement a single IGFS interface.
> >>
> >> On Thu, Jul 5, 2018 at 10:44 PM Pavel Kovalenko
> >> wrote:
> >>
> >> > Vladimir,
> >> >
> >> > The key difference between BLOB storage and IGFS is that BLOB storage
> >> will
> >> > have persistent-based architecture with possibility to cache blocks in
> >> > offheap (using mmap, which is more simple, because we delegate it to
> OS
> >> > level)
> >> > , while IGFS has in-memory based architecture with possibility to
> >> persist
> >> > blocks.
> >> > BLOB storage will have possibility to work with small amount of RAM
> >> without
> >> > signficant performance drop (Using zero-copy from socket to disk) and
> in
> >> > opposite case it can keep all available blocks in offheap if it's
> >> possible
> >> > (Using mmap again).
> >> > IGFS perform a lot of operations with blocks in on-heap which leads to
> >> > unnecessary data copies, long GC pauses and performance drop. All IGFS
> >> > architecture tightly bound with
Re: Add cluster (de)activation events IGNITE-8376
I've linked them as duplicates, however, one ticket suggests to add Lifecycle events, while another is for adding our simple events from EventType Evgenii 2018-07-06 1:10 GMT+03:00 Dmitriy Setrakyan : > On Thu, Jul 5, 2018 at 1:55 AM, Evgenii Zhuravlev < > e.zhuravlev...@gmail.com> > wrote: > > > Guys, > > > > Do we really need events for activation/deactivation? We already have a > > ticket for implementation lifecycle events for it: > > https://issues.apache.org/jira/browse/IGNITE-5427, won't it be enough? > > > > Hm... I think these two tickets are duplicates of one another, no? >
[jira] [Created] (IGNITE-8947) Web Console: minor regression on Queries screen
Alexey Kuznetsov created IGNITE-8947: Summary: Web Console: minor regression on Queries screen Key: IGNITE-8947 URL: https://issues.apache.org/jira/browse/IGNITE-8947 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 2.7 Page size & Max page size dropdowns looks shifted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
