From dev-return-31616-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Fri Mar 2 17:21:51 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id DC93718062F for ; Fri, 2 Mar 2018 17:21:50 +0100 (CET) Received: (qmail 86881 invoked by uid 500); 2 Mar 2018 16:21:49 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 86265 invoked by uid 99); 2 Mar 2018 16:21:49 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2018 16:21:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id A3772180543 for ; Fri, 2 Mar 2018 16:21:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id vR2oBffntng3 for ; Fri, 2 Mar 2018 16:21:46 +0000 (UTC) Received: from forward102j.mail.yandex.net (forward102j.mail.yandex.net [5.45.198.243]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 840B45F17A for ; Fri, 2 Mar 2018 16:21:45 +0000 (UTC) Received: from mxback19j.mail.yandex.net (mxback19j.mail.yandex.net [IPv6:2a02:6b8:0:1619::95]) by forward102j.mail.yandex.net (Yandex) with ESMTP id 74E7A56058E4 for ; Fri, 2 Mar 2018 19:21:38 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback19j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id FEdIoj3nMn-LbrOFaa4; Fri, 02 Mar 2018 19:21:37 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1520007697; bh=BcVfohwJH0x//Kw2djKxWjAhZ8X2dZI2616bx+u7Dww=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=RqIChgYDKjHWNI05YMVpC6u9V5SldxpI+a3SXMwUldaSNwh44ZTCLDr0htFDBRA4i uIbfiMFbe8lLbhEBdXwwDH3+LsGp1DJbR/ml85A7PIm2nD5Jc8vpemBjhFvCmgbWhT BmTQzu7q+U7teGBKcKiq8wAEUxr1Z1HDVYcAgkg8= Authentication-Results: mxback19j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web43j.yandex.ru with HTTP; Fri, 02 Mar 2018 19:21:37 +0300 From: Anton Kalashnikov Envelope-From: kaa-dev@yandex.ru To: "dev@ignite.apache.org" In-Reply-To: References: <70861519830933@web7g.yandex.ru> Subject: Re: Race on IgniteAtomicLong#close MIME-Version: 1.0 Message-Id: <781301520007697@web43j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 02 Mar 2018 19:21:37 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Thank you, Anton. If it is expected behaviour I will fix test but anyway in my opinion this behaviour is not straight, I mean when you do same action and you getting differents result it is not good. At least, exception of missing value should be one. I don't have solution right now but I will think about it. But if you have any thoughts about it, please, share them. Nevertheless my target was understand the problem and it was achived. Now I can fix the test. --  Best regards, Anton Kalashnikov 01.03.2018, 00:33, "Anton Vinogradov" : > Anton, > > dsMap allows you to share any datastructure between local node's threads > without requesting it using retryTopologySafe method (which is heavy). > > T dataStructure = cast(dsMap.get(key), cls); > > if (dataStructure != null) >     return dataStructure; > > return retryTopologySafe( ... > > I see no problems at current behavour since you'll never gain obsolete > value. > You'll gain null once continuous query update dsMap. > > Looks like problem with test, not with atomicLong implementation. > After datastructure closing you should be ready to see non null value some > time, but any get method on this value should cause exception. > > 2018-02-28 18:15 GMT+03:00 Anton Kalashnikov : > >>  Hello Igniters. >> >>  During investigation flaky test IgniteClientDataStructuresTest.testAtomicLong. >>  I found a issue and now I need your help because I don't have enough >>  knowledge about IgniteAtomicLong. >>  I created the task for it - https://issues.apache.org/ >>  jira/browse/IGNITE-7845. And also I duplicate information below: >> >>  Given: >> >>  IgniteAtomicLong was created e.g. atomicLong = ignite.atomicLong("long1", >>  1L, true) >> >>  When: >> >>  IgniteAtomicLong was closed e.g. atomicLong.close() >> >>  Then: >> >>  If you try to get this value again - sometimes you will get null >>  IgniteAtomicLong value and sometimes you will get not null IgniteAtomicLong >>  value e.g. ignite.atomicLong("long1", 1L, false) sometimes null, sometimes >>  not null >> >>  But if we will get not null value IgniteAtomicLong and we will call method >>  "get" on it, we will have one of two exceptions IllegalStateException("Sequence >>  was removed from cache: " + name) if it already marked as deleted, and >>  IgniteException("Failed to find atomic long: " + name) if it sill no marked >>  as deleted but already deleted from cache. >> >>  Expected: >> >>  IgniteAtomicLong value always should be null(or not?) >> >>  Why it's happend: >> >>  When we close IgniteAtomicLong we removing value from cache in transaction >>  but removing from internal storage(dsMap) happen asynchroniously in >>  DataStructuresEntryListener for all nodes include local node. And when we >>  try get value after close we still sometimes able to get IgniteAtomicLong >>  from internal local storage. >> >>  Solution(In my opinion): >> >>  I guess in common case we don't need call Ignite#atomicLong every time >>  when we need value, but we should use IgniteAtomicLong object received >>  after first call. And if it is true, we can remove receiving >>  IgniteAtomicLong from local storage(dsMap) - this changes will fix problem >> >>  -- >>  Best regards, >>  Anton Kalashnikov