[jira] [Created] (IGNITE-13168) Retrigger historical rebalance if it was cancelled in case WAL history is still available
Vladislav Pyatkov created IGNITE-13168: -- Summary: Retrigger historical rebalance if it was cancelled in case WAL history is still available Key: IGNITE-13168 URL: https://issues.apache.org/jira/browse/IGNITE-13168 Project: Ignite Issue Type: Improvement Reporter: Vladislav Pyatkov If historical rebalance is cancelled, full rebalance will be unconditionally triggered on the PME that caused the cancellation (only outdated OWNING partitions can be rebalanced by history in the current implementation). We have to allow MOVING partitions to be historically rebalanced as well. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13167) Cache Store fails to close connection: writeBehind + TRANSACTIONAL + readThrough
Ilya Kasnacheev created IGNITE-13167: Summary: Cache Store fails to close connection: writeBehind + TRANSACTIONAL + readThrough Key: IGNITE-13167 URL: https://issues.apache.org/jira/browse/IGNITE-13167 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.8.1 Reporter: Ilya Kasnacheev Please see referenced mailing list thread. If there is an ongoing transactional (cache is transactional, put uses an implicit transaction, tx != null) then org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter#loadFromStore will not call sessionEnd() - see sessionEnd0() method. If write behind is also enabled, then cache store is not invoked during the operation and connection will never be closed. So, a combination of TRANSACTIONAL cache, implicit transaction, loadFromCache and write behind will leak a connection every time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Checkpoint refactoring(part of IEP-47)
Hi Anton, A side question. Do you feel that it is possible to cover extracted classes with unit tests (I mean unit tests which do not start Ignite nodes)? 2020-06-19 16:59 GMT+03:00, Anton Kalashnikov : > Hi Igniters, > > IEP-47(Native persistence defragmentation) contains a part that implies > refactoring of checkpoint(with the goal of reusing this feature in > defragmentation). > > I just to want to emphasize this part(refactoring) here and share my view to > implementation > I want to split this job to at least 2(but maybe 3) separated tasks: > 1. Extracting checkpoint related classes from > GridCacheDatabaseSharedManager(ex. Checkpoint, Checkpointer, > WriteCheckpointPages, etc.) - > https://issues.apache.org/jira/browse/IGNITE-13151(almost done) > 2. Simplifying result code - I don't sure it is possible, but right now I > see some code which on the first eye has duplication and redundancy > 3. Reorganizing code - There is a lot of work which Checkpointer do right > now, I believe at least this class should be split. > > Perhaps, 2 and 3 items will be done in one ticket. > I believe you understand that I suggested several tickets instead of one in > the target of simplification of review and find bugs. > > Any objections? > > -- > Best regards, > Anton Kalashnikov > > -- Best regards, Ivan Pavlukhin
Checkpoint refactoring(part of IEP-47)
Hi Igniters, IEP-47(Native persistence defragmentation) contains a part that implies refactoring of checkpoint(with the goal of reusing this feature in defragmentation). I just to want to emphasize this part(refactoring) here and share my view to implementation I want to split this job to at least 2(but maybe 3) separated tasks: 1. Extracting checkpoint related classes from GridCacheDatabaseSharedManager(ex. Checkpoint, Checkpointer, WriteCheckpointPages, etc.) - https://issues.apache.org/jira/browse/IGNITE-13151(almost done) 2. Simplifying result code - I don't sure it is possible, but right now I see some code which on the first eye has duplication and redundancy 3. Reorganizing code - There is a lot of work which Checkpointer do right now, I believe at least this class should be split. Perhaps, 2 and 3 items will be done in one ticket. I believe you understand that I suggested several tickets instead of one in the target of simplification of review and find bugs. Any objections? -- Best regards, Anton Kalashnikov
Re: Reviewer request: [IGNITE-13144] Improve ClusterState enum and other minor improvements for the cluster read-only mode.
Sergey, I've looked at your patch. Please see my comments on GitHub. чт, 18 июн. 2020 г. в 18:56, Sergey Antonov : > Guys, could someone review my patch, please? > > вт, 16 июн. 2020 г. в 10:50, Sergey Antonov : > > > Hello, Igniters! > > > > I'd like to get a review of the ticket [1]. The patch is ready [2]. > > Can someone look at it, please? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-13144 > > [2] https://github.com/apache/ignite/pull/7924 > > > > -- > > BR, Sergey Antonov > > > > > -- > BR, Sergey Antonov >
Re: Introduce the ability for a user to manage binary types [IGNITE-13154]
Hi, I change the error message [1]. The suggestion at the message contains info about requirement to remove all data with old schema, then remove metadata by control.sh or manually by delete files and restart grid. [1]. https://github.com/apache/ignite/pull/7936/files#diff-cb1981ab1a44f213b4cadafd80c611c5R1047 On 19.06.2020 1:55, Denis Magda wrote: Glad to see it coming! That was a pain in the neck. Could we also add a hint to the exception message when a type mismatch happens? Basically, the exception should not only report details about the mismatch but also suggest how to solve it. The text can mention these new control.sh commands and advise to remove the old metadata. - Denis On Thu, Jun 18, 2020 at 7:42 AM Taras Ledkov wrote: Hi, I propose to introduce ability for a user to manage cluster binary types. This functionality is useful when user needs to change schema without cluster restart. Motivation: Rid users of manual operations in the folder 'binary_meta' and cluster restart when they need change schema. The proposed implementation contains restrictions (see [1]). So I guess we add internal API and command for public command line tool (control.sh) with mode 'experimental' mode (the property IGNITE_ENABLE_EXPERIMENTAL_COMMAND must be set). Please take a look at the ticket / patch. Any comments / suggestions? [1]. https://issues.apache.org/jira/browse/IGNITE-13154 -- Taras Ledkov Mail-To: tled...@gridgain.com -- Taras Ledkov Mail-To: tled...@gridgain.com
Re: [DISCUSSION] Add autocompletion for commands in control.sh
Hi Alexey! I will take a short pause before the implementation and try to answer all your questions. 18.06.2020, 18:05, "Alexey Goncharuk" : > Definitely a +1 from me for moving the CLI tooling to a separate module. > > As for the autocompletion - can you elaborate how it works? Will it require > to run an additional tool when a user hits TAB? Or will it generate an > autocompletion file during the build? Will we require an install step for > Ignite tools for autocompletion to work then?
Re: [DISCUSSION] Add autocompletion for commands in control.sh
Hi Evgenii! At first glance, api will not change, but I can see it when I will do it. 17.06.2020, 23:16, "Evgenii Zhuravlev" : > Hi, > > +1 for both moving control.sh to the separate module and adding > autocompletion. > > Will API remain the same in control.sh? > > Evgenii > > пт, 5 июн. 2020 г. в 01:59, ткаленко кирилл : > >> Folks have created a ticket [1]. >> >> 1 - https://issues.apache.org/jira/browse/IGNITE-13120 >> >> 02.06.2020, 16:48, "ткаленко кирилл" : >> > Maxim I suggested moving control.sh in a separate module, are we talking >> about the same thing? >> > >> > 02.06.2020, 16:15, "Maxim Muzafarov" : >> >> Folks, >> >> >> >> +1 >> >> >> >> However, AFAIK control.sh is the part of the ignite-core module with >> >> zero dependencies from external resources. >> >> Would it be better going the `control.sh` extensions-way? >> >> >> >> By the way, according to README.md [1] the picocli is already using by >> >> the Apache Ignite, right? :-) >> >> >> >>> Picocli is used in the Apache Hadoop Ozone/HDDS command line tools, >> the Apache Hive benchmark CLI, has ** Apache [Ignite TensorFlow] **, and >> Apache Sling. >> >> >> >> [1] https://github.com/remkop/picocli/blame/master/README.md#L199 >> >> >> >> On Tue, 2 Jun 2020 at 16:09, Ivan Daschinsky >> wrote: >> >>> +1 But this is not only usability improvement, but also a huge code >> >>> improvement. With picocli developers can add custom command without >> writing >> >>> a lot of boilerplate and error prone code to do a trivial task >> >>> of parsing CLI arguments. Cleaner code, less bugs also matter. >> >>> >> >>> вт, 2 июн. 2020 г. в 16:02, Sergey Antonov < >> antonovserge...@gmail.com>: >> >>> >> >>> > It would be a great usability improvement! >> >>> > >> >>> > +1 From me. >> >>> > >> >>> > вт, 2 июн. 2020 г. в 15:54, Zhenya Stanilovsky >> > >>> > >: >> >>> > >> >>> > > >> >>> > > >> >>> > > good catch ! it`s a little bit pain for now to working with it. >> >>> > > >> >>> > > >> >>> > > >Hi, Igniters! >> >>> > > > >> >>> > > >At the moment to work with the control.sh we need to know >> exactly what >> >>> > > the name of the command and its options are and so the user can >> often >> >>> > make >> >>> > > mistakes when using it. So I think it would be useful to do >> control.sh >> >>> > more >> >>> > > user-friendly by adding autocomplete as in modern command-line >> utilities. >> >>> > > > >> >>> > > >For this purpose, I suggest using framework [1] and to do this, >> take out >> >>> > > control.sh together with its associated classes in a separate >> module such >> >>> > > as "modules/control-utility". >> >>> > > > >> >>> > > >Comments, suggestions? >> >>> > > > >> >>> > > >[1] - https://picocli.info/ >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > BR, Sergey Antonov >> >>> > >> >>> >> >>> -- >> >>> Sincerely yours, Ivan Daschinskiy
[jira] [Created] (IGNITE-13166) Flaky H2RowCachePageEvictionTest and IgniteCacheQueryH2IndexingLeakTest tests
Konstantin Orlov created IGNITE-13166: - Summary: Flaky H2RowCachePageEvictionTest and IgniteCacheQueryH2IndexingLeakTest tests Key: IGNITE-13166 URL: https://issues.apache.org/jira/browse/IGNITE-13166 Project: Ignite Issue Type: Task Reporter: Konstantin Orlov Assignee: Konstantin Orlov Currently we have several tests on TC which considered flaky. Need to investigate and fix them. [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4422957309644246466=testDetails] [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8791646325227962211=testDetails] [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-7378154946319099847=testDetails] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
Alexand Polyakov created IGNITE-13165:
-
Summary: NPE when control utility connect to cluster (VisorTxTask)
Key: IGNITE-13165
URL: https://issues.apache.org/jira/browse/IGNITE-13165
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexand Polyakov
Attachments: error_kanga24.txt
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13164) Thin client: Fix nodeIds format for execute compute tasks request
Aleksey Plekhanov created IGNITE-13164: -- Summary: Thin client: Fix nodeIds format for execute compute tasks request Key: IGNITE-13164 URL: https://issues.apache.org/jira/browse/IGNITE-13164 Project: Ignite Issue Type: Improvement Components: thin client Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov Currently, each node id in thin client execute compute task request is written using 17 bytes (1 byte for type id and 16 bytes for UUID raw data). Since we don't need information about type id and node id can't be null we can write only UUID raw data as now implemented for service invoke request. -- This message was sent by Atlassian Jira (v8.3.4#803005)
