Re: IGNITE-12952 Enable travis ci for ignite-extensions

[Saikat Maitra]

Hi Maxim, Pavel

Can you please share more info about how travis build was enabled for
ignite repo?

I tried to execute the travis CI build for ignite-extensions but I do not
have sufficient access to enable the travis build for ignite-extensions
repo.

Regards,
Saikat


On Sun, May 31, 2020 at 4:18 PM Saikat Maitra 
wrote:

> Hi,
>
> I have raised a PR to enable travis CI build.
>
> Jira : https://issues.apache.org/jira/browse/IGNITE-12952
>
> PR : https://github.com/apache/ignite-extensions/pull/15
>
> I need more info about how travis build was enabled for ignite repo. I
> tried to execute the travis CI build for ignite-extensions but I do not
> have sufficient access to enable the travis build for ignite-extensions
> repo.
>
> https://travis-ci.org/github/apache/ignite-extensions
>
> Regards,
> Saikat
>
>

Re: Tool for performance statistics reports

[Saikat Maitra]

Hello Nikita,

I observed we have an open PR in ignite repo for this feature with
different set of changes compared to ignite extensions repo.


apache/ignite#7693 

https://github.com/apache/ignite-extensions/pull/16

Can you please share more info on how we can use the profiling tool with
ignite-extensions modules?


Regards,

Saikat

On Mon, Jun 8, 2020 at 5:51 AM Nikolay Izhikov  wrote:

> Hello, Alexey.
>
> Thanks for the review.
>
> My understanding if the following:
>
> We will have 3 in-depth tool to find issues in cluster:
>
> 1. Metrics + System views - data that describe Ignite entities very
> high-level.
>
> 2. Profiling - tool to know what specific query of transactions are slow.
> In many cases, this knowledge is enough to fix the issue(rewrite query,
> redesign transactions flow, etc)
>
> 3. Tracing - tool to know why one of 1000 of the same queries was slow.
> The most detailed view of the Ignite internal processes.
>
> > For example, a user would not be able to match a long task with a long
> job in that task.
>
> This is not true.
> Profiling report will aggregate data from all nodes.
> So there will be both
>
>  * summary time of the task
>  * time of the each job in the task.
>
>
> > 8 июня 2020 г., в 12:52, Alexey Goncharuk 
> написал(а):
> >
> > Nikita, Igniters,
> >
> > I left a few comments on the tool itself in the PR.
> >
> > However, I would like to reiterate and discuss why a user would prefer to
> > use the profiling tool over tracing? Profiling tool only captures very
> > high-level details of the operations (a single cache operation, for
> > example), and does not interconnect operations happened on different
> nodes.
> > For example, a user would not be able to match a long task with a long
> job
> > in that task. In other words, profiling data is always a subset of data
> > collected by tracing.
> >
> > Maybe it makes sense to adopt local log file approach to write spans so
> we
> > can process those spans later to build a report?
> >
> > чт, 4 июн. 2020 г. в 11:16, Nikita Amelchev :
> >
> >> Hi, Igniters.
> >>
> >> I have implemented cluster profiling and tool to build the performance
> >> report. It's ready to be reviewed. [1, 2]
> >>
> >> Profiling can be managed by JMX bean. I have plans to implement it to
> >> control.sh also.
> >>
> >> Nodes write statistics to the temporary off heap buffer and then one
> >> thread flushes to the profiling files. The write mechanics and format
> >> is like WAL logging.
> >> The report contains the following statistics:
> >> - nodes and caches info
> >> - cache operations and transaction statistics
> >> - SQL and scan queries statistics (include logical and physical reads
> per
> >> query)
> >> - tasks and jobs statistics.
> >>
> >> More details in the IEP [3].
> >>
> >> [1] https://github.com/apache/ignite/pull/7693
> >> [2] https://issues.apache.org/jira/browse/IGNITE-12666
> >> [3]
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/Cluster+performance+profiling+tool
> >>
> >> вс, 26 апр. 2020 г. в 17:29, Вячеслав Коптилин <
> slava.kopti...@gmail.com>:
> >>>
> >>> Hello Nikolay,
> >>>
>  Who deprecated visor and when? Maybe I miss something?
> >>> On the one hand, there was technically no community consensus that this
> >>> tool should be obsolete.
> >>> On the other hand, my opinion based on the following topic:
> >>>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-Visor-plugin-tp44879p44939.html
> >>> Moreover, it seems to me, currently, the control utility is widely used
> >> and
> >>> actively developed, instead of the visor.
> >>>
>  It's true that, for now, Ignite doesn't have "tool strategy" I think
> >> it's
> >>> a big issue from the user's point of view.
> >>> I absolutely agree with that.
> >>>
>  We should solve it in the nearest time. Feel free to start this
> >> activity
> >>> I have no plan at the moment. However, at the first stage, we could
> >>> understand the difference between visor and control utility.
> >>> All useful features from visor should be moved/implemented in control
> >>> utility and after that visor tool and should be marked as
> >>> deprecated/obsoleted.
> >>>
>  You need to throw in control.sh also, which does some kind of
> >> statistics
> >>> too, such as idle_verify.
>  Please, clarify your idea:
>    We should use some info from control.sh to the report?
>    The report should be generated by some control.sh subcommand?
> >>> If I am not mistaken, the oracle database has AWR tool (mentioned on
> the
> >>> IEP page) which is a command-line utility that generates HTML reports.
> >>> I like this idea and I think this is a good approach that can be
> realized
> >>> in the control utility.
> >>> If we have a case that cannot be implemented in this way, we have to
> >>> clearly states the difference between these tools so as not to confuse
> >> our
> >>> users.
> >>> What do you think?
> >>>
> >>> Thanks,

Re: [DISCUSS] Fix confusing "Used by" on GitHub

[Denis Magda]

I can see the badge being signed in.

In fact, there are many more dependents on our modules and packages:
https://github.com/apache/ignite/network/dependents

The badge displays
"apache-ignite-client" stats by default because the package goes first in
the list. However, you can always change it manually. For instance, there
are more than 1,400 dependants on ignite-core module:
https://github.com/apache/ignite/network/dependents?package_id=UGFja2FnZS0xODE0MjIyNzE%3D

Probably, it's possible to show the stats of ignite-core in the badge but I
don't have access to the repo settings. Ivan, would you mind checking this
with INFRA?

-
Denis


On Wed, Jun 10, 2020 at 1:40 PM Ivan Pavlukhin  wrote:

