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 <vladis...@gmail.com> 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 <yzhda...@apache.org> > 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 <vladis...@gmail.com>: > > > > > 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] > > > <ignite-atomics-sys-cache> 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 > > > > > > > > >
