ello Igniters,
I’m planning to change
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
(because I have pending pull request for changing binary meta location), but
don’t have rights for this.
Can someone please give me the access?
Sincerely yours,
Sem
Ivan Rakov,
Your proposal overall looks good to me. My comments:
1. I would avoid adding such a method, because it will be impossible to
change it in the future if some more shutdown policies will be introduced
later.
Also shutdown policy must be always consistent on the grid or unintentional
dat
Hello!
What is your login for apache wiki?
Regards,
--
Ilya Kasnacheev
вт, 9 июн. 2020 г. в 10:11, Данилов Семён :
> ello Igniters,
>
> I’m planning to change
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
> (because I have pending pull request f
I have this scenario:
1 Cluster with 2 server nodes and 4 caches configured with partitioned mode.
With this settings, if I try to recover the data with a client node I lose
some information, but if I have the same scenario with just 1 server node, I
recover all data.
Why? Some miss settings?
T
Alex,
Also shutdown policy must be always consistent on the grid or unintentional
> data loss is possible if two nodes are stopping simultaneously with
> different policies.
Totally agree.
Let's use shutdownPolicy=DEFAULT|GRACEFUL, as was proposed by me earlier.
I'm ok with GRACEFUL instead o
Something went wrong with gmail formatting. Resending my reply.
Alex,
Also shutdown policy must be always consistent on the grid or unintentional
> data loss is possible if two nodes are stopping simultaneously with
> different policies.
Totally agree.
Let's use shutdownPolicy=DEFAULT|GRACEFUL
Ivan,
Using an additional enum on public API for resetting dynamic value looks a
little bit dirty for me.
I'm not sure there is a problem at all, because user can always query the
current policy, and a javadoc can describe such behavior clearly.
If you really insist maybe use null to reset policy
Roman Kondakov created IGNITE-13136:
---
Summary: Calcite integration. Improve join predicate testing.
Key: IGNITE-13136
URL: https://issues.apache.org/jira/browse/IGNITE-13136
Project: Ignite
Vyacheslav Koptilin created IGNITE-13137:
Summary: WAL reservation may failed even though the required
segment is available
Key: IGNITE-13137
URL: https://issues.apache.org/jira/browse/IGNITE-13137
Alex,
I'm not sure there is a problem at all, because user can always query the
> current policy, and a javadoc can describe such behavior clearly.
What will the query method return if the static policy is not overridden?
If we decide to avoid adding dedicated USE_STATIC_CONFIGURATION value,
sema
Sergey Antonov created IGNITE-13138:
---
Summary: Add REST tests for the new cluster state change API
Key: IGNITE-13138
URL: https://issues.apache.org/jira/browse/IGNITE-13138
Project: Ignite
Alex,
Also shutdown policy must be always consistent on the grid or unintentional
> data loss is possible if two nodes are stopping simultaneously with
> different policies.
Totally agree.
Let's use shutdownPolicy=DEFAULT|GRACEFUL, as was proposed by me earlier.
I'm ok with GRACEFUL instead o
I have this scenario:
1 Cluster with 2 server nodes and 4 caches configured with partitioned mode.
With this settings, if I try to recover the data with a client node I lose
some information, but if I have the same scenario with just 1 server node, I
recover all data.
Why? Some miss settings?
T
Greetings, Nikolay,
First of all, thank you for you great effort preparing PoC of
integration testing to Ignite community.
It’s a shame Ignite did not have at least some such tests yet, however,
GridGain, as a major contributor to Apache Ignite had a profound
collection of in-house tools to
Hi,
ignite.cluster().setShutdownPolicy(null); // Clear dynamic value and switch
to statically configured.
I do not understand why we need it. if user want to change configuration to
any other value he set it explicitly.
We can to add warning on start when static option does not math to dynamic
(d
Hello!
Please consider moving to user list.
If you have backups configured you should not lose information when server
is down. Otherwise, it's hard to say what's going on. Do you have a
reproducer?
Regards.
--
Ilya Kasnacheev
вт, 9 июн. 2020 г. в 13:55, Toni Mateu Sanchez <
antonio.ma...@glo
Hi,
Indeed, the tracing feature is almost ready. Discovery, communication and
transactions tracing will be introduced, as well as an option to configure
tracing in runtime. Right now we are working on final performance
optimizations, but it's very likely that we'll complete this activity
before th
Vlad,
+1, that's what I mean.
We don't need either or dedicated USE_STATIC_CONFIGURATION in case
the user will be able to retrieve current shutdown policy and apply the one
he needs.
My only requirement is that ignite.cluster().getShutdownPolicy() should
return a statically configured value {@lin
+1, this is exactly what I want.
I'm fine with either IMMEDIATE or DEFAULT.
вт, 9 июн. 2020 г. в 19:41, Ivan Rakov :
> Vlad,
>
> +1, that's what I mean.
> We don't need either or dedicated USE_STATIC_CONFIGURATION in case
> the user will be able to retrieve current shutdown policy and apply the
Hello Igniters,
I've created the PR for this ticket with related changes in
ignite-spring-data-2.0 and ignite-spring-data-2.2, also I added some
examples in ignite-examples.
I didn't find a maintainer of this component. Who can review my PR?
With best regards,
Sergey.
Hi Team,
I am deploying ignite clustered application on distributed servers.
This works fine for me in local able to add many nodes.
But I am deploying this on AWS where limited ports are open between these
servers, I already open
47500-47520,47100-47120,48100-48120,49500-49520,48500-48520.
Now
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
Tomasz Grygo created IGNITE-13139:
-
Summary: exception when closing Ignite at program end
Key: IGNITE-13139
URL: https://issues.apache.org/jira/browse/IGNITE-13139
Project: Ignite
Issue Type:
Andrey N. Gura created IGNITE-13140:
---
Summary: Incorrect example in Pull Request checklist: comma after
ticket name in commit message
Key: IGNITE-13140
URL: https://issues.apache.org/jira/browse/IGNITE-13140
24 matches
Mail list logo