> A screenshot from my browser [1]. I suppose we still think about
> proper repository URLs.
>
> P.S. I do not see "Used by" when I am not logged in. Might it be the case?
>
> [1]
> https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/3858c12d7b65e3162297b704ba861e4945ed9ca4/ignite-used-by.png
>
> 2020-06-10 23:05 GMT+03:00, Ilya Kasnacheev :
> > Hello!
> >
> > Still nothng. Maybe they are A/B testing this feature? In this case, I
> > suggest we wait.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 10 июн. 2020 г. в 22:40, Pavel Tupitsyn :
> >
> >> Ilya, Andrey, try a forced reload of the page:
> >> [image: image.png]
> >>
> >>
> >> On Wed, Jun 10, 2020 at 10:30 PM Andrey Gura  wrote:
> >>
> >>> +1
> >>>
> >>> I don't see any badges.
> >>>
> >>> On Wed, Jun 10, 2020 at 10:27 PM Ilya Kasnacheev
> >>>  wrote:
> >>> >
> >>> > Hello!
> >>> >
> >>> > I don't see such a badge. Instead I see "Watch" "Star" "Fork".
> >>> >
> >>> > Regards,
> >>> > --
> >>> > Ilya Kasnacheev
> >>> >
> >>> >
> >>> > ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :
> >>> >
> >>> > > Hi Igniters,
> >>> > >
> >>> > > I noticed that we have a confusing "Used by" badge on a GitHub
> >>> > > mirror
> >>> > > repository main page [1] (the badge is located in a line with Star
> >>> > > and
> >>> > > Fork badges). It reports only a couple of usages while there are
> >>> > > much
> >>> > > more. Actually it shows only apache-ignite-client NPM package
> >>> > > usages.
> >>> > > As I understood it happens because only an NPM package config file
> >>> > > refers a GitHub repository URL while e.g. maven modules refer to an
> >>> > > ASF repository (GitBox) (see an  section in parent/pom.xml).
> >>> > >
> >>> > > IMHO a confusing usages number is a problem and it worth resolving.
> >>> > > I
> >>> > > see following options:
> >>> > > 1. Use an ASF repository URL in the NPM package config file.
> >>> > > 2. Use the GitHub repository URL for maven packages.
> >>> > >
> >>> > > While with the first option we will see no "Used by", I tend to
> >>> > > think
> >>> > > that it is a better option. And what do you think?
> >>> > >
> >>> > > [1] https://github.com/apache/ignite
> >>> > >
> >>> > > --
> >>> > >
> >>> > > Best regards,
> >>> > > Ivan Pavlukhin
> >>> > >
> >>>
> >>
> >
>
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Denis Magda]

Ivan, Sergey,

How much effort should we put to resolve the issue with continuous queries?
Are you working on that issue actively? Let's try to guess what would be
the ETA.

-
Denis


On Wed, Jun 10, 2020 at 3:55 AM Ivan Bessonov  wrote:

> Hello,
>
> Sorry for the delay. Sergey Chugunov (sergey.chugu...@gmail.com) just
> replied
> to the main conversation about "communication via discovery" [1]. We work
> on it
> together and recently have found one hard-to-fix scenario, detailed
> description is
> provided in Sergey's reply.
>
> In short, July 10th looks realistic only if we introduce new behavior in
> its current
> implementation, with new setting and IgniteExperimental status. Blocker
> here is
> current implementation of Continuos Query protocol that in some cases
> (described
> at the end) initiates TCP connection right from discovery thread which
> obviously
> leads to deadlock. We haven't estimated efforts needed to redesign of CQ
> protocol
> but it is definitely a risk and fixing it isn't feasible with a code
> freeze at 10th of July.
> So my verdict: we can include this new feature in 2.9 scope as
> experimental and with
> highlighted limitation on CQ usage. Is that OK?
>
> CQ limitation: server needs to open a communication connection to the
> client if during
> CQ registration client tries to p2p deploy new class not available on
> server classpath.
> In other cases registration of CQ should be fine.
>
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html
>
> вт, 9 июн. 2020 г. в 19:36, Ivan Rakov :
>
>> Hi,
>>
>> Indeed, the tracing feature is almost ready. Discovery, communication and
>> transactions tracing will be introduced, as well as an option to configure
>> tracing in runtime. Right now we are working on final performance
>> optimizations, but it's very likely that we'll complete this activity
>> before the code freeze date.
>> Let's include tracing to the 2.9 release scope.
>>
>> More info:
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing
>> https://issues.apache.org/jira/browse/IGNITE-13060
>>
>> --
>> Best Regards,
>> Ivan Rakov
>>
>> On Sat, Jun 6, 2020 at 4:30 PM Denis Magda  wrote:
>>
>> > Hi folks,
>> >
>> > The timelines proposed by Alex Plekhanov sounds reasonable to me. I'd
>> like
>> > only to hear inputs of @Ivan Rakov , who is about
>> to
>> > finish with the tracing support, and @Ivan Bessonov
>> > , who is fixing a serious limitation for K8
>> > deployments [1]. Most likely, both features will be ready by the code
>> > freeze date (July 10), but the guys should know it better.
>> >
>> > [1]
>> >
>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html
>> >
>> > -
>> > Denis
>> >
>> >
>> > On Wed, Jun 3, 2020 at 4:45 AM Alex Plehanov 
>> > wrote:
>> >
>> >> Hello Igniters,
>> >>
>> >> AI 2.8.1 is finally released and as we discussed here [1] its time to
>> >> start
>> >> the discussion about 2.9 release.
>> >>
>> >> I want to propose myself to be the release manager of the 2.9 release.
>> >>
>> >> What about release time, I agree with Maxim that we should deliver
>> >> features
>> >> as frequently as possible. If some feature doesn't fit into release
>> dates
>> >> we should better include it into the next release and schedule the next
>> >> release earlier then postpone the current release.
>> >>
>> >> I propose the following dates for 2.9 release:
>> >>
>> >> Scope Freeze: June 26, 2020
>> >> Code Freeze: July 10, 2020
>> >> Voting Date: July 31, 2020
>> >> Release Date: August 7, 2019
>> >>
>> >> WDYT?
>> >>
>> >> [1] :
>> >>
>> >>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
>> >>
>> >
>>
>
>
> --
> Sincerely yours,
> Ivan Bessonov
>

Re: [DISCUSSION] New Ignite settings for IGNITE-12438 and IGNITE-13013

