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
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
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
I have attempted to add this call to a RandomForestModel in order to obtain
accuracy:
*double accuracy = Evaluator.evaluate(
dataCache,
randomForestMdl,
vectorizer,
new Accuracy<>()
);
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
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
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
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
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:
>
>
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
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,
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
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,
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
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_
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
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
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?
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
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
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
>
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
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.
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
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
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
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:
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
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.
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
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
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
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
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
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
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]
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
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
38 matches
Mail list logo
