To me it doesn't really matter if it will be 'slim' or 'lite' :) I would
not name it 'core' because indeed it would be confusing with the core
module name.
Agree that platforms support is useful, so I would keep them as Ilya
suggested. As for the C++ packages pre-build - let's hear out Igor's
opin
Sergey Kosarev created IGNITE-12549:
---
Summary: Scan query/iterator on a replicated cache may get wrong
results
Key: IGNITE-12549
URL: https://issues.apache.org/jira/browse/IGNITE-12549
Project: Igni
Alexey, if I understand correctly, Ilya does not suggest to pre-built
binaries, just to ship it with configure script pre-generated, which
is a common practice for autotools packages. Building will be still
required for the user, but there will be less requirements and
possible errors during build.
Nikolaj,
We already have cancellation possibilities for almost every user
computation.
Transactions are cancelled using tx.rollback()
Queries are cancelled using query.close()
Task is cancellable through ComputeTaskSession
What is uniform cancel API ? Why do we need it ?
ср, 15 янв. 2020 г. в
Transactions can be also rolled back using tx.close where close is
java.lang.AutoCloseable#close
It looks for me to the definition of uniform cancel API.
чт, 16 янв. 2020 г. в 13:37, Alexei Scherbakov :
> Nikolaj,
>
> We already have cancellation possibilities for almost every user
> computatio
Classification: Public
Hello, Igniters,
Recently I've came across a problem with REPLICATED caches, so I've created an
issue:
https://issues.apache.org/jira/browse/IGNITE-12549
Please look at this. I believe, it's a bug.
Not sure I could fix it quickly, feel free to take it if you like.
And as
Hello, Alexey.
I’m talking about *administrator* API.
For example, the User has a cluster that is used by several applications.
Some application starts buggy compute tasks that consume all CPU resources.
Right now, administrator doesn’t have the ability to kill this task.
This can lead to instab
Nikolaj,
Can we use system views instead of implementing something new ?
Each user operation has an unique ID.
It's possible to introduce universal SQL kill something like:
kill transaction ID
where id is taken from system view.
чт, 16 янв. 2020 г. в 14:19, Николай Ижиков :
> Hello, Alexey.
Alexey Goncharuk created IGNITE-12550:
-
Summary: Add page read latency histogram per data region
Key: IGNITE-12550
URL: https://issues.apache.org/jira/browse/IGNITE-12550
Project: Ignite
Alexey.
I think, yes.
We certainly should be able to use system view data for the new KILL API.
I think we should support both SQL and Java(JMX) API for this KILL command.
> 16 янв. 2020 г., в 15:28, Alexei Scherbakov
> написал(а):
>
> Nikolaj,
>
> Can we use system views instead of impleme
Sergey Kosarev,
Check my comment below the JIRA issue for better WA.
чт, 16 янв. 2020 г. в 13:51, Sergey-A Kosarev :
> Classification: Public
> Hello, Igniters,
>
> Recently I've came across a problem with REPLICATED caches, so I've
> created an issue:
> https://issues.apache.org/jira/browse/IGN
Sounds good.
JMX API should be very similar: accept operation type and ID.
чт, 16 янв. 2020 г. в 15:46, Николай Ижиков :
> Alexey.
>
> I think, yes.
> We certainly should be able to use system view data for the new KILL API.
>
> I think we should support both SQL and Java(JMX) API for this KILL
Hi Sergey,
Just FYI: a similar problem with replicated caches has been fixed in SQL
[1].
If you have a reproducer, you may check whether your issue is still actual.
[1]: https://issues.apache.org/jira/browse/IGNITE-12482
On Thu, Jan 16, 2020 at 1:51 PM Sergey-A Kosarev
wrote:
> Classification:
Hi, Igniters.
I have created the issue [1] and prepared PR [2] to remove the
stopProcess method from interfaces.
I have removed the method from the internal interface
(DiscoveryCustomMessage) and marked deprecated in the public interface
(DiscoverySpiCustomMessage).
Could anyone review my change
The ticket [1] was https://issues.apache.org/jira/browse/IGNITE-12550
чт, 16 янв. 2020 г. в 16:39, Alexey Goncharuk :
> Igniters, Nikolay,
>
> I was adding a new metric in the scope of the ticket [1] and was surprised
> by a few things:
> * DataRegionMetric public interface is deprecated, howeve
Folks,
There might be an API-related blocker for 2.8, please join the 'Internal
classes are exposed in public API' dev-list discussion.
Hello, Alexey.
> * DataRegionMetric public interface is deprecated, however, the suggested
> replacement class GridMetricsManager is internal and cannot be acquired by a
> user. This makes impossible for the user to fix their code to not use
> deprecated API
May be it’s not clear text here.
M
Igniters, Nikolay,
I was adding a new metric in the scope of the ticket [1] and was surprised
by a few things:
* DataRegionMetric public interface is deprecated, however, the suggested
replacement class GridMetricsManager is internal and cannot be acquired by
a user. This makes impossible for the
Hello, Denis.
Thanks, for the feedback.
Alexey, it seems, PR is ready to be reviewed, but I need some time(a day or
two) to write tests.
You can start with the core code review if you wish.
Here are autoconfigurer requirements:
1. Start usage of Ignite with minimal(or zero) configuration.
2. C
Let's say I am upgrading from 2.7 to 2.8. Given that I figured out to
obtain an instance of the JMX exporter SPI, how should I map the old
'interface + method name' to the new metric name? I think deprecation of
the public API may be a bit harsh in this case.
чт, 16 янв. 2020 г. в 16:44, Николай И
Alexey Scherbakov created IGNITE-12551:
--
Summary: Partition desync if partition is evicted when owned again
and historically rebalanced
Key: IGNITE-12551
URL: https://issues.apache.org/jira/browse/IGNITE-1255
Do you propose to keep these interfaces forever?
> 16 янв. 2020 г., в 16:52, Alexey Goncharuk
> написал(а):
>
> Let's say I am upgrading from 2.7 to 2.8. Given that I figured out to
> obtain an instance of the JMX exporter SPI, how should I map the old
> 'interface + method name' to the new met
Hello!
I have bumped beanutils and re-ran Cassandra Store tests. Can you please
comment on the ticket?
I think that fixing ZooKeeper is too much effort (there's chaos with
jackson vs. jackson-asl), maybe it should be split up as a separate ticket
to be done later.
Regards,
--
Ilya Kasnacheev
Nikolay Izhikov created IGNITE-12552:
Summary: [IEP-35] Expose MetricRegistry to the public API
Key: IGNITE-12552
URL: https://issues.apache.org/jira/browse/IGNITE-12552
Project: Ignite
I
Ticket to export MetricRegistry to the public API created -
https://issues.apache.org/jira/browse/IGNITE-12552
> 16 янв. 2020 г., в 16:58, Николай Ижиков написал(а):
>
> Do you propose to keep these interfaces forever?
>
>> 16 янв. 2020 г., в 16:52, Alexey Goncharuk
>> написал(а):
>>
>> Let
Classification: Public
Hi Ivan,
Yes, I have simple reproducer and I've checked on master, unfortunately issue
is still actual.
-Original Message-
From: Ivan Rakov [mailto:ira...@gridgain.com]
Sent: 16 January 2020 14:33
To: dev@ignite.apache.org
Subject: Re: Wrong results on Scan queries
I closed the ticket ignite-8115 because it's duplicating ignite-8190. In
the ticket ignite-8190 requested functionality is already done.
Thanks!
On Wed, Jan 15, 2020 at 1:26 PM fi1ipx wrote:
> Hello folks!
>
> I'm a new community member and tried to solve the issue as a first
> introduction tas
I think it would make sense to make something like a new IgniteMonitoring
facade on Ignite interface and add an ability to obtain a metric value
through this facade, not through an exporter. This would be a
straightforward replacement for all old metrics interfaces.
чт, 16 янв. 2020 г. в 17:13, Ни
May be we should enable JMX exporter, by default?
This would provide the same value for the user as `IgniteMonitoring` you
propose.
> 16 янв. 2020 г., в 20:06, Alexey Goncharuk
> написал(а):
>
> I think it would make sense to make something like a new IgniteMonitoring
> facade on Ignite interf
That's an option, I agree. Yet for me, from the usability point of view, it
would be quite strange - to get an instance of the monitoring interface, I
would need to do
JmxMetricExporterSpi metrics =
(JmxMetricExporterSpi)ignite.configuration().getMetricExporterSpi()[0];
which is too verbose and fra
Agree with Alexey, there should be an obvious public API to retrieve metrics
On Thu, Jan 16, 2020 at 8:23 PM Alexey Goncharuk
wrote:
> That's an option, I agree. Yet for me, from the usability point of view, it
> would be quite strange - to get an instance of the monitoring interface, I
> would
Hello, Pavel.
> there should be an obvious public API to retrieve metrics
What do you mean by «retrieve»?
I don’t create pure Java API for metric intentionally.
We have MetricExporterSPI for this purpose.
It very simple from my point of view.
What use cases for `Ignite.monitoring()` API exists?
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
After that, we can return to this pending pull request.
-
Denis
On Sun, Jan 12, 2020 at 12:59 PM Saikat
Looks like we didn't rich consensus here.
Igor, as thin client maintainer, can you please share your opinion?
Everyone else also welcome, please share your thoughts about options to
implement operations for compute.
чт, 28 нояб. 2019 г. в 10:02, Alex Plehanov :
> > Since all thin client operat
Николай, can you provide a full example - how do I get a metric value in my
code as an Ignite user?
var ignite = Ignition.ignite();
var totalAllocatedPages = ???;
On Fri, Jan 17, 2020 at 12:47 AM Николай Ижиков wrote:
> Hello, Pavel.
>
> > there should be an obvious public API to retrieve metri
Pavel,
As I said before - I don’t see any real use-cases for your example.
That’s why
> I don’t create pure Java API for metric intentionally.
What real-world use-case you are keeping in mind?
Why do you want to do it in that way?
The API you’re talking about is very simple and straightforwar
36 matches
Mail list logo