[Denis Magda]

Sergey,

Thanks for the detailed explanation and for covering all corner cases.

Considering the improvement's criticality, I would continue moving in the
initial direction and add that particular configuration property.
Potentially, we can put more effort throughout an Ignite 3.0 timeframe and
remove the property altogether. @Valentin Kulichenko
, could you please suggest any alternate naming?

Btw, what are the specifics of the issue with continuous queries? It will
be ideal if we could release this new communication option in the GA state
in 2.9.

-
Denis


On Wed, Jun 10, 2020 at 1:22 AM Sergey Chugunov 
wrote:

> Denis, Val,
>
> Idea of prohibiting servers to open connections to clients and force
> clients to always open "inverse connections" to servers looks promising. To
> be clear, by "inverse connections" I mean here that server needed to
> communicate with client requests client to open a connection back instead
> of opening connection by itself using addresses published by the client.
>
> If we apply the idea it will indeed allow us to simplify our configuration
> (no need for new configuration property), another advantage is clients
> won't need to publish their addresses anymore (with one side note I'll
> cover at the end), it will also simplify our code.
>
> However applying it with current implementation of inverse connection
> request (when request goes across all ring) may bring significant delay of
> opening first connection depending on cluster size and relative positions
> between server that needs to communicate with client (target server) and
> client's router node.
>
> It is possible to overcome this by sending inverse connection request not
> via discovery but directly to router server node via communication and
> convert to discovery message only on the router. We'll still have two hops
> of communication request instead of one plus discovery worker on client may
> be busy working on other stuff slowing down handling of connection request.
> But it should be fine.
>
> However with this solution it is hard to implement failover of router node:
> let me describe it in more details.
> In case of router node failure target server won't be able to determine if
> client received inverse comm request successfully and (even worse) won't be
> able to figure out new router for the client without waiting for discovery
> event of the client reconnect.
> And this brings us to the following choise: we either wait for discovery
> event about client reconnect (this is deadlock-prone as current protocol of
> CQ registration opens comm connection to client right from discovery thread
> in some cases; if we wait for new discovery event from discovery thread, it
> is a deadlock) or we fail opening the connection by timeout thus adding new
> scenarios when opening connection may fail.
>
> Thus implementing communication model "clients connect to servers, servers
> never connect to clients" efficiently requires more work on different parts
> of our functionality and rigorous testing of readiness of our code for more
> communication connection failures.
>
> So to me the least risky decision is not to delete new configuration but
> leave it with experimental status. If we find out that direct request
> (server -> router server -> target client) implementation works well and
> doesn't bring much complexity in failover scenarios we'll remove that
> configuration and prohibit servers to open connections to clients by
> default.
>
> Side note: there are rare but yet possible scenarios where client node
> needs to open communication connection to other client node. If we let
> clients not to publish their addresses these scenarios will stop working
> without additional logic like sending data through router node. As far as I
> know client-client connectivity is involved in p2p class deployment
> scenarios, does anyone know about other cases?
>
> --
> Thanks,
> Sergey Chugunov
>
> On Wed, Jun 3, 2020 at 5:37 PM Denis Magda  wrote:
>
> > Ivan,
> >
> > It feels like Val is driving us in the right direction. Is there any
> reason
> > for keeping the current logic when servers can open connections to
> clients?
> >
> > -
> > Denis
> >
> >
> > On Thu, May 21, 2020 at 4:48 PM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Ivan,
> > >
> > > Have you considered eliminating server to client connections
> altogether?
> > > Or, at the very least making the "client to server only" mode the
> default
> > > one?
> > >
> > > All the suggested names are confusing and not intuitive, and I doubt we
> > > will be able to find a good one. A server initiating a TCP connection
> > with
> > > a client is confusing in the first place and creates a usability issue.
> > We
> > > now want to solve it by introducing an additional configuration
> > > parameter, and therefore additional complexity. I don't think this is
> the
> > > right approach.
> > >
> > > What are the drawbacks of permanently switching to 

Re: [DISCUSS] Add flag methods to ClusterState enum

[Sergey Antonov]

Pavel, Alexei thank you for your replays.

> is this one special in some way?
Yes. We have two "active" cluster states: ACTIVE, ACTIVE_READ_ONLY.
Probably, I chose the wrong method's name, but I mean that in "active"
state the caches must be started.

> But it looks like we do not need methods *readOnly *and *inactive*.
I agree.

ср, 10 июн. 2020 г. в 21:17, Alexei Scherbakov :

> But it looks like we do not need methods *readOnly *and *inactive*.
> What is the point in adding them ?
>
>
> ср, 10 июн. 2020 г. в 21:05, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> > Sergey Antonov,
> >
> > The proposal looks good to me.
> > Use of org.apache.ignite.cluster.ClusterState#active adds a
> > boilerplate code (a lot of static imports) and does an unnecessary state
> > check.
> >
> >
> >
> >
> > ср, 10 июн. 2020 г. в 19:02, Pavel Tupitsyn :
> >
> >> Sergey,
> >>
> >> I disagree - looks weird.
> >> We have lots of enums, is this one special in some way?
> >>
> >> Thanks,
> >> Pavel
> >>
> >> On Wed, Jun 10, 2020 at 6:58 PM Sergey Antonov <
> antonovserge...@gmail.com
> >> >
> >> wrote:
> >>
> >> > Igniters, I'd like to propose a small improvement in ClusterState
> >> class. I
> >> > want to remove the static method boolean ClusterState#active and add
> >> > methods to the enum:
> >> >
> >> >- boolean active()
> >> >- boolean readOnly()
> >> >- boolean inactive()
> >> >
> >> > From my point of view these methods more useful than comparing with
> >> > specific enum's value.
> >> >
> >> > I'm going to do that on the ticket [1].
> >> >
> >> > Any objections?
> >> >
> >> > [1] https://issues.apache.org/jira/browse/IGNITE-13144
> >> > --
> >> > BR, Sergey Antonov
> >> >
> >>
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
> >
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


-- 
BR, Sergey Antonov

Re: [DISCUSS] Fix confusing "Used by" on GitHub

[Ivan Pavlukhin]

A screenshot from my browser [1]. I suppose we still think about
proper repository URLs.

P.S. I do not see "Used by" when I am not logged in. Might it be the case?

[1] 
https://gist.githubusercontent.com/pavlukhin/c8c7c6266eeab56048c31f5cdfb31d20/raw/3858c12d7b65e3162297b704ba861e4945ed9ca4/ignite-used-by.png

