Re: Internal classes are exposed in public API
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 straightforward.
It’s an easy thing to create, but this will open to the user's wrong usage
pattern.
From my point of view, to get metrics values one should use MetricExporterSPI.
> 17 янв. 2020 г., в 09:40, Pavel Tupitsyn написал(а):
>
> Николай, 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 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?
>>
>> ```
>> public interface MetricExporterSpi extends IgniteSpi {
>>public void setMetricRegistry(ReadOnlyMetricRegistry registry);
>>public void setExportFilter(Predicate filter);
>> }
>> ```
>>
>> ```
>> public interface ReadOnlyMetricRegistry extends Iterable {
>>public void addMetricRegistryCreationListener(Consumer
>> lsnr);
>>public void addMetricRegistryRemoveListener(Consumer
>> lsnr);
>> }
>> ```
>>
>> ```
>> public class MetricRegistry implements Iterable {
>>public String name();
>>@Nullable public M findMetric(String name);
>> }
>> ```
>>
>>> 16 янв. 2020 г., в 20:32, Pavel Tupitsyn
>> написал(а):
>>>
>>> Agree with Alexey, there should be an obvious public API to retrieve
>> metrics
>>>
>>> On Thu, Jan 16, 2020 at 8:23 PM Alexey Goncharuk <
>> alexey.goncha...@gmail.com>
>>> 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 need to do
JmxMetricExporterSpi metrics =
(JmxMetricExporterSpi)ignite.configuration().getMetricExporterSpi()[0];
which is too verbose and fragile if someone changes configuration (say,
inserts another SPI to the first position).
чт, 16 янв. 2020 г. в 20:14, Николай Ижиков :
> 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 <
>> alexey.goncha...@gmail.com
>
> написал(а):
>>
>> 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, Николай Ижиков :
>>
>>> 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 <
> alexey.goncha...@gmail.com>
>>> написал(а):
>
> 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, Николай Ижиков :
>
>> 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.
>> My point here, that user should obtain metrics values via
configured
>> metric exporters and don’t use *Metric interfaces.
>>
>>> * In ReadOnlyMetricsRegistry there is a Consumer,
> but
>> MetricRegistry is again an internal class.
>>
>> This is a real issue.
>> We should expose MetricRegistry interface to the public API and
keep
>> internal implementation.
>>
>> I will create ticket and fix it, shortly.
>>
>>
>>> 16 янв. 2020 г., в 16:39, Alexey Goncharuk <
>>> alexey.goncha...@gmail.com>
>> написал(а):
>>>
>>> Igniters, Nikolay,
>>>
>>> I
Re: Thin client: compute support
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 operations are inherently async, we should be able
> to cancel any of them
> It's illogical to have such ability. What should do cancel operation of
> cancel operation? Moreover, sometimes it's dangerous, for example, create
> cache operation should never be canceled. There should be an explicit set
> of processes that we can cancel: queries, transactions, tasks, services.
> The lifecycle of services is more complex than the lifecycle of tasks. With
> services, I suppose, we can't use request cancelation, so tasks will be the
> only process with an exceptional pattern.
>
> > The request would be "execute task with specified node filter" - simple
> and efficient.
> It's not simple: every compute or service request should contain complex
> node filtering logic, which duplicates the same logic for cluster API.
> It's not efficient: for example, we can't implement forPredicate()
> filtering in this case.
>
>
> ср, 27 нояб. 2019 г. в 19:25, Pavel Tupitsyn :
>
>> > The request is already processed (task is started), we can't cancel the
>> request
>> The request is not "start a task". It is "execute task" (and get result).
>> Same as "cache get" - you get a result in the end, we don't "start cache
>> get" then "end cache get".
>>
>> Since all thin client operations are inherently async, we should be able
>> to
>> cancel any of them
>> by sending another request with an id of prior request to be cancelled.
>> That's why I'm advocating for this approach - it will work for anything,
>> no
>> special cases.
>> And it keeps "happy path" as simple as it is right now.
>>
>> Queries are different because we retrieve results in pages, we can't do
>> them as one request.
>> Transactions are also different because client controls when they should
>> end.
>> There is no reason for task execution to be a special case like queries or
>> transactions.
>>
>> > we always need to send 2 requests to server to execute the task
>> Nope. We don't need to get nodes on client at all.
>> The request would be "execute task with specified node filter" - simple
>> and
>> efficient.
>>
>>
>> On Wed, Nov 27, 2019 at 4:31 PM Alex Plehanov
>> wrote:
>>
>> > > We do cancel a request to perform a task. We may and should use this
>> to
>> > cancel any other request in future.
>> > The request is already processed (task is started), we can't cancel the
>> > request. As you mentioned before, we already do almost the same for
>> queries
>> > (close the cursor, but not cancel the request to run a query), it's
>> better
>> > to do such things in a common way. We have a pattern: start some process
>> > (query, transaction), get id of this process, end process by this id.
>> The
>> > "Execute task" process should match the same pattern. In my opinion,
>> > implementation with two-way requests is the best option to match this
>> > pattern (we can even reuse OP_RESOURCE_CLOSE operation type in this
>> case).
>> > Sometime in the future, we will need two-way requests for some other
>> > functionality (continuous queries, event listening, etc). But even
>> without
>> > two-way requests introducing some process id (task id in our case) will
>> be
>> > closer to existing pattern than canceling tasks by request id.
>> >
>> > > So every new request will apply those filters on server side, using
>> the
>> > most recent set of nodes.
>> > In this case, we always need to send 2 requests to server to execute the
>> > task. First - to get nodes by the filter, second - to actually execute
>> the
>> > task. It seems like overhead. The same will be for services. Cluster
>> group
>> > remains the same if the topology hasn't changed. We can use this fact
>> and
>> > bind "execute task" request to topology. If topology has changed - get
>> > nodes for new topology and retry request.
>> >
>> > вт, 26 нояб. 2019 г. в 17:44, Pavel Tupitsyn :
>> >
>> > > > After all, we don't cancel request
>> > > We do cancel a request to perform a task. We may and should use this
>> to
>> > > cancel any other request in future.
>> > >
>> > > > Client uses some cluster group filtration (for example forServers()
>> > > cluster group)
>> > > Please see above - Aleksandr Shapkin described how we store
>> > > filtered cluster groups on client.
>> > > We don't store node IDs, we store actual filters. So every new request
>> > will
>> > > apply those filters on server side,
>> > > using the most recent set of nodes.
>> > >
>> > > var myGrp = cluster.forServers().forAttribute("foo"); // This does not
>> > > issue any server requests, just builds an object with filters on
>> client
>> > > while (true) myGrp.compute().executeTask("bar"); // Every request
>> > includes
>> > > filters, and filters are applied
Re: IGNITE-12358 Migrate ZeroMQ module to ignite-extensions
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 Maitra wrote: > Hi, > > I have raised PR for Ignite zeromq migration to Ignite Extensions repo. > > Jira https://issues.apache.org/jira/browse/IGNITE-12358 > > PR https://github.com/apache/ignite-extensions/pull/5 > https://github.com/apache/ignite/pull/7240 > > Please review and share feedback. > > This is part of our Modularization effort for Streamer modules > > https://issues.apache.org/jira/browse/IGNITE-12355 > > Regards, > Saikat >
Re: Internal classes are exposed in public API
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?
```
public interface MetricExporterSpi extends IgniteSpi {
public void setMetricRegistry(ReadOnlyMetricRegistry registry);
public void setExportFilter(Predicate filter);
}
```
```
public interface ReadOnlyMetricRegistry extends Iterable {
public void addMetricRegistryCreationListener(Consumer
lsnr);
public void addMetricRegistryRemoveListener(Consumer lsnr);
}
```
```
public class MetricRegistry implements Iterable {
public String name();
@Nullable public M findMetric(String name);
}
```
> 16 янв. 2020 г., в 20:32, Pavel Tupitsyn написал(а):
>
> 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 need to do
>> JmxMetricExporterSpi metrics =
>> (JmxMetricExporterSpi)ignite.configuration().getMetricExporterSpi()[0];
>> which is too verbose and fragile if someone changes configuration (say,
>> inserts another SPI to the first position).
>>
>> чт, 16 янв. 2020 г. в 20:14, Николай Ижиков :
>>
>>> 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 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, Николай Ижиков :
> 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 <
>>> alexey.goncha...@gmail.com>
> написал(а):
>>>
>>> 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, Николай Ижиков :
>>>
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.
My point here, that user should obtain metrics values via
>> configured
metric exporters and don’t use *Metric interfaces.
> * In ReadOnlyMetricsRegistry there is a Consumer,
>>> but
MetricRegistry is again an internal class.
This is a real issue.
We should expose MetricRegistry interface to the public API and
>> keep
internal implementation.
I will create ticket and fix it, shortly.
> 16 янв. 2020 г., в 16:39, Alexey Goncharuk <
> alexey.goncha...@gmail.com>
написал(а):
>
> 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 user to fix their
> code to
not use deprecated API
> * In ReadOnlyMetricsRegistry there is a Consumer,
>>> but
MetricRegistry is again an internal class. This will cause the user
> code
compilation to break when MetricRegistry is changed
>
> These things violate the public-private API separation and need to
>>> be
fixed prior 2.8 is released. Let's discuss what changes need to be
> made to
the API or perhaps move incomplete IEP-35 interfaces to the private
> package
and remove deprecations until the API is ready.
>
> --AG
>>
>
>
>>>
>>>
>>
Re: Internal classes are exposed in public API
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 need to do > JmxMetricExporterSpi metrics = > (JmxMetricExporterSpi)ignite.configuration().getMetricExporterSpi()[0]; > which is too verbose and fragile if someone changes configuration (say, > inserts another SPI to the first position). > > чт, 16 янв. 2020 г. в 20:14, Николай Ижиков : > > > 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 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, Николай Ижиков : > > > > > >> 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 < > > alexey.goncha...@gmail.com> > > >> написал(а): > > > > 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, Николай Ижиков : > > > > > 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. > > > My point here, that user should obtain metrics values via > configured > > > metric exporters and don’t use *Metric interfaces. > > > > > >> * In ReadOnlyMetricsRegistry there is a Consumer, > > but > > > MetricRegistry is again an internal class. > > > > > > This is a real issue. > > > We should expose MetricRegistry interface to the public API and > keep > > > internal implementation. > > > > > > I will create ticket and fix it, shortly. > > > > > > > > >> 16 янв. 2020 г., в 16:39, Alexey Goncharuk < > > >> alexey.goncha...@gmail.com> > > > написал(а): > > >> > > >> 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 user to fix their > > >> code to > > > not use deprecated API > > >> * In ReadOnlyMetricsRegistry there is a Consumer, > > but > > > MetricRegistry is again an internal class. This will cause the user > > >> code > > > compilation to break when MetricRegistry is changed > > >> > > >> These things violate the public-private API separation and need to > > be > > > fixed prior 2.8 is released. Let's discuss what changes need to be > > >> made to > > > the API or perhaps move incomplete IEP-35 interfaces to the private > > >> package > > > and remove deprecations until the API is ready. > > >> > > >> --AG > > > > > > > > >>> > > >> > > >> > > > > >
Re: Internal classes are exposed in public API
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 fragile if someone changes configuration (say, inserts another SPI to the first position). чт, 16 янв. 2020 г. в 20:14, Николай Ижиков : > 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 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, Николай Ижиков : > > > >> 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 < > alexey.goncha...@gmail.com> > >> написал(а): > > 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, Николай Ижиков : > > > 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. > > My point here, that user should obtain metrics values via configured > > metric exporters and don’t use *Metric interfaces. > > > >> * In ReadOnlyMetricsRegistry there is a Consumer, > but > > MetricRegistry is again an internal class. > > > > This is a real issue. > > We should expose MetricRegistry interface to the public API and keep > > internal implementation. > > > > I will create ticket and fix it, shortly. > > > > > >> 16 янв. 2020 г., в 16:39, Alexey Goncharuk < > >> alexey.goncha...@gmail.com> > > написал(а): > >> > >> 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 user to fix their > >> code to > > not use deprecated API > >> * In ReadOnlyMetricsRegistry there is a Consumer, > but > > MetricRegistry is again an internal class. This will cause the user > >> code > > compilation to break when MetricRegistry is changed > >> > >> These things violate the public-private API separation and need to > be > > fixed prior 2.8 is released. Let's discuss what changes need to be > >> made to > > the API or perhaps move incomplete IEP-35 interfaces to the private > >> package > > and remove deprecations until the API is ready. > >> > >> --AG > > > > > >>> > >> > >> > >
Re: Internal classes are exposed in public API
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 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, Николай Ижиков : > >> 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'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, Николай Ижиков : > 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. > My point here, that user should obtain metrics values via configured > metric exporters and don’t use *Metric interfaces. > >> * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. > > This is a real issue. > We should expose MetricRegistry interface to the public API and keep > internal implementation. > > I will create ticket and fix it, shortly. > > >> 16 янв. 2020 г., в 16:39, Alexey Goncharuk < >> alexey.goncha...@gmail.com> > написал(а): >> >> 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 user to fix their >> code to > not use deprecated API >> * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. This will cause the user >> code > compilation to break when MetricRegistry is changed >> >> These things violate the public-private API separation and need to be > fixed prior 2.8 is released. Let's discuss what changes need to be >> made to > the API or perhaps move incomplete IEP-35 interfaces to the private >> package > and remove deprecations until the API is ready. >> >> --AG > > >>> >> >>
Re: Internal classes are exposed in public API
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, Николай Ижиков : > 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'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, Николай Ижиков : > >> > >>> 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. > >>> My point here, that user should obtain metrics values via configured > >>> metric exporters and don’t use *Metric interfaces. > >>> > * In ReadOnlyMetricsRegistry there is a Consumer, but > >>> MetricRegistry is again an internal class. > >>> > >>> This is a real issue. > >>> We should expose MetricRegistry interface to the public API and keep > >>> internal implementation. > >>> > >>> I will create ticket and fix it, shortly. > >>> > >>> > 16 янв. 2020 г., в 16:39, Alexey Goncharuk < > alexey.goncha...@gmail.com> > >>> написал(а): > > 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 user to fix their > code to > >>> not use deprecated API > * In ReadOnlyMetricsRegistry there is a Consumer, but > >>> MetricRegistry is again an internal class. This will cause the user > code > >>> compilation to break when MetricRegistry is changed > > These things violate the public-private API separation and need to be > >>> fixed prior 2.8 is released. Let's discuss what changes need to be > made to > >>> the API or perhaps move incomplete IEP-35 interfaces to the private > package > >>> and remove deprecations until the API is ready. > > --AG > >>> > >>> > > > >
Re: Hint for user that baseline topology should be changed in order to trigger rebalance
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 task. > > I've got this log message: > "Local node is not included in Baseline Topology and will not be used for > data storage. Use control.(sh|bat) script or IgniteCluster interface to > include the node to Baseline Topology." when started an additional node > after a cluster was activated. > > I suppose the message explains the situation quite well. > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
RE: Wrong results on Scan queries on REPLICATED caches during rebalance
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 on REPLICATED caches during rebalance 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: 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 workaround I think PARTITIONED caches with Integer.MAX_VALUE > backups can be used instead of REPLICATED caches. > > Will be glad for any feedback. > > Kind regards, > Sergey Kosarev > > > > > --- > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. > Any unauthorized copying, disclosure or distribution of the material > in this e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information > about privacy. > -- Best Regards, Ivan Rakov --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
Re: Internal classes are exposed in public API
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'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, Николай Ижиков : >> >>> 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. >>> My point here, that user should obtain metrics values via configured >>> metric exporters and don’t use *Metric interfaces. >>> * In ReadOnlyMetricsRegistry there is a Consumer, but >>> MetricRegistry is again an internal class. >>> >>> This is a real issue. >>> We should expose MetricRegistry interface to the public API and keep >>> internal implementation. >>> >>> I will create ticket and fix it, shortly. >>> >>> 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, 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 * In ReadOnlyMetricsRegistry there is a Consumer, but >>> MetricRegistry is again an internal class. This will cause the user code >>> compilation to break when MetricRegistry is changed These things violate the public-private API separation and need to be >>> fixed prior 2.8 is released. Let's discuss what changes need to be made to >>> the API or perhaps move incomplete IEP-35 interfaces to the private package >>> and remove deprecations until the API is ready. --AG >>> >>> >
[jira] [Created] (IGNITE-12552) [IEP-35] Expose MetricRegistry to the public API
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 Issue Type: Improvement Affects Versions: 2.8 Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov Fix For: 2.8 MetricRegistry is not a part of public API, but used in MetricExporter which is the part of public API. We should export MetricRegistry to the public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Internal classes are exposed in public API
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 metric name? I think deprecation of > the public API may be a bit harsh in this case. > > чт, 16 янв. 2020 г. в 16:44, Николай Ижиков : > >> 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. >> My point here, that user should obtain metrics values via configured >> metric exporters and don’t use *Metric interfaces. >> >>> * In ReadOnlyMetricsRegistry there is a Consumer, but >> MetricRegistry is again an internal class. >> >> This is a real issue. >> We should expose MetricRegistry interface to the public API and keep >> internal implementation. >> >> I will create ticket and fix it, shortly. >> >> >>> 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, 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 >>> * In ReadOnlyMetricsRegistry there is a Consumer, but >> MetricRegistry is again an internal class. This will cause the user code >> compilation to break when MetricRegistry is changed >>> >>> These things violate the public-private API separation and need to be >> fixed prior 2.8 is released. Let's discuss what changes need to be made to >> the API or perhaps move incomplete IEP-35 interfaces to the private package >> and remove deprecations until the API is ready. >>> >>> --AG >> >>
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
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 ср, 15 янв. 2020 г. в 18:31, Vladimir Pligin : > Thanks, Ilya. It would be really great to have your patch included into 2.8 > scope. > I'd like to give my two cent as well. For example we have vulnerable > dependencies here: > modules/cassandra/store/pom.xml - commons-beanutils > modules/zookeeper/pom.xml - transitive Jackson from Curator > > I'd suggest to uprgrade commons-beanutils:commons-beanutils to 1.9.4 and > override com.fasterxml.jackson.core:jackson-databind to our common jackson > version from other modules. > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
[jira] [Created] (IGNITE-12551) Partition desync if partition is evicted when owned again and historically rebalanced
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-12551 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.7.6 Reporter: Alexey Scherbakov Assignee: Alexey Scherbakov Fix For: 2.9 Where is a possibility of partition desync in the following scenario: 1. Some partition is evicted with non zero counters. 2. It is owned again and are going to be rebalanced. 3. Some node in grid has history for the partition defined by it's (initial, current) counters pair. In this scenario partition will be historically rebalanced having only partial data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Internal classes are exposed in public API
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, Николай Ижиков : > 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. > My point here, that user should obtain metrics values via configured > metric exporters and don’t use *Metric interfaces. > > > * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. > > This is a real issue. > We should expose MetricRegistry interface to the public API and keep > internal implementation. > > I will create ticket and fix it, shortly. > > > > 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, 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 > > * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. This will cause the user code > compilation to break when MetricRegistry is changed > > > > These things violate the public-private API separation and need to be > fixed prior 2.8 is released. Let's discuss what changes need to be made to > the API or perhaps move incomplete IEP-35 interfaces to the private package > and remove deprecations until the API is ready. > > > > --AG > >
Re: Ignite-spring-boot-autoconfigurer
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. Configure Ignite configuration properties with the standard spring boot
application properties.
3. Configure Ignite SPI implementation and so on that can’t be configured via
#2.
After some consultation with the Spring experts from the community(Maxim
Stepachev thanks for the idea)
I updated the PR with the logic described below:
1. To enable Ignite auto-configuration user should add
`org.apache.ignite:spring-boot-ignite-autoconfigure:2.9.0` to dependencies.
After it Ignite node will be started during spring-boot application startup.
2. IgniteConfiguration initialization logic:
2.1 If {@link IgniteConfiguration} bean exists in {@link BeanFactory} it will
be used for the node start.
2.2 If {@link IgniteConfiguration} bean doesn't exist following rules are
applied:
* Newly introducer IgniteConfigurer bean will be used to customize an empty
IgniteConfiguration instance.
If a user wants to set custom SPI instances or similar hardcoded values one
should do it IgniteConfigurer implementation.
* Application properties will override config values. Prefix for properties
names is "ignite».
PS. Similar logic applied for the second module -
`org.apache.ignite:spring-boot-ignite-client-autoconfigure:2.9.0`.
It provides the same features but for the autoconfiguration of the IgniteClient
> 15 янв. 2020 г., в 03:03, Denis Magda написал(а):
>
> Nikolay,
>
> Thanks for contributing in this direction! That's one of the gaps on our
> end and the user community will be certainly thankful once we fill it in.
>
> *Alexey Kuznetsov*, as one of the Spring Boot experts, could you spend some
> time reviewing the changes?
>
> As for the extensions/modularization activities, please join Saikat in the
> discussions ([1] and [2]). He is contributing the foundation and moving our
> existing integrations to that new repository. The Spring Boot improvements
> might be moved or, another option, we might add this class to the core?
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
> [2]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Proposal-for-Ignite-Extensions-as-a-separate-Bahir-module-or-Incubator-project-td44064.html
>
> -
> Denis
>
>
> On Sat, Jan 11, 2020 at 10:44 AM Николай Ижиков wrote:
>
>> Hello, Igniters.
>>
>> During Ignite meetup I took part in there was a request from the users.
>> They propose to create a custom spring boot autoconfigurer module for
>> Ignite.
>> This module should provide a smooth injection of Ignite to any spring-boot
>> application.
>>
>> I've implemented a tiny straightforward prototype of the module [1]
>> Examples of the usage of integration can be found in the example
>> application [2]
>>
>> For now, the module provides the following features:
>>
>> 1. Starts Ignite node and inject it in the spring ApplicationContext if
>> bean of the type IgniteConfiguration exists in the context.
>>This can be achieved in two ways:
>>* create `IgniteConfiguration` from java code [3]
>>* add `ignite.xml` file to the application context [4]
>>
>> 2. Starts IgniteClient instance and injects it int the spring Application
>> if:
>>* ClientConfiguration bean exists in the context [5]
>>* `spring.data.ignite.clientAddresses` exists in the application
>> properties. [6]
>>
>> I have a following questions regards new module:
>>
>>1. We have an extension initiative so where is the right place for the
>> new module?
>>2. Do we have spring experts in the community? What other features for
>> this autoconfigurer module required?
>>
>> [1] https://github.com/apache/ignite/pull/7237/files
>> [2] https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
>> [3]
>> https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/configfrombean
>> [4]
>> https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/configfromfile
>> [5]
>> https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/thinclientfrombean
>> [6]
>> https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example/tree/master/src/main/java/org/apache/ignite/spring/boot/thinclientfromconfig
>>
>>
Re: Apache Ignite 2.8 RELEASE [Time, Scope, Manager]
Folks, There might be an API-related blocker for 2.8, please join the 'Internal classes are exposed in public API' dev-list discussion.
Re: Internal classes are exposed in public API
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. My point here, that user should obtain metrics values via configured metric exporters and don’t use *Metric interfaces. > * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. This is a real issue. We should expose MetricRegistry interface to the public API and keep internal implementation. I will create ticket and fix it, shortly. > 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, 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 > * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. This will cause the user code > compilation to break when MetricRegistry is changed > > These things violate the public-private API separation and need to be fixed > prior 2.8 is released. Let's discuss what changes need to be made to the API > or perhaps move incomplete IEP-35 interfaces to the private package and > remove deprecations until the API is ready. > > --AG
Re: Unclear to use methods in the DiscoverySpiCustomMessage interface
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 changes, please? [1] https://issues.apache.org/jira/browse/IGNITE-12400 [2] https://github.com/apache/ignite/pull/7268/files пт, 25 окт. 2019 г. в 11:24, Nikolay Izhikov : > > Nikita, please, feel free: > > 1. To create a ticket to remove `stopProcess` method from the interface. > This improvement looks obvious to me. > Seems we can implement it easily. > > 2. To make all Discovery messages immutable. > This one more complex. > I think we should discuss every single mutable message separately. > Lets' do it in a separate discussion. > > WDYT? > > В Пт, 25/10/2019 в 11:10 +0300, Ivan Pavlukhin пишет: > > There are at least a couple more mutable messages: > > StartRoutineDiscoveryMessage and SchemaProposeDiscoveryMessage. > > > > I agree that here that making all messages immutable are highly > > desired (e.g. it will allow implementation of new discovery > > protocols). But so far I do not understand why marker interface is a > > better approach. Pavel, could you please elaborate? > > > > чт, 24 окт. 2019 г. в 17:55, Pavel Kovalenko : > > > > > > Hi Nikita, > > > > > > 1. As I can understand, this functionality is needed if a custom message > > > is > > > needed to be processed only on the coordinator node. I'm not following for > > > what purposes it was implemented and I see the real usage only in tests. > > > As far as this functionality is not used in production code, I suggest to > > > remove it. > > > 2. This method needs if we want to perform a message mutation during > > > sending it over the ring. Each node after message receive can mutate its > > > state and resend to another node. I know only 2 mechanisms where this > > > functionality is needed: > > > binary metadata propagation and cluster-wide metrics collecting. From my > > > side of view, this is poor approach and we should avoid discovery messages > > > mutation and use only immutable messages. It can be removed from the > > > custom > > > message interface and marker interface should be introduced instead. > > > > > > чт, 24 окт. 2019 г. в 16:35, Nikita Amelchev : > > > > > > > Hi, Igniters. > > > > > > > > The discovery custom message interface has two methods the use of > > > > which is not clear to developers: > > > > > > > > 1. The stopProcess() method. Currently, it works only if the zookeeper > > > > discovery configured. It doesn't work in TcpDiscoverySpi. I did not > > > > find any usages of this method except tests. I suggest to remove it > > > > from the discovery custom message interface. > > > > > > > > 2. The isMutable() method. It works in TcpDiscoverySpi but not in the > > > > zookeeper SPI. Using this method is opaque to the developer when he > > > > wants to add new features to the project. In general, it cannot be > > > > used because may not be supported depending on the configuration. > > > > Perhaps some functionality that uses it is not working correctly with > > > > zookeeper configured. It seems we should avoid it in the custom > > > > message interface too. > > > > > > > > WDYT? > > > > > > > > -- > > > > Best wishes, > > > > Amelchev Nikita > > > > > > > > > > -- Best wishes, Amelchev Nikita
Re: Internal classes are exposed in public API
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, 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 > * In ReadOnlyMetricsRegistry there is a Consumer, but > MetricRegistry is again an internal class. This will cause the user code > compilation to break when MetricRegistry is changed > > These things violate the public-private API separation and need to be > fixed prior 2.8 is released. Let's discuss what changes need to be made to > the API or perhaps move incomplete IEP-35 interfaces to the private package > and remove deprecations until the API is ready. > > --AG >
Internal classes are exposed in public API
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 user to fix their code to not use deprecated API * In ReadOnlyMetricsRegistry there is a Consumer, but MetricRegistry is again an internal class. This will cause the user code compilation to break when MetricRegistry is changed These things violate the public-private API separation and need to be fixed prior 2.8 is released. Let's discuss what changes need to be made to the API or perhaps move incomplete IEP-35 interfaces to the private package and remove deprecations until the API is ready. --AG
Re: Wrong results on Scan queries on REPLICATED caches during rebalance
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: 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 workaround I think PARTITIONED caches with Integer.MAX_VALUE > backups can be used instead of REPLICATED caches. > > Will be glad for any feedback. > > Kind regards, > Sergey Kosarev > > > > > --- > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information about > privacy. > -- Best Regards, Ivan Rakov
Re: [DISCUSSION] API to KILL any user started computation
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 command. > > > > 16 янв. 2020 г., в 15:28, Alexei Scherbakov < > alexey.scherbak...@gmail.com> написал(а): > > > > 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. > >> > >> 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 instability of the whole cluster. > >> > >> > >>> 16 янв. 2020 г., в 13:42, Alexei Scherbakov < > >> alexey.scherbak...@gmail.com> написал(а): > >>> > >>> 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 < > >> alexey.scherbak...@gmail.com > : > >>> > 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 г. в 21:30, Николай Ижиков : > > > Hello, Igniters. > > > > As you may know, we put a lot of effort to improve Ignite metric and > > diagnostic API. > > We have created the following API: > > * Metric manager > > * System view manager > > As far as I know, we would have tracing capabilities soon. > > > > I think it's time to take the next step. > > We should provide to the administrator the API to cancel(stop, kill) > > arbitrary user started computation. > > > > Right now we have API to do it for: > > * transactions `TransactionsMXBean#getActiveTransactions`. > > * SQL queries: `KILL QUERY` sql command and visor task - > > `VisorQueryCancelTask` > > > > Please, note, these features are implemented via different API. > > > > I think we should introduce uniform Cancel API for the following > > computations: > > > > * service. > > * specific service method execution. > > * compute job(compute task). > > * query(scan, continuous, text). > > > > We should also rework kill transaction and kill SQL queries API to > >> make > > them similar to each other. > > I have plans to write an IEP for it and implement it. > > What do you think? > > > > > > -- > > Best regards, > Alexei Scherbakov > > >>> > >>> > >>> -- > >>> > >>> Best regards, > >>> Alexei Scherbakov > >> > >> > > > > -- > > > > Best regards, > > Alexei Scherbakov > > -- Best regards, Alexei Scherbakov
Re: Wrong results on Scan queries on REPLICATED caches during rebalance
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/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 workaround I think PARTITIONED caches with Integer.MAX_VALUE > backups can be used instead of REPLICATED caches. > > Will be glad for any feedback. > > Kind regards, > Sergey Kosarev > > > > > --- > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to https://www.db.com/disclosures for additional EU > corporate and regulatory disclosures and to > http://www.db.com/unitedkingdom/content/privacy.htm for information about > privacy. > -- Best regards, Alexei Scherbakov
Re: [DISCUSSION] API to KILL any user started computation
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 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. >> >> 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 instability of the whole cluster. >> >> >>> 16 янв. 2020 г., в 13:42, Alexei Scherbakov < >> alexey.scherbak...@gmail.com> написал(а): >>> >>> 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 < >> alexey.scherbak...@gmail.com : >>> 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 г. в 21:30, Николай Ижиков : > Hello, Igniters. > > As you may know, we put a lot of effort to improve Ignite metric and > diagnostic API. > We have created the following API: > * Metric manager > * System view manager > As far as I know, we would have tracing capabilities soon. > > I think it's time to take the next step. > We should provide to the administrator the API to cancel(stop, kill) > arbitrary user started computation. > > Right now we have API to do it for: > * transactions `TransactionsMXBean#getActiveTransactions`. > * SQL queries: `KILL QUERY` sql command and visor task - > `VisorQueryCancelTask` > > Please, note, these features are implemented via different API. > > I think we should introduce uniform Cancel API for the following > computations: > > * service. > * specific service method execution. > * compute job(compute task). > * query(scan, continuous, text). > > We should also rework kill transaction and kill SQL queries API to >> make > them similar to each other. > I have plans to write an IEP for it and implement it. > What do you think? > > -- Best regards, Alexei Scherbakov >>> >>> >>> -- >>> >>> Best regards, >>> Alexei Scherbakov >> >> > > -- > > Best regards, > Alexei Scherbakov
[jira] [Created] (IGNITE-12550) Add page read latency histogram per data region
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 Issue Type: Improvement Components: persistence Reporter: Alexey Goncharuk Assignee: Alexey Goncharuk Fix For: 2.9 During an incident I experienced a large checkpoint mark duration. It was impossible to determine whether this was caused by a stalled disk because of large number of long page reads or by some other reasons. Having a metric showing the page read latency histogram would help in such cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSSION] API to KILL any user started computation
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. > > 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 instability of the whole cluster. > > > > 16 янв. 2020 г., в 13:42, Alexei Scherbakov < > alexey.scherbak...@gmail.com> написал(а): > > > > 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 < > alexey.scherbak...@gmail.com > >> : > > > >> 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 г. в 21:30, Николай Ижиков : > >> > >>> Hello, Igniters. > >>> > >>> As you may know, we put a lot of effort to improve Ignite metric and > >>> diagnostic API. > >>> We have created the following API: > >>>* Metric manager > >>>* System view manager > >>> As far as I know, we would have tracing capabilities soon. > >>> > >>> I think it's time to take the next step. > >>> We should provide to the administrator the API to cancel(stop, kill) > >>> arbitrary user started computation. > >>> > >>> Right now we have API to do it for: > >>>* transactions `TransactionsMXBean#getActiveTransactions`. > >>>* SQL queries: `KILL QUERY` sql command and visor task - > >>> `VisorQueryCancelTask` > >>> > >>> Please, note, these features are implemented via different API. > >>> > >>> I think we should introduce uniform Cancel API for the following > >>> computations: > >>> > >>>* service. > >>>* specific service method execution. > >>>* compute job(compute task). > >>>* query(scan, continuous, text). > >>> > >>> We should also rework kill transaction and kill SQL queries API to > make > >>> them similar to each other. > >>> I have plans to write an IEP for it and implement it. > >>> What do you think? > >>> > >>> > >> > >> -- > >> > >> Best regards, > >> Alexei Scherbakov > >> > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > -- Best regards, Alexei Scherbakov
Re: [DISCUSSION] API to KILL any user started computation
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 instability of the whole cluster. > 16 янв. 2020 г., в 13:42, Alexei Scherbakov > написал(а): > > 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 >> 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 г. в 21:30, Николай Ижиков : >> >>> Hello, Igniters. >>> >>> As you may know, we put a lot of effort to improve Ignite metric and >>> diagnostic API. >>> We have created the following API: >>>* Metric manager >>>* System view manager >>> As far as I know, we would have tracing capabilities soon. >>> >>> I think it's time to take the next step. >>> We should provide to the administrator the API to cancel(stop, kill) >>> arbitrary user started computation. >>> >>> Right now we have API to do it for: >>>* transactions `TransactionsMXBean#getActiveTransactions`. >>>* SQL queries: `KILL QUERY` sql command and visor task - >>> `VisorQueryCancelTask` >>> >>> Please, note, these features are implemented via different API. >>> >>> I think we should introduce uniform Cancel API for the following >>> computations: >>> >>>* service. >>>* specific service method execution. >>>* compute job(compute task). >>>* query(scan, continuous, text). >>> >>> We should also rework kill transaction and kill SQL queries API to make >>> them similar to each other. >>> I have plans to write an IEP for it and implement it. >>> What do you think? >>> >>> >> >> -- >> >> Best regards, >> Alexei Scherbakov >> > > > -- > > Best regards, > Alexei Scherbakov
Wrong results on Scan queries on REPLICATED caches during rebalance
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 workaround I think PARTITIONED caches with Integer.MAX_VALUE backups can be used instead of REPLICATED caches. Will be glad for any feedback. Kind regards, Sergey Kosarev --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.
Re: [DISCUSSION] API to KILL any user started computation
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 > 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 г. в 21:30, Николай Ижиков : > >> Hello, Igniters. >> >> As you may know, we put a lot of effort to improve Ignite metric and >> diagnostic API. >> We have created the following API: >> * Metric manager >> * System view manager >> As far as I know, we would have tracing capabilities soon. >> >> I think it's time to take the next step. >> We should provide to the administrator the API to cancel(stop, kill) >> arbitrary user started computation. >> >> Right now we have API to do it for: >> * transactions `TransactionsMXBean#getActiveTransactions`. >> * SQL queries: `KILL QUERY` sql command and visor task - >> `VisorQueryCancelTask` >> >> Please, note, these features are implemented via different API. >> >> I think we should introduce uniform Cancel API for the following >> computations: >> >> * service. >> * specific service method execution. >> * compute job(compute task). >> * query(scan, continuous, text). >> >> We should also rework kill transaction and kill SQL queries API to make >> them similar to each other. >> I have plans to write an IEP for it and implement it. >> What do you think? >> >> > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
Re: [DISCUSSION] API to KILL any user started computation
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 г. в 21:30, Николай Ижиков : > Hello, Igniters. > > As you may know, we put a lot of effort to improve Ignite metric and > diagnostic API. > We have created the following API: > * Metric manager > * System view manager > As far as I know, we would have tracing capabilities soon. > > I think it's time to take the next step. > We should provide to the administrator the API to cancel(stop, kill) > arbitrary user started computation. > > Right now we have API to do it for: > * transactions `TransactionsMXBean#getActiveTransactions`. > * SQL queries: `KILL QUERY` sql command and visor task - > `VisorQueryCancelTask` > > Please, note, these features are implemented via different API. > > I think we should introduce uniform Cancel API for the following > computations: > > * service. > * specific service method execution. > * compute job(compute task). > * query(scan, continuous, text). > > We should also rework kill transaction and kill SQL queries API to make > them similar to each other. > I have plans to write an IEP for it and implement it. > What do you think? > > -- Best regards, Alexei Scherbakov
Re: Slim binary release and docker image for Apache Ignite
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.
I like the idea. Let's do this.
Best Regards,
Igor
On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> 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
> opinion on this. Pre-built binaries certainly add usability, but I am not
> sure how those binaries should be tested afterwards.
>
> ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
>
> > I'm +1 for "SLIM" it is a common name in Docker world.
> >
> > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov wrote:
> >
> > > +1 for slim binary
> > > Plus docker-slim
> > > Plus RPM / DEB packages modularisation like PHP distribution — with
> core
> > > and lots of integrations / modules.
> > >
> > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev >
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > I think we should name it "core" since we already have ignite-core
> and
> > it
> > > > will be confusing. Maybe we should go full 00s and call it "lite"?
> > > >
> > > > I also think we should keep both .Net and C++. .Net is runnable out
> of
> > > box
> > > > which is awesome, and C++ needs building but it is rather small in
> > source
> > > > form.
> > > >
> > > > I also suggest a different change to build process. Let's ship C++
> with
> > > > automake, etc, already run, for all binary packaging options? WDYT? I
> > can
> > > > assist in build process tuning.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > > >
> > > >> Alex,
> > > >>
> > > >> I'm on your end and support the proposal. Could you also clarify if
> > you
> > > >> suggest we keeping or removing C++ and .NET thick clients?
> > > >>
> > > >> Speaking of the naming, how about titling such packages as 'core'
> > > instead
> > > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > > >>
> > > >>
> > > >> -
> > > >> Denis
> > > >>
> > > >>
> > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > >>>
> > > >> wrote:
> > > >>
> > > >>> Hello!
> > > >>>
> > > >>> Pavel, I believe these JARs are fully covered by the list of
> modules
> > > >>> specified above.
> > > >>>
> > > >>> Regards,
> > > >>> --
> > > >>> Ilya Kasnacheev
> > > >>>
> > > >>>
> > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn >:
> > > >>>
> > > I like the idea, current distribution is certainly too big.
> > >
> > > Here is a list of jar files we include in NuGet package:
> > >
> > > cache-api-1.0.0.jar
> > > commons-codec-1.11.jar
> > > commons-logging-1.1.1.jar
> > > h2-1.4.197.jar
> > > ignite-core-2.9.0-SNAPSHOT.jar
> > > ignite-indexing-2.9.0-SNAPSHOT.jar
> > > ignite-shmem-1.0.0.jar
> > > ignite-spring-2.9.0-SNAPSHOT.jar
> > > lucene-analyzers-common-7.4.0.jar
> > > lucene-core-7.4.0.jar
> > > lucene-queryparser-7.4.0.jar
> > > spring-aop-4.3.18.RELEASE.jar
> > > spring-beans-4.3.18.RELEASE.jar
> > > spring-context-4.3.18.RELEASE.jar
> > > spring-core-4.3.18.RELEASE.jar
> > > spring-expression-4.3.18.RELEASE.jar
> > > spring-jdbc-4.3.18.RELEASE.jar
> > > spring-tx-4.3.18.RELEASE.jar
> > >
> > > Those are required for SQL and Spring configs to work properly,
> > > maybe we want to include them into the slim distro as well.
> > >
> > > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > > >>> ilya.kasnach...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > This is a reasonable idea.
> > > >
> > > > I think we should also drop benchmarks/ directory from that
> build,
> > > >> it's
> > > 60M
> > > > of (potentially vulnerable) JARs that are not needed by an
> average
> > > > developer's use cases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > >> :
> > > >
> > > >> Igniters,
> > > >>
> > > >> I would like to discuss with the community a possibility to
> create
> > > >> additional 'slim' binary releases and docker images for Apache
> > > >>> Ignite.
> > > > The
> > > >> reason is two-fold:
> > > >> * The full set of 3rd party libraries distributed with Apache
> > > >> Ignite
> > > > looks
> > > >> too large for me. I know there is an ongoing
[jira] [Created] (IGNITE-12549) Scan query/iterator on a replicated cache may get wrong results
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: Ignite Issue Type: Bug Components: cache Affects Versions: 2.7.6 Reporter: Sergey Kosarev Case 1 1. start server node 1 2 create and fill replicated cache with RebalanceMode.Async (as by default) 3 start servr node 2 3 immediately execute scan query on the replicated cache((or just iterate the cache)) on the node 2 It can get empty or partial results. (if rebalance on node 2 is finished) Case 2 1. start server node 1 2 create and fill replicated cache with RebalanceMode.Async (as by default) 3 start client node 2 3 start server node 3 3 immediately execute scan query on the replicated cache((or just iterate the cache)) on the client node 2 It can get empty or partial results. (if rebalance on node 2 is not finished and query is mapped on the node 2) It looks like problem in the org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter#nodes() case REPLICATED: if (prj != null || part != null) return nodes(cctx, prj, part); if (cctx.affinityNode()) return *Collections.singletonList(cctx.localNode())*; Collection affNodes = nodes(cctx, null, null); return affNodes.isEmpty() ? affNodes : *Collections.singletonList(F.rand(affNodes))*; case PARTITIONED: return nodes(cctx, prj, part); -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Slim binary release and docker image for Apache Ignite
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
opinion on this. Pre-built binaries certainly add usability, but I am not
sure how those binaries should be tested afterwards.
ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
> I'm +1 for "SLIM" it is a common name in Docker world.
>
> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov wrote:
>
> > +1 for slim binary
> > Plus docker-slim
> > Plus RPM / DEB packages modularisation like PHP distribution — with core
> > and lots of integrations / modules.
> >
> > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev
> > wrote:
> > >
> > > Hello!
> > >
> > > I think we should name it "core" since we already have ignite-core and
> it
> > > will be confusing. Maybe we should go full 00s and call it "lite"?
> > >
> > > I also think we should keep both .Net and C++. .Net is runnable out of
> > box
> > > which is awesome, and C++ needs building but it is rather small in
> source
> > > form.
> > >
> > > I also suggest a different change to build process. Let's ship C++ with
> > > automake, etc, already run, for all binary packaging options? WDYT? I
> can
> > > assist in build process tuning.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > >
> > >> Alex,
> > >>
> > >> I'm on your end and support the proposal. Could you also clarify if
> you
> > >> suggest we keeping or removing C++ and .NET thick clients?
> > >>
> > >> Speaking of the naming, how about titling such packages as 'core'
> > instead
> > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > >>
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > >>>
> > >> wrote:
> > >>
> > >>> Hello!
> > >>>
> > >>> Pavel, I believe these JARs are fully covered by the list of modules
> > >>> specified above.
> > >>>
> > >>> Regards,
> > >>> --
> > >>> Ilya Kasnacheev
> > >>>
> > >>>
> > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
> > >>>
> > I like the idea, current distribution is certainly too big.
> >
> > Here is a list of jar files we include in NuGet package:
> >
> > cache-api-1.0.0.jar
> > commons-codec-1.11.jar
> > commons-logging-1.1.1.jar
> > h2-1.4.197.jar
> > ignite-core-2.9.0-SNAPSHOT.jar
> > ignite-indexing-2.9.0-SNAPSHOT.jar
> > ignite-shmem-1.0.0.jar
> > ignite-spring-2.9.0-SNAPSHOT.jar
> > lucene-analyzers-common-7.4.0.jar
> > lucene-core-7.4.0.jar
> > lucene-queryparser-7.4.0.jar
> > spring-aop-4.3.18.RELEASE.jar
> > spring-beans-4.3.18.RELEASE.jar
> > spring-context-4.3.18.RELEASE.jar
> > spring-core-4.3.18.RELEASE.jar
> > spring-expression-4.3.18.RELEASE.jar
> > spring-jdbc-4.3.18.RELEASE.jar
> > spring-tx-4.3.18.RELEASE.jar
> >
> > Those are required for SQL and Spring configs to work properly,
> > maybe we want to include them into the slim distro as well.
> >
> > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > >>> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > This is a reasonable idea.
> > >
> > > I think we should also drop benchmarks/ directory from that build,
> > >> it's
> > 60M
> > > of (potentially vulnerable) JARs that are not needed by an average
> > > developer's use cases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > >> :
> > >
> > >> Igniters,
> > >>
> > >> I would like to discuss with the community a possibility to create
> > >> additional 'slim' binary releases and docker images for Apache
> > >>> Ignite.
> > > The
> > >> reason is two-fold:
> > >> * The full set of 3rd party libraries distributed with Apache
> > >> Ignite
> > > looks
> > >> too large for me. I know there is an ongoing activity towards more
> > clear
> > >> Ignite modularization [1][2][3], but this seems to be quite a long
> > > process.
> > >> On the other hand, creating a slim release may give an immediate
> > benefit
> > > to
> > >> the users who are interested in a smaller image. For example,
> > >>> removing
> > > the
> > >> benchmarks alone from the binary release saves 80M.
> > >> * As Ilya Kasnacheev demonstrated [4], the more 3rd party
> > >> libraries
> > >>> we
> > >> have, the more potential vulnerabilities will show up in audit
> > >> tools.
> > > This
> > >> may be a formal barrier for Apache Ignite adoption and moving to
> > > production
> > >> for many users. Having a
