Re: [DISCUSS] Targeting issues to 2.8.1
Andrey, > targeting to specific version means that this change should be > included in release with target fix version. No more, no less. What do you mean by "targeting to a specific version" here? Fix version in JIRA? Something else? My main point here is to simplify things. Issues like [1] looks invalid for me. And I expect problems from such issues in the future. [1] https://issues.apache.org/jira/browse/IGNITE-12756 Best regards, Ivan Pavlukhin ср, 11 мар. 2020 г. в 03:23, Andrey Gura : > > Ivan, > > targeting to specific version means that this change should be > included in release with target fix version. No more, no less. > > On Wed, Mar 11, 2020 at 2:42 AM Ivan Pavlukhin wrote: > > > > Igniters, > > > > Initially I wanted to delay the discussion about everything related to > > 2.8.1 until all 2.8 release activities are finished, but I already see > > some possible problems. Mainly it is related to adding tickets to > > 2.8.1 scope. I recall that it was already discussed in some other > > thread that it is not good idea to mark tickets with 2.8.1 fix version > > because a branch for it does not exist yet and technically we can > > resolve tickets for 2.9 but not for 2.8.1. > > > > I checked JIRA for 2.8.1 and found a bunch of tickets with 2.8.1 fix > > version [1] and what is even worse some of them are already RESOLVED > > [2]. > > > > Not using 2.8.1 looks much cleaner especially for RESOLVED tickets. > > But I feel that we can miss some tickets because an intent to include > > a ticket into 2.8.1 is not indicated at all. > > > > Please share your thoughts how the situation could be improved. > > > > [1] > > https://issues.apache.org/jira/browse/IGNITE-12769?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8.1 > > [2] > > https://issues.apache.org/jira/browse/IGNITE-12756?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8.1%20AND%20resolution%20is%20not%20EMPTY%20 > > > > Best regards, > > Ivan Pavlukhin
Re: [DISCUSS] Targeting issues to 2.8.1
Ivan, targeting to specific version means that this change should be included in release with target fix version. No more, no less. On Wed, Mar 11, 2020 at 2:42 AM Ivan Pavlukhin wrote: > > Igniters, > > Initially I wanted to delay the discussion about everything related to > 2.8.1 until all 2.8 release activities are finished, but I already see > some possible problems. Mainly it is related to adding tickets to > 2.8.1 scope. I recall that it was already discussed in some other > thread that it is not good idea to mark tickets with 2.8.1 fix version > because a branch for it does not exist yet and technically we can > resolve tickets for 2.9 but not for 2.8.1. > > I checked JIRA for 2.8.1 and found a bunch of tickets with 2.8.1 fix > version [1] and what is even worse some of them are already RESOLVED > [2]. > > Not using 2.8.1 looks much cleaner especially for RESOLVED tickets. > But I feel that we can miss some tickets because an intent to include > a ticket into 2.8.1 is not indicated at all. > > Please share your thoughts how the situation could be improved. > > [1] > https://issues.apache.org/jira/browse/IGNITE-12769?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8.1 > [2] > https://issues.apache.org/jira/browse/IGNITE-12756?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8.1%20AND%20resolution%20is%20not%20EMPTY%20 > > Best regards, > Ivan Pavlukhin
[DISCUSS] Targeting issues to 2.8.1
Igniters, Initially I wanted to delay the discussion about everything related to 2.8.1 until all 2.8 release activities are finished, but I already see some possible problems. Mainly it is related to adding tickets to 2.8.1 scope. I recall that it was already discussed in some other thread that it is not good idea to mark tickets with 2.8.1 fix version because a branch for it does not exist yet and technically we can resolve tickets for 2.9 but not for 2.8.1. I checked JIRA for 2.8.1 and found a bunch of tickets with 2.8.1 fix version [1] and what is even worse some of them are already RESOLVED [2]. Not using 2.8.1 looks much cleaner especially for RESOLVED tickets. But I feel that we can miss some tickets because an intent to include a ticket into 2.8.1 is not indicated at all. Please share your thoughts how the situation could be improved. [1] https://issues.apache.org/jira/browse/IGNITE-12769?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8.1 [2] https://issues.apache.org/jira/browse/IGNITE-12756?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.8.1%20AND%20resolution%20is%20not%20EMPTY%20 Best regards, Ivan Pavlukhin
Re: Re[4]: Text queries/indexes (GridLuceneIndex, @QueryTextFiled)
Igniters, Not intentionally the discussion continued outside of dev list. I am returning it back. You can find it below. Do not hesitate to join if you have some thoughts on raised questions. May be you have ideas how to enrich text query results with score/rank information. вт, 10 мар. 2020 г. в 09:11, Yuriy Shuliga : > Yes, please do. > > вт, 10 бер. 2020, 02:26 користувач Ivan Pavlukhin > пише: > >> Yuriy, >> >> I noticed that from some point our discussion moved out of Ignite dev >> list. Would you mind if I return it back to dev list? >> >> Best regards, >> Ivan Pavlukhin >> >> вт, 10 мар. 2020 г. в 03:25, Ivan Pavlukhin : >> > >> > > PS As far as i see, the are no chance to get on 2.8 release train. >> What will be the next version/date we can aim on with this update? >> > >> > Yes, 2.8 is already available and the community is working on >> finalizing activities (e.g. publishing documentation). I do not have any >> reliable expectations about next releases. I suppose that there could be a >> couple of maintenance releases like 2.8.1 as several problems were already >> discovered. I do not know whether next more significant release is going to >> be 2.9 even major release 3.0. It sounds realistic to facilitate 2.9 >> because there are already several "almost ready" features in master. In my >> mind it is a good idea to start a discussion about next releases on dev >> list. >> > >> > Best regards, >> > Ivan Pavlukhin >> > >> > вт, 10 мар. 2020 г. в 00:58, Ivan Pavlukhin : >> > > >> > > Hi Yuriy, >> > > >> > > Sorry for a late response. >> > > >> > > > Suitable solution without subclassing might be: >> > > > 1. Explicitly add float field to entity >> > > > 2. Annotate it with special @QueryRankField, (for instance) >> > > > 3. Fill in this field with docScore in GrlidLuceneindex, pass back >> to initiating node >> > > > 4. Possibly still need to proxify entity with adding Comparable >> interface. >> > > > 5. Perform merge sort on initiating node >> > > >> > > Possibly I missed it but one moment is not clear for me. What will >> > > happen if an entity class does not have a field annotated with >> > > QueryRankField? >> > > >> > > And I am still not sure that it is a proper (enough) approach. The >> > > thing which bothers me is a transient and dynamic nature of "rank" >> > > field. It does belong to entity, it can have different values for the >> > > same entity (e.g. different indices are used). >> > > >> > > I would like to experiment with a code a little bit. But most likely I >> > > will have a chance only at the end of this week. >> > > >> > > Best regards, >> > > Ivan Pavlukhin >> > > >> > > пн, 2 мар. 2020 г. в 20:09, Yuriy Shuliga : >> > > > >> > > > Hi Ivan, >> > > > >> > > > Have concerns about entity annotation variant. >> > > > Wrapping into dynamic proxy for passing back, will be quite a >> complex thing that requires changes in IgniteCacheObjectProcessor >> > > > and entity marshaling. >> > > > >> > > > Suitable solution without subclassing might be: >> > > > 1. Explicitly add float field to entity >> > > > 2. Annotate it with special @QueryRankField, (for instance) >> > > > 3. Fill in this field with docScore in GrlidLuceneindex, pass back >> to initiating node >> > > > 4. Possibly still need to proxify entity with adding Comparable >> interface. >> > > > 5. Perform merge sort on initiating node >> > > > >> > > > Would you consider this approach or return back to using Ranked >> superclass? >> > > > >> > > > Regarding your proposal to implement megre sort - definitely yes. >> > > > I will implement this. >> > > > Sorry, didn't understand you earlier ) >> > > > >> > > > BR, >> > > > Yuriy Shuliha >> > > > >> > > > PS As far as i see, the are no chance to get on 2.8 release train. >> What will be the next version/date we can aim on with this update? >> > > > >> > > > >> > > > пт, 28 лют. 2020 о 23:08 Ivan Pavlukhin пише: >> > > >> >> > > >> Hi Yuriy, >> > > >> >> > > >> Sorry for a late response and thank you for your comments. >> > > >> >> > > >> Approach with @Ranked annotation looks cleaner to me from API >> point of view. >> > > >> >> > > >> Regarding merging responses from multiple nodes I suppose that good >> > > >> enough solution is possible: >> > > >> 1. Request one page of entries from each node. >> > > >> 2. Return one page to a user (as there is definitely a page of the >> > > >> best results already). >> > > >> 3. Request next result pages from nodes corresponding to pages we >> > > >> exposed to the user (actually nodes having lesser than 1 page of >> > > >> pending results). Repeat from step 2. >> > > >> >> > > >> Some kind of sort merge plus backpressure. Backpressure part might >> be >> > > >> left as an improvement. >> > > >> >> > > >> What do you think? >> > > >> >> > > >> Best regards, >> > > >> Ivan Pavlukhin >> > > >> >> > > >> вт, 18 февр. 2020 г. в 18:27, Yuriy Shuliga : >> > > >> >> > > >> > >> > > >> > Hi Ivan, >> > > >> > >> > > >> > Thank you for keeping
Re: Cache metrics on server nodes does not update correctly
@Nikolay Izhikov , @Andrey Gura ,
could you folks check out this thread?
I have a feeling that what Dominik is describing was talked out before and
rather some sort of a limitation than an issue with the current
implementation.
-
Denis
On Tue, Mar 3, 2020 at 11:41 PM Dominik Przybysz
wrote:
> Hi,
> I am trying to use partitioned cache on server nodes to which I connect
> with client node. Statistics of cache in the cluster are updated, but only
> for hits metric - misses metric is always 0.
>
> To reproduce this problem I created cluster of two nodes:
>
> Server node 1 adds 100 random test cases and prints cache statistics
> continuously:
>
> public class IgniteClusterNode1 {
> public static void main(String[] args) throws InterruptedException {
> IgniteConfiguration igniteConfiguration = new
> IgniteConfiguration();
>
> CacheConfiguration cacheConfiguration = new CacheConfiguration();
> cacheConfiguration.setName("test");
> cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheConfiguration.setStatisticsEnabled(true);
> igniteConfiguration.setCacheConfiguration(cacheConfiguration);
>
> TcpCommunicationSpi communicationSpi = new TcpCommunicationSpi();
> communicationSpi.setLocalPort(47500);
> igniteConfiguration.setCommunicationSpi(communicationSpi);
>
> TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
> discoverySpi.setLocalPort(47100);
> discoverySpi.setLocalPortRange(100);
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
> ipFinder.setAddresses(Arrays.asList("127.0.0.1:47100..47200",
> "127.0.0.1:48100..48200"));
> igniteConfiguration.setDiscoverySpi(discoverySpi);
>
> try (Ignite ignite = Ignition.start(igniteConfiguration)) {
> try (IgniteCache cache =
> ignite.getOrCreateCache("test")) {
> new Random().ints(1000).map(i -> Math.abs(i %
> 1000)).distinct().limit(100).forEach(i -> {
> String key = "data_" + i;
> String value = UUID.randomUUID().toString();
> cache.put(key, value);
> }
> );
> }
> while (true) {
> System.out.println(ignite.cache("test").metrics());
> Thread.sleep(5000);
> }
> }
> }
> }
>
> Server node 2 only prints cache statistics continuously:
>
> public class IgniteClusterNode2 {
> public static void main(String[] args) throws InterruptedException {
> IgniteConfiguration igniteConfiguration = new
> IgniteConfiguration();
>
> CacheConfiguration cacheConfiguration = new CacheConfiguration();
> cacheConfiguration.setName("test");
> cacheConfiguration.setCacheMode(CacheMode.PARTITIONED);
> cacheConfiguration.setStatisticsEnabled(true);
> igniteConfiguration.setCacheConfiguration(cacheConfiguration);
>
> TcpCommunicationSpi communicationSpi = new TcpCommunicationSpi();
> communicationSpi.setLocalPort(48500);
> igniteConfiguration.setCommunicationSpi(communicationSpi);
>
> TcpDiscoverySpi discoverySpi = new TcpDiscoverySpi();
> discoverySpi.setLocalPort(48100);
> discoverySpi.setLocalPortRange(100);
> TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
> ipFinder.setAddresses(Arrays.asList("127.0.0.1:47100..47200",
> "127.0.0.1:48100..48200"));
> igniteConfiguration.setDiscoverySpi(discoverySpi);
>
> try (Ignite ignite = Ignition.start(igniteConfiguration)) {
> while (true) {
> System.out.println(ignite.cache("test").metrics());
> Thread.sleep(5000);
> }
> }
> }
> }
>
> Next I start a client node which continuously read data from the cluster:
>
> public class CacheClusterReader {
> public static void main(String[] args) throws InterruptedException {
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setClientMode(true);
>
> TcpDiscoverySpi spi = new TcpDiscoverySpi();
> TcpDiscoveryVmIpFinder tcMp = new TcpDiscoveryVmIpFinder();
> tcMp.setAddresses(Arrays.asList("127.0.0.1:47100..47200",
> "127.0.0.1:48100..48200"));
> spi.setIpFinder(tcMp);
> cfg.setDiscoverySpi(spi);
>
> CacheConfiguration cacheConfig = new
> CacheConfiguration<>("test");
> cacheConfig.setStatisticsEnabled(true);
> cacheConfig.setCacheMode(CacheMode.PARTITIONED);
> cfg.setCacheConfiguration(cacheConfig);
>
> try (Ignite ignite = Ignition.start(cfg)) {
> System.out.println(ignite.cacheNames());
>
> while (true) {
> try (IgniteCache cache =
> ignite.getOrCreateCache(cacheConfig)) {
>
Re: Ignite Website: New Look
Hi Dmitry, Thanks for the guidance. I've created the repository and will keep things moving. https://github.com/apache/ignite-website - Denis On Sat, Mar 7, 2020 at 3:08 AM Dmitriy Pavlov wrote: > Hi Denis, > > Unfortunately, I don't know details on how to set it up. > > One thing I've noticed in Apache Training (incubating) and in Apache DLab > (incubating) that both projects > 1. added site sources to Git repository and > 2. created an INFRA ticket for setting up the site. > > Let's try it too, and let's hope INFRA will guide us on the required steps. > > Sincerely, > Dmitriy Pavlov > > сб, 7 мар. 2020 г. в 01:08, Denis Magda : > > > Dmitry, > > > > Agree on the Github repository. Let me look into it. If you have any > > pointers or came across any instructions earlier please let me know. > > > > - > > Denis > > > > > > On Fri, Mar 6, 2020 at 8:03 AM Dmitriy Pavlov > wrote: > > > > > Hi Igniters, > > > > > > IMO, new design looks good, but please pay attention > > > - every mention of Apache Ignite is better to be followed by (R) mark > > since > > > it is registered trademark of the ASF in the US and other countries. > > > - download page is not available (as Denis mentioned it should not be > an > > > issue). > > > > > > And one more side note: since 1) it is a major change in the site look > > and > > > 2) our site is still stored in the SVN, could we consider migrating to > > Git > > > repository first? > > > > > > Git benefits are more or less obvious: > > > - It will allow us to make a PRs for contributions to the site. > > > - Git repository is slightly more convenient. It works faster during > > clone, > > > commit, and update. > > > - It should help to recognize contributions from Mauricio and Ignacio > > and > > > all other members, who updates and maintains the site (we don't have > > > contributors listing page and we use git for listing of the project's > > > developers). > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > BTW, since this is important topic, I suggest every email with proposal > > is > > > marked with [DISCUSSION] to help it to be noticed. > > > > > > пт, 6 мар. 2020 г. в 03:21, Nikita Ivanov : > > > > > > > Denis - looks very nice! I do indeed think we need to work on better > > > > content (home page specifically). > > > > Thanks! > > > > -- > > > > Nikita Ivanov > > > > > > > > > > > > > > > > On Thu, Mar 5, 2020 at 3:18 PM Denis Magda > wrote: > > > > > > > > > Folks, > > > > > > > > > > As many of you know, these days I mostly contribute by optimizing > our > > > > > website, preparing different content including > > documentation/articles, > > > > and > > > > > presenting the project at various events. One of the continuous > > website > > > > > activities we undertake together with Mauricio and Ignacio is > search > > > > engine > > > > > optimization (SEO). It helps our website to be ranked higher by > > search > > > > > engines for user searches falling in categories of in-memory > caches, > > > > grids, > > > > > databases, etc. (check this simple guide [1] if you'd like to learn > > the > > > > > internals of SEO). > > > > > > > > > > After checking the results of our recent user questionnaire [2] and > > > > > confirming key capabilities with use cases Ignite is selected for, > we > > > > > decided to put more effort into the SEO. And, in addition to the > > > keywords > > > > > optimizations, we invested some time into the structural and UI > > changes > > > > of > > > > > the website trying to make the experience better and, as a result, > be > > > > > ranked higher. > > > > > > > > > > So, today we'd like to share our first results and check your > > thoughts. > > > > In > > > > > particular, pay attention to: > > > > > > > > > >- The new UI - instead of a dark and bloody theme, we decided to > > > > >experiment with a more lightweight and contemporary design. > > > > >- A new main page structure with the following blocks - banner, > > use > > > > >cases, features, quicks links + tweeter feed. > > > > >- Updated navigation menu - kept essential or highly-ranked > pages. > > > > > > > > > > > > > > > Do NOT pay attention to the following yet (we're ready to carry on > > with > > > > the > > > > > items below once hear your feedback): > > > > > > > > > >- Text on the front page will be massaged and tweaked going > > forward > > > to > > > > >get better SEO. Presently, something might sound off to you. > > > > >- Secondary pages are broken from the UI and structure > standpoint > > > > >- Some of the pages of the navigation menu, such as Videos, are > > not > > > > >created yet. > > > > > > > > > > > > > > > Alright, we deployed our branch to this test server. Go and check: > > > > > http://157.245.190.104 (user: ignite, pass: apache2020) > > > > > > > > > > > > > > > > > > > > [1] https://moz.com/beginners-guide-to-seo > > > > > [2] > > > > > > > > > > > > > > > > > > > >
Re: Reference of local service.
Hi, everyone.
I've done some benchmarks and wonder whether we need to disable service
metrics somehow. As Denis suggested, proxies might be involved for local
services. If I enable current proxy for local services, I see the flowing
cases:
1) Service proxy is too slow with trivial operations to care about metrics
performance.
2) Service metrics do not hit performance significantly or do not hit at
all on real operations.
I doubt other implementation of service proxy could bring serious changes
and would worth. Do we need to care about performance hit of the service
metrics and think how to disable?
Without metrics:
- Test [3] : proxy [2] is 6.5 times slower than local [1] (11kk ops/s VS
72kk ops/s)
- Test [4] : proxy is 19% slower than local (990k ops/s VS 1182k ops/s)
- Test [5] : proxy is not slower (same 250k ops/s)
With metrics:
- Test [3] : proxy [2] is 7.5 times slower than local [1] (9.6kk ops/s VS
73kk ops/s)
- Test [4] : proxy is 21% slower than local (995k ops/s VS 1200k ops/s)
- Test [5] : proxy is 10% slower than local (244k ops/s VS 264k ops/s)
private TestService localService [1];
private TestService serviceProxy [2];
private IgniteEx ignite;
private IgniteCache cache;
interface TestService {
Object handleVal(int value);
}
static class TestServiceImpl implements Service, TestService {
…
private IgniteCache cache;
@Override public Object handleVal(int value) {
[3] return randomInt(value);
[4] return cache.get(value);
[5] return cache.getAndPut(randomInt(value), value);
}
}
@Benchmark
public void localService(Blackhole blackhole) throws Exception {
blackhole.consume( localService.handleVal(1+randomInt(MAX_VALUE)) );
}
@Benchmark
public void proxiedService(Blackhole blackhole) throws Exception {
blackhole.consume( serviceProxy.handleVal(1+randomInt(MAX_VALUE)) );
}
@Setup
public void setup() throws Exception {
ignite = (IgniteEx)Ignition.start(configuration("grid0"));
cache = ignite.createCache("cache");
for(int i=0; i(ignite.cluster(),"srv",
TestService.class, true, 0, ignite.context()).proxy();
}
чт, 5 мар. 2020 г., 16:48 Andrey Gura ag...@apache.org:
> Hi there,
>
> what if we will generate proxy that collects service's metrics only if
> service will implement some special interface? In such case:
>
> - we won't affect existing services at all.
> - we can impose additional requirement for services that want use
> metrics out of box (i.e. service that implements our special interface
> *must* also have own interface and only invocations of methods of this
> interface will be taken into account for metrics collection).
> - user always can use own metrics framework instead of our (just do
> not implement this new special interface).
>
> About metrics enabling/disabling. At present IGNITE-11927 doesn't
> solve this problem. Just because there is no metrics implementation
> for services :)
> Anyway we should provide a way for configuring service metrics (in
> sense of enabled/disabled) during service deploy. It's easy for cases
> where deploy() methods have ServiceConfiguration as parameter. But
> there are "short cut" methods like deployXxxSingleton(). I have ideas
> how to solve this problem. For example we can introduce "short cut"
> factory methods like nodeSingletonConfiguration(String name, Service
> service) and clusterSingletonConfiguration(String name, Service
> service). This methods will return configuration which has parameters
> for given type of deployment and could be modified, e.g. metrics could
> be enabled.
>
> WDYT?
>
> On Wed, Mar 4, 2020 at 8:42 PM Vladimir Steshin
> wrote:
> >
> > Vyacheslav, Denis, hi again.
> >
> >
> >
> > >>> I agree with the proposal to introduce a new method which returns
> proxy
> > include the case of locally deployed services.
> >
> >
> >
> > I see one is restricted to use an interface for service with
> > IgniteServiceProcessor#serviceProxy(…):
> >
> >
> >
> > A.ensure(svcItf.isInterface(), "Service class must be an interface: " +
> > svcItf);
> >
> >
> >
> > What if we change IgniteService#serviceProxy(...) so that it will return
> > proxy everytime? That looks safe for user code. Doing so we might only
> > deprecate IgniteService#service(...).
> >
> >
> >
> > вт, 3 мар. 2020 г., 11:03 Vyacheslav Daradur :
> >
> > > Denis, finally I understood your arguments about interfaces check,
> thank
> > > you for the explanation.
> > >
> > > I agree with the proposal to introduce a new method which returns proxy
> > > include the case of locally deployed services.
> > >
> > > Also, such a method should be able to work in mode "local services
> > > preferred", perhaps with load-balancing (in case of multiple locally
> > > deployed instances). This allows our end-users to reach better
> performance.
> > >
> > >
> > >
> > > On Mon, Mar 2, 2020 at 7:51 PM Denis Mekhanikov >
> > > wrote:
> > >
> > > > Vyacheslav,
> > > >
> > > > You can't make
[jira] [Created] (IGNITE-12769) MetricRegistryMBean and OpenCensusExporterSpi have memory leak
Andrey N. Gura created IGNITE-12769:
---
Summary: MetricRegistryMBean and OpenCensusExporterSpi have memory
leak
Key: IGNITE-12769
URL: https://issues.apache.org/jira/browse/IGNITE-12769
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
{{MetricRegistryMBean}} and {{OpenCensusExporterSpi}} have memory leak.
To the following maps values add but never remove (i.e. on remove corresponding
histogram or on change histogram buckets layout):
* {{MetricRegistryMBean.histogramNames}}
* {{OpenCensusMetricExporterSpi.histogramNames}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Ignite 2.8 documentation
> • Looks like this sentence should contain a link to somewhere: "Please, see > XXX as an example and OpenCensus documentation for additional information." Fixed. > • Please mention that for the OpenCensus exporter to work, the module > should be enabled. Fixed. > • Also, there is no information on how to specify a filter via > configuration. Filter is very straightforward so I don’t think we should provide examples for it. > 10 марта 2020 г., в 15:00, Artem Budnikov > написал(а): > > Hi Nikolay, > > I looked through the metrics pages and found a couple of minor issues: > > • Looks like this sentence should contain a link to somewhere: "Please, > see XXX as an example and OpenCensus documentation for additional > information." > • Please mention that for the OpenCensus exporter to work, the module > should be enabled. > • Also, there is no information on how to specify a filter via > configuration. > -Artem > > On 10.03.2020 12:50, Maxim Muzafarov wrote: >> Folks, >> >> It seems everything is ready to go and only minor issues left with >> documentation. >> Are we ready to announce 2.8 release widely? >> >> >> On Tue, 10 Mar 2020 at 12:10, Nikolay Izhikov >> >> wrote: >> >>> Hello, Igniters. >>> >>> I rewrote pages about new metrics and system views. >>> Please, take a look. >>> >>> >>> https://apacheignite.readme.io/docs/new-metrics >>> https://apacheignite.readme.io/docs/system-views >>> >>> >>> >>> https://issues.apache.org/jira/browse/IGNITE-12408 >>> >>> >>> >>> 6 марта 2020 г., в 16:40, Artem Budnikov написал(а): Anton, Thanks for the feedback. I updated the page. -Artem On 05.03.2020 16:32, Anton Vinogradov wrote: > Artem, great! > > Some minors: > > >>> read operations become more costly for caches with backup copies. >>> > Since it makes sense only for cache with backups, can we say something > like > "read operations become at least 2 times costly since backups checked as > well" > > >>> for atomic caches, a consistency violation exception is thrown. >>> > ... after N checks, where N is 3 by default and can be set by > "IGNITE_NEAR_GET_MAX_REMAPS" system property. > > Also, need to mention that each found violation triggers event with type > == > org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes > org.apache.ignite.events.CacheConsistencyViolationEvent which should be > used for rechecking of repait results. > > On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov > > > wrote: > > >> Anton, >> >> Could you please review the page about Read Rapair? >> >> >> https://apacheignite.readme.io/docs/read-repair >> >> >> -Artem >> >> On 05.03.2020 12:20, Artem Budnikov wrote: >> >>> OK, I'll recreate it. >>> >>> Nikolay, please let me know when you are finished with the Metrics and >>> system views documentation. I'm done with the list of docs we >>> identified in this thread and want to publish v. 2.8. >>> >>> -Artem >>> >>> On 05.03.2020 11:55, Maxim Muzafarov wrote: >>> Artem, I've created that. It is not public and can be safely removed since it's a full copy of 2.7.6 (at that moment) On Thu, 5 Mar 2020 at 11:53, Artem Budnikov wrote: > Guys, > > I see that there is already version 2.8 for Ignite docs on readme.io. > Who created it and when? I've changed some pages under 2.7.6 version > without knowing that there is a newer version. > > -Artem > > On 05.03.2020 11:45, Artem Budnikov wrote: > >> I'm confused. Igor, could you please double check? >> >> -Artem >> >> On 05.03.2020 04:15, Ivan Pavlukhin wrote: >> That's right, only C++ and .NET clients have partition awareness >>> Are your sure? Was not the feature implemented for java thin client >>> in [1]? >>> >>> [1] >>> https://issues.apache.org/jira/browse/IGNITE-11898 >>> >>> >>> Best regards, >>> Ivan Pavlukhin >>> >>> ср, 4 мар. 2020 г. в 18:18, Denis Magda >>> >>> : >>> Maxim, Yes, it's preferable to have metrics pages fully completed even though the feature is an experimental state. We want to encourage to try it out and switch to the new APIs eventually. Without technical instructions available our users will have a hard time checking the new capabilities.
[jira] [Created] (IGNITE-12768) MetricRegistryMBean doesn't show histogram values in case when histogram name contains underscore character
Andrey N. Gura created IGNITE-12768:
---
Summary: MetricRegistryMBean doesn't show histogram values in case
when histogram name contains underscore character
Key: IGNITE-12768
URL: https://issues.apache.org/jira/browse/IGNITE-12768
Project: Ignite
Issue Type: Bug
Reporter: Andrey N. Gura
Fix For: 2.8.1
{{MetricRegistryMBean}} doesn't show histogram values in case when histogram
name contains underscore character.
The problem in {{MetricRegistryMBean.searchHistogram()}} method which relies on
first underscore character in the fully qualified metric name. This method also
use relatively old and not effective API for string parsing (this API
implementation is synchronized). It should be replaced by simple
{{String.lastIndexOf()}} for example.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Ignite 2.8 announcement plan
Anton, Does it mean that the PME is skipped only for cases when the native persistence is used and a failed node was in the baseline topology? How about pure in-memory clusters and clusters with CacheStore? - Denis On Tue, Mar 10, 2020 at 12:40 AM Anton Vinogradov wrote: > Denis, > > >> the blocking PME no longer happens if a node leaves the cluster > We should mention this should be the baseline node > > On Tue, Mar 10, 2020 at 9:40 AM Denis Magda wrote: > > > Pavel, thank you. I referred to your article from a blog post to be > > published on blogs.apache.org. Please feel free to share feedback before > > it's published. You can use the comment feature of Google Docs: > > > > > https://docs.google.com/document/d/1ssTC1Jf_reqZFWgl4ayhaohiAJCpzdL4tPrHTxvfvAM/edit?usp=sharing > > > > > > @Alexey Zinoviev , @Andrey Gura > > , @Nikolay Izhikov , @Anton > > Vinogradov could you glance at the paragraphs > mentioning > > the improvements you contributed to the release? I just want to be sure > my > > understanding is correct. > > > > - > > Denis > > > > > > On Mon, Mar 9, 2020 at 3:54 AM Pavel Tupitsyn > > wrote: > > > >> Published: https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.8/ > >> > >> On Sat, Mar 7, 2020 at 1:49 AM Pavel Tupitsyn > >> wrote: > >> > >> > Denis, ok, I'll publish on Monday afternoon then (UTC), weekend is not > >> the > >> > best time. > >> > > >> > Thanks, > >> > Pavel > >> > > >> > On Sat, Mar 7, 2020 at 1:25 AM Denis Magda wrote: > >> > > >> >> Pavel, > >> >> > >> >> Thanks for clarifying the way partition-awareness handles topology > >> >> changes. > >> >> > >> >> Please publish your article as soon as you're ready. I plan to finish > >> mine > >> >> on Monday-Tuesday and will refer to yours. > >> >> > >> >> - > >> >> Denis > >> >> > >> >> > >> >> On Fri, Mar 6, 2020 at 1:36 AM Pavel Tupitsyn > >> >> wrote: > >> >> > >> >> > Denis, thanks for the feedback! > >> >> > When should I publish the post? Right after official release > >> >> announcement, > >> >> > or later? > >> >> > > >> >> > > I would use "thick client" as a term instead of the "classic > >> client" > >> >> > Good point, fixed > >> >> > > >> >> > > partition-awareness doesn't handle topology changes automatically > >> >> > (partition map won't be updated on the client-side) > >> >> > This is not true, we keep the partition map up to date by checking > >> >> > AffinityTopologyVersion [1] > >> >> > > >> >> > > Now I can run Ignite.NET easily on my Mac OS machine > >> >> > Just to clarify, you can do that since 2.4 release [2]. > >> >> > In 2.8 we have refined build-related things (jar file handling), > and > >> >> made > >> >> > sure that recent .NET versions are supported. > >> >> > > >> >> > [1] > >> >> > > >> >> > > >> >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > >> >> > [2] https://habr.com/ru/company/gridgain/blog/347374/ (in Russian) > >> >> > > >> >> > On Fri, Mar 6, 2020 at 2:40 AM Denis Magda > >> wrote: > >> >> > > >> >> > > Pavel, thanks, > >> >> > > > >> >> > > I enjoyed reading the blog, crystal clear and straight to the > >> point! > >> >> > Please > >> >> > > consider these several items that might strengthen the article a > >> bit: > >> >> > > > >> >> > >- I would use "thick client" as a term instead of the "classic > >> >> client" > >> >> > >(and mention that Ignite.NET client is a thick one). The thick > >> >> client > >> >> > is > >> >> > >already a coined term that based on my observations are used a > >> lot > >> >> by > >> >> > > dev > >> >> > >and user communities. Also, you might add some differences of > >> thick > >> >> > vs. > >> >> > >thin taking from this page - > >> >> > > > >> >> > > > >> >> > > >> >> > >> > https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients > >> >> > >- Should we mention that presently partition-awareness doesn't > >> >> handle > >> >> > >topology changes automatically (partition map won't be updated > >> on > >> >> the > >> >> > >client-side)? This might be a blocker for some users. > >> >> > >- Excited to read about the cross-platform support, that's > huge! > >> >> Now I > >> >> > >can run Ignite.NET easily on my Mac OS machine. I would > insert a > >> >> > > reference > >> >> > >to updated documentation pages that explain how to start with > >> >> > > Ignite.NET on > >> >> > >various platforms. > >> >> > > > >> >> > > Hope, you will find this helpful, thanks for helping with project > >> >> > > promotion! > >> >> > > > >> >> > > - > >> >> > > Denis > >> >> > > > >> >> > > > >> >> > > On Thu, Mar 5, 2020 at 7:32 AM Pavel Tupitsyn < > >> ptupit...@apache.org> > >> >> > > wrote: > >> >> > > > >> >> > > > Denis, > >> >> > > > > >> >> > > > The first post is going to be ready soon, probably by tomorrow. > >> >> > > > Here is a draft, feedback welcome: > >> >> > > > > >> >> > > > > >> >> > > > >> >> > >
[jira] [Created] (IGNITE-12767) MetricRegistryMBean is not hread safe
Andrey N. Gura created IGNITE-12767:
---
Summary: MetricRegistryMBean is not hread safe
Key: IGNITE-12767
URL: https://issues.apache.org/jira/browse/IGNITE-12767
Project: Ignite
Issue Type: Improvement
Reporter: Andrey N. Gura
Fix For: 2.8.1
{{MetricRegistryMBean}} is not thread safe due to usage of {{histogramNames}}
instance of {{HashMap}} class. Changing {{HashMap}} to {{ConcurrentHashMap}}
will not help a lot (likely) because method
{{MetricUtils.histogramBucketNames()}} uses just {{put}} method
({{putIfAbsent}} will help I believe).
{{OpenCensusExporterSpi}} uses the same {{MetricUtils.histogramBucketNames()}}
method. But it isn't issue for this exporter because it is single threaded.
Also {{MetricUtils.histogramBucketNames()}} method is responsible for histogram
bucket's name representation. I believe that it is responsibility of metric
exporter and this method should be removed from {{MetricUtils}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12766) Node startup can be broken in case of using Local cache with persistence enabled.
Vyacheslav Koptilin created IGNITE-12766:
Summary: Node startup can be broken in case of using Local cache
with persistence enabled.
Key: IGNITE-12766
URL: https://issues.apache.org/jira/browse/IGNITE-12766
Project: Ignite
Issue Type: Bug
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.9
Trying to upgrade from the previous version of Apache Ignite (AI 2.7.6 for
example) may result in the following exception when Local cache is used and
persistence enabled.
{noformat}
[2020-03-05 16:47:39,222][ERROR][main][IgniteKernal] Exception during start
processors, node will be stopped and close connections[2020-03-05
16:47:39,222][ERROR][main][IgniteKernal] Exception during start processors,
node will be stopped and close connectionsclass
org.apache.ignite.IgniteCheckedException: An error occurred during cache
configuration loading from file [file=...] at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:965)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:907)
at
org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCaches(GridLocalConfigManager.java:171)
at
org.apache.ignite.internal.processors.cache.GridLocalConfigManager.restoreCacheConfigurations(GridLocalConfigManager.java:124)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5198)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:488)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:824)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:5378)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1286) at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2054)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1704)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1117) at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1035)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:820) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:690) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:659) at
org.apache.ignite.Ignition.start(Ignition.java:346) at
org.apache.ignite.examples.ExampleNodeStartup.main(ExampleNodeStartup.java:38)Caused
by: class org.apache.ignite.IgniteCheckedException: Failed to find class with
given class loader for unmarshalling (make sure same versions of all classes
are available on all nodes or enable peer-class-loading)
[clsLdr=sun.misc.Launcher$AppClassLoader@18b4aac2,
cls=org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction]
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:129)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
at
org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:961)
... 18 moreCaused by: java.lang.ClassNotFoundException:
org.apache.ignite.internal.processors.cache.GridCacheProcessor$LocalAffinityFunction
at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at
java.lang.ClassLoader.loadClass(ClassLoader.java:424) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at
java.lang.ClassLoader.loadClass(ClassLoader.java:357) at
java.lang.Class.forName0(Native Method) at
java.lang.Class.forName(Class.java:348) at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8870) at
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:59)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1826) at
java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1713) at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2000) at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535) at
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2245) at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2169) at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2027) at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535) at
Re: Slim binary release and docker image for Apache Ignite
Hello! I understand that procedures are courtesy Apache Ignite, but I assume that you went through them and can now repeat them reproducibly. Thank you! -- Ilya Kasnacheev вт, 10 мар. 2020 г. в 18:12, Maxim Muzafarov : > Ilya, > > It is not "mine" generic release procedures they are "ours" :-) > I've created the issue [1] based on current discussion thread. > > > [1] https://issues.apache.org/jira/browse/IGNITE-12765 > > On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev > wrote: > > > > Hello! > > > > It is currently included. > > > > Maxim, can you prepare a slim release package based on your generic > release > > procedures? We could take a look at it and then perhaps add it to > downloads > > page officially. > > > > What do you think? > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov : > > > > > Ilya, > > > > > > `ignite-compress` is necessary for `wal page snapshot compression` [1] > > > which in turn shows very good performance results. So, I suppose, it's > > > better to include it to the "slim" binary. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11336 > > > > > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > > wrote: > > > > > > > > Hello! > > > > > > > > I added these because they are infrastructural to Ignite, as opposed > to > > > > integrations. They are also both very slim. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < > > > > stephen.darling...@gridgain.com>: > > > > > > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know > very > > > few > > > > > people who use either. > > > > > > > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev < > ilya.kasnach...@gmail.com> > > > > > wrote: > > > > > > > > > > > > Hello! > > > > > > > > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* > > > > > > > > > > > > I have prepared assemblies for Apache Ignite slim packaging: > > > > > > https://github.com/apache/ignite/tree/ignite-slim > > > > > > > > > > > > It is based on ignite-2.8 > > > > > > > > > > > > You can build it with mvn initialize -Prelease,lgpl > > > > > -Dignite.edition=apache- > > > > > > ignite-slim after a normal release build. > > > > > > > > > > > > Please consider the contents of resulting > > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip > > > > > > It will be a 65M download as opposed to main 455M > apache-ignite-2.8.0 > > > > > > distribution. > > > > > > > > > > > > My suggestion is that we can publish it as a post-release step > since > > > it > > > > > > does not affect the release in any way. If we do, we should > probably > > > > > > indicate size for every kind of artifact in our download > section, so > > > our > > > > > > users can choose based on that information. > > > > > > > > > > > > The following modules are included: > > > > > > > > > > > > libs: > > > > > > core/shmem/jcache > > > > > > ignite-indexing > > > > > > ignite-spring > > > > > > > > > > > > libs/optional: > > > > > > ignite-compress ignite-kubernetes ignite-log4j2 > > > ignite-rest-http > > > > > > ignite-spring-data_2.2 > > > > > > ignite-jta ignite-log4j ignite-opencensus > ignite-slf4j > > > > > > ignite-urideploy > > > > > > > > > > > > I have kept examples, but removed benchmarks. sqlline still > present, > > > of > > > > > > course. > > > > > > > > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not > > > update > > > > > > often enough (such as guava, curator, jackson), and which may > form an > > > > > > attack surface. > > > > > > > > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users, > since > > > > > they > > > > > > can re-import these dependencies with more recent versions using > > > maven or > > > > > > gradle. > > > > > > But for our users who rely on binary package for all JARs, > outdated > > > > > > dependencies may pose a problem. > > > > > > > > > > > > Therefore my opinion is to exclude this dependency and not put > our > > > faith > > > > > on > > > > > > zookeeper dependency version. > > > > > > > > > > > > The same can be put for ignite-compress, and indeed, I'm not > sure if > > > we > > > > > > should keep it. > > > > > > > > > > > > We can have an ad-hoc vote here. > > > > > > > > > > > > I would like to hear arguments for both inclusion and exclusion > of > > > > > > ignite-zookeeper and ignite-compress into slim package (in any > > > > > combination). > > > > > > > > > > > > I would also like to know if you want a formal vote on the issue. > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda : > > > > > > > > > > > >> Alex, could you please list all the modules that will be > excluded? > > > It > > > > > will > > > > > >> help to confirm we haven't dumped anything essential. > > > > > >> > >
Re: Slim binary release and docker image for Apache Ignite
Ilya, It is not "mine" generic release procedures they are "ours" :-) I've created the issue [1] based on current discussion thread. [1] https://issues.apache.org/jira/browse/IGNITE-12765 On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev wrote: > > Hello! > > It is currently included. > > Maxim, can you prepare a slim release package based on your generic release > procedures? We could take a look at it and then perhaps add it to downloads > page officially. > > What do you think? > > Regards, > -- > Ilya Kasnacheev > > > пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov : > > > Ilya, > > > > `ignite-compress` is necessary for `wal page snapshot compression` [1] > > which in turn shows very good performance results. So, I suppose, it's > > better to include it to the "slim" binary. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-11336 > > > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev > > wrote: > > > > > > Hello! > > > > > > I added these because they are infrastructural to Ignite, as opposed to > > > integrations. They are also both very slim. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < > > > stephen.darling...@gridgain.com>: > > > > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very > > few > > > > people who use either. > > > > > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev > > > > wrote: > > > > > > > > > > Hello! > > > > > > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* > > > > > > > > > > I have prepared assemblies for Apache Ignite slim packaging: > > > > > https://github.com/apache/ignite/tree/ignite-slim > > > > > > > > > > It is based on ignite-2.8 > > > > > > > > > > You can build it with mvn initialize -Prelease,lgpl > > > > -Dignite.edition=apache- > > > > > ignite-slim after a normal release build. > > > > > > > > > > Please consider the contents of resulting > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip > > > > > It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 > > > > > distribution. > > > > > > > > > > My suggestion is that we can publish it as a post-release step since > > it > > > > > does not affect the release in any way. If we do, we should probably > > > > > indicate size for every kind of artifact in our download section, so > > our > > > > > users can choose based on that information. > > > > > > > > > > The following modules are included: > > > > > > > > > > libs: > > > > > core/shmem/jcache > > > > > ignite-indexing > > > > > ignite-spring > > > > > > > > > > libs/optional: > > > > > ignite-compress ignite-kubernetes ignite-log4j2 > > ignite-rest-http > > > > > ignite-spring-data_2.2 > > > > > ignite-jta ignite-log4j ignite-opencensus ignite-slf4j > > > > > ignite-urideploy > > > > > > > > > > I have kept examples, but removed benchmarks. sqlline still present, > > of > > > > > course. > > > > > > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not > > update > > > > > often enough (such as guava, curator, jackson), and which may form an > > > > > attack surface. > > > > > > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users, since > > > > they > > > > > can re-import these dependencies with more recent versions using > > maven or > > > > > gradle. > > > > > But for our users who rely on binary package for all JARs, outdated > > > > > dependencies may pose a problem. > > > > > > > > > > Therefore my opinion is to exclude this dependency and not put our > > faith > > > > on > > > > > zookeeper dependency version. > > > > > > > > > > The same can be put for ignite-compress, and indeed, I'm not sure if > > we > > > > > should keep it. > > > > > > > > > > We can have an ad-hoc vote here. > > > > > > > > > > I would like to hear arguments for both inclusion and exclusion of > > > > > ignite-zookeeper and ignite-compress into slim package (in any > > > > combination). > > > > > > > > > > I would also like to know if you want a formal vote on the issue. > > > > > > > > > > Regards, > > > > > -- > > > > > Ilya Kasnacheev > > > > > > > > > > > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda : > > > > > > > > > >> Alex, could you please list all the modules that will be excluded? > > It > > > > will > > > > >> help to confirm we haven't dumped anything essential. > > > > >> > > > > >> - > > > > >> Denis > > > > >> > > > > >> > > > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < > > > > >> alexey.goncha...@gmail.com> wrote: > > > > >> > > > > >>> Got it, sounds good! > > > > >>> Should we consider the list of modules included in the slim package > > > > >>> finalized? > > > > >>> > > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego : > > > > >>> > > > > 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
[jira] [Created] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
Maxim Muzafarov created IGNITE-12765:
Summary: Slim binary release and docker image for Apache Ignite
Key: IGNITE-12765
URL: https://issues.apache.org/jira/browse/IGNITE-12765
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Fix For: 2.8.1
1. Prepare Apache Ignite "slim" distribution (example:
https://github.com/apache/ignite/tree/ignite-slim)
2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
according to a new additional package distribution.
See - discussion on dev-list
http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
{code}
libs:
core/shmem/jcache
ignite-indexing
ignite-spring
libs/optional:
ignite-compress
ignite-kubernetes
ignite-log4j2
ignite-rest-http
ignite-spring-data_2.2
ignite-jta ignite-log4j ignite-opencensus ignite-slf4j
ignite-urideploy
* ignite-core
* ignite-indexing
* ignite-rest-http
* ignite-spring
* ignite-log4j
* ignite-log4j2
* ignite-slf4j
* ignite-urideploy
* ignite-kubernetes
* ignite-opencensus
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12764) Regression: Thin JDBC streaming fails/BatchUpdateException if function is used
Ilya Kasnacheev created IGNITE-12764: Summary: Regression: Thin JDBC streaming fails/BatchUpdateException if function is used Key: IGNITE-12764 URL: https://issues.apache.org/jira/browse/IGNITE-12764 Project: Ignite Issue Type: Bug Reporter: Ilya Kasnacheev insert INTO city1(id,name,name1) VALUES(?,?,RANDOM_UUID()) happily worked in 2.7.6 but will fail on 2.8.0 with: Exception in thread "main" java.sql.BatchUpdateException: class org.apache.ignite.IgniteCheckedException: null at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1364) at java.base/java.lang.Thread.run(Thread.java:834) Suspected reason is that function RANDOM_UUID() is not processed correctly here. Column type does not matter between UUID and VARCHAR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
System view for compute jobs
Hello, Igniters. I prepared a PR for the new system view - JOBS. [1]. Ticket [2] For now, as you may know, internally we have two processors that implement compute feature: * `GridTaskProcessor` - manage locally started compute tasks. * `GridJobProcessor` - manage compute jobs that should be executed on the local node as a part of some remote compute task. We have TASKS system view that exposes locally started compute tasks from `GridTaskProcessor` to the user. But we don’t have the ability to view JOBS that executed on the node in the `GridJobProcessor`. PR should fill this gap. Is there any IgniteCompute who can make the review? [1] https://github.com/apache/ignite/pull/7495 [2] https://issues.apache.org/jira/browse/IGNITE-12745
[jira] [Created] (IGNITE-12763) OpenCensus integration example.
Nikolay Izhikov created IGNITE-12763: Summary: OpenCensus integration example. Key: IGNITE-12763 URL: https://issues.apache.org/jira/browse/IGNITE-12763 Project: Ignite Issue Type: Sub-task Reporter: Nikolay Izhikov We should provide to the user simple self-explaining example of the integration with the opencensus. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Workaround for possible NPE in Selector.open()
Hello! Feel free to file a ticket, contribute a fix. Regards, -- Ilya Kasnacheev вт, 10 мар. 2020 г. в 16:38, Seliverstov Igor : > Hi Igniters, > > Today I noticed quite old code aimed to workaround an old bug in 1.5 JDK > revision which was fixed in rev 1.7 > > org/apache/ignite/internal/util/nio/GridNioServer.java:161 > > Since we widely use lambdas now (so Ignite requires at least Java 1.8) do > we really need it now? > > I would like to remove it. > > Regards, > Igor
Workaround for possible NPE in Selector.open()
Hi Igniters, Today I noticed quite old code aimed to workaround an old bug in 1.5 JDK revision which was fixed in rev 1.7 org/apache/ignite/internal/util/nio/GridNioServer.java:161 Since we widely use lambdas now (so Ignite requires at least Java 1.8) do we really need it now? I would like to remove it. Regards, Igor
[jira] [Created] (IGNITE-12762) PHP: Thin client: Transactions
Alexander Kovalev created IGNITE-12762: -- Summary: PHP: Thin client: Transactions Key: IGNITE-12762 URL: https://issues.apache.org/jira/browse/IGNITE-12762 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Alexander Kovalev dear colleagues, could you explain when in https://apacheignite.readme.io/docs/php-thin-client transaction support will be enabled? I found an implementation for other languages, but support is needed specifically for PHP -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.
Philipp Masharov created IGNITE-12761: - Summary: Add ability to disable check crc sums of stored pages due to invalidate_indexes. Key: IGNITE-12761 URL: https://issues.apache.org/jira/browse/IGNITE-12761 Project: Ignite Issue Type: Bug Reporter: Philipp Masharov Assignee: Philipp Masharov Add additional param to validate_indexes command org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like here: org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC now by default this check is always enabled, need to be configurable like the same one in IdleVerifyCommandArg -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Ignite 2.8 documentation
Hi Nikolay, I looked through the metrics pages and found a couple of minor issues: * Looks like this sentence should contain a link to somewhere: "Please, see XXX as an example and OpenCensus documentation for additional information." * Please mention that for the OpenCensus exporter to work, the module should be enabled. * Also, there is no information on how to specify a filter via configuration. -Artem On 10.03.2020 12:50, Maxim Muzafarov wrote: Folks, It seems everything is ready to go and only minor issues left with documentation. Are we ready to announce 2.8 release widely? On Tue, 10 Mar 2020 at 12:10, Nikolay Izhikov wrote: Hello, Igniters. I rewrote pages about new metrics and system views. Please, take a look. https://apacheignite.readme.io/docs/new-metrics https://apacheignite.readme.io/docs/system-views https://issues.apache.org/jira/browse/IGNITE-12408 6 марта 2020 г., в 16:40, Artem Budnikov написал(а): Anton, Thanks for the feedback. I updated the page. -Artem On 05.03.2020 16:32, Anton Vinogradov wrote: Artem, great! Some minors: read operations become more costly for caches with backup copies. Since it makes sense only for cache with backups, can we say something like "read operations become at least 2 times costly since backups checked as well" for atomic caches, a consistency violation exception is thrown. ... after N checks, where N is 3 by default and can be set by "IGNITE_NEAR_GET_MAX_REMAPS" system property. Also, need to mention that each found violation triggers event with type == org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes org.apache.ignite.events.CacheConsistencyViolationEvent which should be used for rechecking of repait results. On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov wrote: Anton, Could you please review the page about Read Rapair? https://apacheignite.readme.io/docs/read-repair -Artem On 05.03.2020 12:20, Artem Budnikov wrote: OK, I'll recreate it. Nikolay, please let me know when you are finished with the Metrics and system views documentation. I'm done with the list of docs we identified in this thread and want to publish v. 2.8. -Artem On 05.03.2020 11:55, Maxim Muzafarov wrote: Artem, I've created that. It is not public and can be safely removed since it's a full copy of 2.7.6 (at that moment) On Thu, 5 Mar 2020 at 11:53, Artem Budnikov wrote: Guys, I see that there is already version 2.8 for Ignite docs on readme.io. Who created it and when? I've changed some pages under 2.7.6 version without knowing that there is a newer version. -Artem On 05.03.2020 11:45, Artem Budnikov wrote: I'm confused. Igor, could you please double check? -Artem On 05.03.2020 04:15, Ivan Pavlukhin wrote: That's right, only C++ and .NET clients have partition awareness Are your sure? Was not the feature implemented for java thin client in [1]? [1]https://issues.apache.org/jira/browse/IGNITE-11898 Best regards, Ivan Pavlukhin ср, 4 мар. 2020 г. в 18:18, Denis Magda: Maxim, Yes, it's preferable to have metrics pages fully completed even though the feature is an experimental state. We want to encourage to try it out and switch to the new APIs eventually. Without technical instructions available our users will have a hard time checking the new capabilities. Nikolay, thanks a lot! - Denis On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov I think yes. I will prepare documentation shortly. 4 марта 2020 г., в 17:50, Maxim Muzafarov написал(а): Folks, Do we need a fully complete public documentation for metrics marked with @ExperimentalFeature? The API can significantly be changed. On Wed, 4 Mar 2020 at 17:10, Artem Budnikov wrote: The only feature that is left is "WAL page compression" The three other features are limitations that were present in Ignite 2.7 and now they are removed. Since they were never mentioned in the docs, there is nothing to do. -Artem On 04.03.2020 17:02, Denis Magda wrote: I'll work on the following items today and tomorrow: - JDBC: Support for query cancellation - JDBC: Support for query timeout - suspend/resume for pessimistic transactions - WAL page compression Artem, are these the only tickets left apart from the metrics & monitoring? @Nikolay Izhikov how soon will you be able to finish the metrics documentation pages? - Denis On Wed, Mar 4, 2020 at 2:55 AM Artem Budnikov wrote: Hi everyone, I have created the docs for the following items so far: -Default Ignite work dir location https://apacheignite.readme.io/docs/getting-started-28#section-setting-up-work-directory - Baseline auto-adjust feature https://apacheignite.readme.io/docs/baseline-topology-28#section-baseline-topology-autoadjustment - Cluster (de)activation events documentation https://apacheignite.readme.io/docs/baseline-topology-28#section-cluster-activationdeactivation-events -
[jira] [Created] (IGNITE-12760) Prevent AssertionError on message unmarshalling, when classLoaderId contains id of node that already left
Denis Chudov created IGNITE-12760:
-
Summary: Prevent AssertionError on message unmarshalling, when
classLoaderId contains id of node that already left
Key: IGNITE-12760
URL: https://issues.apache.org/jira/browse/IGNITE-12760
Project: Ignite
Issue Type: Bug
Reporter: Denis Chudov
Assignee: Denis Chudov
Following assertion error triggers failure handler and crashes the node. Can
possibly crash the whole cluster.
{code:java}
2020-02-18
14:34:09.775\[ERROR]\[query-#146129%DPL_GRID%DplGridNodeName%]\[o.a.i.i.p.cache.GridCacheIoManager]
Failed to process message \[senderId=727757ed-4ad4-4779-bda9-081525725cce,
msg=GridCacheQueryRequest \[id=178,
cacheName=com.sbt.tokenization.data.entity.KEKEntity_DPL_union-module,
type=SCAN, fields=false, clause=null, clsName=null, keyValFilter=null,
rdc=null, trans=null, pageSize=1024, incBackups=false, cancel=false,
incMeta=false, all=false, keepBinary=true,
subjId=727757ed-4ad4-4779-bda9-081525725cce, taskHash=0, part=-1,
topVer=AffinityTopologyVersion \[topVer=97, minorTopVer=0], sendTimestamp=-1,
receiveTimestamp=-1, super=GridCacheIdMessage \[cacheId=-1129073400,
super=GridCacheMessage \[msgId=179, depInfo=GridDeploymentInfoBean
\[clsLdrId=c32670e3071-d30ee64b-0833-45d4-abbe-fb6282669caa, depMode=SHARED,
userVer=0, locDepOwner=false, participants=null],
lastAffChangedTopVer=AffinityTopologyVersion \[topVer=8, minorTopVer=6],
err=null, skipPrepare=false
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:918)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager$CachedDeploymentInfo.(GridCacheDeploymentManager.java:889)
at
org.apache.ignite.internal.processors.cache.GridCacheDeploymentManager.p2pContext(GridCacheDeploymentManager.java:422)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1576)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:584)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:386)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:312)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:102)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:301)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1565)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4300(GridIoManager.java:130)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1092)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748){code}
There is no fair reproducer for now, but it seems that we should prevent such
situation in general like following:
1) check the correctness of the message before it will be sent - inside of
GridCacheDeploymentManager#prepare. If we have the corresponding class loader
on local node, we can try to fix message and replace wrong class loader with
local one.
2) log suspicious deployments which we receive from
GridDeploymentManager#deploy - maybe we have obsolete deployments in caches.
3) possibly we can remove this assertion, we should have this class on sender
node and use it as class loader id, and if we don't, we will receive exception
on finishUnmarshall (Failed to peer load class) and try to process this
situation with GridCacheIoManager#processFailedMessage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Security Subject of thin client on remote nodes
Hello! Please avoid targeting feature tickets on 2.8.1 by default. As far as my understanding goes, plan for 2.8.1 is to be a bugfix release with specific changes cherry picked, so new features are unlikely to be included, and should be negotiated with person responsible for this release before being included in scope. Regards, -- Ilya Kasnacheev вт, 10 мар. 2020 г. в 12:00, Denis Garus : > Hi guys! > I created the iep ticket [1] and started work. > > 1. https://issues.apache.org/jira/browse/IGNITE-12759 > > чт, 5 мар. 2020 г. в 12:00, Denis Garus : > > > Hi, guys! > > > > > > I've prepared the IEP-41: Security Context of a thin client on remote > > nodes [1]; take a look, please. > > > > If there aren't any questions, I could create an issue and start work. > > > > > > Ivan, could you be an IEP sponsor? > > > > > > Thx! > > > > > > > >1. > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-41%3A+Security+Context+of+a+thin+client+on+remote+nodes > > > > > > ср, 26 февр. 2020 г. в 12:42, Mikhail Petrov : > > > >> Hi, Alexei. > >> > >> The ticket [1] describes the general problem for all thin client > >> authorizations. Its particular case is described in the mentioned in [1] > >> ticket [2] on the example of a JDBC client with the reproducer > attached. > >> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12589 > >> [2] https://issues.apache.org/jira/browse/IGNITE-12579 > >> > >> On 26.02.2020 11:47, Alexei Scherbakov wrote: > >> > Denis Garus, > >> > > >> > It is forbidden to remove any public IGNITE attribute without proper > >> > deprecation steps. > >> > > >> > I have read the thread and still do not clearly see the problem. The > >> subject id > >> > is not required to be a node id. > >> > > >> > The referenced in the thread ticket [1] do not provide any > reproducers. > >> > > >> > Can you properly demonstrate a broken scenario ? > >> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12589 > >> > > >> > пт, 21 февр. 2020 г. в 13:35, Andrey Kuznetsov : > >> > > >> >> Hi, guys! > >> >> > >> >> The change suggested by Denis looks robust to me: it covers security > >> >> subject handling by all kinds of clients/nodes at once. As for > >> >> ATTR_SECURITY_SUBJECT_V2 attribute, it is really better to move it to > >> >> plugin implementations to support backward compatibility with peer > >> nodes of > >> >> older versions. Obviously, cluster with security disabled will not > >> suffer > >> >> from attribute removal. Ignite core should know nothing about the > >> specific > >> >> way of security context propagation. > >> >> > >> >> Denis, could you please create Jira issue for your change? > >> >> > >> >> чт, 20 февр. 2020 г. в 17:01, Denis Garus : > >> >> > >> I just transmitted security subjects for rest requests. > >> >>> SecurityContext has an unlimited size so we can get significant > >> overhead. > >> >>> And we do not solve problems with other thin clients. > >> >>> > >> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility > >> between > >> >>> old > >> >>> versions and new. > >> >>> > >> >>> I suggest removing ATTR_SECURITY_SUBJECT_V2 from Ignite's codebase, > >> but > >> >> for > >> >>> compatibility, it can be used by a security plugin like in PoC. > >> >>> > >> >>> чт, 20 февр. 2020 г. в 16:47, Maksim Stepachev < > >> >> maksim.stepac...@gmail.com > >> : > >> Yes, I said about it at 07.19. > >> > >> > >> >> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708 > >> And in my solution, I just transmitted security subjects for rest > >> >>> requests. > >> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility > >> between > >> >>> old > >> versions and new. > >> > >> чт, 20 февр. 2020 г. в 15:56, Denis Garus : > >> > >> > Hi, Igniters! > >> > > >> > > >> > At present, a security subject id is assumed to be node id. > >> > > >> > But when we are dealing with thin client, JDBC or REST subject id > is > >> random > >> > UUID. In this case, we cannot get the subject information on a > >> remote > >> node, > >> > and we get problems like these [1], [2]. > >> > > >> > To fix the problem, we should spread the client session to the > whole > >> > cluster. > >> > > >> > > >> > I want to suggest a solution to the problem. > >> > > >> > > >> > First, we should get subject information using > >> GridSecurityProcessor. > >> > > >> > How GridSecurityProcessor will retrieve a subject data, it is up > to > >> plugin > >> > developers. > >> > > >> > > >> > Second, we should get rid of the assumption that a subject id is a > >> >> node > >> id > >> > and remove the ATTR_SECURITY_SUBJECT_V2 attribute. > >> > > >> > > >> > I have prepared PoC PR [3] that: > >> > > >> > - places the existing logic of
Re: Slim binary release and docker image for Apache Ignite
Hello! It is currently included. Maxim, can you prepare a slim release package based on your generic release procedures? We could take a look at it and then perhaps add it to downloads page officially. What do you think? Regards, -- Ilya Kasnacheev пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov : > Ilya, > > `ignite-compress` is necessary for `wal page snapshot compression` [1] > which in turn shows very good performance results. So, I suppose, it's > better to include it to the "slim" binary. > > [1] https://issues.apache.org/jira/browse/IGNITE-11336 > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev > wrote: > > > > Hello! > > > > I added these because they are infrastructural to Ignite, as opposed to > > integrations. They are also both very slim. > > > > Regards, > > -- > > Ilya Kasnacheev > > > > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < > > stephen.darling...@gridgain.com>: > > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very > few > > > people who use either. > > > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev > > > wrote: > > > > > > > > Hello! > > > > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* > > > > > > > > I have prepared assemblies for Apache Ignite slim packaging: > > > > https://github.com/apache/ignite/tree/ignite-slim > > > > > > > > It is based on ignite-2.8 > > > > > > > > You can build it with mvn initialize -Prelease,lgpl > > > -Dignite.edition=apache- > > > > ignite-slim after a normal release build. > > > > > > > > Please consider the contents of resulting > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip > > > > It will be a 65M download as opposed to main 455M apache-ignite-2.8.0 > > > > distribution. > > > > > > > > My suggestion is that we can publish it as a post-release step since > it > > > > does not affect the release in any way. If we do, we should probably > > > > indicate size for every kind of artifact in our download section, so > our > > > > users can choose based on that information. > > > > > > > > The following modules are included: > > > > > > > > libs: > > > > core/shmem/jcache > > > > ignite-indexing > > > > ignite-spring > > > > > > > > libs/optional: > > > > ignite-compress ignite-kubernetes ignite-log4j2 > ignite-rest-http > > > > ignite-spring-data_2.2 > > > > ignite-jta ignite-log4j ignite-opencensus ignite-slf4j > > > > ignite-urideploy > > > > > > > > I have kept examples, but removed benchmarks. sqlline still present, > of > > > > course. > > > > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not > update > > > > often enough (such as guava, curator, jackson), and which may form an > > > > attack surface. > > > > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users, since > > > they > > > > can re-import these dependencies with more recent versions using > maven or > > > > gradle. > > > > But for our users who rely on binary package for all JARs, outdated > > > > dependencies may pose a problem. > > > > > > > > Therefore my opinion is to exclude this dependency and not put our > faith > > > on > > > > zookeeper dependency version. > > > > > > > > The same can be put for ignite-compress, and indeed, I'm not sure if > we > > > > should keep it. > > > > > > > > We can have an ad-hoc vote here. > > > > > > > > I would like to hear arguments for both inclusion and exclusion of > > > > ignite-zookeeper and ignite-compress into slim package (in any > > > combination). > > > > > > > > I would also like to know if you want a formal vote on the issue. > > > > > > > > Regards, > > > > -- > > > > Ilya Kasnacheev > > > > > > > > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda : > > > > > > > >> Alex, could you please list all the modules that will be excluded? > It > > > will > > > >> help to confirm we haven't dumped anything essential. > > > >> > > > >> - > > > >> Denis > > > >> > > > >> > > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < > > > >> alexey.goncha...@gmail.com> wrote: > > > >> > > > >>> Got it, sounds good! > > > >>> Should we consider the list of modules included in the slim package > > > >>> finalized? > > > >>> > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego : > > > >>> > > > 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
Re: Ignite 2.8 documentation
Folks, It seems everything is ready to go and only minor issues left with documentation. Are we ready to announce 2.8 release widely? On Tue, 10 Mar 2020 at 12:10, Nikolay Izhikov wrote: > > Hello, Igniters. > > I rewrote pages about new metrics and system views. > Please, take a look. > > https://apacheignite.readme.io/docs/new-metrics > https://apacheignite.readme.io/docs/system-views > > https://issues.apache.org/jira/browse/IGNITE-12408 > > > > 6 марта 2020 г., в 16:40, Artem Budnikov > > написал(а): > > > > Anton, > > > > Thanks for the feedback. I updated the page. > > > > -Artem > > > > On 05.03.2020 16:32, Anton Vinogradov wrote: > >> Artem, great! > >> > >> Some minors: > >> > read operations become more costly for caches with backup copies. > >> Since it makes sense only for cache with backups, can we say something like > >> "read operations become at least 2 times costly since backups checked as > >> well" > >> > for atomic caches, a consistency violation exception is thrown. > >> ... after N checks, where N is 3 by default and can be set by > >> "IGNITE_NEAR_GET_MAX_REMAPS" system property. > >> > >> Also, need to mention that each found violation triggers event with type == > >> org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes > >> org.apache.ignite.events.CacheConsistencyViolationEvent which should be > >> used for rechecking of repait results. > >> > >> On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov > >> wrote: > >> > >>> Anton, > >>> > >>> Could you please review the page about Read Rapair? > >>> > >>> https://apacheignite.readme.io/docs/read-repair > >>> > >>> -Artem > >>> > >>> On 05.03.2020 12:20, Artem Budnikov wrote: > OK, I'll recreate it. > > Nikolay, please let me know when you are finished with the Metrics and > system views documentation. I'm done with the list of docs we > identified in this thread and want to publish v. 2.8. > > -Artem > > On 05.03.2020 11:55, Maxim Muzafarov wrote: > > Artem, > > > > I've created that. It is not public and can be safely removed since > > it's a full copy of 2.7.6 (at that moment) > > > > On Thu, 5 Mar 2020 at 11:53, Artem Budnikov > > wrote: > >> Guys, > >> > >> I see that there is already version 2.8 for Ignite docs on readme.io. > >> Who created it and when? I've changed some pages under 2.7.6 version > >> without knowing that there is a newer version. > >> > >> -Artem > >> > >> On 05.03.2020 11:45, Artem Budnikov wrote: > >>> I'm confused. Igor, could you please double check? > >>> > >>> -Artem > >>> > >>> On 05.03.2020 04:15, Ivan Pavlukhin wrote: > > That's right, only C++ and .NET clients have partition awareness > Are your sure? Was not the feature implemented for java thin client > in [1]? > > [1] https://issues.apache.org/jira/browse/IGNITE-11898 > > Best regards, > Ivan Pavlukhin > > ср, 4 мар. 2020 г. в 18:18, Denis Magda : > > Maxim, > > > > Yes, it's preferable to have metrics pages fully completed even > > though the > > feature is an experimental state. We want to encourage to try it out > > and > > switch to the new APIs eventually. Without technical instructions > > available > > our users will have a hard time checking the new capabilities. > > > > Nikolay, thanks a lot! > > > > - > > Denis > > > > > > On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov > wrote: > > > >> I think yes. > >> > >> I will prepare documentation shortly. > >> > >>> 4 марта 2020 г., в 17:50, Maxim Muzafarov > >> написал(а): > >>> Folks, > >>> > >>> > >>> Do we need a fully complete public documentation for metrics > >>> marked > >>> with @ExperimentalFeature? The API can significantly be changed. > >>> > >>> On Wed, 4 Mar 2020 at 17:10, Artem Budnikov > >>> > >> wrote: > The only feature that is left is "WAL page compression" > > The three other features are limitations that were present in > Ignite > 2.7 and now they are removed. Since they were never mentioned > in the > docs, there is nothing to do. > > -Artem > > On 04.03.2020 17:02, Denis Magda wrote: > >> I'll work on the following items today and tomorrow: > >> > >> - JDBC: Support for query cancellation > >> > >> > >> - JDBC: Support for query timeout > >> > >> > >> - suspend/resume for
Re: Ignite 2.8 documentation
Hello, Igniters. I rewrote pages about new metrics and system views. Please, take a look. https://apacheignite.readme.io/docs/new-metrics https://apacheignite.readme.io/docs/system-views https://issues.apache.org/jira/browse/IGNITE-12408 > 6 марта 2020 г., в 16:40, Artem Budnikov > написал(а): > > Anton, > > Thanks for the feedback. I updated the page. > > -Artem > > On 05.03.2020 16:32, Anton Vinogradov wrote: >> Artem, great! >> >> Some minors: >> read operations become more costly for caches with backup copies. >> Since it makes sense only for cache with backups, can we say something like >> "read operations become at least 2 times costly since backups checked as >> well" >> for atomic caches, a consistency violation exception is thrown. >> ... after N checks, where N is 3 by default and can be set by >> "IGNITE_NEAR_GET_MAX_REMAPS" system property. >> >> Also, need to mention that each found violation triggers event with type == >> org.apache.ignite.events.EventType#EVT_CONSISTENCY_VIOLATION includes >> org.apache.ignite.events.CacheConsistencyViolationEvent which should be >> used for rechecking of repait results. >> >> On Thu, Mar 5, 2020 at 3:51 PM Artem Budnikov >> wrote: >> >>> Anton, >>> >>> Could you please review the page about Read Rapair? >>> >>> https://apacheignite.readme.io/docs/read-repair >>> >>> -Artem >>> >>> On 05.03.2020 12:20, Artem Budnikov wrote: OK, I'll recreate it. Nikolay, please let me know when you are finished with the Metrics and system views documentation. I'm done with the list of docs we identified in this thread and want to publish v. 2.8. -Artem On 05.03.2020 11:55, Maxim Muzafarov wrote: > Artem, > > I've created that. It is not public and can be safely removed since > it's a full copy of 2.7.6 (at that moment) > > On Thu, 5 Mar 2020 at 11:53, Artem Budnikov > wrote: >> Guys, >> >> I see that there is already version 2.8 for Ignite docs on readme.io. >> Who created it and when? I've changed some pages under 2.7.6 version >> without knowing that there is a newer version. >> >> -Artem >> >> On 05.03.2020 11:45, Artem Budnikov wrote: >>> I'm confused. Igor, could you please double check? >>> >>> -Artem >>> >>> On 05.03.2020 04:15, Ivan Pavlukhin wrote: > That's right, only C++ and .NET clients have partition awareness Are your sure? Was not the feature implemented for java thin client in [1]? [1] https://issues.apache.org/jira/browse/IGNITE-11898 Best regards, Ivan Pavlukhin ср, 4 мар. 2020 г. в 18:18, Denis Magda : > Maxim, > > Yes, it's preferable to have metrics pages fully completed even > though the > feature is an experimental state. We want to encourage to try it out > and > switch to the new APIs eventually. Without technical instructions > available > our users will have a hard time checking the new capabilities. > > Nikolay, thanks a lot! > > - > Denis > > > On Wed, Mar 4, 2020 at 8:52 AM Nikolay Izhikov wrote: > >> I think yes. >> >> I will prepare documentation shortly. >> >>> 4 марта 2020 г., в 17:50, Maxim Muzafarov >> написал(а): >>> Folks, >>> >>> >>> Do we need a fully complete public documentation for metrics >>> marked >>> with @ExperimentalFeature? The API can significantly be changed. >>> >>> On Wed, 4 Mar 2020 at 17:10, Artem Budnikov >>> >> wrote: The only feature that is left is "WAL page compression" The three other features are limitations that were present in Ignite 2.7 and now they are removed. Since they were never mentioned in the docs, there is nothing to do. -Artem On 04.03.2020 17:02, Denis Magda wrote: >> I'll work on the following items today and tomorrow: >> >> - JDBC: Support for query cancellation >> >> >> - JDBC: Support for query timeout >> >> >> - suspend/resume for pessimistic transactions >> >> >> - WAL page compression >> >> > Artem, are these the only tickets left apart from the metrics & > monitoring? @Nikolay > Izhikov how soon will you be able to > finish the > metrics documentation pages? > > - > Denis >
Re: Security Subject of thin client on remote nodes
Hi guys! I created the iep ticket [1] and started work. 1. https://issues.apache.org/jira/browse/IGNITE-12759 чт, 5 мар. 2020 г. в 12:00, Denis Garus : > Hi, guys! > > > I've prepared the IEP-41: Security Context of a thin client on remote > nodes [1]; take a look, please. > > If there aren't any questions, I could create an issue and start work. > > > Ivan, could you be an IEP sponsor? > > > Thx! > > > >1. > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-41%3A+Security+Context+of+a+thin+client+on+remote+nodes > > > ср, 26 февр. 2020 г. в 12:42, Mikhail Petrov : > >> Hi, Alexei. >> >> The ticket [1] describes the general problem for all thin client >> authorizations. Its particular case is described in the mentioned in [1] >> ticket [2] on the example of a JDBC client with the reproducer attached. >> >> [1] https://issues.apache.org/jira/browse/IGNITE-12589 >> [2] https://issues.apache.org/jira/browse/IGNITE-12579 >> >> On 26.02.2020 11:47, Alexei Scherbakov wrote: >> > Denis Garus, >> > >> > It is forbidden to remove any public IGNITE attribute without proper >> > deprecation steps. >> > >> > I have read the thread and still do not clearly see the problem. The >> subject id >> > is not required to be a node id. >> > >> > The referenced in the thread ticket [1] do not provide any reproducers. >> > >> > Can you properly demonstrate a broken scenario ? >> > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12589 >> > >> > пт, 21 февр. 2020 г. в 13:35, Andrey Kuznetsov : >> > >> >> Hi, guys! >> >> >> >> The change suggested by Denis looks robust to me: it covers security >> >> subject handling by all kinds of clients/nodes at once. As for >> >> ATTR_SECURITY_SUBJECT_V2 attribute, it is really better to move it to >> >> plugin implementations to support backward compatibility with peer >> nodes of >> >> older versions. Obviously, cluster with security disabled will not >> suffer >> >> from attribute removal. Ignite core should know nothing about the >> specific >> >> way of security context propagation. >> >> >> >> Denis, could you please create Jira issue for your change? >> >> >> >> чт, 20 февр. 2020 г. в 17:01, Denis Garus : >> >> >> I just transmitted security subjects for rest requests. >> >>> SecurityContext has an unlimited size so we can get significant >> overhead. >> >>> And we do not solve problems with other thin clients. >> >>> >> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility >> between >> >>> old >> >>> versions and new. >> >>> >> >>> I suggest removing ATTR_SECURITY_SUBJECT_V2 from Ignite's codebase, >> but >> >> for >> >>> compatibility, it can be used by a security plugin like in PoC. >> >>> >> >>> чт, 20 февр. 2020 г. в 16:47, Maksim Stepachev < >> >> maksim.stepac...@gmail.com >> : >> Yes, I said about it at 07.19. >> >> >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708 >> And in my solution, I just transmitted security subjects for rest >> >>> requests. >> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility >> between >> >>> old >> versions and new. >> >> чт, 20 февр. 2020 г. в 15:56, Denis Garus : >> >> > Hi, Igniters! >> > >> > >> > At present, a security subject id is assumed to be node id. >> > >> > But when we are dealing with thin client, JDBC or REST subject id is >> random >> > UUID. In this case, we cannot get the subject information on a >> remote >> node, >> > and we get problems like these [1], [2]. >> > >> > To fix the problem, we should spread the client session to the whole >> > cluster. >> > >> > >> > I want to suggest a solution to the problem. >> > >> > >> > First, we should get subject information using >> GridSecurityProcessor. >> > >> > How GridSecurityProcessor will retrieve a subject data, it is up to >> plugin >> > developers. >> > >> > >> > Second, we should get rid of the assumption that a subject id is a >> >> node >> id >> > and remove the ATTR_SECURITY_SUBJECT_V2 attribute. >> > >> > >> > I have prepared PoC PR [3] that: >> > >> > - places the existing logic of spreading security context to >> > GridSecurityProcessor; >> > >> > - uses GridSecurityProcessor to get SecurityContext. >> > >> > >> > >> > 1. >> > >> > >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html >> > 2. https://issues.apache.org/jira/browse/IGNITE-12589 >> > 3. https://github.com/apache/ignite/pull/7375 >> > >> >> >> >> -- >> >> Best regards, >> >>Andrey Kuznetsov. >> >> >> > >> >
[jira] [Created] (IGNITE-12759) Getting a SecurityContext from GridSecurityProcessor
Denis Garus created IGNITE-12759: Summary: Getting a SecurityContext from GridSecurityProcessor Key: IGNITE-12759 URL: https://issues.apache.org/jira/browse/IGNITE-12759 Project: Ignite Issue Type: Improvement Components: security Affects Versions: 2.8 Reporter: Denis Garus Fix For: 2.8.1 1. Extend the _GridSecurityProcessor_ interface by adding _securityContext(UUID subjId)_ method and use this method to get the actual security context. 2. In the case when _GridSecurityProcessor_ cannot get a security context, we should return _the unknown security context_. All operations are forbidden with _the unknown security context_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Ignite 2.8 announcement plan
Denis, >> the blocking PME no longer happens if a node leaves the cluster We should mention this should be the baseline node On Tue, Mar 10, 2020 at 9:40 AM Denis Magda wrote: > Pavel, thank you. I referred to your article from a blog post to be > published on blogs.apache.org. Please feel free to share feedback before > it's published. You can use the comment feature of Google Docs: > > https://docs.google.com/document/d/1ssTC1Jf_reqZFWgl4ayhaohiAJCpzdL4tPrHTxvfvAM/edit?usp=sharing > > > @Alexey Zinoviev , @Andrey Gura > , @Nikolay Izhikov , @Anton > Vinogradov could you glance at the paragraphs mentioning > the improvements you contributed to the release? I just want to be sure my > understanding is correct. > > - > Denis > > > On Mon, Mar 9, 2020 at 3:54 AM Pavel Tupitsyn > wrote: > >> Published: https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.8/ >> >> On Sat, Mar 7, 2020 at 1:49 AM Pavel Tupitsyn >> wrote: >> >> > Denis, ok, I'll publish on Monday afternoon then (UTC), weekend is not >> the >> > best time. >> > >> > Thanks, >> > Pavel >> > >> > On Sat, Mar 7, 2020 at 1:25 AM Denis Magda wrote: >> > >> >> Pavel, >> >> >> >> Thanks for clarifying the way partition-awareness handles topology >> >> changes. >> >> >> >> Please publish your article as soon as you're ready. I plan to finish >> mine >> >> on Monday-Tuesday and will refer to yours. >> >> >> >> - >> >> Denis >> >> >> >> >> >> On Fri, Mar 6, 2020 at 1:36 AM Pavel Tupitsyn >> >> wrote: >> >> >> >> > Denis, thanks for the feedback! >> >> > When should I publish the post? Right after official release >> >> announcement, >> >> > or later? >> >> > >> >> > > I would use "thick client" as a term instead of the "classic >> client" >> >> > Good point, fixed >> >> > >> >> > > partition-awareness doesn't handle topology changes automatically >> >> > (partition map won't be updated on the client-side) >> >> > This is not true, we keep the partition map up to date by checking >> >> > AffinityTopologyVersion [1] >> >> > >> >> > > Now I can run Ignite.NET easily on my Mac OS machine >> >> > Just to clarify, you can do that since 2.4 release [2]. >> >> > In 2.8 we have refined build-related things (jar file handling), and >> >> made >> >> > sure that recent .NET versions are supported. >> >> > >> >> > [1] >> >> > >> >> > >> >> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients >> >> > [2] https://habr.com/ru/company/gridgain/blog/347374/ (in Russian) >> >> > >> >> > On Fri, Mar 6, 2020 at 2:40 AM Denis Magda >> wrote: >> >> > >> >> > > Pavel, thanks, >> >> > > >> >> > > I enjoyed reading the blog, crystal clear and straight to the >> point! >> >> > Please >> >> > > consider these several items that might strengthen the article a >> bit: >> >> > > >> >> > >- I would use "thick client" as a term instead of the "classic >> >> client" >> >> > >(and mention that Ignite.NET client is a thick one). The thick >> >> client >> >> > is >> >> > >already a coined term that based on my observations are used a >> lot >> >> by >> >> > > dev >> >> > >and user communities. Also, you might add some differences of >> thick >> >> > vs. >> >> > >thin taking from this page - >> >> > > >> >> > > >> >> > >> >> >> https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients >> >> > >- Should we mention that presently partition-awareness doesn't >> >> handle >> >> > >topology changes automatically (partition map won't be updated >> on >> >> the >> >> > >client-side)? This might be a blocker for some users. >> >> > >- Excited to read about the cross-platform support, that's huge! >> >> Now I >> >> > >can run Ignite.NET easily on my Mac OS machine. I would insert a >> >> > > reference >> >> > >to updated documentation pages that explain how to start with >> >> > > Ignite.NET on >> >> > >various platforms. >> >> > > >> >> > > Hope, you will find this helpful, thanks for helping with project >> >> > > promotion! >> >> > > >> >> > > - >> >> > > Denis >> >> > > >> >> > > >> >> > > On Thu, Mar 5, 2020 at 7:32 AM Pavel Tupitsyn < >> ptupit...@apache.org> >> >> > > wrote: >> >> > > >> >> > > > Denis, >> >> > > > >> >> > > > The first post is going to be ready soon, probably by tomorrow. >> >> > > > Here is a draft, feedback welcome: >> >> > > > >> >> > > > >> >> > > >> >> > >> >> >> https://github.com/ptupitsyn/ptupitsyn.github.io/blob/ignite-2.8/_posts/2020-03-05-Whats-New-In-Ignite-Net-2.8.md >> >> > > > >> >> > > > On Wed, Mar 4, 2020 at 5:15 PM Denis Magda >> >> wrote: >> >> > > > >> >> > > > > Hi Pavel, >> >> > > > > >> >> > > > > Excellent! It will be good to publish the first article (what's >> >> new >> >> > in >> >> > > > > Ignite.NET 2.8) prior to a generic blog on blogs.apache.org so >> >> that >> >> > we >> >> > > > can >> >> > > > > link your post in for those who are looking for more details. >> Do >> >> you >> >> > > have >> >> > >
Re: Ignite 2.8 announcement plan
Pavel, thank you. I referred to your article from a blog post to be published on blogs.apache.org. Please feel free to share feedback before it's published. You can use the comment feature of Google Docs: https://docs.google.com/document/d/1ssTC1Jf_reqZFWgl4ayhaohiAJCpzdL4tPrHTxvfvAM/edit?usp=sharing @Alexey Zinoviev , @Andrey Gura , @Nikolay Izhikov , @Anton Vinogradov could you glance at the paragraphs mentioning the improvements you contributed to the release? I just want to be sure my understanding is correct. - Denis On Mon, Mar 9, 2020 at 3:54 AM Pavel Tupitsyn wrote: > Published: https://ptupitsyn.github.io/Whats-New-In-Ignite-Net-2.8/ > > On Sat, Mar 7, 2020 at 1:49 AM Pavel Tupitsyn > wrote: > > > Denis, ok, I'll publish on Monday afternoon then (UTC), weekend is not > the > > best time. > > > > Thanks, > > Pavel > > > > On Sat, Mar 7, 2020 at 1:25 AM Denis Magda wrote: > > > >> Pavel, > >> > >> Thanks for clarifying the way partition-awareness handles topology > >> changes. > >> > >> Please publish your article as soon as you're ready. I plan to finish > mine > >> on Monday-Tuesday and will refer to yours. > >> > >> - > >> Denis > >> > >> > >> On Fri, Mar 6, 2020 at 1:36 AM Pavel Tupitsyn > >> wrote: > >> > >> > Denis, thanks for the feedback! > >> > When should I publish the post? Right after official release > >> announcement, > >> > or later? > >> > > >> > > I would use "thick client" as a term instead of the "classic client" > >> > Good point, fixed > >> > > >> > > partition-awareness doesn't handle topology changes automatically > >> > (partition map won't be updated on the client-side) > >> > This is not true, we keep the partition map up to date by checking > >> > AffinityTopologyVersion [1] > >> > > >> > > Now I can run Ignite.NET easily on my Mac OS machine > >> > Just to clarify, you can do that since 2.4 release [2]. > >> > In 2.8 we have refined build-related things (jar file handling), and > >> made > >> > sure that recent .NET versions are supported. > >> > > >> > [1] > >> > > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > >> > [2] https://habr.com/ru/company/gridgain/blog/347374/ (in Russian) > >> > > >> > On Fri, Mar 6, 2020 at 2:40 AM Denis Magda wrote: > >> > > >> > > Pavel, thanks, > >> > > > >> > > I enjoyed reading the blog, crystal clear and straight to the point! > >> > Please > >> > > consider these several items that might strengthen the article a > bit: > >> > > > >> > >- I would use "thick client" as a term instead of the "classic > >> client" > >> > >(and mention that Ignite.NET client is a thick one). The thick > >> client > >> > is > >> > >already a coined term that based on my observations are used a > lot > >> by > >> > > dev > >> > >and user communities. Also, you might add some differences of > thick > >> > vs. > >> > >thin taking from this page - > >> > > > >> > > > >> > > >> > https://www.gridgain.com/docs/latest/installation-guide/deployment-modes#thick-vs-thin-clients > >> > >- Should we mention that presently partition-awareness doesn't > >> handle > >> > >topology changes automatically (partition map won't be updated on > >> the > >> > >client-side)? This might be a blocker for some users. > >> > >- Excited to read about the cross-platform support, that's huge! > >> Now I > >> > >can run Ignite.NET easily on my Mac OS machine. I would insert a > >> > > reference > >> > >to updated documentation pages that explain how to start with > >> > > Ignite.NET on > >> > >various platforms. > >> > > > >> > > Hope, you will find this helpful, thanks for helping with project > >> > > promotion! > >> > > > >> > > - > >> > > Denis > >> > > > >> > > > >> > > On Thu, Mar 5, 2020 at 7:32 AM Pavel Tupitsyn > > >> > > wrote: > >> > > > >> > > > Denis, > >> > > > > >> > > > The first post is going to be ready soon, probably by tomorrow. > >> > > > Here is a draft, feedback welcome: > >> > > > > >> > > > > >> > > > >> > > >> > https://github.com/ptupitsyn/ptupitsyn.github.io/blob/ignite-2.8/_posts/2020-03-05-Whats-New-In-Ignite-Net-2.8.md > >> > > > > >> > > > On Wed, Mar 4, 2020 at 5:15 PM Denis Magda > >> wrote: > >> > > > > >> > > > > Hi Pavel, > >> > > > > > >> > > > > Excellent! It will be good to publish the first article (what's > >> new > >> > in > >> > > > > Ignite.NET 2.8) prior to a generic blog on blogs.apache.org so > >> that > >> > we > >> > > > can > >> > > > > link your post in for those who are looking for more details. Do > >> you > >> > > have > >> > > > > any timeline in mind for this article? > >> > > > > > >> > > > > @Alexey Zinoviev , how about you > >> preparing > >> > > > several > >> > > > > paragraphs for the blog highlighting the biggest changes in ML? > >> The > >> > > same > >> > > > > highlighted content will be elaborated during the webinar. > >> > > > > > >> > > > > - > >> > > > > Denis > >> > > > > > >> > > > > >