2020-06-10 23:05 GMT+03:00, Ilya Kasnacheev :
> Hello!
>
> Still nothng. Maybe they are A/B testing this feature? In this case, I
> suggest we wait.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 10 июн. 2020 г. в 22:40, Pavel Tupitsyn :
>
>> Ilya, Andrey, try a forced reload of the page:
>> [image: image.png]
>>
>>
>> On Wed, Jun 10, 2020 at 10:30 PM Andrey Gura  wrote:
>>
>>> +1
>>>
>>> I don't see any badges.
>>>
>>> On Wed, Jun 10, 2020 at 10:27 PM Ilya Kasnacheev
>>>  wrote:
>>> >
>>> > Hello!
>>> >
>>> > I don't see such a badge. Instead I see "Watch" "Star" "Fork".
>>> >
>>> > Regards,
>>> > --
>>> > Ilya Kasnacheev
>>> >
>>> >
>>> > ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :
>>> >
>>> > > Hi Igniters,
>>> > >
>>> > > I noticed that we have a confusing "Used by" badge on a GitHub
>>> > > mirror
>>> > > repository main page [1] (the badge is located in a line with Star
>>> > > and
>>> > > Fork badges). It reports only a couple of usages while there are
>>> > > much
>>> > > more. Actually it shows only apache-ignite-client NPM package
>>> > > usages.
>>> > > As I understood it happens because only an NPM package config file
>>> > > refers a GitHub repository URL while e.g. maven modules refer to an
>>> > > ASF repository (GitBox) (see an  section in parent/pom.xml).
>>> > >
>>> > > IMHO a confusing usages number is a problem and it worth resolving.
>>> > > I
>>> > > see following options:
>>> > > 1. Use an ASF repository URL in the NPM package config file.
>>> > > 2. Use the GitHub repository URL for maven packages.
>>> > >
>>> > > While with the first option we will see no "Used by", I tend to
>>> > > think
>>> > > that it is a better option. And what do you think?
>>> > >
>>> > > [1] https://github.com/apache/ignite
>>> > >
>>> > > --
>>> > >
>>> > > Best regards,
>>> > > Ivan Pavlukhin
>>> > >
>>>
>>
>


-- 

Best regards,
Ivan Pavlukhin

Re: [DISCUSS] Fix confusing "Used by" on GitHub

[Ilya Kasnacheev]

Hello!

Still nothng. Maybe they are A/B testing this feature? In this case, I
suggest we wait.

Regards,
-- 
Ilya Kasnacheev


ср, 10 июн. 2020 г. в 22:40, Pavel Tupitsyn :

> Ilya, Andrey, try a forced reload of the page:
> [image: image.png]
>
>
> On Wed, Jun 10, 2020 at 10:30 PM Andrey Gura  wrote:
>
>> +1
>>
>> I don't see any badges.
>>
>> On Wed, Jun 10, 2020 at 10:27 PM Ilya Kasnacheev
>>  wrote:
>> >
>> > Hello!
>> >
>> > I don't see such a badge. Instead I see "Watch" "Star" "Fork".
>> >
>> > Regards,
>> > --
>> > Ilya Kasnacheev
>> >
>> >
>> > ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :
>> >
>> > > Hi Igniters,
>> > >
>> > > I noticed that we have a confusing "Used by" badge on a GitHub mirror
>> > > repository main page [1] (the badge is located in a line with Star and
>> > > Fork badges). It reports only a couple of usages while there are much
>> > > more. Actually it shows only apache-ignite-client NPM package usages.
>> > > As I understood it happens because only an NPM package config file
>> > > refers a GitHub repository URL while e.g. maven modules refer to an
>> > > ASF repository (GitBox) (see an  section in parent/pom.xml).
>> > >
>> > > IMHO a confusing usages number is a problem and it worth resolving. I
>> > > see following options:
>> > > 1. Use an ASF repository URL in the NPM package config file.
>> > > 2. Use the GitHub repository URL for maven packages.
>> > >
>> > > While with the first option we will see no "Used by", I tend to think
>> > > that it is a better option. And what do you think?
>> > >
>> > > [1] https://github.com/apache/ignite
>> > >
>> > > --
>> > >
>> > > Best regards,
>> > > Ivan Pavlukhin
>> > >
>>
>

[MTCGA]: new failures in builds [5376278] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 If your changes can lead to this failure(s): We're grateful that you were a 
volunteer to make the contribution to this project, but things change and you 
may no longer be able to finalize your contribution.
 Could you respond to this email and indicate if you wish to continue and fix 
test failures or step down and some committer may revert you commit. 

 *New test failure in master 
CacheRegisterMetadataLocallyTest.testClientFindsValueByAffinityKeyDynamicCacheWithoutExtraRequest
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5293904454158188493=%3Cdefault%3E=testDetails

 *New test failure in master 
CacheRegisterMetadataLocallyTest.testClientFindsValueByAffinityKeyStaticCacheWithoutExtraRequest
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5649732816476371550=%3Cdefault%3E=testDetails
 Changes may lead to failure were done by 
 - ravil galeyev  
https://ci.ignite.apache.org/viewModification.html?modId=902925
 - ktkalenko  
https://ci.ignite.apache.org/viewModification.html?modId=902844
 - ilya kasnacheev  
https://ci.ignite.apache.org/viewModification.html?modId=902841
 - vladsz83  
https://ci.ignite.apache.org/viewModification.html?modId=902920
 - ilya kasnacheev  
https://ci.ignite.apache.org/viewModification.html?modId=902843
 - pavel tupitsyn  
https://ci.ignite.apache.org/viewModification.html?modId=902890
 - aleksey plekhanov  
https://ci.ignite.apache.org/viewModification.html?modId=902842
 - semyon danilov  
https://ci.ignite.apache.org/viewModification.html?modId=902900
 - mikhail petrov <32207922+ololo3...@users.noreply.github.com> 
https://ci.ignite.apache.org/viewModification.html?modId=902915

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 23:01:31 10-06-2020 

Re: [DISCUSS] Fix confusing "Used by" on GitHub

[Pavel Tupitsyn]

Ilya, Andrey, try a forced reload of the page:
[image: image.png]


On Wed, Jun 10, 2020 at 10:30 PM Andrey Gura  wrote:

