HAOFENG DENG created IGNITE-12623:
-
Summary: ClassCastException on Thin client when get cache value
with List and Map
Key: IGNITE-12623
URL: https://issues.apache.org/jira/browse/IGNITE-12623
Project:
Nick
Can we retain only single cancel(long queryId) method in QueryMXBean ?
I think query type can be determined by queryId.
I also think we need similar "cancellation" API without the need to use mx
beans.
вт, 4 февр. 2020 г. в 18:07, Nikolay Izhikov :
> Hello, Igniters.
>
> I propose to creat
Hello all.
Denis, which changes exactly? In current implementation of ticket [2] flag
[1] is checked before requiring --force flag and showing any warnings. Do
we need to set reuse-memory-on-deactivate to true by default?
[1]
org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIV
Folks,
Shouldn't we unify identifiers for all ongoing tasks in Ignite and move
cancel to a single method in a single bean?
Right now different types of IDs (long, UUID, IgniteUuid) look confusing
and messy. I understand that such API is enforced by the IDs implementation
in the corresponding Igni
Denis,
I just realized that this vote would not be a regular Apache vote we used
to run. Usually we vote for a change to be accepted or rejected. Here, on
the other hand, we need to choose between two alternatives, and I am not
sure yet how this should be formally handled.
Dmitriy, perhaps, you c
Sorry for the rush, I think I got it - it's right in the voting process
[1]. This would be a vote on a procedural issue of how to handle code
deprecation.
I'll start the discussion soon, let's agree on the alternatives and then
start the vote.
[1] https://www.apache.org/foundation/voting.html
Folks,
A bit of offtop. Do we have some recommendations in the community how
long should we wait until treating something as "a Community
conclusion"? It worries me a little bit that I see a discussion for a
first time and there is already a conclusion. And the discussion was
started lesser than 2
Andrey,
> > Andrey, then I suggest firstly check if old annotations are present,
and if
> > not - are there any new annotations. Do you agree?
> I'm afraid I don't understand. Old annotations are present and new
> annotations don't exist yet :)
I talked about implementation of methods *getDescri
Ivan.
It seems we don’t have a format definition for a «community decision»
We, for sure, should fill this gap.
Me and Andrey Gura, have certain proposals for our development process based on
metrics API discussion.
We will share those proposals after 2.8 release and some additional discussion.
Different approaches are possible. For me it would be logical if
MXBeanParameter override MXBeanParametersNames and
MXBeanParametersDescriptions.
In such case the order of annotation processing is fixed: old on
method then new on method's parameters if exists.
On Wed, Feb 5, 2020 at 1:11 PM Лев Ки
Ivan,
Thanks for pointing this out. Less than one day is indeed too early to
treat this discussion thread as a "community conclusion". Still, the
consensus among the current participants made me feel that a conclusion
will be reached.
We'll surely get back to the discussion if opposite opinions wi
Aleksey Plekhanov created IGNITE-12624:
--
Summary: Java thin client: Wrong typeId generation for system types
Key: IGNITE-12624
URL: https://issues.apache.org/jira/browse/IGNITE-12624
Project: Igni
Igniters, thanks for the feedback.
> Can we retain only single cancel(long queryId) method in QueryMXBean ?
> I think query type can be determined by queryId.
It seems the answer is no we can’t do it for now.
Different types of queries are handled by different managers and have different
sets of
Nikolay,
> Consider copy-pasting wrong id from log to its
> parameters(killing not the buggy compute task, but *VERY* important
> transaction.
> How users even know about this type of error with the
> single method approach?
>
> I thought that the identifiers would
Alexey.
I’m talking the following scenario:
1. Consider we have unified bean to kill tasks:
CancelMXBean {
public void cancel(long id);
}
2. And we have the following log:
```
Transaction with ID=42 started.
Compute task with ID=43 started.
```
3. We want to kill compute task and by
Hi, folks.
I recently found that one node might be started with flag
reuse-memory-on-deactivate [1] set off while another node might be
configured with the flag enabled. This ability hinders prediction of
cluster behavior on deactivation/activation. One node keeps data in memory,
other doesn’t.
Aleksey Plekhanov created IGNITE-12625:
--
Summary: Thin client: Marshaling/unmarshaling of objects performed
twice
Key: IGNITE-12625
URL: https://issues.apache.org/jira/browse/IGNITE-12625
Project
Vladimir.
This looks like a bug to me.
Can you, please, prepare the simple reproducer for this issue and it’s
consequences?
> 5 февр. 2020 г., в 17:08, Vladimir Steshin написал(а):
>
> Hi, folks.
>
>
>
> I recently found that one node might be started with flag
> reuse-memory-on-deactivat
Hello!
Just to resurrect this old thread:
I have uncommented another batch of tests, would appreciate a review of PR:
https://issues.apache.org/jira/browse/IGNITE-9216
Regards,
--
Ilya Kasnacheev
ср, 31 окт. 2018 г. в 15:22, Ilya Kasnacheev :
> Hello!
>
> So we have uncommented 4 batches out
Anton, Mikhail,
I stumbled upon impossibility to configure plugin with out adding
appropriate class names to org.apache.ignite.plugin.PluginProvider
file and found change where this possibility was added [1].
Thanks a lot for this change. I noticed also that
IgniteConfiguration.setPluginProviders
Hello, Igniters.
We don't have a release process for newly created ignite-extensions modules.
I want to release two modules:
* ignite-spring-boot-autoconfigure
* ignite-client-spring-boot-autoconfigure
Let's discuss it.
Any objections to it?
What should be done before release?
Alex, did you have a chance to review Saikat’s changes related to the
extensions repository organization and release approach?
Denis
On Wednesday, February 5, 2020, Nikolay Izhikov wrote:
> Hello, Igniters.
>
> We don't have a release process for newly created ignite-extensions
> modules.
> I w
Maxim Muzafarov created IGNITE-12626:
Summary: Add RELEASE_NOTES about 2.8
Key: IGNITE-12626
URL: https://issues.apache.org/jira/browse/IGNITE-12626
Project: Ignite
Issue Type: Task
Folks,
I think it's a common problem for such system properties (which may be
different on different nodes and which may lead to unpredictable
cluster behaviour). The same mentioned by Ivan here [1].
Is it better to validate (somehow) all system properties, for
instance, started with IGNITE_ pre
Hi, Andrey.
The approach of setting plugins via IgniteConfiguration provides an
additional feature to control the order in which plugins will be loaded.
It's important in the case when several plugins provide different
implementations of the same GridComponent while providing some other
unique
Hi Vladimir,
Yes, I'm suggesting us to enable this flag by
org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
default instead of introducing --force flag and showing any warnings.
-
Denis
On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin wrote:
> Hello all.
>
> Denis, wh
Vladimir Malinovskiy created IGNITE-12627:
-
Summary: Control utility does not show corrupted indexes
Key: IGNITE-12627
URL: https://issues.apache.org/jira/browse/IGNITE-12627
Project: Ignite
Denis, but why reuse-data-on-deactivate was disabled by default? There
should be a reason for that. Any data consistency issues when node gets
activated anew? We may use both solutions because the flag can be switched
off again.
ср, 5 февр. 2020 г. в 20:47, Denis Magda :
> Hi Vladimir,
>
> Yes, I
I believe there might be a consistency-related reason why this flag was
disabled by default for caches that store data in Ignite native
persistence. I hope, Alex Goncharuk or Scherbakov can shed some light on
this.
As for the memory-only caches or caches backed up by a CacheStore such as
an RDBMS,
Igniters,
I've prepared RELEASE_NOTES pull-request [1] to the 2.8 release.
Currently, IEP-35 monitoring issues are not included in this PR. Will
do it soon.
Please, take a look.
[1] https://github.com/apache/ignite/pull/7367/files
On Mon, 3 Feb 2020 at 14:38, Maxim Muzafarov wrote:
>
> Ignit
Maxim,
A couple of questions:
1. We added an annotation to designate experimental API. Should not we
state in release notes what new experimental API was added? Perhaps in
a separate block.
2. As Flink integration was moved to external repository how Ignite
2.8 users will be able to use that integ
Vladimir Malinovskiy created IGNITE-12628:
-
Summary: Add tests for jmx metrics return types
Key: IGNITE-12628
URL: https://issues.apache.org/jira/browse/IGNITE-12628
Project: Ignite
I
Ivan,
> Should not we state in release notes what new experimental API was added?
I think we should. Will do.
Just not to miss anything that we should mark with
@IgniteExperimental: Consistency Check [1], Monitoring [2] anything
else?
> As Flink integration was moved to external repository how I
Igniters,
We would like to add some formal requirements to the API deprecation
process. So far the API deprecation was more like intuitive-driven which
recently led to some disagreement and delaying the AI 2.8 release [1][2].
During the discussion [1] we agreed to add an
annotation @IgniteExperim
I have attempted to add this call to a RandomForestModel in order to obtain
accuracy:
*double accuracy = Evaluator.evaluate(
dataCache,
randomForestMdl,
vectorizer,
new Accuracy<>()
);
The justification and choices look crystal clear to me.
-
Denis
On Wed, Feb 5, 2020 at 1:36 PM Alexey Goncharuk
wrote:
> Igniters,
>
> We would like to add some formal requirements to the API deprecation
> process. So far the API deprecation was more like intuitive-driven which
> recently led
Vladimir Malinovskiy created IGNITE-12629:
-
Summary: Fit all metrics into single standard
Key: IGNITE-12629
URL: https://issues.apache.org/jira/browse/IGNITE-12629
Project: Ignite
Iss
Yes, the known issue in the Random Forest, it throws the strange math
exception in the case, when the preprocessed vector has the
different length with the vector which could be handled by the model.
I didn't see your another code, but I could suppose, that you have another
preprocessing stages lik
38 matches
Mail list logo