RE: When Cache Metrics are switched on (statisticsEnabled = true) the empty cache events arrive to the client nodes
Hi Ivan,
Does it mean that the problem is gone and I should close the JIRA IGNITE-12445 ?
-Original Message-
From: Ivan Pavlukhin
Sent: Monday, December 16, 2019 11:05 PM
To: dev
Subject: Re: When Cache Metrics are switched on (statisticsEnabled = true) the
empty cache events arrive to the client nodes
I also checked the reproducer with current master. It seems that the problem is
fixed there.
пн, 16 дек. 2019 г. в 19:36, Ilya Kasnacheev :
>
> Hello!
>
> Is there a chance you are using Zk?
>
> I believe it's https://issues.apache.org/jira/browse/IGNITE-6564
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 13 дек. 2019 г. в 12:24, :
>
> > Hi Community,
> >
> > I’d like to ask you about the following behavior of Apache Ignite:
> >
> >
> > If we want to react on some PUT or READ cache operations first of
> > all we need to turn on the appropriate cache events on the server
> > node and catch those events on the client nodes using remote approach with
> > two listeners.
> > It works well until we switch on statisticsEnabled on the server
> > node, it will lead to the situation when we get empty CacheEvent objects.
> >
> > The example that demonstrates this issue is in the attachments. This
> > example is consists of three nodes: 1 server node with cache and 2
> > clients. One client is filling the cache and the second one is
> > listening PUT operations. When we turn on Cache Metrics on the server node:
> > cacheConfig.setStatisticsEnabled(true); in EventServerCache.java we
> > get empty events (Sometimes CacheEvent objects with null fields.
> > Sometimes there are no events at all)
> >
> > My suppose is there is some Exception in
> > GridCacheEventManager.addEvent() when Cache Metrics is turned on.
> >
> > catch (Exception e) {
> > if
> > (!cctx.cacheObjectContext().kernalContext().cacheObjects().isBinaryEnabled(cctx.config()))
> > throw e; if (log.isDebugEnabled())
> > log.debug("Failed to unmarshall cache object value for the
> > event
> > notification: " + e);
> >
> > if (!forceKeepBinary)
> > LT.warn(log, "Failed to unmarshall cache object value for the
> > event notification " +
> > "(all further notifications will keep binary object
> > format).");
> >
> > forceKeepBinary = true;
> >
> > key0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(key, true,
> > false);
> >
> > val0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(newVal,
> > true, false);
> >
> > oldVal0 = cctx.cacheObjectContext().unwrapBinaryIfNeeded(oldVal,
> > true, false);
> >
> > }
> >
> > Can public this point in JIRA?
> >
> > Best regards,
> >
> > T-Systems RUS
> > Point of Production
> > Roman Koriakov
> > Software Developer
> > Kirova 11, Voronezh, Russia
> > Tel: + 7 473 200 15 30
> > E-mail:
> > roman.koria...@t-systems.com
> > http://www.t-systems.com > > ms.com
> > >>
> >
> > > http://www.t-systems.com > http://www.t-systems.com%3chttp:/www.t-systems.ru/>>
> >
> > >
> >
> > >
> >
> > >
> >
> > > -Original Message-
> >
> > > From: Ilya Kasnacheev > ilya.kasnach...@gmail.com>>
> >
> > > Sent: Thursday, December 12, 2019 5:25 PM
> >
> > > To: dev mailto:dev@ignite.apache.org>>
> >
> > > Subject: Re: joining
> >
> > >
> >
> > >
> >
> > >
> >
> > > Hello!
> >
> > >
> >
> > >
> >
> > >
> >
> > > I will need an Apache JIRA username to add you to contributors.
> > > Can you
> >
> > > provide it?
> >
> > >
> >
> > >
> >
> > >
> >
> > > Regards,
> >
> > >
> >
> > > --
> >
> > >
> >
> > > Ilya Kasnacheev
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > > чт, 12 дек. 2019 г. в 17:20, >
> > > roman.koria...@t-systems.com>>:
> >
> > >
> >
> > >
> >
> > >
> >
> > > > Hi everyone,
> >
> > >
> >
> > > > I'd like to participate in this project!
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > Best regards,
> >
> > >
> >
> > > >
> >
> > >
> >
> > > > T-Systems RUS
> >
> > >
> >
> > > > Point of Production
> >
> >
[jira] [Created] (IGNITE-12495) Make historical rebalance wokring per-partition level
Maxim Muzafarov created IGNITE-12495: Summary: Make historical rebalance wokring per-partition level Key: IGNITE-12495 URL: https://issues.apache.org/jira/browse/IGNITE-12495 Project: Ignite Issue Type: Sub-task Reporter: Maxim Muzafarov Currently, historical rebalance run after all cache group partition files have been preloaded and inited. To make file-rebalance faster historical rebalance can be started on per-partition level right after each cache group partition file loaded and inited. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12494) Design an cluster traversal algorithm to preload cache groups as faster as possible
Maxim Muzafarov created IGNITE-12494: Summary: Design an cluster traversal algorithm to preload cache groups as faster as possible Key: IGNITE-12494 URL: https://issues.apache.org/jira/browse/IGNITE-12494 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Currently, we are preloading cache group partitions sequentially bypassing each cluster node. To preload each cache group faster we need to design a new cluster nodes traversal algorithm which preload, for instance, a large cache groups first. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] Single point in API for changing cluster state.
Igniters, ticket[1] in patch available state. Anybody want to review changes? [1] https://issues.apache.org/jira/browse/IGNITE-12225 пн, 25 нояб. 2019 г. в 14:56, Sergey Antonov : > Alexei Scherbakov, > > > After activation (in read-only mode or not) rebalancing is possible to > begin and the grid will not be free of updates until it's finished. So the > grid will not be in truly read-only mode even if cache updates are > prohibited. Probably it would be enough just wait until rebalancing is > finished before releasing future. > I'm afraid, we can't guarantee truly read-only mode due to TTL on cache > entries > > > I do not understand the necessity of handling states comparison on > transition. Why not just return current(previous) state ? Could you give > more detailed explanation for this ? > User could face the unexpected behaviour, If we always return current > state (target state of transition) or previous state (initial state of > transition). For example, transition from INACTIVE to ACTIVE and we return > current state. User gets cluster state (ACTIVE) and tries to get cache, but > activation has not been completed yet. User will get exception, but cluster > state returns ACTIVE value. So, we can't always return current state. > Another example: transition from ACTIVE to READ_ONLY and we return > previous state. User gets cluster state (ACTIVE) and tries to update value > in cache. User could get ClusterReadOnlyModeException in this case. > So we should return state with lower functionality from previous and > current states for avoiding unexpected behaviour. > > > > чт, 31 окт. 2019 г. в 18:24, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> Sergey Antonov, >> >> > Read-only mode doesn't affects rebalance process. >> After activation (in read-only mode or not) rebalancing is possible to >> begin and the grid will not be free of updates until it's finished. >> So the grid will not be in truly read-only mode even if cache updates are >> prohibited. Probably it would be enough just wait until rebalancing is >> finished before releasing future. >> >> > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? >> INACTIVE, READ_WRITE, READ_ONLY seems more appropriate for ClusterState. >> >> I do not understand the necessity of handling states comparison on >> transition. Why not just return current(previous) state ? Could you give >> more detailed explanation for this ? >> >> вт, 29 окт. 2019 г. в 14:25, Sergey Antonov : >> >> > He, Igniters! >> > >> > I'd like to share some points encountered during work on ticket [1]: >> > >> >- I added property clusterStateOnStart with type ClusterState to >> >IgniteConfiguration. The property will be analogue of activeOnStart. >> >Default value of the property will be ACTIVE for keeping defalut >> value >> >consistency. Also I marked property activeOnStart as deprecated. >> >- I introduced order on values of ClusterState. It needs for user >> >friendly behaviour during cluster state transition. If cluster is >> > changing >> >state from state_A to state_B and user is requesting current cluster >> >state without waiting end of transition we must return lesser of two >> >states: state_A and state_B. I think the order must be: ACTIVE > >> >READ_ONLY > INACTIVE. Examples (state_A -> state_B = response on the >> >users cluster state request during transition): >> > - ACTIVE -> INACTIVE = INACTIVE (Now we have this behavior) >> > - INACTIVE -> ACTIVE = INACTIVE (Now we have this behavior) >> > - ACTIVE -> READ_ONLY = READ_ONLY >> > - READ_ONLY -> ACTIVE = READ_ONLY >> > - READ_ONLY -> INACTIVE = INACTIVE >> > - INACTIVE -> READ_ONLY = INACTIVE >> > >> > I'd like to know your opinion about my points. What do you think about >> it? >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12225 >> > >> > >> > вт, 15 окт. 2019 г. в 14:56, Sergey Antonov > >: >> > >> > > Hi, Alexei! >> > > >> > > Thank you for reply! >> > > >> > > > The states ACTIVE, INACTIVE, READ-ONLY look confusing. Actually >> > > read-only cluster is active too. >> > > How about INACTIVE, ACTIVE, ACTIVE_READ-ONLY states? >> > > >> > > > Also it would be useful to allow users wait for re-balance which >> could >> > > happen after activation in read-only mode to achieve really idle grid. >> > > Read-only mode doesn't affects rebalance process. >> > > >> > > > I would suggest adding new property to Ignite configuration like >> > > setActivationOptions(ActivationOption... options) which should be >> mutable >> > > in runtime. >> > > I'm not sure that it's good idea. @Alexey Goncharuk >> > > I'd like to know your opinion about >> activation >> > > option and storing them on PDS. >> > > >> > > > This proposal also better regarding backward compatibility. >> > > Which kind of compatibility did you mean? New cluster mode doesn't >> > affects >> > > PDS compatibility. >> > > >> > > ср, 25 сент. 2019 г. в 13:26, Alexei Sch
[jira] [Created] (IGNITE-12493) Test refactoring. Explicit method for starting client nodes
Nikolay Izhikov created IGNITE-12493:
Summary: Test refactoring. Explicit method for starting client
nodes
Key: IGNITE-12493
URL: https://issues.apache.org/jira/browse/IGNITE-12493
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7.6
Reporter: Nikolay Izhikov
Assignee: Ivan Pavlukhin
Right now there is almost 500 explicit usage of {{setClientMode}} in tests.
Seems we should support the starting of client nodes in test framework.
We should introduce method {{startClientNode(String name)}} and similar.
This will simplify tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [MTCGA]: new failures in builds [4874916, 4874915] needs to be handled
I reverted the problematic patch. The fix is on the way. ср, 25 дек. 2019 г. в 10:01, : > > Hi Igniters, > > I've detected some new issue on TeamCity to be handled. You are more than > welcomed to help. > > If your changes can lead to this failure(s): We're grateful that you were a > volunteer to make the contribution to this project, but things change and you > may no longer be able to finalize your contribution. > Could you respond to this email and indicate if you wish to continue and fix > test failures or step down and some committer may revert you commit. > > *New Critical Failure in master [Javadoc] > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Javadoc?branch=%3Cdefault%3E > Changes may lead to failure were done by > - kirill tkalenko > https://ci.ignite.apache.org/viewModification.html?modId=894906 > > *New Critical Failure in master ~Build Apache Ignite~ > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_BuildApacheIgnite?branch=%3Cdefault%3E > Changes may lead to failure were done by > - kirill tkalenko > https://ci.ignite.apache.org/viewModification.html?modId=894906 > > - Here's a reminder of what contributors were agreed to do > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute > - Should you have any questions please contact dev@ignite.apache.org > > Best Regards, > Apache Ignite TeamCity Bot > https://github.com/apache/ignite-teamcity-bot > Notification generated at 10:01:08 25-12-2019 -- Best regards, Ivan Pavlukhin
