Igniters, i found that near idle check commands only shows partitions in MOVING
states as info in log and not take into account this fact as erroneous idle
cluster state.
control.sh --cache idle_verify, control.sh --cache validate_indexes --check-crc
for example command would show something li
Hi Zhenya,
I see your point. Need to show some message, because cluster is not idle
(rebalance is going).
When cluster not idle we cannot validate partitions honestly. After several
minutes we can to get absolutely different result, without any client's
operation of cache happened.
May be enough
Alex, Denis,
Seems like security API is indeed a bit over-engineered.
Let's get rid of SecurityContext and use SecuritySubject instead.
> SecurityContext is just a POJO wrapper over
> SecuritySubject's
> org.apache.ignite.plugin.security.SecuritySubject#permissions.
> It's functionality can be ea
Hello, Alexei!
Thank you for the review!
I`ve fixed your comments, take a look, please.
пн, 17 февр. 2020 г. в 12:53, Nikita Amelchev :
> Denis,
>
> I have pre-reviewed your changes, LGTM.
>
> Could some security maintainer take a look?
>
> вт, 11 февр. 2020 г. в 20:37, Denis Garus :
> >
> > H
Zhenya,
As for me, the current behavior of idle_verify looks correct.
There's no sense in checking MOVING partitions (on which we explicitly
inform user), however checking consistency between the rest of owners still
makes sense: they still can diverge and we can be aware of the presence of
the co
Guys thank for quick response, Ivan what do you think about Vlad`s proposal to
add additional info like :
"Possible results are not consistent due to rebalance still in progress" ?
Thanks !
>Понедельник, 23 марта 2020, 12:30 +03:00 от Ivan Rakov :
>
>Zhenya,
>
>As for me, the current behavior
Hi, Igniters.
I propose to introduce separate configuration class for SQL configuration.
e.g. SqlInitailConfiguration.
Now we have several SQL parameters:
- sqlSchemas;
- defaultQueryTimeout;
- longQueryWarningTimeout;
- sqlQueryHistorySize;
are placed at the IgniteConfiguration.
I propose to d
Partial results are consistent though.
I'd add something like "Possible results are not full" instead.
On Mon, Mar 23, 2020 at 12:47 PM Zhenya Stanilovsky
wrote:
>
> Guys thank for quick response, Ivan what do you think about Vlad`s
> proposal to add additional info like :
> "Possible results ar
Zhenya, Vlad's message looks incorrectly. How about something like: "Not
all partitions were checked. Check of
partitions was skipped due to rebalancing is in progress. Please rerun
idle_verify after finish rebalancing."
пн, 23 мар. 2020 г. в 12:47, Zhenya Stanilovsky :
>
> Guys thank for quick
Ilya Shishkov created IGNITE-12831:
--
Summary: Invoking destroy of local cache on one node destroys
local caches with the same name on all other nodes
Key: IGNITE-12831
URL: https://issues.apache.org/jira/browse/I
Andrey Kuznetsov created IGNITE-12832:
-
Summary: Add user attributes support to control.sh
Key: IGNITE-12832
URL: https://issues.apache.org/jira/browse/IGNITE-12832
Project: Ignite
Issue
Hello Ignite Community!
My name is Oleg. I want to contribute to Apache Ignite and want to
start with this issue - IGNITE-12832, my JIRA username oleg-a-ostanin.
Any help on this will be appreciated.
Thanks!
Hi Taras,
I support the idea, it brings some order to the IgniteConfiguration.
However, I have strong objections to `Initial` prefix:
> many parameters may be changed in runtime
This applies to many other config properties, but we don't name them
`Initial`
Let's just make it SqlConfiguration.
O
Hello Taras,
I think this is the right way.
I agree with Pavel's comment. It would be nice to provide a list of
properties that can be changed at runtime and remove the word “Initial”
from the class name.
Thanks,
S.
пн, 23 мар. 2020 г. в 16:54, Pavel Tupitsyn :
> Hi Taras,
>
> I support the ide
Hi,
> It would be nice to provide a list of properties that can be changed
at runtime
Ok, I catch the your and Pavel's opinion.
My be add javadoc for each changed parameter instead of list?
e.g. for longQueryWarningTimeout
See {@link
org.apache.ignite.internal.mxbean.SqlQueryMXBean#setLongQu
Folks,
Let's revive this discussion until it's too late and all API changes are
merged to master [1].
Seems like we don't have a final agreement on whether we should add force
flag to deactivation API.
First of all, I think we are all on the same page that in-memory caches
data vanishing on deact
Hello!
I think that we should defer changes to IgniteConfiguration to AI 3.0.
Maybe it will motivate us to start work on it.
Just my opinion, without any reservations.
Regards.
--
Ilya Kasnacheev
пн, 23 мар. 2020 г. в 13:04, Taras Ledkov :
> Hi, Igniters.
>
> I propose to introduce separat
Hello, Alexei, Ivan!
>> Seems like security API is indeed a bit over-engineered
Nobody has doubt we should do a reworking of GridSecurityProcessor.
But this point is outside of scope thin client's problem that we are
solving.
I think we can create new IEP that will accumulate all ideas of Ignite'
Oleg, welcome to the community! I've added you to the contributors' list in
JIRA.
Look forward to seeing your first contribution completed shortly. Let us
know if you have any questions.
-
Denis
On Mon, Mar 23, 2020 at 6:22 AM Oleg Ostanin
wrote:
> Hello Ignite Community!
>
> My name is Oleg.
Hi Kartik, welcome back to the community! Let's work together this time to
help you drive your contributions to a logic end ;)
Maksim, thanks for stepping in and offering extra support.
-
Denis
On Sun, Mar 22, 2020 at 6:21 AM Maksim Stepachev
wrote:
> Hi, you are welcome!
>
> If you have any
Hi Kartik,
Actually, it means quite the opposite. You should fill in the release notes
field before the ticket is resolved/closed so that a release manager of a
next Ignite version adds a proper line to the final release notes with all
the changes.
As for the docs, it's highly likely you don't ne
Hello, Ivan.
> Seems like we don't have a final agreement on whether we should add force
flag to deactivation API.
I think the only question is - Do we need —force flag in Java API or not.
> As a final solution, I'd want to see behavior when all in-memory data is
> available after deactivation
Hi,
In 2.8.0 maven version of ignite-core, I encountered one issue within spring
service configuration.
All service properties fields are null (Ex. testField1, testField2) at
runtime on TestServiceImpl - init() or execute().
In 2.7.6 version everything works well.
Ex.
...
Hi,
I tried to reproduce the behaviour you described, but everything works fine
for me. Please check if I missed something:
https://github.com/ezhuravl/ignite-code-examples/tree/master/src/main/java/examples/service/parameters
https://github.com/ezhuravl/ignite-code-examples/blob/master/src/main/r
24 matches
Mail list logo
