Re: Hello
Hi Alexandr, Thank you for interest in Apache Ignite, and welcome to the community. I've added your account to the list of contributors, now you could assign issues. Full Guide https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute (now wiki can be down, please check later); shorter version https://github.com/apache/ignite/blob/master/CONTRIBUTING.md Looking forward to your contributions. Sincerely, Dmitriy Pavlov пн, 18 мар. 2019 г. в 19:15, Alexandr Shapkin : > Hello Ignite Community! > My name is Alexandr Shapkin. I want to contribute to Apache Ignite, my > JIRA username is ashapkin. > Thanks! > > >
Hello
Hello Ignite Community! My name is Alexandr Shapkin. I want to contribute to Apache Ignite, my JIRA username is ashapkin. Thanks!
Re: Peer review: Victory over Patch Available debt
Nikolay, sorry for going off-topic of the current thread. Just a few examples: https://issues.apache.org/jira/browse/IGNITE-8376 https://issues.apache.org/jira/browse/IGNITE-11521 https://issues.apache.org/jira/browse/IGNITE-11397 https://issues.apache.org/jira/browse/IGNITE-11346 https://issues.apache.org/jira/browse/IGNITE-11337 Maybe some contributions there have some issues, but in this case, we can be confident to press 'Cancel Patch' Sincerely, пн, 18 мар. 2019 г. в 16:47, Nikolay Izhikov : > Dmitriy. > > Actually, I doesn't understand your last mail. > Do we have some issue to solve? > If yes, can you write it down? > > What fixes need to be reviewed? > > > пн, 18 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > I'm not second-guessing someone's motivation. And without a particular > > case, it is not reasonable to discuss reasons why a patch is not merged. > > > > Silence=agreement in case there was clearly stated about it. Lazy > consensus > > is simply an announcement of 'silence gives assent.' When someone wants > to > > determine the sense of the community this way, it might do so with a mail > > message such as: > > "The patch below fixes bug #8271847; if no-one objects within three days, > > I'll assume lazy consensus and commit it." > > > > We used this approach from time to time, and we do have a situation when > > nobody wants to review even a small fix. > > > > It is as simple as this: > > - Any contributor (even non-committer) may come and say I will review. > > - Only committers can merge. So it is not reasonable to call to Lazy > > consensus if you are not a committer. > > - PMCs may revert by veto. > > > > We can remove any words from HTC because of reasonable concerns of > > misunderstanding, but policy still can be used. > > > > > > пн, 18 мар. 2019 г. в 13:52, Anton Vinogradov : > > > > > In case nobody cares, most likely we have a problem with a contribution > > or > > > motivation, not with lazy committers :) > > > Please remove the "lazy" phrase, since it can be interpreted as > "silence > > as > > > an agreement" which is always not true. > > > > > > On Mon, Mar 18, 2019 at 1:13 PM Dmitriy Pavlov > > wrote: > > > > > > > Hi, thank you all for your replies, I'm happy we discussing it, so we > > > could > > > > clearly understand this policy and how to apply it. > > > > > > > > a committer will always merge the change, was it approved by another > > > > contributor/committer/lazy consensus/vote - does not matter. And a > > > > committer will be responsible to take a final decision. > > > > > > > > There will no any kind of automatic merge. > > > > > > > > If a maintainer is on vacation, some other contributor may come to > the > > > > thread and say: Hi, please wait for a review from xxx. Any kind of > > > > discussion != silence. And lazy consensus is a way to apply change > when > > > > absolutely nobody (except the author) cares about it. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пн, 18 мар. 2019 г. в 12:37, Nikolay Izhikov : > > > > > > > > > Hello, Vladimir. > > > > > > > > > > Thanks for the detailed answer. > > > > > I think your statement doesn't differs with Dmitry statement much. > > > > > Do we have committer who merge without confidence in patch content? > > > > > If yes, they should stop to do it. > > > > > > > > > > > > > > > пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov : > > > > > > > > > > > Huge +1 to "We should stress out that a patch should be committed > > if > > > > and > > > > > > only if committer is confident with the changes." > > > > > > > > > > > > On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov < > > > voze...@gridgain.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > This is tough question, and first of all I'd like to ask > > > participants > > > > > to > > > > > > > keep cold head. This is a public question and can be discussed > on > > > the > > > > > dev > > > > > > > list safely. > > > > > > > > > > > > > > On the one hand, it is true that a number of patches are not > > > reviewed > > > > > > for a > > > > > > > long time, what negatively affects community development. On > the > > > > other > > > > > > > hand, we definitely do not want to sacrifice product quality > only > > > > > because > > > > > > > e.g. responsible component owner was on a sick leave or > vacation > > > and > > > > > was > > > > > > > not able to review the patch in a timely manner. Some > compromise > > is > > > > > > needed. > > > > > > > > > > > > > > IMO additional comments in HTC may solve the issue. We should > > > stress > > > > > out > > > > > > > that a patch should be committed if and only if committer is > > > > confident > > > > > > with > > > > > > > the changes. Confidence comes from either experience (you > worked > > > with > > > > > > > component a lot and know what you are doing), or from review by > > > > > > component's > > > > > > > expert. But if there is an outdated patch and you ar
[jira] [Created] (IGNITE-11562) Critical failure on stopping client node
Ryabov Dmitrii created IGNITE-11562:
---
Summary: Critical failure on stopping client node
Key: IGNITE-11562
URL: https://issues.apache.org/jira/browse/IGNITE-11562
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Ryabov Dmitrii
Critical failure in
{{IgniteAbstractDynamicCacheStartFailTest#testBrokenAffinityFunStartOnServerFailedOnClient()}}
is ignored because of no-op failure handler.
{code:java}
[2019-03-18
16:26:26,953][ERROR][exchange-worker-#210%clienttestBrokenAffinityFunStartOnServerFailedOnClient%][GridCachePartitionExchangeManager]
Failed to wait for completion of partition map exchange (preloading will not
start): GridDhtPartitionsExchangeFuture [firstDiscoEvt=DiscoveryCustomEvent
[customMsg=null, affTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
super=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=b9afbb48-3396-4ca6-b714-d2aa4e90,
consistentId=53086654-443a-44ab-88e3-a4d4f50d2477, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
lastExchangeTime=1552915586426, loc=false, ver=2.7.0#20190318-sha1:,
isClient=false], topVer=4, nodeId8=7355a5c6, msg=null,
type=DISCOVERY_CUSTOM_EVT, tstamp=1552915586506]], crd=TcpDiscoveryNode
[id=b9afbb48-3396-4ca6-b714-d2aa4e90,
consistentId=53086654-443a-44ab-88e3-a4d4f50d2477, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
lastExchangeTime=1552915586426, loc=false, ver=2.7.0#20190318-sha1:,
isClient=false], exchId=GridDhtPartitionExchangeId
[topVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
discoEvt=DiscoveryCustomEvent [customMsg=null,
affTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
super=DiscoveryEvent [evtNode=TcpDiscoveryNode
[id=b9afbb48-3396-4ca6-b714-d2aa4e90,
consistentId=53086654-443a-44ab-88e3-a4d4f50d2477, addrs=ArrayList [127.0.0.1],
sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
lastExchangeTime=1552915586426, loc=false, ver=2.7.0#20190318-sha1:,
isClient=false], topVer=4, nodeId8=7355a5c6, msg=null,
type=DISCOVERY_CUSTOM_EVT, tstamp=1552915586506]], nodeId=b9afbb48,
evt=DISCOVERY_CUSTOM_EVT], added=true, initFut=GridFutureAdapter
[ignoreInterrupts=false, state=DONE, res=true, hash=731087400], init=true,
lastVer=null, partReleaseFut=null, exchActions=ExchangeActions
[startCaches=[TestDynamicCache-server-1], stopCaches=null,
startGrps=[TestDynamicCache-server-1], stopGrps=[], resetParts=null,
stateChangeRequest=null], affChangeMsg=null, initTs=1552915586506,
centralizedAff=false, forceAffReassignment=false, exchangeLocE=class
o.a.i.IgniteCheckedException: Failed to initialize exchange locally
[locNodeId=7355a5c6-5779-4d95-8508-c9a51f30fb96],
cacheChangeFailureMsgSent=false, done=true, state=DONE,
registerCachesFuture=null, partitionsSent=false, partitionsReceived=false,
delayedLatestMsg=null, afterLsnrCompleteFut=GridFutureAdapter
[ignoreInterrupts=false, state=DONE, res=null, hash=1846768135],
timeBag=o.a.i.i.util.TimeBag@7682124a, startTime=20675138215608, evtLatch=0,
remaining=HashSet [7b53fbf7-537c-451a-b939-7099f492,
d63e4f5f-83b7-4449-8067-8d51bca1, b9afbb48-3396-4ca6-b714-d2aa4e90],
mergedJoinExchMsgs=null, super=GridFutureAdapter [ignoreInterrupts=false,
state=DONE, res=class o.a.i.IgniteCheckedException: Failed to initialize
exchange locally [locNodeId=7355a5c6-5779-4d95-8508-c9a51f30fb96],
hash=1196794290]]
class org.apache.ignite.IgniteCheckedException: Failed to initialize exchange
locally [locNodeId=7355a5c6-5779-4d95-8508-c9a51f30fb96]
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1257)
at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:782)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2920)
at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2769)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Simulated exception
[locNodeId=7355a5c6-5779-4d95-8508-c9a51f30fb96]
at
org.apache.ignite.internal.processors.cache.IgniteAbstractDynamicCacheStartFailTest$BrokenAffinityFunction.assignPartitions(IgniteAbstractDynamicCacheStartFailTest.java:920)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.calculate(GridAffinityAssignmentCache.java:369
Re: Peer review: Victory over Patch Available debt
Dmitriy. Actually, I doesn't understand your last mail. Do we have some issue to solve? If yes, can you write it down? What fixes need to be reviewed? пн, 18 мар. 2019 г. в 16:31, Dmitriy Pavlov : > I'm not second-guessing someone's motivation. And without a particular > case, it is not reasonable to discuss reasons why a patch is not merged. > > Silence=agreement in case there was clearly stated about it. Lazy consensus > is simply an announcement of 'silence gives assent.' When someone wants to > determine the sense of the community this way, it might do so with a mail > message such as: > "The patch below fixes bug #8271847; if no-one objects within three days, > I'll assume lazy consensus and commit it." > > We used this approach from time to time, and we do have a situation when > nobody wants to review even a small fix. > > It is as simple as this: > - Any contributor (even non-committer) may come and say I will review. > - Only committers can merge. So it is not reasonable to call to Lazy > consensus if you are not a committer. > - PMCs may revert by veto. > > We can remove any words from HTC because of reasonable concerns of > misunderstanding, but policy still can be used. > > > пн, 18 мар. 2019 г. в 13:52, Anton Vinogradov : > > > In case nobody cares, most likely we have a problem with a contribution > or > > motivation, not with lazy committers :) > > Please remove the "lazy" phrase, since it can be interpreted as "silence > as > > an agreement" which is always not true. > > > > On Mon, Mar 18, 2019 at 1:13 PM Dmitriy Pavlov > wrote: > > > > > Hi, thank you all for your replies, I'm happy we discussing it, so we > > could > > > clearly understand this policy and how to apply it. > > > > > > a committer will always merge the change, was it approved by another > > > contributor/committer/lazy consensus/vote - does not matter. And a > > > committer will be responsible to take a final decision. > > > > > > There will no any kind of automatic merge. > > > > > > If a maintainer is on vacation, some other contributor may come to the > > > thread and say: Hi, please wait for a review from xxx. Any kind of > > > discussion != silence. And lazy consensus is a way to apply change when > > > absolutely nobody (except the author) cares about it. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пн, 18 мар. 2019 г. в 12:37, Nikolay Izhikov : > > > > > > > Hello, Vladimir. > > > > > > > > Thanks for the detailed answer. > > > > I think your statement doesn't differs with Dmitry statement much. > > > > Do we have committer who merge without confidence in patch content? > > > > If yes, they should stop to do it. > > > > > > > > > > > > пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov : > > > > > > > > > Huge +1 to "We should stress out that a patch should be committed > if > > > and > > > > > only if committer is confident with the changes." > > > > > > > > > > On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov < > > voze...@gridgain.com > > > > > > > > > wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > This is tough question, and first of all I'd like to ask > > participants > > > > to > > > > > > keep cold head. This is a public question and can be discussed on > > the > > > > dev > > > > > > list safely. > > > > > > > > > > > > On the one hand, it is true that a number of patches are not > > reviewed > > > > > for a > > > > > > long time, what negatively affects community development. On the > > > other > > > > > > hand, we definitely do not want to sacrifice product quality only > > > > because > > > > > > e.g. responsible component owner was on a sick leave or vacation > > and > > > > was > > > > > > not able to review the patch in a timely manner. Some compromise > is > > > > > needed. > > > > > > > > > > > > IMO additional comments in HTC may solve the issue. We should > > stress > > > > out > > > > > > that a patch should be committed if and only if committer is > > > confident > > > > > with > > > > > > the changes. Confidence comes from either experience (you worked > > with > > > > > > component a lot and know what you are doing), or from review by > > > > > component's > > > > > > expert. But if there is an outdated patch and you are not > confident > > > > > enough, > > > > > > just don't merge. Let is stay in Patch Available as long as > needed. > > > > > > > > > > > > In case of lazy consensus we may ask committers to add comments > to > > > the > > > > > > ticket explaining why they decided to merge a ticket without > > expert's > > > > > > review. This should help us avoid bad commits. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov > > > > > wrote: > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > Phrase "Code modifications can be approved by silence: by lazy > > > > > consensus > > > > > > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > > > > > > > > > > > Please roll back the chang
Re: Consistent ID specification from previous random UUID
Hi Dmitriy, Quick start for a new user is a perfect concern. I thought about it as well. I and would like to outline that I am completely ok with an approach in your patch. пн, 18 мар. 2019 г. в 16:16, Dmitriy Pavlov : > > Hi Ivan, > > reasonable points, but we had a long and hot discussion about this logic. > > Reason for selecting auto-generation was users that just try to use Apache > Ignite with native persistence for the first time. They must be able to > test features without any extensive setup, but before go-live we expect > them to study the product a little bit more. There are not so many reasons > to use the same folder (or even same device) for 2+ nodes. > > Sincerely, > Dmitriy Pavlov > > вс, 17 мар. 2019 г. в 13:34, Павлухин Иван : > > > Hi Dmitriy, > > > > It is a pitty that we have to guess here. Some comments: > > 1. The usage scenario is not very complex and erything might work well > > with aforementioned patch. Unfortunately some tradeoff and extra > > transformations are involved and consequently it is hard to predict > > how many users will be troubled. But on a bright side the change is > > seemless and perhaps nobody will be really troubled. > > 2. From "honest" code perspective introducing nodeStorageName seems > > better to me because no (surprising) transformations are involved. > > 3. Also, it seems to me that original logic for choosing storage was > > not designed well. From the first glance it looks strange that need > > folders for a particular node in different places. Is not it much > > clear to have all data of the node in a single directory isolated from > > other nodes? AFAIK Hazelcast follows this approach. They generate an > > error when someone is trying to launch second instance in the same > > working directory. Perhaps, we at least should think about changing > > our layout and consider including such change in some future release. > > > > Thank you! > > > > пт, 15 мар. 2019 г. в 17:55, Dmitriy Pavlov : > > > > > > Hi Ivan, yes, after the restart we need to re-use both folder name and > > UUID > > > as consistent ID. > > > > > > About returning exact directory name: I'm just guessing here, but the > > > persistent store is not the only folder, there are several more folders, > > > e.g. binary-meta, etc. > > > > > > About several nodes reusing same root folder, yes, the proposed solution > > > will not works because 00 is hardcoded here. But I expect it will be too > > > rare case. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пт, 15 мар. 2019 г. в 11:29, Павлухин Иван : > > > > > > > Hi Dmitriy, > > > > > > > > It looks like that case with only one node in working directory is > > > > covered. But what is problem is solved? As I understand before fix in > > > > such case node after restart uses proper folder and proper > > > > consistentId. After fix we can specify automatically generated UUID in > > > > configuration and everything will go smooth. Is it the main problem > > > > case? If yes then such simplicity is very attractive. > > > > > > > > But honestly I do not fully understand why do we need to return a node > > > > to node00-UUID directory after that directory was deleted? > > > > > > > > чт, 14 мар. 2019 г. в 17:21, Dmitriy Pavlov : > > > > > > > > > > Hi, I've prepared demo PR for approach 1, just checking UUID and > > trying > > > > to > > > > > use node00-UUID. https://github.com/apache/ignite/pull/6266/ > > Actually > > > > for > > > > > this approach it is really simple, no API change is required. > > > > > > > > > > I guess the case is not very often because automatic folders > > assignment > > > > > works well in most cases. > > > > > > > > > > WDYT? > > > > > > > > > > ср, 13 мар. 2019 г. в 09:42, Павлухин Иван : > > > > > > > > > > > Alex, > > > > > > > > > > > > Why do we need > > > > > > > - check if consistent ID is set to a string 'nodeXX-UUID'. In > > this > > > > case > > > > > > > the consistent ID is set to UUID, and the storage folder is > > chosen > > > > > > > according to the proper rules. This change has a minimal chance > > to > > > > affect > > > > > > > current users because it's unlikely that somebody is using > > > > auto-generated > > > > > > > folder naming scheme as consistent ID. > > > > > > ? > > > > > > It looks hacky as well. The thing I do not like here is that a > > > > > > consistentId specified in configuration is not a consistentId used > > by > > > > > > a node sometimes. > > > > > > > > > > > > Can we go just with > > > > > > > - either check if consistent ID is an instance of UUID and then > > take > > > > the > > > > > > > appropriate folder. This approach is straightforward, but may > > affect > > > > > > > current users > > > > > > ? > > > > > > > > > > > > And as a last chance a user will have a possibility to rename a > > > > directory. > > > > > > > > > > > > > > > > > > вт, 12 мар. 2019 г. в 19:33, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com > > > > > > >: > > > > > > > > > > > > >
Re: Peer review: Victory over Patch Available debt
I'm not second-guessing someone's motivation. And without a particular case, it is not reasonable to discuss reasons why a patch is not merged. Silence=agreement in case there was clearly stated about it. Lazy consensus is simply an announcement of 'silence gives assent.' When someone wants to determine the sense of the community this way, it might do so with a mail message such as: "The patch below fixes bug #8271847; if no-one objects within three days, I'll assume lazy consensus and commit it." We used this approach from time to time, and we do have a situation when nobody wants to review even a small fix. It is as simple as this: - Any contributor (even non-committer) may come and say I will review. - Only committers can merge. So it is not reasonable to call to Lazy consensus if you are not a committer. - PMCs may revert by veto. We can remove any words from HTC because of reasonable concerns of misunderstanding, but policy still can be used. пн, 18 мар. 2019 г. в 13:52, Anton Vinogradov : > In case nobody cares, most likely we have a problem with a contribution or > motivation, not with lazy committers :) > Please remove the "lazy" phrase, since it can be interpreted as "silence as > an agreement" which is always not true. > > On Mon, Mar 18, 2019 at 1:13 PM Dmitriy Pavlov wrote: > > > Hi, thank you all for your replies, I'm happy we discussing it, so we > could > > clearly understand this policy and how to apply it. > > > > a committer will always merge the change, was it approved by another > > contributor/committer/lazy consensus/vote - does not matter. And a > > committer will be responsible to take a final decision. > > > > There will no any kind of automatic merge. > > > > If a maintainer is on vacation, some other contributor may come to the > > thread and say: Hi, please wait for a review from xxx. Any kind of > > discussion != silence. And lazy consensus is a way to apply change when > > absolutely nobody (except the author) cares about it. > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 18 мар. 2019 г. в 12:37, Nikolay Izhikov : > > > > > Hello, Vladimir. > > > > > > Thanks for the detailed answer. > > > I think your statement doesn't differs with Dmitry statement much. > > > Do we have committer who merge without confidence in patch content? > > > If yes, they should stop to do it. > > > > > > > > > пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov : > > > > > > > Huge +1 to "We should stress out that a patch should be committed if > > and > > > > only if committer is confident with the changes." > > > > > > > > On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov < > voze...@gridgain.com > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > This is tough question, and first of all I'd like to ask > participants > > > to > > > > > keep cold head. This is a public question and can be discussed on > the > > > dev > > > > > list safely. > > > > > > > > > > On the one hand, it is true that a number of patches are not > reviewed > > > > for a > > > > > long time, what negatively affects community development. On the > > other > > > > > hand, we definitely do not want to sacrifice product quality only > > > because > > > > > e.g. responsible component owner was on a sick leave or vacation > and > > > was > > > > > not able to review the patch in a timely manner. Some compromise is > > > > needed. > > > > > > > > > > IMO additional comments in HTC may solve the issue. We should > stress > > > out > > > > > that a patch should be committed if and only if committer is > > confident > > > > with > > > > > the changes. Confidence comes from either experience (you worked > with > > > > > component a lot and know what you are doing), or from review by > > > > component's > > > > > expert. But if there is an outdated patch and you are not confident > > > > enough, > > > > > just don't merge. Let is stay in Patch Available as long as needed. > > > > > > > > > > In case of lazy consensus we may ask committers to add comments to > > the > > > > > ticket explaining why they decided to merge a ticket without > expert's > > > > > review. This should help us avoid bad commits. > > > > > > > > > > Thoughts? > > > > > > > > > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov > > > wrote: > > > > > > > > > > > Dmitry, > > > > > > > > > > > > Phrase "Code modifications can be approved by silence: by lazy > > > > consensus > > > > > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > > > > > > > > > Please roll back the changes and start the discussion at the > > private > > > > list > > > > > > and never do such updates in the future without the discussion. > > > > > > > > > > > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov < > dpav...@apache.org > > > > > > > > wrote: > > > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > > > sorry for the late reply. Because this process time to time > > causes > > > > > > > questions, I decided to add a couple of words to our wiki. >
Re: Consistent ID specification from previous random UUID
Hi Ivan, reasonable points, but we had a long and hot discussion about this logic. Reason for selecting auto-generation was users that just try to use Apache Ignite with native persistence for the first time. They must be able to test features without any extensive setup, but before go-live we expect them to study the product a little bit more. There are not so many reasons to use the same folder (or even same device) for 2+ nodes. Sincerely, Dmitriy Pavlov вс, 17 мар. 2019 г. в 13:34, Павлухин Иван : > Hi Dmitriy, > > It is a pitty that we have to guess here. Some comments: > 1. The usage scenario is not very complex and erything might work well > with aforementioned patch. Unfortunately some tradeoff and extra > transformations are involved and consequently it is hard to predict > how many users will be troubled. But on a bright side the change is > seemless and perhaps nobody will be really troubled. > 2. From "honest" code perspective introducing nodeStorageName seems > better to me because no (surprising) transformations are involved. > 3. Also, it seems to me that original logic for choosing storage was > not designed well. From the first glance it looks strange that need > folders for a particular node in different places. Is not it much > clear to have all data of the node in a single directory isolated from > other nodes? AFAIK Hazelcast follows this approach. They generate an > error when someone is trying to launch second instance in the same > working directory. Perhaps, we at least should think about changing > our layout and consider including such change in some future release. > > Thank you! > > пт, 15 мар. 2019 г. в 17:55, Dmitriy Pavlov : > > > > Hi Ivan, yes, after the restart we need to re-use both folder name and > UUID > > as consistent ID. > > > > About returning exact directory name: I'm just guessing here, but the > > persistent store is not the only folder, there are several more folders, > > e.g. binary-meta, etc. > > > > About several nodes reusing same root folder, yes, the proposed solution > > will not works because 00 is hardcoded here. But I expect it will be too > > rare case. > > > > Sincerely, > > Dmitriy Pavlov > > > > пт, 15 мар. 2019 г. в 11:29, Павлухин Иван : > > > > > Hi Dmitriy, > > > > > > It looks like that case with only one node in working directory is > > > covered. But what is problem is solved? As I understand before fix in > > > such case node after restart uses proper folder and proper > > > consistentId. After fix we can specify automatically generated UUID in > > > configuration and everything will go smooth. Is it the main problem > > > case? If yes then such simplicity is very attractive. > > > > > > But honestly I do not fully understand why do we need to return a node > > > to node00-UUID directory after that directory was deleted? > > > > > > чт, 14 мар. 2019 г. в 17:21, Dmitriy Pavlov : > > > > > > > > Hi, I've prepared demo PR for approach 1, just checking UUID and > trying > > > to > > > > use node00-UUID. https://github.com/apache/ignite/pull/6266/ > Actually > > > for > > > > this approach it is really simple, no API change is required. > > > > > > > > I guess the case is not very often because automatic folders > assignment > > > > works well in most cases. > > > > > > > > WDYT? > > > > > > > > ср, 13 мар. 2019 г. в 09:42, Павлухин Иван : > > > > > > > > > Alex, > > > > > > > > > > Why do we need > > > > > > - check if consistent ID is set to a string 'nodeXX-UUID'. In > this > > > case > > > > > > the consistent ID is set to UUID, and the storage folder is > chosen > > > > > > according to the proper rules. This change has a minimal chance > to > > > affect > > > > > > current users because it's unlikely that somebody is using > > > auto-generated > > > > > > folder naming scheme as consistent ID. > > > > > ? > > > > > It looks hacky as well. The thing I do not like here is that a > > > > > consistentId specified in configuration is not a consistentId used > by > > > > > a node sometimes. > > > > > > > > > > Can we go just with > > > > > > - either check if consistent ID is an instance of UUID and then > take > > > the > > > > > > appropriate folder. This approach is straightforward, but may > affect > > > > > > current users > > > > > ? > > > > > > > > > > And as a last chance a user will have a possibility to rename a > > > directory. > > > > > > > > > > > > > > > вт, 12 мар. 2019 г. в 19:33, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > > >: > > > > > > > > > > > > Igniters, > > > > > > > > > > > > I came across the same issue during development and found no sane > > > > > > workaround for this issue. I believe the solution should be as > > > simple as > > > > > > possible because we are already adding a warning to let users > know > > > that > > > > > it > > > > > > is good to specify a consistent ID in production deployments. > > > > > > > > > > > > As for the current solution, I do not like adding a new > configurat
[jira] [Created] (IGNITE-11561) [ML] IgniteDistributedModel for XGBoost doesn't work in example
Alexey Platonov created IGNITE-11561: Summary: [ML] IgniteDistributedModel for XGBoost doesn't work in example Key: IGNITE-11561 URL: https://issues.apache.org/jira/browse/IGNITE-11561 Project: Ignite Issue Type: Bug Components: ml Affects Versions: 2.7, 2.8 Reporter: Alexey Platonov Assignee: Anton Dmitriev Distributed inference model for XGBoost doesn't work in example (XGBoostModelParserExample). It always returns same value. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Ignite 2.8 Release: Time & Scope & Release manager
As far as I remember that's not the first time we choose X.Y instead of X.Y.Z, because of ... So, seems we have to choose it now. >> Anton or Nikolay, would you like to be a release manager for 2.7.1? I can assist or perform the technical part of the release. >> Also, I can suggest 2.7.3 release as first Ignite maintenance release Agree On Mon, Mar 18, 2019 at 1:53 PM Dmitriy Pavlov wrote: > Anton, thanks for checking compatibility. > > Anton or Nikolay, would you like to be a release manager for 2.7.1 ? > > 1) Ticket version update happens from time to time, it is a mass update in > JIRA - 1 operation. Actually, we have tradition noticed by Alex G: > > even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, and > why not 2.8? > > 2) If we select 2.7.1: one major problem can occur - it is artifacts > versions clash for another company (and probably a lot of users involved), > because there is ignite-core 2.7.1. issued from Ignite fork. This issue is > now solved, so 2.8.1/2.9.1. can be created later without any risk > > 3) Also, I can suggest 2.7.3 release as first Ignite maintenance release - > cause there is no risk of clash here, as well. Otherwise, we need to select > between one company's internal links update vs another company's artifact > clash. > > Here I feel 2.7.1 is more natural, but it is safer to keep the process as > is, for at least, this release. > > Sincerely, > Dmitriy Pavlov > > пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > > > +1 to 2.7.1 version. > > > > I think it's time to learn to do minor releases. > > > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > > > > The major objection is to release 2.7.1 as 2.8. > > > > > > 1) A lot of people fixed issues at master with version 2.8. > > > So, they and their companies/customers (who used Ignite) waits for 2.8 > > > because of fixes. > > > At least my company waits for fixes at 2.8. > > > It will be a real problem to update all private links for 2.9 to wait > for > > > another release. > > > "You told me you fixed this at 2.8, ... lair", that what I expect. > > > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. > > > This will look odd to contributors. > > > > > > 3) I do not see any problems to release AI as 2.7.1. > > > I checked that assembly and release procedure have no issues with this > > > version. > > > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone > > doubts. > > > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda > wrote: > > > > > > > Dmitriy, > > > > > > > > Thanks for putting this together and sharing the results of our > > > > conversation in a smaller group. Igniters, if there are no major > > > objections > > > > I would suggest us kicking off release related procedures early next > > > week. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > > > wrote: > > > > > > > > > Hi everybody, > > > > > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > > > understood > > > > > the problem with the master based release is not only 2 or more > > faulty > > > > > commits, but 1040 commits we have since 2.7. All of these commits > > need > > > to > > > > > be tested (unfortunately not all QA steps are visible to the > > > community), > > > > > and this will require the most amount of time. Reverting and > > disabling > > > a > > > > > couple of features is possible, but other commits may impact users. > > > > > > > > > > You can find a complete list here > > > > > > > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > > > > > And estimation of commits related to Java 11 (plus commits fixing > > > native > > > > > persistence critical problems) is less than 50. > > > > > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > > > suggest > > > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as > master > > > > based > > > > > is counter-intuitive). > > > > > > > > > > 2.7.1, for now, is not an option because > > > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > > > experimental release may delay us, as well. > > > > > B. in this case we don't need 2.7.2 because there is almost no > risk > > > that > > > > > additional changes will be necessary. > > > > > we can schedule 2.9.1 with fixes may be necessary after new cool > > > release > > > > > after 1.5 months. > > > > > > > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > > > > warnings > > > > > provisioning and corruption fix. > > > > > > > > > > To finalize the scope, please share your commits in 3 days, which > > needs > > > > to > > > > > go to scope. Also, you can contribute by removing unnecessary > commit > > > from > > > > > sheet above. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > пн, 11 мар. 2019 г. в 16:
[jira] [Created] (IGNITE-11560) @WithSystemProperty annotation breaks some existing tests.
Ivan Bessonov created IGNITE-11560: -- Summary: @WithSystemProperty annotation breaks some existing tests. Key: IGNITE-11560 URL: https://issues.apache.org/jira/browse/IGNITE-11560 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Assignee: Ivan Bessonov https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-4555192785549771867&branch=%3Cdefault%3E&tab=testDetails -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11559) MVCC: Tx hangs on finish if StorageException occurs.
Andrew Mashenkov created IGNITE-11559: - Summary: MVCC: Tx hangs on finish if StorageException occurs. Key: IGNITE-11559 URL: https://issues.apache.org/jira/browse/IGNITE-11559 Project: Ignite Issue Type: Bug Components: mvcc, persistence Reporter: Andrew Mashenkov By default non-mvcc transactions don't log their states in WAL log, so tx rollbacks without hanging as there is nothing to save to WAL or PageMemory. So, it may be helpful to check case for non-mvcc tx with txState WAL-logging enabled at first. When StorageException occurs during any mvcc tx operation enabled, then storage locks become blocked. Then Ignite try to rollback Tx due to the error and try to save txState into WAL and TxLog and hangs forever. A thread hangs awaiting uninterruptibly for next WAL segment or lock released. Failure handler tries to stop a node and hangs as well. Looks like we shouldn't wait if kernal context become invalid. Good startpoint is IgniteWalFlush* tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Ignite 2.8 Release: Time & Scope & Release manager
Anton, thanks for checking compatibility. Anton or Nikolay, would you like to be a release manager for 2.7.1 ? 1) Ticket version update happens from time to time, it is a mass update in JIRA - 1 operation. Actually, we have tradition noticed by Alex G: even-numbered minor release all were emergency-styled: 2.2, 2.4, 2.6, and why not 2.8? 2) If we select 2.7.1: one major problem can occur - it is artifacts versions clash for another company (and probably a lot of users involved), because there is ignite-core 2.7.1. issued from Ignite fork. This issue is now solved, so 2.8.1/2.9.1. can be created later without any risk 3) Also, I can suggest 2.7.3 release as first Ignite maintenance release - cause there is no risk of clash here, as well. Otherwise, we need to select between one company's internal links update vs another company's artifact clash. Here I feel 2.7.1 is more natural, but it is safer to keep the process as is, for at least, this release. Sincerely, Dmitriy Pavlov пн, 18 мар. 2019 г. в 11:53, Nikolay Izhikov : > +1 to 2.7.1 version. > > I think it's time to learn to do minor releases. > > пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > > > The major objection is to release 2.7.1 as 2.8. > > > > 1) A lot of people fixed issues at master with version 2.8. > > So, they and their companies/customers (who used Ignite) waits for 2.8 > > because of fixes. > > At least my company waits for fixes at 2.8. > > It will be a real problem to update all private links for 2.9 to wait for > > another release. > > "You told me you fixed this at 2.8, ... lair", that what I expect. > > > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. > > This will look odd to contributors. > > > > 3) I do not see any problems to release AI as 2.7.1. > > I checked that assembly and release procedure have no issues with this > > version. > > > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone > doubts. > > > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda wrote: > > > > > Dmitriy, > > > > > > Thanks for putting this together and sharing the results of our > > > conversation in a smaller group. Igniters, if there are no major > > objections > > > I would suggest us kicking off release related procedures early next > > week. > > > > > > - > > > Denis > > > > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > > wrote: > > > > > > > Hi everybody, > > > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > > understood > > > > the problem with the master based release is not only 2 or more > faulty > > > > commits, but 1040 commits we have since 2.7. All of these commits > need > > to > > > > be tested (unfortunately not all QA steps are visible to the > > community), > > > > and this will require the most amount of time. Reverting and > disabling > > a > > > > couple of features is possible, but other commits may impact users. > > > > > > > > You can find a complete list here > > > > > > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > > > And estimation of commits related to Java 11 (plus commits fixing > > native > > > > persistence critical problems) is less than 50. > > > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > > suggest > > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master > > > based > > > > is counter-intuitive). > > > > > > > > 2.7.1, for now, is not an option because > > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > > experimental release may delay us, as well. > > > > B. in this case we don't need 2.7.2 because there is almost no risk > > that > > > > additional changes will be necessary. > > > > we can schedule 2.9.1 with fixes may be necessary after new cool > > release > > > > after 1.5 months. > > > > > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > > > warnings > > > > provisioning and corruption fix. > > > > > > > > To finalize the scope, please share your commits in 3 days, which > needs > > > to > > > > go to scope. Also, you can contribute by removing unnecessary commit > > from > > > > sheet above. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > > > > > > > Hi Ignite Developers, > > > > > > > > > > I remember I've fixed one case of Corrupted Tree Exception, and > this > > > fix > > > > > still not released. This is DB corruption, and loss of data: if > user > > > > face > > > > > with it he/she will probably ban Ignite for him/her preferences > > > forever. > > > > > > > > > > If we select 2.7.1 (BTW it is more natural naming of proposed > > release, > > > > > here I agree with proposed numbering), we can not ship this and > > similar > > > > > fixes made by Igniters. And what is the reason for this? Is it the > > > > presence > > > > > of a number of faulty commit
Re: Peer review: Victory over Patch Available debt
In case nobody cares, most likely we have a problem with a contribution or motivation, not with lazy committers :) Please remove the "lazy" phrase, since it can be interpreted as "silence as an agreement" which is always not true. On Mon, Mar 18, 2019 at 1:13 PM Dmitriy Pavlov wrote: > Hi, thank you all for your replies, I'm happy we discussing it, so we could > clearly understand this policy and how to apply it. > > a committer will always merge the change, was it approved by another > contributor/committer/lazy consensus/vote - does not matter. And a > committer will be responsible to take a final decision. > > There will no any kind of automatic merge. > > If a maintainer is on vacation, some other contributor may come to the > thread and say: Hi, please wait for a review from xxx. Any kind of > discussion != silence. And lazy consensus is a way to apply change when > absolutely nobody (except the author) cares about it. > > Sincerely, > Dmitriy Pavlov > > пн, 18 мар. 2019 г. в 12:37, Nikolay Izhikov : > > > Hello, Vladimir. > > > > Thanks for the detailed answer. > > I think your statement doesn't differs with Dmitry statement much. > > Do we have committer who merge without confidence in patch content? > > If yes, they should stop to do it. > > > > > > пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov : > > > > > Huge +1 to "We should stress out that a patch should be committed if > and > > > only if committer is confident with the changes." > > > > > > On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov > > > > wrote: > > > > > > > Hi, > > > > > > > > This is tough question, and first of all I'd like to ask participants > > to > > > > keep cold head. This is a public question and can be discussed on the > > dev > > > > list safely. > > > > > > > > On the one hand, it is true that a number of patches are not reviewed > > > for a > > > > long time, what negatively affects community development. On the > other > > > > hand, we definitely do not want to sacrifice product quality only > > because > > > > e.g. responsible component owner was on a sick leave or vacation and > > was > > > > not able to review the patch in a timely manner. Some compromise is > > > needed. > > > > > > > > IMO additional comments in HTC may solve the issue. We should stress > > out > > > > that a patch should be committed if and only if committer is > confident > > > with > > > > the changes. Confidence comes from either experience (you worked with > > > > component a lot and know what you are doing), or from review by > > > component's > > > > expert. But if there is an outdated patch and you are not confident > > > enough, > > > > just don't merge. Let is stay in Patch Available as long as needed. > > > > > > > > In case of lazy consensus we may ask committers to add comments to > the > > > > ticket explaining why they decided to merge a ticket without expert's > > > > review. This should help us avoid bad commits. > > > > > > > > Thoughts? > > > > > > > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov > > wrote: > > > > > > > > > Dmitry, > > > > > > > > > > Phrase "Code modifications can be approved by silence: by lazy > > > consensus > > > > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > > > > > > > Please roll back the changes and start the discussion at the > private > > > list > > > > > and never do such updates in the future without the discussion. > > > > > > > > > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov > > > > > wrote: > > > > > > > > > > > Hi Igniters, > > > > > > > > > > > > sorry for the late reply. Because this process time to time > causes > > > > > > questions, I decided to add a couple of words to our wiki. > > > > > > > > > > > > I've added topics about peer review to HTC > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > > > > > > > > > > > Actually, it is (more or less) rules of Apache Beam project, as > > well > > > as > > > > > > Apache Training(incubating), as well as our current process + > > Apache > > > > > > policies. > > > > > > > > > > > > Sincerely, > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov >: > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > I like your suggestion very much! And I want everyone to > follow. > > > > Let's > > > > > > see > > > > > > > if it helps. > > > > > > > > > > > > > > Can I ask everyone who has submitted tickets for review to add > a > > > > > comment > > > > > > > described by Dmitry to each ticket submitted and see if any > > > > additional > > > > > > > check is still required and fix remaining issues? I believe > this > > > > should > > > > > > > speed up review process very much. > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Peer review: Victory over Patch Available debt
Hi, thank you all for your replies, I'm happy we discussing it, so we could clearly understand this policy and how to apply it. a committer will always merge the change, was it approved by another contributor/committer/lazy consensus/vote - does not matter. And a committer will be responsible to take a final decision. There will no any kind of automatic merge. If a maintainer is on vacation, some other contributor may come to the thread and say: Hi, please wait for a review from xxx. Any kind of discussion != silence. And lazy consensus is a way to apply change when absolutely nobody (except the author) cares about it. Sincerely, Dmitriy Pavlov пн, 18 мар. 2019 г. в 12:37, Nikolay Izhikov : > Hello, Vladimir. > > Thanks for the detailed answer. > I think your statement doesn't differs with Dmitry statement much. > Do we have committer who merge without confidence in patch content? > If yes, they should stop to do it. > > > пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov : > > > Huge +1 to "We should stress out that a patch should be committed if and > > only if committer is confident with the changes." > > > > On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov > > wrote: > > > > > Hi, > > > > > > This is tough question, and first of all I'd like to ask participants > to > > > keep cold head. This is a public question and can be discussed on the > dev > > > list safely. > > > > > > On the one hand, it is true that a number of patches are not reviewed > > for a > > > long time, what negatively affects community development. On the other > > > hand, we definitely do not want to sacrifice product quality only > because > > > e.g. responsible component owner was on a sick leave or vacation and > was > > > not able to review the patch in a timely manner. Some compromise is > > needed. > > > > > > IMO additional comments in HTC may solve the issue. We should stress > out > > > that a patch should be committed if and only if committer is confident > > with > > > the changes. Confidence comes from either experience (you worked with > > > component a lot and know what you are doing), or from review by > > component's > > > expert. But if there is an outdated patch and you are not confident > > enough, > > > just don't merge. Let is stay in Patch Available as long as needed. > > > > > > In case of lazy consensus we may ask committers to add comments to the > > > ticket explaining why they decided to merge a ticket without expert's > > > review. This should help us avoid bad commits. > > > > > > Thoughts? > > > > > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov > wrote: > > > > > > > Dmitry, > > > > > > > > Phrase "Code modifications can be approved by silence: by lazy > > consensus > > > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > > > > > Please roll back the changes and start the discussion at the private > > list > > > > and never do such updates in the future without the discussion. > > > > > > > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov > > > wrote: > > > > > > > > > Hi Igniters, > > > > > > > > > > sorry for the late reply. Because this process time to time causes > > > > > questions, I decided to add a couple of words to our wiki. > > > > > > > > > > I've added topics about peer review to HTC > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > > > > > > > > > Actually, it is (more or less) rules of Apache Beam project, as > well > > as > > > > > Apache Training(incubating), as well as our current process + > Apache > > > > > policies. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov : > > > > > > > > > > > Dmitry, > > > > > > > > > > > > I like your suggestion very much! And I want everyone to follow. > > > Let's > > > > > see > > > > > > if it helps. > > > > > > > > > > > > Can I ask everyone who has submitted tickets for review to add a > > > > comment > > > > > > described by Dmitry to each ticket submitted and see if any > > > additional > > > > > > check is still required and fix remaining issues? I believe this > > > should > > > > > > speed up review process very much. > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > > > > > >
Re: Request for review/merge couple of small JUnit patches
Hi Ilya, Thanks a lot! I rebased second PR. Can you please take a look? пн, 18 мар. 2019 г. в 12:57, Ilya Kasnacheev : > > Hello! > > Did the first, can you rebase the second one? I'm relying on script and it > requires that change will merge flawlessly. > > Regards, > -- > Ilya Kasnacheev > > > вс, 17 мар. 2019 г. в 21:29, Павлухин Иван : > > > Hi Igniters, > > > > Recently I created 2 PRs with simple changes related our testing framework. > > 1. Remove several @RunWith(JUnit4.class) lines left after migration to > > junit 4 [1]. > > 2. Remove custom assumption handler in order to improve reporting on > > TC for tests skipped by failed assumption [2]. See the ticket for more > > details. > > > > First patch is rather trivial. Second patch was already reviewed but > > it still waits for someone able to merge it. > > > > Please take a look. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11398 > > [2] https://issues.apache.org/jira/browse/IGNITE-11356 > > > > -- > > Best regards, > > Ivan Pavlukhin > > -- Best regards, Ivan Pavlukhin
Re: Request for review/merge couple of small JUnit patches
Hello! Did the first, can you rebase the second one? I'm relying on script and it requires that change will merge flawlessly. Regards, -- Ilya Kasnacheev вс, 17 мар. 2019 г. в 21:29, Павлухин Иван : > Hi Igniters, > > Recently I created 2 PRs with simple changes related our testing framework. > 1. Remove several @RunWith(JUnit4.class) lines left after migration to > junit 4 [1]. > 2. Remove custom assumption handler in order to improve reporting on > TC for tests skipped by failed assumption [2]. See the ticket for more > details. > > First patch is rather trivial. Second patch was already reviewed but > it still waits for someone able to merge it. > > Please take a look. > > [1] https://issues.apache.org/jira/browse/IGNITE-11398 > [2] https://issues.apache.org/jira/browse/IGNITE-11356 > > -- > Best regards, > Ivan Pavlukhin >
[jira] [Created] (IGNITE-11558) Developer warning when HashMap is passed to putAll()
Ilya Kasnacheev created IGNITE-11558: Summary: Developer warning when HashMap is passed to putAll() Key: IGNITE-11558 URL: https://issues.apache.org/jira/browse/IGNITE-11558 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.7 Reporter: Ilya Kasnacheev Currently when HashMap is passed to putAll it's very easy to cause deadlock since the order of keys is not stable. This is a pity because users will use HashMap by default and not expect any trouble. We should issue a warning when user passes HashMap (but not LinkedHashMap) to putAll(). On .Net we should probably check for Dictionary. Warning similar to the one issues when index cannot be efficiently inlined. Another approach is to turn keys into binary form and then sort them, if map is not a SortedMap. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: DeadLocked while calling .Net ThinClient PutAll ?
Hello! We can defnitely do a heuristic check that passed map is HashMap (therefore unordered), since HashMap is basically "the" map. If we do a warning in 99% of problematic cases but fail to detect the remaining 1%, it's still a big improvement over the current behavior. Same thing in .Net with their default Dictionary. I have created a ticket: https://issues.apache.org/jira/browse/IGNITE-11558 Regards, -- Ilya Kasnacheev пн, 18 мар. 2019 г. в 11:12, Pavel Tupitsyn : > To avoid deadlocks you have to always take locks in the same order. > * That order is not always going to be "sorted with default comparer". > * Not every type has a default comparer > > So Ignite can't sort the keys for you, nor can it check if they are sorted. > And even if it could, it would be making unnecessary assumptions about user > code. > And it would be potentially expensive to sort or check order. > > Ilya, if you mean `instanceof` check, that does not look like a good API to > me to require a particular interface implementation. > > On Mon, Mar 18, 2019 at 10:25 AM Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > wrote: > > > Hello! > > > > Maybe we could issue a developer warning as soon as we detect putAll() > with > > something which has more than one element and which is not a sorted map? > > > > Like we do with indexed when they don't fit inline, etc. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пн, 18 мар. 2019 г. в 09:13, Павлухин Иван : > > > > > Hi, > > > > > > When you are working with TRANSACTIONAL cache you should be aware that > > > deadlocks might happen. I see the following options to prevent > > > deadlocks to happen: > > > 1. Explicitly order all keys involved in any transaction using the > > > same comparator. > > > 2. Use OPTIMISTIC transactions. > > > > > > Also, in many databases deadlocks can happen as well. So, instead of > > > preventing deadlocks it is quite common to provide some means of > > > breaking them. In Ignite it is possible to configure a transaction > > > timeout. In that case deadlocked transaction will be aborted sooner or > > > later and another transaction will be able to make a progress. > > > > > > > Should it be handle natively in Ignite Core, shouldn't it ? > > > > > > Unfortunately there is no general way to prevent deadlocks when using > > > PutAll with unordered collection. Ignite does not enforce all keys to > > > be Comparable which means that there could be keys without defined > > > consistent order. And if we cannot order keys consistently then we can > > > catch a deadlock. > > > > > > пн, 18 мар. 2019 г. в 05:53, Tâm Nguyễn Mạnh < > nguyenmanhtam...@gmail.com > > >: > > > > > > > > Hi Igniters, > > > > > > > > I heard that It could lead to DeadLocked when I pass non sorted > > > collection > > > > into putAll method. Is it true ? > > > > > > > > From document i see that method requires a > IEnumerable > > > TV>> as input. I think pass a sorted collection into API is just a > > > > workaround way. Should it be handle natively in Ignite Core, > shouldn't > > > it ? > > > > > > > > How do you thing ? > > > > > > > > -- > > > > Thanks & Best Regards > > > > > > > > Tam, Nguyen Manh > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > >
Re: Peer review: Victory over Patch Available debt
Hello, Vladimir. Thanks for the detailed answer. I think your statement doesn't differs with Dmitry statement much. Do we have committer who merge without confidence in patch content? If yes, they should stop to do it. пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov : > Huge +1 to "We should stress out that a patch should be committed if and > only if committer is confident with the changes." > > On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov > wrote: > > > Hi, > > > > This is tough question, and first of all I'd like to ask participants to > > keep cold head. This is a public question and can be discussed on the dev > > list safely. > > > > On the one hand, it is true that a number of patches are not reviewed > for a > > long time, what negatively affects community development. On the other > > hand, we definitely do not want to sacrifice product quality only because > > e.g. responsible component owner was on a sick leave or vacation and was > > not able to review the patch in a timely manner. Some compromise is > needed. > > > > IMO additional comments in HTC may solve the issue. We should stress out > > that a patch should be committed if and only if committer is confident > with > > the changes. Confidence comes from either experience (you worked with > > component a lot and know what you are doing), or from review by > component's > > expert. But if there is an outdated patch and you are not confident > enough, > > just don't merge. Let is stay in Patch Available as long as needed. > > > > In case of lazy consensus we may ask committers to add comments to the > > ticket explaining why they decided to merge a ticket without expert's > > review. This should help us avoid bad commits. > > > > Thoughts? > > > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov wrote: > > > > > Dmitry, > > > > > > Phrase "Code modifications can be approved by silence: by lazy > consensus > > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > > > Please roll back the changes and start the discussion at the private > list > > > and never do such updates in the future without the discussion. > > > > > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov > > wrote: > > > > > > > Hi Igniters, > > > > > > > > sorry for the late reply. Because this process time to time causes > > > > questions, I decided to add a couple of words to our wiki. > > > > > > > > I've added topics about peer review to HTC > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > > > > > > > Actually, it is (more or less) rules of Apache Beam project, as well > as > > > > Apache Training(incubating), as well as our current process + Apache > > > > policies. > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > > > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov : > > > > > > > > > Dmitry, > > > > > > > > > > I like your suggestion very much! And I want everyone to follow. > > Let's > > > > see > > > > > if it helps. > > > > > > > > > > Can I ask everyone who has submitted tickets for review to add a > > > comment > > > > > described by Dmitry to each ticket submitted and see if any > > additional > > > > > check is still required and fix remaining issues? I believe this > > should > > > > > speed up review process very much. > > > > > > > > > > --Yakov > > > > > > > > > > > > > > >
Re: [DISCUSSION] Usage of system properties in tests
Hello Igniters,
current improvement has been merged to master recently,
please feel free to use it in your tests.
пт, 15 февр. 2019 г. в 11:26, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com>:
> ++1 from my side. I guess it will be a more reliable way for works with
> properties in the tests. From time to time somebody forgot clear property
> after test and next tests may be failed or flaky failed completion.
>
> On Thu, Feb 14, 2019 at 6:56 PM Dmitriy Pavlov wrote:
>
> > I find it absolutely positive and modern approach and good contribution.
> > Count on my support if you will need any assistance with applying this
> > patch.
> >
> > чт, 14 февр. 2019 г. в 18:53, Ivan Bessonov :
> >
> > > Hello Igniters,
> > >
> > > I'd like to discuss the way we treat system properties in our test
> > > codebase.
> > > It's a common pattern where we set system property in
> > "beforeTestsStarted"
> > > and clear it in "afterTestsStopped". Purest example that I've found is
> > > class
> > > "RedisProtocolGetAllAsArrayTest".
> > >
> > > There are similar things with "beforeTest"/"afterTest" or huge
> > > "try/finally" blocks
> > > right in test methods.
> > >
> > > I think that all this code can be avoided and solution might look like
> > > this:
> > >
> > > @Test
> > > @WithSystemProperty(key = IGNITE_PROPERTY_NAME, value = "true")
> > > public void testSomething() throws Exception {
> > > ...
> > > }
> > >
> > > Same annotation might be used on class, this way new system property
> will
> > > be applied to all test methods in the class.
> > >
> > > I already created the issue for this change [1] and PR with demo [2].
> It
> > > contains
> > > implementation of annotation processing and a few migrated tests. If
> you
> > > like
> > > the idea then I will migrate all the other tests on the same mechanism.
> > >
> > > What do you think?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-11323
> > > [2] https://github.com/apache/ignite/pull/6109
> > >
> > > --
> > > Sincerely yours,
> > > Ivan Bessonov
> > >
> >
>
--
Sincerely yours,
Ivan Bessonov
Re: Peer review: Victory over Patch Available debt
Huge +1 to "We should stress out that a patch should be committed if and only if committer is confident with the changes." On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov wrote: > Hi, > > This is tough question, and first of all I'd like to ask participants to > keep cold head. This is a public question and can be discussed on the dev > list safely. > > On the one hand, it is true that a number of patches are not reviewed for a > long time, what negatively affects community development. On the other > hand, we definitely do not want to sacrifice product quality only because > e.g. responsible component owner was on a sick leave or vacation and was > not able to review the patch in a timely manner. Some compromise is needed. > > IMO additional comments in HTC may solve the issue. We should stress out > that a patch should be committed if and only if committer is confident with > the changes. Confidence comes from either experience (you worked with > component a lot and know what you are doing), or from review by component's > expert. But if there is an outdated patch and you are not confident enough, > just don't merge. Let is stay in Patch Available as long as needed. > > In case of lazy consensus we may ask committers to add comments to the > ticket explaining why they decided to merge a ticket without expert's > review. This should help us avoid bad commits. > > Thoughts? > > On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov wrote: > > > Dmitry, > > > > Phrase "Code modifications can be approved by silence: by lazy consensus > > (72h) after Dev.List announcement." looks unacceptable to me. > > > > Please roll back the changes and start the discussion at the private list > > and never do such updates in the future without the discussion. > > > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov > wrote: > > > > > Hi Igniters, > > > > > > sorry for the late reply. Because this process time to time causes > > > questions, I decided to add a couple of words to our wiki. > > > > > > I've added topics about peer review to HTC > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > > > > > Actually, it is (more or less) rules of Apache Beam project, as well as > > > Apache Training(incubating), as well as our current process + Apache > > > policies. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov : > > > > > > > Dmitry, > > > > > > > > I like your suggestion very much! And I want everyone to follow. > Let's > > > see > > > > if it helps. > > > > > > > > Can I ask everyone who has submitted tickets for review to add a > > comment > > > > described by Dmitry to each ticket submitted and see if any > additional > > > > check is still required and fix remaining issues? I believe this > should > > > > speed up review process very much. > > > > > > > > --Yakov > > > > > > > > > >
Re: Peer review: Victory over Patch Available debt
Hi, This is tough question, and first of all I'd like to ask participants to keep cold head. This is a public question and can be discussed on the dev list safely. On the one hand, it is true that a number of patches are not reviewed for a long time, what negatively affects community development. On the other hand, we definitely do not want to sacrifice product quality only because e.g. responsible component owner was on a sick leave or vacation and was not able to review the patch in a timely manner. Some compromise is needed. IMO additional comments in HTC may solve the issue. We should stress out that a patch should be committed if and only if committer is confident with the changes. Confidence comes from either experience (you worked with component a lot and know what you are doing), or from review by component's expert. But if there is an outdated patch and you are not confident enough, just don't merge. Let is stay in Patch Available as long as needed. In case of lazy consensus we may ask committers to add comments to the ticket explaining why they decided to merge a ticket without expert's review. This should help us avoid bad commits. Thoughts? On Mon, Mar 18, 2019 at 11:33 AM Anton Vinogradov wrote: > Dmitry, > > Phrase "Code modifications can be approved by silence: by lazy consensus > (72h) after Dev.List announcement." looks unacceptable to me. > > Please roll back the changes and start the discussion at the private list > and never do such updates in the future without the discussion. > > On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov wrote: > > > Hi Igniters, > > > > sorry for the late reply. Because this process time to time causes > > questions, I decided to add a couple of words to our wiki. > > > > I've added topics about peer review to HTC > > > > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > > > Actually, it is (more or less) rules of Apache Beam project, as well as > > Apache Training(incubating), as well as our current process + Apache > > policies. > > > > Sincerely, > > Dmitriy Pavlov > > > > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov : > > > > > Dmitry, > > > > > > I like your suggestion very much! And I want everyone to follow. Let's > > see > > > if it helps. > > > > > > Can I ask everyone who has submitted tickets for review to add a > comment > > > described by Dmitry to each ticket submitted and see if any additional > > > check is still required and fix remaining issues? I believe this should > > > speed up review process very much. > > > > > > --Yakov > > > > > >
Re: Ignite 2.8 Release: Time & Scope & Release manager
+1 to 2.7.1 version. I think it's time to learn to do minor releases. пн, 18 мар. 2019 г. в 11:51, Anton Vinogradov : > The major objection is to release 2.7.1 as 2.8. > > 1) A lot of people fixed issues at master with version 2.8. > So, they and their companies/customers (who used Ignite) waits for 2.8 > because of fixes. > At least my company waits for fixes at 2.8. > It will be a real problem to update all private links for 2.9 to wait for > another release. > "You told me you fixed this at 2.8, ... lair", that what I expect. > > 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. > This will look odd to contributors. > > 3) I do not see any problems to release AI as 2.7.1. > I checked that assembly and release procedure have no issues with this > version. > > P.s. I'm ready to assist or to release AI as 2.7.1 in case someone doubts. > > On Fri, Mar 15, 2019 at 11:52 PM Denis Magda wrote: > > > Dmitriy, > > > > Thanks for putting this together and sharing the results of our > > conversation in a smaller group. Igniters, if there are no major > objections > > I would suggest us kicking off release related procedures early next > week. > > > > - > > Denis > > > > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov > wrote: > > > > > Hi everybody, > > > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > > understood > > > the problem with the master based release is not only 2 or more faulty > > > commits, but 1040 commits we have since 2.7. All of these commits need > to > > > be tested (unfortunately not all QA steps are visible to the > community), > > > and this will require the most amount of time. Reverting and disabling > a > > > couple of features is possible, but other commits may impact users. > > > > > > You can find a complete list here > > > > > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > > > And estimation of commits related to Java 11 (plus commits fixing > native > > > persistence critical problems) is less than 50. > > > > > > So to get faster release we may use branch ignite-2.7 + fixes. I > suggest > > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master > > based > > > is counter-intuitive). > > > > > > 2.7.1, for now, is not an option because > > > A. we never did it before, and Java 11 fixes are urgent. A new > > > experimental release may delay us, as well. > > > B. in this case we don't need 2.7.2 because there is almost no risk > that > > > additional changes will be necessary. > > > we can schedule 2.9.1 with fixes may be necessary after new cool > release > > > after 1.5 months. > > > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > > warnings > > > provisioning and corruption fix. > > > > > > To finalize the scope, please share your commits in 3 days, which needs > > to > > > go to scope. Also, you can contribute by removing unnecessary commit > from > > > sheet above. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > > > > > Hi Ignite Developers, > > > > > > > > I remember I've fixed one case of Corrupted Tree Exception, and this > > fix > > > > still not released. This is DB corruption, and loss of data: if user > > > face > > > > with it he/she will probably ban Ignite for him/her preferences > > forever. > > > > > > > > If we select 2.7.1 (BTW it is more natural naming of proposed > release, > > > > here I agree with proposed numbering), we can not ship this and > similar > > > > fixes made by Igniters. And what is the reason for this? Is it the > > > presence > > > > of a number of faulty commits in master? > > > > > > > > How long does it take us to revert not tested features from > ignite-2.8 > > > > provided that branch is created from the master? > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev < > > ilya.kasnach...@gmail.com > > > >: > > > > > > > >> Hello! > > > >> > > > >> > - *was hard to start the code samples (same issue as with > > cmd).* > > > >> > - *The step above have to be repeated for every single > sample* > > > >> > > > >> For this issue, do we have any solution at all? I'm afraid you will > > > still > > > >> have to add JVM args manually for every main class or test that you > > run. > > > >> > > > >> Regards, > > > >> -- > > > >> Ilya Kasnacheev > > > >> > > > >> > > > >> чт, 7 мар. 2019 г. в 21:03, Denis Magda : > > > >> > > > >> > Dmitriy, > > > >> > > > > >> > Please find a copy-paste from the first conversation when > impactful > > > >> > usability problems were reported more than a month ago: > > > >> > > > > >> > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results > > are > > > >> sad:* > > > >> > > > > >> >- *Starting a node from cmd (ignite.sh) - FAILED* > > > >> >- *Opening Ignite examples - BAD EXPERIENCE* > > > >> > - *po
Re: Ignite 2.8 Release: Time & Scope & Release manager
The major objection is to release 2.7.1 as 2.8. 1) A lot of people fixed issues at master with version 2.8. So, they and their companies/customers (who used Ignite) waits for 2.8 because of fixes. At least my company waits for fixes at 2.8. It will be a real problem to update all private links for 2.9 to wait for another release. "You told me you fixed this at 2.8, ... lair", that what I expect. 2) You'll have to update 1000+ issues to have 2.9 as the fixed version. This will look odd to contributors. 3) I do not see any problems to release AI as 2.7.1. I checked that assembly and release procedure have no issues with this version. P.s. I'm ready to assist or to release AI as 2.7.1 in case someone doubts. On Fri, Mar 15, 2019 at 11:52 PM Denis Magda wrote: > Dmitriy, > > Thanks for putting this together and sharing the results of our > conversation in a smaller group. Igniters, if there are no major objections > I would suggest us kicking off release related procedures early next week. > > - > Denis > > > On Fri, Mar 15, 2019 at 6:05 AM Dmitriy Pavlov wrote: > > > Hi everybody, > > > > I had a private talk with Denis, Vladimir, and Alex G. As far I > understood > > the problem with the master based release is not only 2 or more faulty > > commits, but 1040 commits we have since 2.7. All of these commits need to > > be tested (unfortunately not all QA steps are visible to the community), > > and this will require the most amount of time. Reverting and disabling a > > couple of features is possible, but other commits may impact users. > > > > You can find a complete list here > > > > > https://docs.google.com/spreadsheets/d/1XJAsPEhYLcudVK4kdd6ZDoFZ6dnbAokgdJUDjWVZsKM/edit#gid=1445866798 > > > > And estimation of commits related to Java 11 (plus commits fixing native > > persistence critical problems) is less than 50. > > > > So to get faster release we may use branch ignite-2.7 + fixes. I suggest > > naming release as 2.8 and next 2.9 (cause 2.8 now and 2.8.1 as master > based > > is counter-intuitive). > > > > 2.7.1, for now, is not an option because > > A. we never did it before, and Java 11 fixes are urgent. A new > > experimental release may delay us, as well. > > B. in this case we don't need 2.7.2 because there is almost no risk that > > additional changes will be necessary. > > we can schedule 2.9.1 with fixes may be necessary after new cool release > > after 1.5 months. > > > > So, I'm ok to do ( +0.5 ) an emergency-style release for Java 11, > warnings > > provisioning and corruption fix. > > > > To finalize the scope, please share your commits in 3 days, which needs > to > > go to scope. Also, you can contribute by removing unnecessary commit from > > sheet above. > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 11 мар. 2019 г. в 16:31, Dmitriy Pavlov : > > > > > Hi Ignite Developers, > > > > > > I remember I've fixed one case of Corrupted Tree Exception, and this > fix > > > still not released. This is DB corruption, and loss of data: if user > > face > > > with it he/she will probably ban Ignite for him/her preferences > forever. > > > > > > If we select 2.7.1 (BTW it is more natural naming of proposed release, > > > here I agree with proposed numbering), we can not ship this and similar > > > fixes made by Igniters. And what is the reason for this? Is it the > > presence > > > of a number of faulty commits in master? > > > > > > How long does it take us to revert not tested features from ignite-2.8 > > > provided that branch is created from the master? > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > пн, 11 мар. 2019 г. в 11:37, Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > >: > > > > > >> Hello! > > >> > > >> > - *was hard to start the code samples (same issue as with > cmd).* > > >> > - *The step above have to be repeated for every single sample* > > >> > > >> For this issue, do we have any solution at all? I'm afraid you will > > still > > >> have to add JVM args manually for every main class or test that you > run. > > >> > > >> Regards, > > >> -- > > >> Ilya Kasnacheev > > >> > > >> > > >> чт, 7 мар. 2019 г. в 21:03, Denis Magda : > > >> > > >> > Dmitriy, > > >> > > > >> > Please find a copy-paste from the first conversation when impactful > > >> > usability problems were reported more than a month ago: > > >> > > > >> > *I played with the latest Oracle JDK 11 on Mac OS Mojave. Results > are > > >> sad:* > > >> > > > >> >- *Starting a node from cmd (ignite.sh) - FAILED* > > >> >- *Opening Ignite examples - BAD EXPERIENCE* > > >> > - *pom.xml wasn't detected automatically, had to select it > > >> manually* > > >> > - *was hard to start the code samples (same issue as with > cmd). > > >> As a > > >> > committer, I know how to fix it > > >> > ( > > >> > > > >> > > > https://apacheignite.readme.io/docs/getting-started#section-running-ignite-with-java-9-10-11 > > >> > < > > >> > > > >> > > > https://apacheignite.readme.io/do
[jira] [Created] (IGNITE-11557) flaky test SqlSystemViewsSelfTest.testQueryHistoryMetricsModes
Yury Gerzhedovich created IGNITE-11557: -- Summary: flaky test SqlSystemViewsSelfTest.testQueryHistoryMetricsModes Key: IGNITE-11557 URL: https://issues.apache.org/jira/browse/IGNITE-11557 Project: Ignite Issue Type: Bug Reporter: Yury Gerzhedovich test failed with the following trace _[2019-03-18 08:24:48,268][ERROR][test-runner-#443693%query.SqlSystemViewsSelfTest%][GridMapQueryExecutor] Failed to execute local query. class org.apache.ignite.IgniteCheckedException: Failed to execute SQL query. Exception calling user-defined function: "can_fail(): null"; SQL statement: SELECT "STRING"._KEY, "STRING"._VAL FROM "STRING" WHERE _key=100 AND sleep()>0 AND can_fail()=0 [90105-197] at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:846) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:923) at org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:588) at org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:388) at org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:203) at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:163) at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor$1.applyx(GridReduceQueryExecutor.java:161) at org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.send(IgniteH2Indexing.java:2057) at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.send(GridReduceQueryExecutor.java:1234) at org.apache.ignite.internal.processors.query.h2.twostep.GridReduceQueryExecutor.query(GridReduceQueryExecutor.java:757) at org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing$3.iterator(IgniteH2Indexing.java:1015) at org.apache.ignite.internal.processors.cache.QueryCursorImpl.iter(QueryCursorImpl.java:102) at org.apache.ignite.internal.processors.cache.query.RegisteredQueryCursor.iter(RegisteredQueryCursor.java:64) at org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:121) at org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.lambda$testQueryHistoryMetricsModes$0(SqlSystemViewsSelfTest.java:349) at org.apache.ignite.testframework.GridTestUtils.assertThrows(GridTestUtils.java:317) at org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.testQueryHistoryMetricsModes(SqlSystemViewsSelfTest.java:347) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2107) at java.lang.Thread.run(Thread.java:748) Caused by: org.h2.jdbc.JdbcSQLException: Exception calling user-defined function: "can_fail(): null"; SQL statement: SELECT "STRING"._KEY, "STRING"._VAL FROM "STRING" WHERE _key=100 AND sleep()>0 AND can_fail()=0 [90105-197] at org.h2.message.DbException.getJdbcSQLException(DbException.java:357) at org.h2.message.DbException.get(DbException.java:168) at org.h2.message.DbException.convertInvocation(DbException.java:324) at org.h2.engine.FunctionAlias$JavaMethod.getValue(FunctionAlias.java:468) at org.h2.expression.JavaFunction.getValue(JavaFunction.java:38) at org.h2.expression.Comparison.getValue(Comparison.java:239) at org.h2.expression.ConditionAndOr.getValue(ConditionAndOr.java:86) at org.h2.expression.Expression.getBooleanValue(Expression.java:178) at org.h2.command.dml.Select.isConditionMet(Select.java:312) at org.h2.command.dml.Select$LazyResultQueryFlat.fetchNextRow(Select.java:1455) at org.h2.result.LazyResult.hasNext(LazyResult.java:79) at org.h2.result.LazyResult.next(LazyResult.java:59) at org.h2.command.dml.Select.queryFlat(Select.java:527) at org.h2.command.dml.Select.queryWithoutCache(Select.java:633) at
Re: Peer review: Victory over Patch Available debt
Dmitry, Phrase "Code modifications can be approved by silence: by lazy consensus (72h) after Dev.List announcement." looks unacceptable to me. Please roll back the changes and start the discussion at the private list and never do such updates in the future without the discussion. On Fri, Mar 15, 2019 at 8:29 PM Dmitriy Pavlov wrote: > Hi Igniters, > > sorry for the late reply. Because this process time to time causes > questions, I decided to add a couple of words to our wiki. > > I've added topics about peer review to HTC > > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM > > Actually, it is (more or less) rules of Apache Beam project, as well as > Apache Training(incubating), as well as our current process + Apache > policies. > > Sincerely, > Dmitriy Pavlov > > > чт, 16 авг. 2018 г. в 17:46, Yakov Zhdanov : > > > Dmitry, > > > > I like your suggestion very much! And I want everyone to follow. Let's > see > > if it helps. > > > > Can I ask everyone who has submitted tickets for review to add a comment > > described by Dmitry to each ticket submitted and see if any additional > > check is still required and fix remaining issues? I believe this should > > speed up review process very much. > > > > --Yakov > > >
Re: DeadLocked while calling .Net ThinClient PutAll ?
To avoid deadlocks you have to always take locks in the same order. * That order is not always going to be "sorted with default comparer". * Not every type has a default comparer So Ignite can't sort the keys for you, nor can it check if they are sorted. And even if it could, it would be making unnecessary assumptions about user code. And it would be potentially expensive to sort or check order. Ilya, if you mean `instanceof` check, that does not look like a good API to me to require a particular interface implementation. On Mon, Mar 18, 2019 at 10:25 AM Ilya Kasnacheev wrote: > Hello! > > Maybe we could issue a developer warning as soon as we detect putAll() with > something which has more than one element and which is not a sorted map? > > Like we do with indexed when they don't fit inline, etc. > > Regards, > -- > Ilya Kasnacheev > > > пн, 18 мар. 2019 г. в 09:13, Павлухин Иван : > > > Hi, > > > > When you are working with TRANSACTIONAL cache you should be aware that > > deadlocks might happen. I see the following options to prevent > > deadlocks to happen: > > 1. Explicitly order all keys involved in any transaction using the > > same comparator. > > 2. Use OPTIMISTIC transactions. > > > > Also, in many databases deadlocks can happen as well. So, instead of > > preventing deadlocks it is quite common to provide some means of > > breaking them. In Ignite it is possible to configure a transaction > > timeout. In that case deadlocked transaction will be aborted sooner or > > later and another transaction will be able to make a progress. > > > > > Should it be handle natively in Ignite Core, shouldn't it ? > > > > Unfortunately there is no general way to prevent deadlocks when using > > PutAll with unordered collection. Ignite does not enforce all keys to > > be Comparable which means that there could be keys without defined > > consistent order. And if we cannot order keys consistently then we can > > catch a deadlock. > > > > пн, 18 мар. 2019 г. в 05:53, Tâm Nguyễn Mạnh >: > > > > > > Hi Igniters, > > > > > > I heard that It could lead to DeadLocked when I pass non sorted > > collection > > > into putAll method. Is it true ? > > > > > > From document i see that method requires a IEnumerable > > TV>> as input. I think pass a sorted collection into API is just a > > > workaround way. Should it be handle natively in Ignite Core, shouldn't > > it ? > > > > > > How do you thing ? > > > > > > -- > > > Thanks & Best Regards > > > > > > Tam, Nguyen Manh > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
Re: DeadLocked while calling .Net ThinClient PutAll ?
Hello! Maybe we could issue a developer warning as soon as we detect putAll() with something which has more than one element and which is not a sorted map? Like we do with indexed when they don't fit inline, etc. Regards, -- Ilya Kasnacheev пн, 18 мар. 2019 г. в 09:13, Павлухин Иван : > Hi, > > When you are working with TRANSACTIONAL cache you should be aware that > deadlocks might happen. I see the following options to prevent > deadlocks to happen: > 1. Explicitly order all keys involved in any transaction using the > same comparator. > 2. Use OPTIMISTIC transactions. > > Also, in many databases deadlocks can happen as well. So, instead of > preventing deadlocks it is quite common to provide some means of > breaking them. In Ignite it is possible to configure a transaction > timeout. In that case deadlocked transaction will be aborted sooner or > later and another transaction will be able to make a progress. > > > Should it be handle natively in Ignite Core, shouldn't it ? > > Unfortunately there is no general way to prevent deadlocks when using > PutAll with unordered collection. Ignite does not enforce all keys to > be Comparable which means that there could be keys without defined > consistent order. And if we cannot order keys consistently then we can > catch a deadlock. > > пн, 18 мар. 2019 г. в 05:53, Tâm Nguyễn Mạnh : > > > > Hi Igniters, > > > > I heard that It could lead to DeadLocked when I pass non sorted > collection > > into putAll method. Is it true ? > > > > From document i see that method requires a IEnumerable > TV>> as input. I think pass a sorted collection into API is just a > > workaround way. Should it be handle natively in Ignite Core, shouldn't > it ? > > > > How do you thing ? > > > > -- > > Thanks & Best Regards > > > > Tam, Nguyen Manh > > > > -- > Best regards, > Ivan Pavlukhin >