> +1
>
> I don't see any badges.
>
> On Wed, Jun 10, 2020 at 10:27 PM Ilya Kasnacheev
>  wrote:
> >
> > Hello!
> >
> > I don't see such a badge. Instead I see "Watch" "Star" "Fork".
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :
> >
> > > Hi Igniters,
> > >
> > > I noticed that we have a confusing "Used by" badge on a GitHub mirror
> > > repository main page [1] (the badge is located in a line with Star and
> > > Fork badges). It reports only a couple of usages while there are much
> > > more. Actually it shows only apache-ignite-client NPM package usages.
> > > As I understood it happens because only an NPM package config file
> > > refers a GitHub repository URL while e.g. maven modules refer to an
> > > ASF repository (GitBox) (see an  section in parent/pom.xml).
> > >
> > > IMHO a confusing usages number is a problem and it worth resolving. I
> > > see following options:
> > > 1. Use an ASF repository URL in the NPM package config file.
> > > 2. Use the GitHub repository URL for maven packages.
> > >
> > > While with the first option we will see no "Used by", I tend to think
> > > that it is a better option. And what do you think?
> > >
> > > [1] https://github.com/apache/ignite
> > >
> > > --
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
>

Re: [DISCUSS] Fix confusing "Used by" on GitHub

[Andrey Gura]

+1

I don't see any badges.

On Wed, Jun 10, 2020 at 10:27 PM Ilya Kasnacheev
 wrote:
>
> Hello!
>
> I don't see such a badge. Instead I see "Watch" "Star" "Fork".
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :
>
> > Hi Igniters,
> >
> > I noticed that we have a confusing "Used by" badge on a GitHub mirror
> > repository main page [1] (the badge is located in a line with Star and
> > Fork badges). It reports only a couple of usages while there are much
> > more. Actually it shows only apache-ignite-client NPM package usages.
> > As I understood it happens because only an NPM package config file
> > refers a GitHub repository URL while e.g. maven modules refer to an
> > ASF repository (GitBox) (see an  section in parent/pom.xml).
> >
> > IMHO a confusing usages number is a problem and it worth resolving. I
> > see following options:
> > 1. Use an ASF repository URL in the NPM package config file.
> > 2. Use the GitHub repository URL for maven packages.
> >
> > While with the first option we will see no "Used by", I tend to think
> > that it is a better option. And what do you think?
> >
> > [1] https://github.com/apache/ignite
> >
> > --
> >
> > Best regards,
> > Ivan Pavlukhin
> >

Re: [DISCUSS] Fix confusing "Used by" on GitHub

[Ilya Kasnacheev]

Hello!

I don't see such a badge. Instead I see "Watch" "Star" "Fork".

Regards,
-- 
Ilya Kasnacheev


ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :

> Hi Igniters,
>
> I noticed that we have a confusing "Used by" badge on a GitHub mirror
> repository main page [1] (the badge is located in a line with Star and
> Fork badges). It reports only a couple of usages while there are much
> more. Actually it shows only apache-ignite-client NPM package usages.
> As I understood it happens because only an NPM package config file
> refers a GitHub repository URL while e.g. maven modules refer to an
> ASF repository (GitBox) (see an  section in parent/pom.xml).
>
> IMHO a confusing usages number is a problem and it worth resolving. I
> see following options:
> 1. Use an ASF repository URL in the NPM package config file.
> 2. Use the GitHub repository URL for maven packages.
>
> While with the first option we will see no "Used by", I tend to think
> that it is a better option. And what do you think?
>
> [1] https://github.com/apache/ignite
>
> --
>
> Best regards,
> Ivan Pavlukhin
>

[MTCGA]: new failures in builds [5368816] needs to be handled

[dpavlov . tasks]

Hi Igniters,

 I've detected some new issue on TeamCity to be handled. You are more than 
welcomed to help.

 *New test failure in master 
CacheSerializableTransactionsTest.testNoOptimisticExceptionOnChangingTopology 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-3749787405866025633=%3Cdefault%3E=testDetails
 No changes in the build

 - Here's a reminder of what contributors were agreed to do 
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute 
 - Should you have any questions please contact dev@ignite.apache.org 

Best Regards,
Apache Ignite TeamCity Bot 
https://github.com/apache/ignite-teamcity-bot
Notification generated at 21:46:30 10-06-2020 

Re: [DISCUSS] Add flag methods to ClusterState enum

[Alexei Scherbakov]

But it looks like we do not need methods *readOnly *and *inactive*.
What is the point in adding them ?


ср, 10 июн. 2020 г. в 21:05, Alexei Scherbakov :

> Sergey Antonov,
>
> The proposal looks good to me.
> Use of org.apache.ignite.cluster.ClusterState#active adds a
> boilerplate code (a lot of static imports) and does an unnecessary state
> check.
>
>
>
>
> ср, 10 июн. 2020 г. в 19:02, Pavel Tupitsyn :
>
>> Sergey,
>>
>> I disagree - looks weird.
>> We have lots of enums, is this one special in some way?
>>
>> Thanks,
>> Pavel
>>
>> On Wed, Jun 10, 2020 at 6:58 PM Sergey Antonov > >
>> wrote:
>>
>> > Igniters, I'd like to propose a small improvement in ClusterState
>> class. I
>> > want to remove the static method boolean ClusterState#active and add
>> > methods to the enum:
>> >
>> >- boolean active()
>> >- boolean readOnly()
>> >- boolean inactive()
>> >
>> > From my point of view these methods more useful than comparing with
>> > specific enum's value.
>> >
>> > I'm going to do that on the ticket [1].
>> >
>> > Any objections?
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-13144
>> > --
>> > BR, Sergey Antonov
>> >
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


-- 

Best regards,
Alexei Scherbakov

Re: [DISCUSS] Add flag methods to ClusterState enum

[Alexei Scherbakov]

Sergey Antonov,

The proposal looks good to me.
Use of org.apache.ignite.cluster.ClusterState#active adds a
boilerplate code (a lot of static imports) and does an unnecessary state
check.




ср, 10 июн. 2020 г. в 19:02, Pavel Tupitsyn :

> Sergey,
>
> I disagree - looks weird.
> We have lots of enums, is this one special in some way?
>
> Thanks,
> Pavel
>
> On Wed, Jun 10, 2020 at 6:58 PM Sergey Antonov 
> wrote:
>
> > Igniters, I'd like to propose a small improvement in ClusterState class.
> I
> > want to remove the static method boolean ClusterState#active and add
> > methods to the enum:
> >
> >- boolean active()
> >- boolean readOnly()
> >- boolean inactive()
> >
> > From my point of view these methods more useful than comparing with
> > specific enum's value.
> >
> > I'm going to do that on the ticket [1].
> >
> > Any objections?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-13144
> > --
> > BR, Sergey Antonov
> >
>


