Hi Nikolay,
Thank you for your email. As part of Ignite Extensions migration we are
migrating Ignite Extensions to following repo.
https://github.com/apache/ignite-extensions
We have added flink and pub-sub modules and few additional modules are open
in PR.
You can refer to this PR to see how w
Hello Alexey,
Thank you for your email.
1. Yes, we discussed in dev list and agreed on creating a new repository
for hosting our Ignite integrations. Please find the discussion thread
below. I will update the wiki page as well and share updates.
http://apache-ignite-developers.2346864.n4.nabble.
Yes sure, thank you Denis
Regards,
Saikat
On Thu, Jan 16, 2020 at 3:53 PM Denis Magda wrote:
> Hi Saikat,
>
> Let's wait while Alex Goncharuk checks a similar PR here:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
>
Have any of you performed an H20 integration with Ignite to import an
extracted feature data set directly as input into Ignite training engine?
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Hello all Apache Ignite ML developers:
I understand currently Ignite can't save a model after training, in such a
way that the model can be re-imported by another Ignite cluster. Correct me
if you can save and reload a model but I don't think you can.
Anyway, I'd like to know if you have recomme
+1 to mark feature or whole release as EA.
пт, 17 янв. 2020 г., 23:00 Denis Magda :
> Folks, if you don't mind I'll share some thoughts/suggestions as an
> observer who was not involved in the feature development.
>
> It's absolutely 'ok' to deprecate an API that is replaced with a much
> better
Folks, if you don't mind I'll share some thoughts/suggestions as an
observer who was not involved in the feature development.
It's absolutely 'ok' to deprecate an API that is replaced with a much
better version. However, we should do this only when the new APIs are
production-ready. If there are s
Hello, Andrey.
Thanks for positive feedback.
Appreciate it.
> we can't cancel service or service's method
I understand it.
Seems, we have several obvious options here:
* Try to do it and if fail answer to the user: «I’ve tried and fail. Sorry»
* Kill hanging thread.
> This invocations not reg
> Also I agree with Alexey about introducing public IgniteMonitoring facade
This is not an issue with the API.
Just the new feature that doesn’t affects API.
Moreover, I create a ticket to fix it, already.
> It's right. But if you add checking of statisticsEnabling property then test
> will fail
It would be grate.
Only one comment: we can't cancel service or service's method
execution because service grid API doesn't imply any requirement to
service implementation. So if user do something like infinite cycle or
blocking but non-interruptible operation it's impossible to interrupt
it. Also
>> All issues Alexey mentioned in starting letter are fixed with my PR [1].
>> I don’t think other issues you mentioned are blocker for the release.
As I mentioned already IGNITE-11927 is part of IEP-35 and
implementation seriously affects API's. Also I agree with Alexey about
introducing public I
Andrey.
All issues Alexey mentioned in starting letter are fixed with my PR [1].
I don’t think other issues you mentioned are blocker for the release.
> I talk about ignored existing functionality.
There is no existing tests that was broken by this contribution.
If you know the issues with it, f
The discussion is hot and can be endless. So in separate post I want
propose my solution.
1. Moving IEP-35 API's to the internal package.
2. Create special feature branch B.
3. In branch B will be merged IGNITE-11927
4. Because IGNITE-11927 doesn't solve all problems we should propose
solution and
>> Because it is brand new API and it requires rewrite client code.
> We doesn’t break backward compatibility.
> The message is - this interface would be remove in the next major release.
We don't know anything about development processes our users. I can
admit that process could require that depr
Andrey.
> Because it is brand new API and it requires rewrite client code.
We doesn’t break backward compatibility.
The message is - this interface would be remove in the next major release.
> ReadOnlyMetricRegistry
> Form user stand point it is very strange interface which don't give me any
>
> If I’m not missing something, you were one of the active reviewers of the
> Metric API.
Yes. But if I'm not missing some thing you were major developer of
Metric API :) Shit happens. And it happened.
>> The first, I agree with Alexey about deprecation of APIs that are still
>> supported and d
Maxim,
I will do that on monday (20/01).
пт, 17 янв. 2020 г. в 13:08, Maxim Muzafarov :
> Sergey,
>
>
> Can you, please, resolve the PR conflicts [1] [2]?
>
> [1] https://github.com/apache/ignite/pull/7238
> [2] https://issues.apache.org/jira/browse/IGNITE-11256
>
> On Thu, 16 Jan 2020 at 16:59,
Andrey, thanks for your opinion and your ownest critisism.
I can’t wait for your contribution.
If I’m not missing something, you were one of the active reviewers of the
Metric API.
> The first, I agree with Alexey about deprecation of APIs that are still
> supported and don't offer reasonable s
Saikat,
Code-wise the PR looks ok because it basically moves the module to another
repo. I have some infrastructure/process questions though before we merge
the PRs
* I see that there are some objections from Alexey Zinoviev [1] on whether
the streaming modules should be placed in extensions or i
Hi,
The first, I agree with Alexey about deprecation of APIs that are
still supported and don't offer reasonable substitution.
The second, from my point of view, we can't recommend
MetricExporterSpi's because it are still not-production ready. There
are some issues with it and usage of ReadOnlyMe
Hi Alexei,
> Not sure I've understand a question. JMX supports security via password
protection and secure channel.
That is the obvious thing I missed! :) Thank you!
Thanks,
S.
пт, 17 янв. 2020 г. в 14:45, Alexei Scherbakov :
> Slava,
>
> Not sure I've understand a question. JMX supports securi
Slava,
Not sure I've understand a question. JMX supports security via password
protection and secure channel.
пт, 17 янв. 2020 г. в 14:30, Вячеслав Коптилин :
> Hello Nikolay,
>
> I'm not sure we need JMX API for this case. If I’m not mistaken, it’s about
> the administrator’s ability to cancel
Nikolay, thanks! I am not insisting we must implement IGNITE-12553 right
away nor am I saying it's mandatory. I just want to make sure we do not
deprecate existing APIs unless we as a community are certain that they will
be dropped and there is no need for the replacement.
Will take a look at the
Hello Nikolay,
I'm not sure we need JMX API for this case. If I’m not mistaken, it’s about
the administrator’s ability to cancel any task/query in the cluster, and in
my opinion, such action must require administrator permission.
Could you please clarify how it can be done via JMX? I mean permissi
Sergey,
Can you, please, resolve the PR conflicts [1] [2]?
[1] https://github.com/apache/ignite/pull/7238
[2] https://issues.apache.org/jira/browse/IGNITE-11256
On Thu, 16 Jan 2020 at 16:59, Ilya Kasnacheev wrote:
>
> Hello!
>
> I have bumped beanutils and re-ran Cassandra Store tests. Can you
Alex.
OK, I may leverage your experience and create pure Java API.
Ticket [1] created.
But, personally, I don’t agree with you.
Ignite has dozens of the API that theoretically have a usage scenario, but in
real-world have 0 custom implementation and usages.
Moreover, many APIs that were created
Nikolay Izhikov created IGNITE-12553:
Summary: [IEP-35] public Java metric API
Key: IGNITE-12553
URL: https://issues.apache.org/jira/browse/IGNITE-12553
Project: Ignite
Issue Type: Improv
Tests added.
Please, review.
Saikat, can you help with this PR [1]?
I think it should be added as a separate module as we do with the flink
integration.
Can you help me with it?
Do we have some how-to for it?
[1] https://github.com/apache/ignite/pull/7237
> 16 янв. 2020 г., в 16:51, Николай Иж
Nikolay,
Why do you think this is a wrong usage pattern? From the top of my head,
here is a few cases of direct metric API usage that I know are currently
being used in production:
* A custom task execution scheduling service with load balancing based on
utilization metrics readings from Java cod
29 matches
Mail list logo
