I support the idea. All issues notifications are also sent to
iss...@ignite.apache.org so one can subscribe to this list in order to
track the created tickets. The notifications trash the devlist archive UI
and make it extremely difficult to navigate.
вт, 20 апр. 2021 г. в 18:35, Ilya Kasnacheev
Aleksei,
> The method should always report root cause, in your example it will be
> B-, no matter which module API is called
I may be wrong, but I doubt this will be usable for an end-user. Let's
imagine that the same root exception was raised in different contexts
resulting in two outcomes.
Hello Denis, Andrey, Igniters,
Why don't we take a step further in improving the security model in Ignite
3? I think it would be great to have a default implementation of
user-role-permission model in Ignite to be on par with security models of
widely-used databases. This will complement
be free to change them without any compatibility contract" -
> let's mark such classes with a special annotation like @Internal, will it
> work for you ?
>
>
>
> ср, 31 мар. 2021 г. в 15:10, Alexey Goncharuk >:
>
> > This won't work with the Java Jigsaw module sys
Alexey Goncharuk created IGNITE-14502:
-
Summary: Ignite 3: Consider JSON-formatted toString implementations
Key: IGNITE-14502
URL: https://issues.apache.org/jira/browse/IGNITE-14502
Project
Alexey Goncharuk created IGNITE-14501:
-
Summary: Ignite 3: Fix toString implementations
Key: IGNITE-14501
URL: https://issues.apache.org/jira/browse/IGNITE-14501
Project: Ignite
Issue
Alexey Goncharuk created IGNITE-14459:
-
Summary: Affinity call may fail if called upon merged exchanges
Key: IGNITE-14459
URL: https://issues.apache.org/jira/browse/IGNITE-14459
Project: Ignite
e. What are the benefits of this ?
>
> ср, 31 мар. 2021 г. в 12:16, Alexey Goncharuk >:
>
> > Alexei,
> >
> > I had the same opinion regarding the internal package, but we still need
> to
> > somehow distinguish between public and internal classes in the
> ignite-uti
ient as affinity or schema make no sense without the table.
> > Processor is just helper-component of the Service that routes messages,
> > executes async tasks, manages subscriptions and implements some secondary
> > functions.
> >
> > On Tue, Mar 30, 2021 at 11:24 AM
Ivan,
My concern with the concept of a user completing the future returned from
Ignite public API is that it is unclear how to interpret this action (this
backs Val's message).
Let's say a user started a compute with fut = compute.runAsync(task); and
now calls fut.complete(someVal); Does this
Hello Alexander, Igniters,
I support the suggestion, we need to work out some ground rules to have a
consistent naming convention. Agree with having at most one component per
project module - this requirement may turn out to be too strict in the
future, but now it seems reasonable and may help us
Alexey Goncharuk created IGNITE-14393:
-
Summary: Describe components interactions with metastorage
Key: IGNITE-14393
URL: https://issues.apache.org/jira/browse/IGNITE-14393
Project: Ignite
Alexey Goncharuk created IGNITE-14325:
-
Summary: SQL COPY command: when conversion fails, the error does
not contain information about line number and the failed value
Key: IGNITE-14325
URL: https
Alexey Goncharuk created IGNITE-14315:
-
Summary: Ignite 3: Use maven-flatten plugin for project pom.xml
Key: IGNITE-14315
URL: https://issues.apache.org/jira/browse/IGNITE-14315
Project: Ignite
Alexey Goncharuk created IGNITE-14272:
-
Summary: Merge modules/DEVNOTES.txt and DEVNOTES.txt
Key: IGNITE-14272
URL: https://issues.apache.org/jira/browse/IGNITE-14272
Project: Ignite
Alexey Goncharuk created IGNITE-14112:
-
Summary: Revisit GridClosureProcessor#runLocalSafe(Runnable, byte)
usages
Key: IGNITE-14112
URL: https://issues.apache.org/jira/browse/IGNITE-14112
Project
Alexey Goncharuk created IGNITE-14111:
-
Summary: Clarify how AbstractDataPageIO works
Key: IGNITE-14111
URL: https://issues.apache.org/jira/browse/IGNITE-14111
Project: Ignite
Issue Type
Alexey Goncharuk created IGNITE-14002:
-
Summary: Formalize coding guidelines for platforms (C++, Python,
Node)
Key: IGNITE-14002
URL: https://issues.apache.org/jira/browse/IGNITE-14002
Project
Alexey Goncharuk created IGNITE-14001:
-
Summary: Minor code style fixes for configuration and runner
modules
Key: IGNITE-14001
URL: https://issues.apache.org/jira/browse/IGNITE-14001
Project
Alexey Goncharuk created IGNITE-14000:
-
Summary: Ignite 3.0: Fix codestyle for cli and cli-common packages
Key: IGNITE-14000
URL: https://issues.apache.org/jira/browse/IGNITE-14000
Project: Ignite
Folks,
I updated the IEP to contain the missing pieces; actually, most of the
questions here were covered by the text. Please let me know if there is
something still missing or unclear.
чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk :
> Mikhail and Igniters,
>
> Thanks for your
y thoughts or objections?
> > > > Are interfaces good enough to be merged within the current ticket?
> > > >
> > > >
> > > > https://issues.apache.org/jira/browse/IGNITE-13748
> > > >
> > > > On Thu, Nov 26, 2020 at 2:33 PM Юрий
> &
Alexey Goncharuk created IGNITE-13874:
-
Summary: Add PMD and idea inspections to Ignite-3 build cycle
Key: IGNITE-13874
URL: https://issues.apache.org/jira/browse/IGNITE-13874
Project: Ignite
Alexey Goncharuk created IGNITE-13800:
-
Summary: Provide distributed metastorage interface
Key: IGNITE-13800
URL: https://issues.apache.org/jira/browse/IGNITE-13800
Project: Ignite
Issue
Alexey Goncharuk created IGNITE-13799:
-
Summary: Provide a required storage interface for metastorage and
partitions for replication protocol
Key: IGNITE-13799
URL: https://issues.apache.org/jira/browse
Alexey Goncharuk created IGNITE-13798:
-
Summary: Prototype Raft implementation port to a separate
zero-dependency Ignite module
Key: IGNITE-13798
URL: https://issues.apache.org/jira/browse/IGNITE-13798
The vote is closed now.
Vote result: Vote passed with 5 "+1" votes (3 binding and 2 non-binding
votes), no "0" and no "-1" votes.
+1 Votes:
Denis Magda (binding)
Saikat Maitra (binding)
Andrey Gura (binding)
Kirill Tkalenko
Konstantin Orlov
Vote thread
t; чт, 26 нояб. 2020 г. в 13:18, Ivan Daschinsky :
>
> > Alexey, is it possible to manage call at 16:00 MSK?
> >
> > чт, 26 нояб. 2020 г. в 12:30, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Hi Ivan,
> > >
> > &
ariant -- in the morning.
>
> ср, 25 нояб. 2020 г. в 20:10, Alexey Goncharuk >:
>
> > Folks, let's have the call on Friday, Nov 27th at 18:00 MSK? We can use
> the
> > following waiting room link:
> > https://zoom.us/j/99450012496?pwd=RWZmOGhCNWlRK0ZpamdOOTZsYTJ0dz09
Folks, let's have the call on Friday, Nov 27th at 18:00 MSK? We can use the
following waiting room link:
https://zoom.us/j/99450012496?pwd=RWZmOGhCNWlRK0ZpamdOOTZsYTJ0dz09
Let me know if this time works for everybody.
ср, 25 нояб. 2020 г. в 16:42, Alexey Goncharuk :
> Folks,
>
> I've
пн, 23 нояб. 2020 г. в 13:28, Alexey Goncharuk :
> Thanks, Ivan,
>
> Another protocol for group membership worth checking out is RAPID [1] (a
> recent one). Not sure though if there are any available implementations for
> it already.
>
> [1] https://www.usenix.org/system/f
gt; end of story.
>
> On Tue, Nov 24, 2020 at 6:25 PM Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> wrote:
>
> > Folks, I think this is a reasonable request. I thought about this when I
> > was drafting the IEP, but hesitated to add these types right away.
> &g
gt; > > > > should be validated against the latest version
> and
> > > > local
> > > > > > > > mapping
> > > > > > > > > > > should
> > > >
Alexey Goncharuk created IGNITE-13753:
-
Summary: Non-thread-safe collection is used for the list of
registered MBeans in JmxMetricExporterSpi
Key: IGNITE-13753
URL: https://issues.apache.org/jira/browse
Dear Ignite Community,
I have uploaded a release candidate of the following extension modules:
ignite-camel-ext
ignite-flink-ext
ignite-flume-ext
ignite-jms11-ext
ignite-kafka-ext
ignite-mqtt-ext
ignite-pub-sub-ext
ignite-rocketmq-ext
ignite-storm-ext
ignite-twitter-ext
ignite-zeromq-ext
The
Alexey Goncharuk created IGNITE-13745:
-
Summary: Add release notes for streaming extensions release 1.0.0
Key: IGNITE-13745
URL: https://issues.apache.org/jira/browse/IGNITE-13745
Project: Ignite
> etcd (see raft/node.go) contains some heartbeats mechanism etc.
> > I agree with you, this seems not to be a huge deal to port.
> >
> > чт, 19 нояб. 2020 г. в 16:13, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> >> Ivan,
> >>
> >&
Igniters,
I think we a bit overdue for releasing already migrated extension modules
which were removed in Ignite 2.9. As Saikat mentioned, I suggest releasing
the following modules:
ignite-flink-ext
ignite-flume-ext
ignite-pub-sub-ext
ignite-zeromq-ext
ignite-twitter-ext
ignite-rocketmq-ext
an Daschinsky :
> >
> >>
> >>
> >> -- Forwarded message -
> >> От: Ivan Daschinsky
> >> Date: чт, 19 нояб. 2020 г. в 13:02
> >> Subject: Re: IEP-61 Technical discussion
> >> To: Alexey Goncharuk
> >>
&g
Following up the Ignite 3.0 scope/development approach threads, this is a
separate thread to discuss technical aspects of the IEP.
Let's reiterate one more time on the questions raised by Ivan and also see
if there are any other thoughts on the IEP:
- *Whether to deploy metastorage on a
I support having a single vote for all the extensions. Mikhail, do you mind
releasing the rest of the modules together with spring-boot? If you do, I
can take care of them but looks like this will be a separate vote, though.
чт, 19 нояб. 2020 г. в 10:55, Petr Ivanov :
> No 11 separate votes, but
Good,
I think we have an intermediate agreement on the scope and significance of
the changes we want to make. I suggest creating separate discussion streams
and calls for each of the suggested topics so that:
- It is clear for the community what is the motivation of the stream
(this
s sense to me.
> > > > >>>
> > > > >>> вт, 10 нояб. 2020 г. в 18:47, Sergey Chugunov <
> > > > sergey.chugu...@gmail.com>:
> > > > >>>
> > > > >>>> Igniters,
> > > >
e extensions as independent as possible.
> >
> > Doubt if we can do it for each module.
> > We have, ignite-hibernate_4.2, ignite-hibernate_5.1 modules that
> attached to specific hibernate version by their name.
> >
> >
> >> 11 нояб. 2020 г., в 11:19, Alex
Alexey Goncharuk created IGNITE-13693:
-
Summary: Add flags field with tombstone support, update schema
size to 2 bytes
Key: IGNITE-13693
URL: https://issues.apache.org/jira/browse/IGNITE-13693
:
> >
> >> Alex,
> >>
> >> Should we create a dedicated ticket for the documentation changes or
> can we
> >> reuse IGNITE-13634? As a bare minimum, we need to update maven
> artifacts'
> >> names and versions:
> >>
> >>
&
iev <
> zaleslaw@gmail.com>
> > > > wrote:
> > > >
> > > >> Let's discuss the possible planning dates for feature freeze for
> 2.10,
> > > for
> > > >> example? Do you have any plans or ideas?
> > > >>
> >
Alexey Goncharuk created IGNITE-13670:
-
Summary: Omit nullmap where possible
Key: IGNITE-13670
URL: https://issues.apache.org/jira/browse/IGNITE-13670
Project: Ignite
Issue Type
Alexey Goncharuk created IGNITE-13669:
-
Summary: Implement date native types
Key: IGNITE-13669
URL: https://issues.apache.org/jira/browse/IGNITE-13669
Project: Ignite
Issue Type
Alexey Goncharuk created IGNITE-13668:
-
Summary: Implement Number(n) and Decimal native types
Key: IGNITE-13668
URL: https://issues.apache.org/jira/browse/IGNITE-13668
Project: Ignite
Alexey Goncharuk created IGNITE-13667:
-
Summary: Add schema columns relocation table to map from user
order to system order
Key: IGNITE-13667
URL: https://issues.apache.org/jira/browse/IGNITE-13667
Folks,
I want to bump up this discussion and slightly change the format suggested
by Nikita. I dot think it is correct to gather any information related to
the user environment. However, can we collect just the fact of some of the
Ignite APIs/subsystems being used with no user information
t;> component wiring mechanics, general methods to approach core components
> >> such as exchange/communication
> >> to avoid code mess like we have in ExchangeFuture with all these custom
> >> callbacks for each component, interfaces like
> >> Partiti
bugs and issues that can be fixed in 2.x without breaking
> backward
> > compatibility.
> > We have many users who are happy with the 2.x with all it’s issues.
> >
> > > 2 нояб. 2020 г., в 14:09, Anton Vinogradov написал(а):
> > >
> > > Alexey,
> > >
> >
APIs
> and internal structure is overwhelming
> >
> > Maybe we should relax a bit requirements for Ignite3?
> > Maybe we should move step by step and make Ignite3 with new
> configuration than Ignite4 with new transactions, etc?
> >
> >> 2 нояб. 2020 г., в 13:1
Igniters,
I wanted to pitch a rather radical idea regarding the Ignite 3.0
development which has occurred to me some time ago.
We already have several IEPs targeted to Ignite 3.0 which imply major
changes to the codebase (the change in replication protocol and thus
transactions, change in binary
Hello folks,
I think we should start both 2.9.1 and 2.10. In practice, maintenance
release contains only critical and usability bugfixes (for example, I would
include this ticket [1] to include in 2.9.1 as it prevents users from using
tracing) and is released much faster than a minor release.
Igniters,
Since Ignite 2.9 has been released, I think we can now release the
extension modules related to streaming.
I noticed that unlike spring autoconfigure, the streamer extensions
dependencies do not have provided scope, so I created a ticket to fix that
[1]. Anything else we should fix
Alexey Goncharuk created IGNITE-13634:
-
Summary: Ignite-extensions: update dependencies to use provided
scope
Key: IGNITE-13634
URL: https://issues.apache.org/jira/browse/IGNITE-13634
Project
Alexey Goncharuk created IGNITE-13616:
-
Summary: IEP-54 Live schema for tables
Key: IGNITE-13616
URL: https://issues.apache.org/jira/browse/IGNITE-13616
Project: Ignite
Issue Type: Bug
Hello Ivan,
Thanks for the feedback, see my comments inline:
чт, 22 окт. 2020 г. в 17:59, Ivan Daschinsky :
> Hi!
> Alexey, your proposal looks great. Can I ask you some questions?
> 1. Is nodes, that take part of metastorage replication group (raft
> candidates and leader) are expected to also
Hello Yakov,
Glad to see you back!
Hi!
> I am back!
>
> Here are several ideas on top of my mind for Ignite 3.0
> 1. Client nodes should take the config from servers. Basically it should be
> enough to provide some cluster identifier or any known IP address to start
> a client.
>
This totally
Hello Nikolay,
Thanks for the suggestion, it definitely may be a good feature, however, I
do not see any significant value that it currently adds to the already
existing WAL Iterator. I think the following issues should be addressed,
otherwise, no regular user will be able to use the CDC
Nikolay,
> > I thought the extensions should be tested against the latest released
> Ignite version
>
> It seems, we should try to keep extension Ignite version agnostic.
> If it impossible, then yes, we should use latest Ignite version.
>
I doubt it's possible at least for OSGi: the published
Nikolay, Saikat, Igniters,
I started migrating the OSGi modules to the ignite-extensions repository
and I've got some questions regarding the ignite-extensions project:
- We agreed that ignite extensions have their own release cycle, so why
do we reference a -snapshot version of Ignite in
Makes sense,
I added a tag copy to match the released module name.
вт, 13 окт. 2020 г. в 10:08, Petr Ivanov :
> Keep it as a reference to what?
> That tag will be confusing both users and developers because:
> — there is no release of any extension with version 1.0, only 1.0.0
> —
the ignite-extensions
> > >>>> modules
> > >>>>> as required.
> > >>>>> 4. Update the docs for ignite-extensions modules in ignite-website.
> > >>>>> 5. Release each module separately and share updates.
> > >>>
Alexey Goncharuk created IGNITE-13570:
-
Summary: Migrate OSGI module to ignite-extensions
Key: IGNITE-13570
URL: https://issues.apache.org/jira/browse/IGNITE-13570
Project: Ignite
Issue
Denis,
I've tried to quickly add licenses to the files, but there are simply too
many different file types in the change. I reverted the original commit and
the dependent one about the continuous query guarantees (which, btw, was
merged without ticket name and with a merge commit).
Please make
root: "GitBox [asf/ignite]" {instance id=300, parent
>> > internal id=74, parent id=GitBoxAsfIgnite, description: "
>> > https://gitbox.apache.org/repos/asf/ignite.git#refs/heads/master"}
>> >
>> > Is there some problem with this TC task? What am
t; >>> > Andrey, can you take a look at my change? I think it is fairly
> >>> straightforward and does not change the semantics, just skips the
> factory
> >>> closures for certain messages.
> >>>
> >>> IMHO 2.5% isn't too much especially b
Hi folks,
Despite the autocompletion support only for bash, I see the following
benefits from this change:
* It may unify all the CLI tooliing in Ignite, providing a better user
experience
* The library has an ability to generate man pages, which may be nice
* I see there is an open issue for
lowing the instruction. Unfortunately, I won't be
>> able to spend any time on this project any longer. You can send your pull
>> requests and questions about the documentation to Denis Magda.
>>
>> -Artem
>>
>> [1] : https://cwiki.apache.org/confluence/display/IGNIT
; order since the 2 row when fields_count>10"
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12809
> > > [2]
> >
> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
> > >
> > > > 31 авг. 2020
Ivan,
Thank you, I got your concern now. As it is mostly regarding the
terminology, I am absolutely fine with changing the name to whatever fits
the approach best. Dynamic or evolving schema sounds great. I will make
corresponding changes to the IEP once we settle on the name.
пн, 7 сент. 2020
Ivan,
Thank you for reminding me about the dynamic schema. I've updated the IEP
draft with more details on the approach, hopefully now it's more clear. I
think we will be able to take the best from both fixed-schema and
schemaless approaches.
вт, 1 сент. 2020 г. в 14:31, Ivan Pavlukhin :
> Hi
do with IGNITE-12568 (MessageFactory refactoring)?
>
> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk >:
>
>> Alexey,
>>
>> While investigating, I found that IGNITE-12568 has an incorrect fix
>> version and is actually present in ignite-2.8.1 branch [1], so
to verify the fix versions.
--AG
[1]
https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk :
> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov :
>
>> Guys,
>>
>> We have benchmarked 2.9 without IGNIT
пт, 28 авг. 2020 г. в 11:16, Alex Plehanov :
> Guys,
>
> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
> locally) and got the same performance as on 2.8.1
>
> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
> hot paths, it's clear why we have
>
> Alexey.
>
> This option should be on the server side, so server administrator can
> disable stack trace for all clients.
> Correct?
>
Yes, correct.
Hello folks,
I agree with Val: IgniteFuture was created long before we could use the
Java futures and is being kept for compatibility reasons. While keeping API
consistent between thin/thick clients is a good reason, I think moving to
Java futures benefits more to the project and end-users.
Zhenya,
Stacktraces are considered to be able to expose sensitive information about
code, see [1]. So as previously, I agree with Pavel that we should have an
option to disable this behavior.
[1]
Kirill,
Thank you for driving this discussion and implementation.
A few points from my side:
* Agree that it will be best to keep the strategy interface private because
it will be very dependent on the persistent storage implementation. We
would need to expose page IDs and types to public API,
Konstantin, thank you, I will take a look.
пт, 31 июл. 2020 г. в 19:04, Konstantin Sirotkin :
> Hello!
>
> Done, I divided the PR into five smaller ones 8090-8093,8095.
> Can someone please check the changes now?
>
> Thanks.
>
> ---
> Kind Regards,
> Konstantin Sirotkin
>
> On 28 Jul 2020, at
Hello Nikolay,
> > 10. Question - CRC is read in two places encryptionFileIO and
> filePageStore - what should we do with this?
>
> filePageStore checks CRC of the encrypted page. This required to confirm
> the page not corrupted on the disk.
> encryptionFileIO checks CRC of the decrypted
nd serve client requests. Entries for not
> owning anymore partitions expire according to configuration.
>
> Actually, I have an idea. My guess is that "rebalancing" is a smarter
> and better approach than waiting for expiration. Am I right?
>
> 2020-07-21 15:31 GMT+03:00, Alex
evidence:
> > >
> >
> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
> > >
> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
> > >
> > > wrote:
> > >
> > >> Igniters,
> &
Igniters,
I would like to run the idea of deprecating and probably ignoring the NONE
rebalance mode by the community. It's in the removal list for Ignite 3.0
[1], but it looks like it still confuses and creates issues for users [2].
What about deprecating it in one of the next releases and even
Stan,
Currently we never build indexes one-by-one - we always use a cache data
row visitor which either updates all indexes (see IndexRebuildFullClosure)
or updates a set of all indexes that need to catch up (see
IndexRebuildPartialClosure). GIven that, I do not see any need for
per-index rebuild
Alexey Goncharuk created IGNITE-13241:
-
Summary: Get rid of Externalizable implementation for
GridCacheAdapter
Key: IGNITE-13241
URL: https://issues.apache.org/jira/browse/IGNITE-13241
Project
Alexey Goncharuk created IGNITE-13220:
-
Summary: Cleanup IgniteCacheOffheapManager interface
Key: IGNITE-13220
URL: https://issues.apache.org/jira/browse/IGNITE-13220
Project: Ignite
Alexey Goncharuk created IGNITE-13195:
-
Summary: Allow skipping autotools invocation when building Ignite
release
Key: IGNITE-13195
URL: https://issues.apache.org/jira/browse/IGNITE-13195
Project
Hello Maxim, folks,
ср, 6 мая 2020 г. в 21:01, Maxim Muzafarov :
> We won't do performance analysis on the production environment. Each
> time we need performance analysis it will be done on a test
> environment with verbose logging enabled. Thus I suggest moving these
> changes to a separate
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
Nikita, Igniters,
I left a few comments on the tool itself in the PR.
However, I would like to reiterate and discuss why a user would prefer to
use the profiling tool over tracing? Profiling tool only captures very
high-level details of the operations (a single cache operation, for
example), and
> affecting cluster availability and consistency. That ticket reminds me of
> those notorious issues that would fire once a week or month under specific
> configuration settings. So, I would not touch the code that fixes the issue
> unless @Alexey Goncharuk or @Sergey Chugunov
> co
Alexey,
Hello,
>
> I've benchmarked 1-operation approach vs 2-operations approach and
> published benchmark results on IEP page [1]. It looks like performance
> almost the same, so the single-operation approach should be implemented.
>
Do I understand correctly that you suggest to remote
the
> > How exactly do you want to change the StopNodeFH?
> I want to stop JVM with KILL_EXIT_CODE and add an option (constructor
> argument of JVM option) for disabling JVM termination.
>
When the flag is enabled, the behavior is identical to StopNodeOrHaltFH
with tryStop=false. In other words,
Sergey,
How exactly do you want to change the StopNodeFH? The current behavior does
not terminate the JVM and its exit code is totally out of our control; one
of the use-cases we had in mind for this failure handler is that a user may
have other processes running in the same JVM, so we do not
Alexey Goncharuk created IGNITE-13101:
-
Summary: Metastore may leave uncompleted write futures during node
stop
Key: IGNITE-13101
URL: https://issues.apache.org/jira/browse/IGNITE-13101
Project
1 - 100 of 980 matches
Mail list logo
