Return-Path: X-Original-To: apmail-ignite-dev-archive@minotaur.apache.org Delivered-To: apmail-ignite-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6AC2518CC1 for ; Tue, 17 Nov 2015 18:25:58 +0000 (UTC) Received: (qmail 61126 invoked by uid 500); 17 Nov 2015 18:25:58 -0000 Delivered-To: apmail-ignite-dev-archive@ignite.apache.org Received: (qmail 61084 invoked by uid 500); 17 Nov 2015 18:25:58 -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 61072 invoked by uid 99); 17 Nov 2015 18:25:57 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Nov 2015 18:25:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 85036C3997 for ; Tue, 17 Nov 2015 18:25:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.981 X-Spam-Level: ** X-Spam-Status: No, score=2.981 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain_com.20150623.gappssmtp.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id L8-66LukbW6H for ; Tue, 17 Nov 2015 18:25:44 +0000 (UTC) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 2CFE520271 for ; Tue, 17 Nov 2015 18:25:44 +0000 (UTC) Received: by lfaz4 with SMTP id z4so11096618lfa.0 for ; Tue, 17 Nov 2015 10:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RNbHiG/F0HkXwU2b6Xb0HaqPStuXkKVAC5AgLXNgh0w=; b=Z7DyZ5HnUyXSsNKcxaXJUhKlWYBxcr139xoHUL3Na4kQeGLN3kN5aoqM27oqBKxg+2 By4I2nP7YsX39/BSaJPC1NuucUvMadZPAhnU4HPNyOI/pz6lwijfzqZT8jNPt5XbqRDw cvQAve+oKSPVGaBB3Pb/0RxntolPTFdmT+1QEG7GnYx1yoMCRSCpBVGrUmiQ8n6KbrrU af1BhsQ+7C3Xms9UrEF0+tPlF+r08WXncBo8fdbPSDjW5J4QLw/qxPEUtPOPV228DLh1 GTA5FmYO5teBoSw3TvOvEoXeGdUjDDQHVm6OD1pGUl2LXimZJQSLhRfShdVayTlAZeA5 o9nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=RNbHiG/F0HkXwU2b6Xb0HaqPStuXkKVAC5AgLXNgh0w=; b=fhV/jlZ9yVG75plbK7Iwnj8b9+U70cVtxUKsZ3p0iqPXzGa+YhEK5BYdqGJtwScMF2 fmh+SaciFo6K7C+XD/jtKoXVogjjq40q2KH9sH7Cy0cxctdpNVjb5NUoDIIpUXRjt1ft 4vCAAtgV9VOMo3kd9OMNuwfFwdkH9XMDkKuz/GmO1mLgVum/qCxw/2hCYbfuSUHjxQ8E LcsTMjFf3kUbrN8AeVFrYeEelqBSEKpnfgY6TCai1L7Fv3SsdMeWBCE+eq/thZYX4X/d cxwvpyovjFmJQm4k5AOc8+cdhHwqZqgkaYB5CeWcanl/2xeiBTAfzq8wIsN/X5hHISf7 IMMA== X-Gm-Message-State: ALoCoQkFqwQD9TPT62Ltu2srXqIQZm9XhDvd02WYEr1Ll6lKNb6U/W1NYfv53ZuO0pqsc0F9esau MIME-Version: 1.0 X-Received: by 10.25.83.139 with SMTP id h133mr21289923lfb.89.1447784743497; Tue, 17 Nov 2015 10:25:43 -0800 (PST) Received: by 10.114.77.102 with HTTP; Tue, 17 Nov 2015 10:25:43 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Nov 2015 21:25:43 +0300 Message-ID: Subject: Re: Ignite-1.5 Release From: Vladimir Ozerov To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary=001a11405a0a5917550524c0a7da --001a11405a0a5917550524c0a7da Content-Type: text/plain; charset=UTF-8 I meant "release branch", not "master". On Tue, Nov 17, 2015 at 9:25 PM, Vladimir Ozerov wrote: > Folks, > > I continue working on IGNITE-1917 - marshalling microoptimizations. I did > a bunch of things today which increased performance a bit, so that > unmarshalling with PortableMarshaller is now a bit faster than > OptimizedMarshaller when object has several fields, but still slower when > there are lots of small fields. > > I'm going to apply the last easy optimization in the nearest time and then > will focus on merging all pending tickets to master. Once all important > things are merged, I'm going to spend some more efforts on performance > again. > > On Tue, Nov 17, 2015 at 8:30 PM, Vladisav Jelisavcic > wrote: > >> Hi Yakov, >> 1. Yes >> >> 2. if you mean that nodeMap is accessed in onNodeRemoved(UUID nodeID) >> method of the GridCacheSemaphoreImpl class, >> it shouldn't be a problem, but it can be changed easily not to do so; >> >> 3. >> >> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantTopologyChangeFailoverSafe() >> >> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantMultipleTopologyChangeFailoverSafe() >> >> I think the problem is with the atomicity of the simulated grid failure; >> once stopGrid() is called for a node, other threads on this same node >> start >> throwing interrupted exceptions, >> which are in turn not handled properly in the >> GridCacheAbstractDataStructuresFailoverSelfTest; >> Those exceptions shouldn't be dealt with inside the GridCacheSemaphoreImpl >> itself. >> In a realworld node failure scenario, all those threads would fail at the >> same time >> (none of them would influence the rest of the grid anymore); >> >> I think fixing the issue Denis is working on can fix this (IGNITE-801 and >> IGNITE-803) >> Am i right? Does it makes sense? >> >> >> Best regards, >> Vladisav >> >> >> >> >> On Tue, Nov 17, 2015 at 5:40 PM, Yakov Zhdanov >> wrote: >> >> > Vladislav, >> > >> > I started to review the latest changes and have couple of questions: >> > >> > 1. latest changes are here - https://github.com/apache/ignite/pull/120? >> Is >> > that correct? >> > 2. >> > >> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.Sync#nodeMap >> > is accessed in both sync and unsync context. Are you sure this is fine. >> > 3. As far as failing test - can you please isolate it into separate >> junit >> > or point out existing one? >> > >> > --Yakov >> > >> > 2015-11-11 12:33 GMT+03:00 Vladisav Jelisavcic : >> > >> > > Yakov, >> > > >> > > sorry for running a bit late. >> > > >> > > > Vladislav, do you have any updates for >> > > > https://issues.apache.org/jira/browse/IGNITE-638? Or any questions? >> > > > >> > > > --Yakov >> > > >> > > I have problems with some fail-over scenarios; >> > > It seems that if the two nodes are in the middle of acquiring or >> > releasing >> > > the semaphore, >> > > and one of them fails, all nodes get: >> > > >> > > [09:36:38,509][ERROR][ignite-#13%pub-null%][GridCacheSemaphoreImpl] >> > > Failed to compare and set: >> > > >> o.a.i.i.processors.datastructures.GridCacheSemaphoreImpl$Sync$1@5528b728 >> > > class >> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: >> > > Failed to acquire lock for keys (primary node left grid, retry >> > transaction >> > > if possible) [keys=[UserKeyCacheObjectImpl >> [val=GridCacheInternalKeyImpl >> > > [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]], >> > > node=c321fcc4-5db5-4b03-9811-6a5587f2c253] >> > > ... >> > > Caused by: class >> > > org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: >> > Failed >> > > to acquire lock for keys (primary node left grid, retry transaction if >> > > possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl >> > > [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]], >> > > node=c321fcc4-5db5-4b03-9811-6a5587f2c253] >> > > at >> > > >> > > >> > >> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.newTopologyException(GridDhtColocatedLockFuture.java:1199) >> > > ... 10 more >> > > >> > > >> > > I'm still trying to find out how to exactly reproduce this behavior, >> > > I'll send you more details once I try few more things. >> > > >> > > I am still using partitioned cache, does it make sense to use >> replicated >> > > cache instead? >> > > >> > > >> > > Other than that, I'm done with everything else. >> > > >> > > Thanks, >> > > Vladisav >> > > >> > > >> > >> > > --001a11405a0a5917550524c0a7da--