-- 

Best regards,
Alexei Scherbakov

[DISCUSS] Fix confusing "Used by" on GitHub

[Ivan Pavlukhin]

Hi Igniters,

I noticed that we have a confusing "Used by" badge on a GitHub mirror
repository main page [1] (the badge is located in a line with Star and
Fork badges). It reports only a couple of usages while there are much
more. Actually it shows only apache-ignite-client NPM package usages.
As I understood it happens because only an NPM package config file
refers a GitHub repository URL while e.g. maven modules refer to an
ASF repository (GitBox) (see an  section in parent/pom.xml).

IMHO a confusing usages number is a problem and it worth resolving. I
see following options:
1. Use an ASF repository URL in the NPM package config file.
2. Use the GitHub repository URL for maven packages.

While with the first option we will see no "Used by", I tend to think
that it is a better option. And what do you think?

[1] https://github.com/apache/ignite

-- 

Best regards,
Ivan Pavlukhin

Re: [DISCUSS] Add flag methods to ClusterState enum

[Pavel Tupitsyn]

Sergey,

I disagree - looks weird.
We have lots of enums, is this one special in some way?

Thanks,
Pavel

On Wed, Jun 10, 2020 at 6:58 PM Sergey Antonov 
wrote:

> Igniters, I'd like to propose a small improvement in ClusterState class. I
> want to remove the static method boolean ClusterState#active and add
> methods to the enum:
>
>- boolean active()
>- boolean readOnly()
>- boolean inactive()
>
> From my point of view these methods more useful than comparing with
> specific enum's value.
>
> I'm going to do that on the ticket [1].
>
> Any objections?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-13144
> --
> BR, Sergey Antonov
>

[DISCUSS] Add flag methods to ClusterState enum

[Sergey Antonov]

Igniters, I'd like to propose a small improvement in ClusterState class. I
want to remove the static method boolean ClusterState#active and add
methods to the enum:

   - boolean active()
   - boolean readOnly()
   - boolean inactive()

>From my point of view these methods more useful than comparing with
specific enum's value.

I'm going to do that on the ticket [1].

Any objections?

[1] https://issues.apache.org/jira/browse/IGNITE-13144
-- 
BR, Sergey Antonov

Re: request for contributors permissions

[Ilya Kasnacheev]

Hello!

I can see that you are already added to contributors. You should be able to
assign issues to yourself.

Regards,
-- 
Ilya Kasnacheev


ср, 10 июн. 2020 г. в 18:06, Aleksey Kurinov :

> Hello
>
> i've registered on https://issues.apache.org/jira/secure/Dashboard.jsp and
> according to
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute I'm
> requesting contributors permissions
>
> thank you
> Aleksei Kurinov
>

[jira] [Created] (IGNITE-13144) Add attribute methods to ClusterState enum

[Sergey Antonov (Jira)]

Sergey Antonov created IGNITE-13144:
---

 Summary: Add attribute methods to ClusterState enum
 Key: IGNITE-13144
 URL: https://issues.apache.org/jira/browse/IGNITE-13144
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
 Fix For: 2.9


