ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Ignite-1.5 Release
Date Tue, 17 Nov 2015 18:25:43 GMT
I meant "release branch", not "master".

On Tue, Nov 17, 2015 at 9:25 PM, Vladimir Ozerov <vozerov@gridgain.com>
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 <vladisavj@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 <yzhdanov@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 <vladisavj@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
>> > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message