We have {{boolean ClusterState#active(ClusterState)}} static method. It would 
be better to have an instance method {{boolean active()}}. Also I'd like to add 
methods {{boolean inactive()}} and {{boolean readOnly()}} to {{ClusterState}} 
class.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

request for contributors permissions

[Aleksey Kurinov]

Hello

i've registered on https://issues.apache.org/jira/secure/Dashboard.jsp and
according to
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute I'm
requesting contributors permissions

thank you
Aleksei Kurinov

[jira] [Created] (IGNITE-13143) Persistent store defragmentation

[Sergey Chugunov (Jira)]

Sergey Chugunov created IGNITE-13143:


 Summary: Persistent store defragmentation
 Key: IGNITE-13143
 URL: https://issues.apache.org/jira/browse/IGNITE-13143
 Project: Ignite
  Issue Type: New Feature
Reporter: Sergey Chugunov


Persistent store enables users to store data of their caches in a durable 
fashion on disk still benefiting from in-memory nature of Apache Ignite. Data 
of caches is stored in files created for every primary or backup partition 
assigned to that node and in an additional file for all user indexes.

Files in filesystem are allocated lazily (only if some data is actually stored 
to particular partition) and grow automatically when more data is added to the 
cache. But the problem is that files cannot shrink even if all data is removed.

This umbrella ticket covers all other tasks needed to implement simple yet 
effective approach to defragmentation. Detailed discussion could be found in 
[IEP-47|https://cwiki.apache.org/confluence/display/IGNITE/IEP-47%3A+Native+persistence+defragmentation]
 and in corresponding [dev-list 
discussion|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-IEP-47-Native-persistence-defragmentation-td47717.html]
 but core ideas are as follows:
 # Defragmentation is performed in a special _maintenance_ mode when node 
starts, provides access to some APIs like metrics or JMX management but doesn't 
join the cluster.
 # It is performed by copying all data from all partitions on node to new files 
with automatic compaction. After successful copy old partition files are 
deleted.
 # Metrics on progress of the operation are provided to the user.
 # Operation is fault-tolerant and in case of node failure proceeds after node 
restart.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13142) SQL constraint not null added on key prevents correct inserts

[Sergey Kalashnikov (Jira)]

Sergey Kalashnikov created IGNITE-13142:
---

 Summary: SQL constraint not null added on key prevents correct 
inserts
 Key: IGNITE-13142
 URL: https://issues.apache.org/jira/browse/IGNITE-13142
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Kalashnikov
 Attachments: SqlNotNullKeyFielfTest.java

It is possible to configure {{QueryEntity}} so that subsequent inserts would 
fail.
- lowercase {{keyFieldName}}
- not null constraint on {{keyFieldName}}


{code:java}
new QueryEntity()
.setTableName("Person")
.setKeyFieldName("id")
.setKeyType("java.lang.Integer")
.setValueType("Person")
.setFields(new LinkedHashMap<>(
F.asMap("id", "java.lang.Integer",
"name", "java.lang.String",
"age", "java.lang.Integer")))
.setNotNullFields(F.asSet("id", "name", "age"
{code}

The following SQL produces error: Null value is not allowed for column 'ID'

{code}
insert into Person (id, name, age) values (1, 'John Doe', 30)
{code}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13141) Modify .NET counterpart of IgniteCluster to include functionality of Cluster ID and tag

[Sergey Chugunov (Jira)]

Sergey Chugunov created IGNITE-13141:


 Summary: Modify .NET counterpart of IgniteCluster to include 
functionality of Cluster ID and tag
 Key: IGNITE-13141
 URL: https://issues.apache.org/jira/browse/IGNITE-13141
 Project: Ignite
  Issue Type: Task
Reporter: Sergey Chugunov


After  implementation of  IGNITE-12111 .NET tests showed broken API parity in 
new methods in IgniteCluster interface.

We need to implement the same functionality on .NET side (see description in 
linked ticket).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Not able to connect multiple slaves to Master

[Ilya Kasnacheev]

Hello!

I'm not really sure what do you mean by 'starting master on one server'. Do
you mean a server node? And you can only get a single client to connect to
it?

Can you provide logs from clients and servers?

Regards,
-- 
Ilya Kasnacheev


вт, 9 июн. 2020 г. в 21:33, imran kazi :

> Hi Team,
> I am deploying ignite clustered application on distributed servers.
>
> This works fine for me in local able to add many nodes.
>
> But I am deploying this on AWS where limited ports are open between these
> servers,  I already open
> 47500-47520,47100-47120,48100-48120,49500-49520,48500-48520.
>
> Now for this senario. when I am starting master on one server and 1 salve
> on another server its getting connected. But second slave trying to start
> from another server is not starting and getting connected to master. Second
> slave get connected when I stops 1st slave .
>
> So at a time am able to add only one slave.
>
>
> Can you please help me.
>
> Thanks & Regards,
> Imran
>

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

> Is that OK?


We shouldn’t add any code that is broke some existing, widely used feature.
Let’s fix it before the merge.


> 10 июня 2020 г., в 13:54, Ivan Bessonov  написал(а):
> 
> Hello,
> 
> Sorry for the delay. Sergey Chugunov (sergey.chugu...@gmail.com) just
> replied
> to the main conversation about "communication via discovery" [1]. We work
> on it
> together and recently have found one hard-to-fix scenario, detailed
> description is
> provided in Sergey's reply.
> 
> In short, July 10th looks realistic only if we introduce new behavior in
> its current
> implementation, with new setting and IgniteExperimental status. Blocker
> here is
> current implementation of Continuos Query protocol that in some cases
> (described
> at the end) initiates TCP connection right from discovery thread which
> obviously
> leads to deadlock. We haven't estimated efforts needed to redesign of CQ
> protocol
> but it is definitely a risk and fixing it isn't feasible with a code freeze
> at 10th of July.
> So my verdict: we can include this new feature in 2.9 scope as experimental
> and with
> highlighted limitation on CQ usage. Is that OK?
> 
> CQ limitation: server needs to open a communication connection to the
> client if during
> CQ registration client tries to p2p deploy new class not available on
> server classpath.
> In other cases registration of CQ should be fine.
> 
> [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html
> 
> вт, 9 июн. 2020 г. в 19:36, Ivan Rakov :
> 
>> Hi,
>> 
>> Indeed, the tracing feature is almost ready. Discovery, communication and
>> transactions tracing will be introduced, as well as an option to configure
>> tracing in runtime. Right now we are working on final performance
>> optimizations, but it's very likely that we'll complete this activity
>> before the code freeze date.
>> Let's include tracing to the 2.9 release scope.
>> 
>> More info:
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing
>> https://issues.apache.org/jira/browse/IGNITE-13060
>> 
>> --
>> Best Regards,
>> Ivan Rakov
>> 
>> On Sat, Jun 6, 2020 at 4:30 PM Denis Magda  wrote:
>> 
>>> Hi folks,
>>> 
>>> The timelines proposed by Alex Plekhanov sounds reasonable to me. I'd
>> like
>>> only to hear inputs of @Ivan Rakov , who is about
>> to
>>> finish with the tracing support, and @Ivan Bessonov
>>> , who is fixing a serious limitation for K8
>>> deployments [1]. Most likely, both features will be ready by the code
>>> freeze date (July 10), but the guys should know it better.
>>> 
>>> [1]
>>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Wed, Jun 3, 2020 at 4:45 AM Alex Plehanov 
>>> wrote:
>>> 
 Hello Igniters,
 
 AI 2.8.1 is finally released and as we discussed here [1] its time to
 start
 the discussion about 2.9 release.
 
 I want to propose myself to be the release manager of the 2.9 release.
 
 What about release time, I agree with Maxim that we should deliver
 features
 as frequently as possible. If some feature doesn't fit into release
>> dates
 we should better include it into the next release and schedule the next
 release earlier then postpone the current release.
 
 I propose the following dates for 2.9 release:
 
 Scope Freeze: June 26, 2020
 Code Freeze: July 10, 2020
 Voting Date: July 31, 2020
 Release Date: August 7, 2019
 
 WDYT?
 
 [1] :
 
 
>> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
 
>>> 
>> 
> 
> 
> -- 
> Sincerely yours,
> Ivan Bessonov

Re: Apache Ignite 2.9.0 RELEASE [Time, Scope, Manager]

[Ivan Bessonov]

Hello,

Sorry for the delay. Sergey Chugunov (sergey.chugu...@gmail.com) just
replied
to the main conversation about "communication via discovery" [1]. We work
on it
together and recently have found one hard-to-fix scenario, detailed
description is
provided in Sergey's reply.

In short, July 10th looks realistic only if we introduce new behavior in
its current
implementation, with new setting and IgniteExperimental status. Blocker
here is
current implementation of Continuos Query protocol that in some cases
(described
at the end) initiates TCP connection right from discovery thread which
obviously
leads to deadlock. We haven't estimated efforts needed to redesign of CQ
protocol
but it is definitely a risk and fixing it isn't feasible with a code freeze
at 10th of July.
So my verdict: we can include this new feature in 2.9 scope as experimental
and with
highlighted limitation on CQ usage. Is that OK?

CQ limitation: server needs to open a communication connection to the
client if during
CQ registration client tries to p2p deploy new class not available on
server classpath.
In other cases registration of CQ should be fine.

[1]
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html

вт, 9 июн. 2020 г. в 19:36, Ivan Rakov :

> Hi,
>
> Indeed, the tracing feature is almost ready. Discovery, communication and
> transactions tracing will be introduced, as well as an option to configure
> tracing in runtime. Right now we are working on final performance
> optimizations, but it's very likely that we'll complete this activity
> before the code freeze date.
> Let's include tracing to the 2.9 release scope.
>
> More info:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-48%3A+Tracing
> https://issues.apache.org/jira/browse/IGNITE-13060
>
> --
> Best Regards,
> Ivan Rakov
>
> On Sat, Jun 6, 2020 at 4:30 PM Denis Magda  wrote:
>
> > Hi folks,
> >
> > The timelines proposed by Alex Plekhanov sounds reasonable to me. I'd
> like
> > only to hear inputs of @Ivan Rakov , who is about
> to
> > finish with the tracing support, and @Ivan Bessonov
> > , who is fixing a serious limitation for K8
> > deployments [1]. Most likely, both features will be ready by the code
> > freeze date (July 10), but the guys should know it better.
> >
> > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-New-Ignite-settings-for-IGNITE-12438-and-IGNITE-13013-td47586.html
> >
> > -
> > Denis
> >
> >
> > On Wed, Jun 3, 2020 at 4:45 AM Alex Plehanov 
> > wrote:
> >
> >> Hello Igniters,
> >>
> >> AI 2.8.1 is finally released and as we discussed here [1] its time to
> >> start
> >> the discussion about 2.9 release.
> >>
> >> I want to propose myself to be the release manager of the 2.9 release.
> >>
> >> What about release time, I agree with Maxim that we should deliver
> >> features
> >> as frequently as possible. If some feature doesn't fit into release
> dates
> >> we should better include it into the next release and schedule the next
> >> release earlier then postpone the current release.
> >>
> >> I propose the following dates for 2.9 release:
> >>
> >> Scope Freeze: June 26, 2020
> >> Code Freeze: July 10, 2020
> >> Voting Date: July 31, 2020
> >> Release Date: August 7, 2019
> >>
> >> WDYT?
> >>
> >> [1] :
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Releases-Plan-td47360.html#a47575
> >>
> >
>


-- 
Sincerely yours,
Ivan Bessonov

Re: [DISCUSSION] New Ignite settings for IGNITE-12438 and IGNITE-13013

[Sergey Chugunov]

Denis, Val,

Idea of prohibiting servers to open connections to clients and force
clients to always open "inverse connections" to servers looks promising. To
be clear, by "inverse connections" I mean here that server needed to
communicate with client requests client to open a connection back instead
of opening connection by itself using addresses published by the client.

If we apply the idea it will indeed allow us to simplify our configuration
(no need for new configuration property), another advantage is clients
won't need to publish their addresses anymore (with one side note I'll
cover at the end), it will also simplify our code.

However applying it with current implementation of inverse connection
request (when request goes across all ring) may bring significant delay of
opening first connection depending on cluster size and relative positions
between server that needs to communicate with client (target server) and
client's router node.

It is possible to overcome this by sending inverse connection request not
via discovery but directly to router server node via communication and
convert to discovery message only on the router. We'll still have two hops
of communication request instead of one plus discovery worker on client may
be busy working on other stuff slowing down handling of connection request.
But it should be fine.

However with this solution it is hard to implement failover of router node:
let me describe it in more details.
In case of router node failure target server won't be able to determine if
client received inverse comm request successfully and (even worse) won't be
able to figure out new router for the client without waiting for discovery
event of the client reconnect.
And this brings us to the following choise: we either wait for discovery
event about client reconnect (this is deadlock-prone as current protocol of
CQ registration opens comm connection to client right from discovery thread
in some cases; if we wait for new discovery event from discovery thread, it
is a deadlock) or we fail opening the connection by timeout thus adding new
scenarios when opening connection may fail.

Thus implementing communication model "clients connect to servers, servers
never connect to clients" efficiently requires more work on different parts
of our functionality and rigorous testing of readiness of our code for more
communication connection failures.

So to me the least risky decision is not to delete new configuration but
leave it with experimental status. If we find out that direct request
(server -> router server -> target client) implementation works well and
doesn't bring much complexity in failover scenarios we'll remove that
configuration and prohibit servers to open connections to clients by
default.

Side note: there are rare but yet possible scenarios where client node
needs to open communication connection to other client node. If we let
clients not to publish their addresses these scenarios will stop working
without additional logic like sending data through router node. As far as I
know client-client connectivity is involved in p2p class deployment
scenarios, does anyone know about other cases?

--
Thanks,
Sergey Chugunov

On Wed, Jun 3, 2020 at 5:37 PM Denis Magda  wrote:

> Ivan,
>
> It feels like Val is driving us in the right direction. Is there any reason
> for keeping the current logic when servers can open connections to clients?
>
> -
> Denis
>
>
> On Thu, May 21, 2020 at 4:48 PM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Ivan,
> >
> > Have you considered eliminating server to client connections altogether?
> > Or, at the very least making the "client to server only" mode the default
> > one?
> >
> > All the suggested names are confusing and not intuitive, and I doubt we
> > will be able to find a good one. A server initiating a TCP connection
> with
> > a client is confusing in the first place and creates a usability issue.
> We
> > now want to solve it by introducing an additional configuration
> > parameter, and therefore additional complexity. I don't think this is the
> > right approach.
> >
> > What are the drawbacks of permanently switching to client-to-server
> > connections? Is there any value provided by the server-to-client option?
> >
> > As for pair connections, I'm not sure I understand why there is a
> > limitation. As far as I know, the idea behind this feature is that we
> > maintain two connections between two nodes instead of one, so that every
> > connection is used for communication in a single direction only. Why does
> > it matter which node initiates the connection? Why can't one of the nodes
> > (e.g., a client) initiate both connections, and then use them
> accordingly?
> > Correct me if I'm wrong, but I don't see why we can't do this.
> >
> > -Val
> >
> > On Thu, May 21, 2020 at 1:58 PM Denis Magda  wrote:
> >
> > > Ivan,
> > >
> > > Considering that the setting controls the way a communication SPI
> > > connection is 

Re: IGNITE-12808 Allow create tables for existing caches

[Nikolay Izhikov]

I will take a look.

> 8 июня 2020 г., в 15:17, Ivan Daschinsky  написал(а):
> 
> Hi Igniters.
> 
> I've recently submitted patch[1] that implemented subj.
> Any help with review would be appreciated.
> 
> 
> [1] - https://issues.apache.org/jira/browse/IGNITE-12808
> -- 
> Sincerely yours, Ivan Daschinskiy