Re: Commit message format

[Valentin Kulichenko]

Andrey,

Some rules are good, some rules are bad :)

If you create such a script so that it relies on having a colon in every
message, it will never work, simply because people make mistakes. The only
consequence of such a rule would be that we will have to fight it forever
trying to enforce it. I'm sure you don't want this.

-Val

On Fri, Mar 20, 2020 at 2:40 PM Andrey Gura  wrote:

> Ivan, Val,
>
> > But is it really important whether someone puts a colon, a dash, or just
> a
> > space after the ticket number?
>
> Absolutely not important. But every time when you want to write script
> for processing commit messages in some way you should check what
> exactly format committers use.
>
> I do not want to argue about this. But it always better to follow some
> rules then not.
>
> On Fri, Mar 20, 2020 at 3:01 AM Valentin Kulichenko
>  wrote:
> >
> > I agree with Ivan. All contribution rules should be reasonable and should
> > *add value*.
> >
> > For example, a requirement to include the ticket number is a great idea
> as
> > it creates a clear link between a commit and a JIRA ticket. This helps to
> > track the history, simplifies searches, etc.
> >
> > But is it really important whether someone puts a colon, a dash, or just
> a
> > space after the ticket number? I believe there is no difference
> whatsoever,
> > and it doesn't make sense to overcomplicate. This will only make it
> harder
> > for new contributors to join the community.
> >
> > -Val
> >
> > On Thu, Mar 19, 2020 at 3:59 PM Ivan Pavlukhin 
> wrote:
> >
> > > Andrey,
> > >
> > > I am working with about 4 projects. And I do not want to bother myself
> > > whether colon in a commit message is required or prohibited. And I
> > > believe that we should encourage to contribute not only those whose
> > > full-time job is contribution to Ignite. So, a contribution process
> > > should be as simple as possible. It is simple when it follows common
> > > sense and practices, but not some project UNNECESSARY rules.
> > >
> > > > What could be simpler than exactly one format without any optional
> > > things? :)
> > > A format that conforms with common sense and practices is much simpler.
> > >
> > > > I don't understand why examples of other project should be
> considered at
> > > all.
> > > To illustrate that there is a common practice to use colon. Also
> > > treating colon optional seems to be a common practice at all.
> > >
> > > And please answer the question from my previous message:
> > > > Is there any any harm from a "colon" in a commit message?
> > >
> > > In my opinion current state with commit messages prefixes is totally
> > > fine and there is no need to change anything.
> > >
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > > пт, 20 мар. 2020 г. в 01:40, Andrey Gura :
> > > >
> > > > Ivan,
> > > >
> > > > What could be simpler than exactly one format without any optional
> > > things? :)
> > > >
> > > > I don't understand why examples of other project should be considered
> > > > at all. Most of commit messages in Apache Ignite have described
> format
> > > > without additional symbols. It is absolutely okay to require to
> follow
> > > > such rules.
> > > >
> > > > On Fri, Mar 20, 2020 at 1:05 AM Ivan Pavlukhin 
> > > wrote:
> > > > >
> > > > > Andrey,
> > > > >
> > > > > Personally I would consider a proper format (where colon is
> optional):
> > > > >
> > > > > IGNITE-[:] my message
> > > > >
> > > > > Is there any any harm from a "colon" in a commit message? While we
> are
> > > > > working in open source simplification is very important. And I
> suggest
> > > > > to not bother contributors and committers with unnecessary rules.
> Not
> > > > > all of us contribute only in Ignite and both formats (with colon
> and
> > > > > not) are common [1, 2, 3].
> > > > >
> > > > > [1] https://github.com/apache/kafka/commits/trunk
> > > > > [2] https://github.com/apache/hive/commits/trunk
> > > > > [3] https://github.com/openjdk/jdk/commits/master
> > > > >
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > > чт, 19 мар. 2020 г. в 23:15, Alexey Zinoviev <
> zaleslaw@gmail.com>:
> > > > > >
> > > > > > Ok, lets keep in mind and remind during PRs to each other
> > > > > >
> > > > > > чт, 19 мар. 2020 г., 17:32 Andrey Gura :
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > please, notice that right commit message format the following:
> > > > > > >
> > > > > > > IGNITE- my message
> > > > > > >
> > > > > > > There is no colon (:) after . There is no hyphen (-)
> between
> > > 
> > > > > > > and message. There is only one space.
> > > > > > >
> > > > > > > How to contribute doc [1] doesn't state this as requirement and
> > > just
> > > > > > > contains some examples of commit message/PR title. But there
> are no
> > > > > > > docs that requires colon and/or hyphen. So the best approach
> here
> > > is
> > > > > > > *uniformity*.
> > > > > > >
> > > > > > > [1]
> > > 

Re: Commit message format

[Andrey Gura]

Ivan, Val,

> But is it really important whether someone puts a colon, a dash, or just a
> space after the ticket number?

Absolutely not important. But every time when you want to write script
for processing commit messages in some way you should check what
exactly format committers use.

I do not want to argue about this. But it always better to follow some
rules then not.

On Fri, Mar 20, 2020 at 3:01 AM Valentin Kulichenko
 wrote:
>
> I agree with Ivan. All contribution rules should be reasonable and should
> *add value*.
>
> For example, a requirement to include the ticket number is a great idea as
> it creates a clear link between a commit and a JIRA ticket. This helps to
> track the history, simplifies searches, etc.
>
> But is it really important whether someone puts a colon, a dash, or just a
> space after the ticket number? I believe there is no difference whatsoever,
> and it doesn't make sense to overcomplicate. This will only make it harder
> for new contributors to join the community.
>
> -Val
>
> On Thu, Mar 19, 2020 at 3:59 PM Ivan Pavlukhin  wrote:
>
> > Andrey,
> >
> > I am working with about 4 projects. And I do not want to bother myself
> > whether colon in a commit message is required or prohibited. And I
> > believe that we should encourage to contribute not only those whose
> > full-time job is contribution to Ignite. So, a contribution process
> > should be as simple as possible. It is simple when it follows common
> > sense and practices, but not some project UNNECESSARY rules.
> >
> > > What could be simpler than exactly one format without any optional
> > things? :)
> > A format that conforms with common sense and practices is much simpler.
> >
> > > I don't understand why examples of other project should be considered at
> > all.
> > To illustrate that there is a common practice to use colon. Also
> > treating colon optional seems to be a common practice at all.
> >
> > And please answer the question from my previous message:
> > > Is there any any harm from a "colon" in a commit message?
> >
> > In my opinion current state with commit messages prefixes is totally
> > fine and there is no need to change anything.
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > пт, 20 мар. 2020 г. в 01:40, Andrey Gura :
> > >
> > > Ivan,
> > >
> > > What could be simpler than exactly one format without any optional
> > things? :)
> > >
> > > I don't understand why examples of other project should be considered
> > > at all. Most of commit messages in Apache Ignite have described format
> > > without additional symbols. It is absolutely okay to require to follow
> > > such rules.
> > >
> > > On Fri, Mar 20, 2020 at 1:05 AM Ivan Pavlukhin 
> > wrote:
> > > >
> > > > Andrey,
> > > >
> > > > Personally I would consider a proper format (where colon is optional):
> > > >
> > > > IGNITE-[:] my message
> > > >
> > > > Is there any any harm from a "colon" in a commit message? While we are
> > > > working in open source simplification is very important. And I suggest
> > > > to not bother contributors and committers with unnecessary rules. Not
> > > > all of us contribute only in Ignite and both formats (with colon and
> > > > not) are common [1, 2, 3].
> > > >
> > > > [1] https://github.com/apache/kafka/commits/trunk
> > > > [2] https://github.com/apache/hive/commits/trunk
> > > > [3] https://github.com/openjdk/jdk/commits/master
> > > >
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > > чт, 19 мар. 2020 г. в 23:15, Alexey Zinoviev :
> > > > >
> > > > > Ok, lets keep in mind and remind during PRs to each other
> > > > >
> > > > > чт, 19 мар. 2020 г., 17:32 Andrey Gura :
> > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > please, notice that right commit message format the following:
> > > > > >
> > > > > > IGNITE- my message
> > > > > >
> > > > > > There is no colon (:) after . There is no hyphen (-) between
> > 
> > > > > > and message. There is only one space.
> > > > > >
> > > > > > How to contribute doc [1] doesn't state this as requirement and
> > just
> > > > > > contains some examples of commit message/PR title. But there are no
> > > > > > docs that requires colon and/or hyphen. So the best approach here
> > is
> > > > > > *uniformity*.
> > > > > >
> > > > > > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> > > > > >
> >

In-Memory Computing Essentials Webinar, March 25th - New Edition

[Denis Magda]

Hi Igniters,

I thought that some of you could benefit from joining a webinar about
in-memory computing essentials [1] on March 25th, where Ignite is used as a
reference platform for explanation/demonstration of the main topics. Some
of you might have watched the original version, that had bee recorded
almost 3 years ago [2], and the list of the top watched Ignite videos on
YouTube.

A lot has changed since the time of the recording.  The content/demos have
been revisited and rebuilt from scratch for the upcoming session. I will be
pleased to see you joining me next Wednesday; you can find the agenda by
following the link [1].

[1] https://bit.ly/3acCtEY
[2] https://www.youtube.com/watch?v=G22L2KW9gEQ

-
Denis

[jira] [Created] (IGNITE-12820) Calcite integration. Do not use AbstarctConverter while planning.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12820:
-

 Summary: Calcite integration. Do not use AbstarctConverter while 
planning.
 Key: IGNITE-12820
 URL: https://issues.apache.org/jira/browse/IGNITE-12820
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Seliverstov


We need to change traits explicitly without AbstractConverter's and appropriate 
rules.



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

[jira] [Created] (IGNITE-12819) Calcite integration. Cost system.

[Igor Seliverstov (Jira)]

Igor Seliverstov created IGNITE-12819:
-

 Summary: Calcite integration. Cost system.
 Key: IGNITE-12819
 URL: https://issues.apache.org/jira/browse/IGNITE-12819
 Project: Ignite
  Issue Type: Task
Reporter: Igor Seliverstov


Current implementation doesn't suit our needs for particular reasons. We need 
to introduce our own one taking into account such parameters as IO operations, 
memory usage, CPU usage, disk usage etc.



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

[Community] Ignite 2.8 User Survey

[Kseniya Romanova]

Hi, Ignite Users and Enthusiasts!


Please take a few minutes to go through the small survey[1] about Ignite
2.8. The survey has only three questions and is anonymous. Your answers
will help contributors to understand which changes were most interesting
and relevant to users.

Please answer before April 5th, and I will share results with the community
after April 7th.

Cheers,

Kseniya

[1]
https://docs.google.com/forms/d/e/1FAIpQLScQIRn7cXJeAgT_wTqa54ekG0UZjmFjf_av8_jstP6R7roUpQ/viewform

Re: [DISCUSSION] Changes in Ignite release process related to documentation

[Denis Magda]

Hi Maxim,

Those JIRA labels support the current process that assumes the creation of
a documentation ticket before a development ticket is closed. If a
contributor believes there is no need to update the docs (like in the case
of bug fixes) then "Documentation required" will stay disabled. Otherwise,
we need to work on the docs and "Documentation required" needs to be on,
and a docs ticket has to be created. That's the current process... that
should be revisited and changed. I've recorded that item of us in this
discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Major-changes-in-Ignite-in-2020-td46579.html

Generally, I like the idea shared by Andrey Gura that documentation and
APIs need to be updated and prepared before a primary development ticket is
closed. As a side effect, we'll get rid off "Documentation required" label.

-
Denis


On Fri, Mar 20, 2020 at 7:03 AM Maxim Muzafarov  wrote:

> Denis,
>
> From my recent practice with the release check-boxes "Release notes
> required" and "Documentation required" also was not so helpful as
> expected. Can we remove them from JIRA issues?
>
> There is no magic pill to not forget to document improvements, but I
> think a wide discussion of each major improvement on the dev-list can
> help much to keep documentation up to date.
>
> On Thu, 19 Mar 2020 at 23:18, Alexey Zinoviev 
> wrote:
> >
> > The Best way to require draft documentation with the proposed PR:) as a
> > part of TC check
> >
> > чт, 19 мар. 2020 г., 21:06 Denis Magda :
> >
> > > Igniters,
> > >
> > > I've modified our release process introducing this step that ensures
> > > documentation readiness before a vote can be started:
> > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.1EnsureDocumentationReadinessandAccouncementBlogPostActivity
> > >
> > > Thanks to everyone who joined this conversation.
> > >
> > > -
> > > Denis
> > >
> > >
> > > On Wed, Mar 18, 2020 at 2:17 AM Artem Budnikov <
> > > a.budnikov.ign...@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Both yours and Andrey's proposal are important. You should start to
> vote
> > > > after the documentation is ready, just like you start to vote after
> all
> > > > features are ready, and documentation is just another feature.
> However,
> > > the
> > > > documentation can't be prepared if there is no information on the
> > > features.
> > > > Implementing the feature and working on the docs should go in
> tandem. As
> > > > Andrey pointed out it brings some benefits, and makes you more
> > > > conscious about the "user" aspect of the feature, which is generally
> a
> > > good
> > > > thing.
> > > >
> > > > -Artem
> > > >
> > > > On Tue, Mar 17, 2020 at 11:59 PM Denis Magda 
> wrote:
> > > >
> > > > > Hi Pavel,
> > > > >
> > > > > We're thinking about the same in regards to the future of Ignite
> > > > > documentation :) Artem and I had some kitchen talks recently and
> we'll
> > > > > restart that activity. Ignite definitely deserves and requires
> next-gen
> > > > > docs. Artem promised to share his thoughts soon.
> > > > >
> > > > > Btw, check out How to write effective documentation for your
> > > open-source
> > > > > projec t
> article
> > > > that I
> > > > > found in one of my newsletters today. It feels like it can be used
> as a
> > > > > reference by Igniters on some best practices.
> > > > >
> > > > > Denis Magda
> > > > >
> > > > >
> > > > > On Tue, Mar 17, 2020 at 1:03 PM Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I agree with Andrey.
> > > > > >
> > > > > > And I'd like to reopen the discussion on "moving docs from
> readme.io
> > > > to
> > > > > > git" [1] [2]
> > > > > > Looks like we reached some agreement there but never moved on
> with
> > > the
> > > > > > migration.
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html
> > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-7595
> > > > > >
> > > > > > On Tue, Mar 17, 2020 at 9:48 PM Denis Magda 
> > > wrote:
> > > > > >
> > > > > > > Andrey,
> > > > > > >
> > > > > > > Thanks for sharing your thoughts. Your second point made me
> recall
> > > > > > several
> > > > > > > occasions when only after a release of some public APIs we had
> a
> > > > chance
> > > > > > to
> > > > > > > complete documentation and discovered the APIs'
> ineffectiveness and
> > > > > > oddness
> > > > > > > from the user usage perspective. But it was already late.
> > > > > > >
> > > > > > > Generally, if to move incrementally with documentation process
> > > > changes,
> > > > > > > "documentation readiness before the vote" should work as the
> first
> > > > step
> > > > > > for
> > > > > > > us. There will be delays with the vote for sure because we
> have to
> > 

[jira] [Created] (IGNITE-12818) SoLinger is not set for reader-sockets in discovery

[Vladislav Pyatkov (Jira)]

Vladislav Pyatkov created IGNITE-12818:
--

 Summary: SoLinger is not set for reader-sockets in discovery
 Key: IGNITE-12818
 URL: https://issues.apache.org/jira/browse/IGNITE-12818
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov


{noformat}
Thread [name="tcp-disco-client-message-worker-#29%DPL_GRID%DplGridNodeName%", 
id=543, state=RUNNABLE, blockCnt=0, waitCnt=109538]
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
at 
sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:879)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:850)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
- locked sun.security.ssl.AppOutputStream@6e6441c6
at java.io.OutputStream.write(OutputStream.java:75)
at 
o.a.i.spi.discovery.tcp.TcpDiscoverySpi.writeToSocket(TcpDiscoverySpi.java:1613)
at 
o.a.i.spi.discovery.tcp.ServerImpl$ClientMessageWorker.processMessage(ServerImpl.java:7281)
at 
o.a.i.spi.discovery.tcp.ServerImpl$ClientMessageWorker.processMessage(ServerImpl.java:7156)
at 
o.a.i.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7538)
at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
at 
o.a.i.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7469)
at o.a.i.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)

Thread [name="grid-timeout-worker-#39%DPL_GRID%DplGridNodeName%", id=230, 
state=WAITING, blockCnt=49, waitCnt=902487]
Lock [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@7dcea545, 
ownerName=tcp-disco-client-message-worker-#29%DPL_GRID%DplGridNodeName%, 
ownerId=543]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at 
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:848)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720)
at sun.security.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:2066)
at sun.security.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1893)
at sun.security.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1656)
- locked sun.security.ssl.SSLSocketImpl@5c2090f8
at sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1594)
at o.a.i.i.util.IgniteUtils.closeQuiet(IgniteUtils.java:4089)
at 
o.a.i.spi.discovery.tcp.TcpDiscoverySpi$SocketTimeoutObject.onTimeout(TcpDiscoverySpi.java:2462)
at 
o.a.i.i.processors.timeout.GridSpiTimeoutObject.onTimeout(GridSpiTimeoutObject.java:42)
at 
o.a.i.i.processors.timeout.GridTimeoutProcessor$TimeoutWorker.body(GridTimeoutProcessor.java:279)
at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Need to use SoLinger for socket got through `sock = srvrSock.accept();` like it 
used in `TcpDiscoverySpi#createSocket`.



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

Re: [DISCUSSION] Changes in Ignite release process related to documentation

[Maxim Muzafarov]

Denis,

>From my recent practice with the release check-boxes "Release notes
required" and "Documentation required" also was not so helpful as
expected. Can we remove them from JIRA issues?

There is no magic pill to not forget to document improvements, but I
think a wide discussion of each major improvement on the dev-list can
help much to keep documentation up to date.

On Thu, 19 Mar 2020 at 23:18, Alexey Zinoviev  wrote:
>
> The Best way to require draft documentation with the proposed PR:) as a
> part of TC check
>
> чт, 19 мар. 2020 г., 21:06 Denis Magda :
>
> > Igniters,
> >
> > I've modified our release process introducing this step that ensures
> > documentation readiness before a vote can be started:
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process#ReleaseProcess-4.1EnsureDocumentationReadinessandAccouncementBlogPostActivity
> >
> > Thanks to everyone who joined this conversation.
> >
> > -
> > Denis
> >
> >
> > On Wed, Mar 18, 2020 at 2:17 AM Artem Budnikov <
> > a.budnikov.ign...@gmail.com>
> > wrote:
> >
> > > Denis,
> > >
> > > Both yours and Andrey's proposal are important. You should start to vote
> > > after the documentation is ready, just like you start to vote after all
> > > features are ready, and documentation is just another feature. However,
> > the
> > > documentation can't be prepared if there is no information on the
> > features.
> > > Implementing the feature and working on the docs should go in tandem. As
> > > Andrey pointed out it brings some benefits, and makes you more
> > > conscious about the "user" aspect of the feature, which is generally a
> > good
> > > thing.
> > >
> > > -Artem
> > >
> > > On Tue, Mar 17, 2020 at 11:59 PM Denis Magda  wrote:
> > >
> > > > Hi Pavel,
> > > >
> > > > We're thinking about the same in regards to the future of Ignite
> > > > documentation :) Artem and I had some kitchen talks recently and we'll
> > > > restart that activity. Ignite definitely deserves and requires next-gen
> > > > docs. Artem promised to share his thoughts soon.
> > > >
> > > > Btw, check out How to write effective documentation for your
> > open-source
> > > > projec t article
> > > that I
> > > > found in one of my newsletters today. It feels like it can be used as a
> > > > reference by Igniters on some best practices.
> > > >
> > > > Denis Magda
> > > >
> > > >
> > > > On Tue, Mar 17, 2020 at 1:03 PM Pavel Tupitsyn 
> > > > wrote:
> > > >
> > > > > I agree with Andrey.
> > > > >
> > > > > And I'd like to reopen the discussion on "moving docs from readme.io
> > > to
> > > > > git" [1] [2]
> > > > > Looks like we reached some agreement there but never moved on with
> > the
> > > > > migration.
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Move-documentation-from-readme-io-to-GitHub-pages-td16409.html
> > > > > [2] https://issues.apache.org/jira/browse/IGNITE-7595
> > > > >
> > > > > On Tue, Mar 17, 2020 at 9:48 PM Denis Magda 
> > wrote:
> > > > >
> > > > > > Andrey,
> > > > > >
> > > > > > Thanks for sharing your thoughts. Your second point made me recall
> > > > > several
> > > > > > occasions when only after a release of some public APIs we had a
> > > chance
> > > > > to
> > > > > > complete documentation and discovered the APIs' ineffectiveness and
> > > > > oddness
> > > > > > from the user usage perspective. But it was already late.
> > > > > >
> > > > > > Generally, if to move incrementally with documentation process
> > > changes,
> > > > > > "documentation readiness before the vote" should work as the first
> > > step
> > > > > for
> > > > > > us. There will be delays with the vote for sure because we have to
> > > get
> > > > > used
> > > > > > to this change, but over time we should get to the point when
> > > > > documentation
> > > > > > will be prepared upon overall task resolution. Andrey, Artem, do
> > you
> > > > > agree
> > > > > > with that?
> > > > > >
> > > > > > Other community members, please share your thoughts. If we don't
> > hear
> > > > any
> > > > > > opposite opinions, then I would update our release procedures with
> > > this
> > > > > > change.
> > > > > >
> > > > > > -
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Mon, Mar 16, 2020 at 9:44 AM Andrey Gura 
> > > wrote:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > I agree with you.
> > > > > > >
> > > > > > > Also I think that we should move to process which will require
> > > > > > > documentation updates during work on issue/feature and will part
> > of
> > > > > > > code review process. Such approach has some useful benefits:
> > > > > > >
> > > > > > > - Documentation readiness at the same time when
> > fix/implementation
> > > is
> > > > > > > ready (remember, documentation is part of a product).
> > > > > > > - Work on documentation and review could discover incompleteness
> > > of a
> > > > > > > 

[jira] [Created] (IGNITE-12817) Streamer threads don't update timestamp

[Anton Kalashnikov (Jira)]

Anton Kalashnikov created IGNITE-12817:
--

 Summary: Streamer threads don't update timestamp
 Key: IGNITE-12817
 URL: https://issues.apache.org/jira/browse/IGNITE-12817
 Project: Ignite
  Issue Type: Bug
  Components: streaming
Reporter: Anton Kalashnikov


Scenario:
1. Start 3 data nodes 
2. Start load with a streamer on 6 clients
3. Start data nodes restarter

Result:
Keys weren't loaded in all (1000) caches.
In the server node log I see:
{noformat}
[2019-07-17 16:52:36,881][ERROR][tcp-disco-msg-worker-#2] Blocked 
system-critical thread has been detected. This can lead to cluster-wide 
undefined behaviour [threadName=data-streamer-stripe-7, blockedFor=16s]
[2019-07-17 16:52:36,883][WARN ][tcp-disco-msg-worker-#2] Thread 
[name="data-streamer-stripe-7-#24", id=43, state=WAITING, blockCnt=111, 
waitCnt=169964]
[2019-07-17 16:52:36,885][ERROR][tcp-disco-msg-worker-#2] Critical system error 
detected. Will be handled accordingly to configured handler 
[hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, 
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet 
[SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], 
failureCtx=FailureContext [type=SYSTEM_WORKER_BLOCKED, err=class 
o.a.i.IgniteException: GridWorker [name=data-streamer-stripe-7, 
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]]]
org.apache.ignite.IgniteException: GridWorker [name=data-streamer-stripe-7, 
igniteInstanceName=null, finished=false, heartbeatTs=1563371540069]
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1838)
 ~[ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1833)
 ~[ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:230)
 ~[ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297) 
~[ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2804)
 ~[ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7568)
 [ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2866)
 [ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) 
[ignite-core-2.5.9.jar:2.5.9]
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7506)
 [ignite-core-2.5.9.jar:2.5.9]
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) 
[ignite-core-2.5.9.jar:2.5.9]
{noformat}



The problem is in data streamer threads. They should update progress timestamps.



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

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

[Maxim Muzafarov]

Igniters,

I support Nikolay Izhikov as the release manager of 2.8.1 Apache
Ignite release. Since no one else of committers, PMCs expressed a
desire to lead this release I think we can close this question and
focus on the release scope and dates.


Ivan,

You helped me configuring TC.Bot that time, can you please help again
and set `ignite-2.8.1` branch for guard under TC.Bot [1]? We should
start collecting TC statistics for the release branch as early as
possible.


[1] https://mtcga.gridgain.com/guard.html

On Fri, 20 Mar 2020 at 14:48, Taras Ledkov  wrote:
>
> Hi,
>
> I propose to add the issue [1] related to SQL query execution to this scope.
>
> We had omitted this case and Ignite 2.8 contains serious SQL issue:
> cursor of a local query is not thread-safe.
> It is root cause of several SQL issue, e.g. JDBC thin client cannot
> execute query  from replicated cache,
> PME may hang after execute such queries from JDBC thin, etc.
>
> [1]. https://issues.apache.org/jira/browse/IGNITE-12800
>
> On 19.03.2020 17:52, Denis Magda wrote:
> > Igniters,
> >
> > As long as 2.8.1 is inevitable and we already keep adding critical issues
> > to the working queue, let's settle on the release time frames and decide
> > who will be a release manager. This is the time proposed by Maxim and,
> > personally, I concur with such a schedule:
> >
> > - Scope Freeze: April 15, 2020
> > - Code Freeze: April 22, 2020
> > - Voting Date: April 27, 2020
> > - Release Date: May 1, 2020
> >
> > Do we agree on this time? Is there anybody who ready to drive the release
> > as a release manager?
> >
> > -
> > Denis
> >
> >
> > On Thu, Mar 19, 2020 at 5:50 AM Sergey Antonov 
> > wrote:
> >
> >> Folks,
> >>
> >> I'd like to add ticket IGNITE-12774 Transaction hangs after too many open
> >> files NIO exception [1] to ignite-2.8.1 scope.
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-12774
> >>
> >> ср, 18 мар. 2020 г. в 16:53, Maxim Muzafarov :
> >>
> >>> Folks,
> >>>
> >>> Can we add ignite-2.8.1 [2] branch under TC.Bot protection [1]?
> >>>
> >>>
> >>> [1] https://mtcga.gridgain.com/guard.html
> >>> [2] https://github.com/apache/ignite/tree/ignite-2.8.1
> >>>
> >>> On Mon, 16 Mar 2020 at 16:32, Alexey Goncharuk
> >>>  wrote:
>  Folks,
> 
>  I've walked through all the commits to master since 2.8 branch was cut
> >>> and
>  filtered some tickets that in my opinion are worth including to 2.8.1
>  release below (note that they are ready end the effort of including
> >> them
> >>> to
>  the release should be low as long as there are no implicit dependencies
>  between tickets). Please share your opinion on whether we should
> >> include
>  them to the 2.8.1.
> 
>  IGNITE-12717 SQL: index creation refactoring
>  IGNITE-12590 MERGE INTO query is failing on Ignite client node
>  IGNITE-12671 Update of partition's states can stuck when rebalance
>  completed during exchange
>  IGNITE-11798 Memory leak on unstable topology caused by partition
>  reservation
>  IGNITE-12665 SQL: Potential race on MapResult close.
>  IGNITE-12605 Historical (WAL) rebalance can start on a cleared
> >> partition
> >>> if
>  some baseline node leaves the cluster and then joins back.
>  IGNITE-12654 Some of rentingFutures in GridDhtPartitionTopologyImpl may
>  accumulate a huge number of eviction callbacks
>  IGNITE-12631 Incorrect rewriting wal record type in marshalled mode
> >>> during
>  iteration
>  IGNITE-12621 Node leave may cause NullPointerException during IO
> >> message
>  processing if security is enabled
>  IGNITE-12636 Full rebalance instead of a historical one
>  IGNITE-12618 Affinity cache for version of last server event can be
> >> wiped
>  from history
>  IGNITE-12013 NullPointerException is thrown by ExchangeLatchManager
> >>> during
>  cache creation
>  IGNITE-11797 Fix consistency issues for atomic and mixed tx-atomic
> >> cache
>  groups.
>  IGNITE-12557 Destroy of big cache which is not only cache in cache
> >> group
>  causes IgniteOOME
>  IGNITE-12567 H2Tree goes into illegal state when non-indexed columns
> >> are
>  dropped
>  IGNITE-12569 Can't set serialized enum to a BinaryObject's field
>  IGNITE-12460 Cluster fails to find the node by consistent ID
>  IGNITE-12459 Searching checkpoint record in WAL doesn't work with
> >> segment
>  compaction
>  IGNITE-12548 Possible tx desync during recovery on near node left.
>  IGNITE-12546 Prevent partitions owned by other nodes switch their state
> >>> to
>  MOVING due to counter difference on node join.
>  IGNITE-12551 Partition desync if a partition is evicted then owned
> >> again
>  and historically rebalanced
>  IGNITE-12536 Inconsistency between cache data and indexes when cache
>  operation is interrupted
>  IGNITE-12403 Throttle page difference output in PageMemoryTracker
> 

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

[Taras Ledkov]

Hi,

I propose to add the issue [1] related to SQL query execution to this scope.

We had omitted this case and Ignite 2.8 contains serious SQL issue: 
cursor of a local query is not thread-safe.
It is root cause of several SQL issue, e.g. JDBC thin client cannot 
execute query  from replicated cache,

PME may hang after execute such queries from JDBC thin, etc.

[1]. https://issues.apache.org/jira/browse/IGNITE-12800

On 19.03.2020 17:52, Denis Magda wrote:

Igniters,

As long as 2.8.1 is inevitable and we already keep adding critical issues
to the working queue, let's settle on the release time frames and decide
who will be a release manager. This is the time proposed by Maxim and,
personally, I concur with such a schedule:

- Scope Freeze: April 15, 2020
- Code Freeze: April 22, 2020
- Voting Date: April 27, 2020
- Release Date: May 1, 2020

Do we agree on this time? Is there anybody who ready to drive the release
as a release manager?

-
Denis


On Thu, Mar 19, 2020 at 5:50 AM Sergey Antonov 
wrote:


Folks,

I'd like to add ticket IGNITE-12774 Transaction hangs after too many open
files NIO exception [1] to ignite-2.8.1 scope.

[1] https://issues.apache.org/jira/browse/IGNITE-12774

ср, 18 мар. 2020 г. в 16:53, Maxim Muzafarov :


Folks,

Can we add ignite-2.8.1 [2] branch under TC.Bot protection [1]?


[1] https://mtcga.gridgain.com/guard.html
[2] https://github.com/apache/ignite/tree/ignite-2.8.1

On Mon, 16 Mar 2020 at 16:32, Alexey Goncharuk
 wrote:

Folks,

I've walked through all the commits to master since 2.8 branch was cut

and

filtered some tickets that in my opinion are worth including to 2.8.1
release below (note that they are ready end the effort of including

them

to

the release should be low as long as there are no implicit dependencies
between tickets). Please share your opinion on whether we should

include

them to the 2.8.1.

IGNITE-12717 SQL: index creation refactoring
IGNITE-12590 MERGE INTO query is failing on Ignite client node
IGNITE-12671 Update of partition's states can stuck when rebalance
completed during exchange
IGNITE-11798 Memory leak on unstable topology caused by partition
reservation
IGNITE-12665 SQL: Potential race on MapResult close.
IGNITE-12605 Historical (WAL) rebalance can start on a cleared

partition

if

some baseline node leaves the cluster and then joins back.
IGNITE-12654 Some of rentingFutures in GridDhtPartitionTopologyImpl may
accumulate a huge number of eviction callbacks
IGNITE-12631 Incorrect rewriting wal record type in marshalled mode

during

iteration
IGNITE-12621 Node leave may cause NullPointerException during IO

message

processing if security is enabled
IGNITE-12636 Full rebalance instead of a historical one
IGNITE-12618 Affinity cache for version of last server event can be

wiped

from history
IGNITE-12013 NullPointerException is thrown by ExchangeLatchManager

during

cache creation
IGNITE-11797 Fix consistency issues for atomic and mixed tx-atomic

cache

groups.
IGNITE-12557 Destroy of big cache which is not only cache in cache

group

causes IgniteOOME
IGNITE-12567 H2Tree goes into illegal state when non-indexed columns

are

dropped
IGNITE-12569 Can't set serialized enum to a BinaryObject's field
IGNITE-12460 Cluster fails to find the node by consistent ID
IGNITE-12459 Searching checkpoint record in WAL doesn't work with

segment

compaction
IGNITE-12548 Possible tx desync during recovery on near node left.
IGNITE-12546 Prevent partitions owned by other nodes switch their state

to

MOVING due to counter difference on node join.
IGNITE-12551 Partition desync if a partition is evicted then owned

again

and historically rebalanced
IGNITE-12536 Inconsistency between cache data and indexes when cache
operation is interrupted
IGNITE-12403 Throttle page difference output in PageMemoryTracker
IGNITE-12523 Continuously generated thread dumps in failure processor

slow

down the whole system
IGNITE-12489 Error during purges by expiration: Unknown page type


--
BR, Sergey Antonov


--
Taras Ledkov
Mail-To: tled...@gridgain.com

[jira] [Created] (IGNITE-12816) Create a table for the existing cache

[Surkov Aleksandr (Jira)]

Surkov Aleksandr created IGNITE-12816:
-

 Summary: Create a table for the existing cache
 Key: IGNITE-12816
 URL: https://issues.apache.org/jira/browse/IGNITE-12816
 Project: Ignite
  Issue Type: Improvement
Reporter: Surkov Aleksandr


It would be great to create a table on an existing cache.

1. Created a cache (without SQL)
2. Insert data
3. We want to make SQL queries (data cannot be deleted). OK. Create a table for 
the existing cache.
4. Make SQL queries



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

IGNITE-8152

[Aleksei Litsov]

Hello Igniters!

I corrected all the comments. If there are no more comments, please accept the 
PR.

Ticket: https://issues.apache.org/jira/browse/IGNITE-8152
PR: https://github.com/apache/ignite/pull/7521

Thanks in advance!

[jira] [Created] (IGNITE-12815) [IEP-39] Management API to cancel SQL queries.

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12815:


 Summary: [IEP-39] Management API to cancel SQL queries.
 Key: IGNITE-12815
 URL: https://issues.apache.org/jira/browse/IGNITE-12815
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov


Ignite provides many API to deploy and execute user-provided code on the server 
nodes inside the same JVM as the Ignite process runs.
Ignite has many APIs that allocate many resources on the server nodes, also. 
In case of some buggy code that consumes many system resources(CPU, RAM, flood 
network) or heavy query the whole cluster can become unstable.

We should provide to the cluster administrator the ability to stop any user 
deployed task.

JMX beans to cancel listed tasks should be introduced:

* Compute task

In the scope of IEP-35 System view API introduced.
A new API should use the same identifier that is used in corresponding System 
View.



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

[jira] [Created] (IGNITE-12814) [IEP-39] Management API to cancel continuous queries.

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12814:


 Summary: [IEP-39] Management API to cancel continuous queries.
 Key: IGNITE-12814
 URL: https://issues.apache.org/jira/browse/IGNITE-12814
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov


Ignite provides many API to deploy and execute user-provided code on the server 
nodes inside the same JVM as the Ignite process runs.
Ignite has many APIs that allocate many resources on the server nodes, also. 
In case of some buggy code that consumes many system resources(CPU, RAM, flood 
network) or heavy query the whole cluster can become unstable.

We should provide to the cluster administrator the ability to stop any user 
deployed task.

JMX beans to cancel listed tasks should be introduced:

* Compute task

In the scope of IEP-35 System view API introduced.
A new API should use the same identifier that is used in corresponding System 
View.



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

[jira] [Created] (IGNITE-12813) [IEP-39] Management API to cancel scan queries.

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12813:


 Summary: [IEP-39] Management API to cancel scan queries.
 Key: IGNITE-12813
 URL: https://issues.apache.org/jira/browse/IGNITE-12813
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov


Ignite provides many API to deploy and execute user-provided code on the server 
nodes inside the same JVM as the Ignite process runs.
Ignite has many APIs that allocate many resources on the server nodes, also. 
In case of some buggy code that consumes many system resources(CPU, RAM, flood 
network) or heavy query the whole cluster can become unstable.

We should provide to the cluster administrator the ability to stop any user 
deployed task.

JMX beans to cancel listed tasks should be introduced:

* Compute task

In the scope of IEP-35 System view API introduced.
A new API should use the same identifier that is used in corresponding System 
View.



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

[jira] [Created] (IGNITE-12812) [IEP-39] Management API to cancel transaction.

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12812:


 Summary: [IEP-39] Management API to cancel transaction.
 Key: IGNITE-12812
 URL: https://issues.apache.org/jira/browse/IGNITE-12812
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov


Ignite provides many API to deploy and execute user-provided code on the server 
nodes inside the same JVM as the Ignite process runs.
Ignite has many APIs that allocate many resources on the server nodes, also. 
In case of some buggy code that consumes many system resources(CPU, RAM, flood 
network) or heavy query the whole cluster can become unstable.

We should provide to the cluster administrator the ability to stop any user 
deployed task.

JMX beans to cancel listed tasks should be introduced:

* Compute task

In the scope of IEP-35 System view API introduced.
A new API should use the same identifier that is used in corresponding System 
View.



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

[jira] [Created] (IGNITE-12811) [IEP-39] Management API to cancel services.

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12811:


 Summary: [IEP-39] Management API to cancel services.
 Key: IGNITE-12811
 URL: https://issues.apache.org/jira/browse/IGNITE-12811
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov


Ignite provides many API to deploy and execute user-provided code on the server 
nodes inside the same JVM as the Ignite process runs.
Ignite has many APIs that allocate many resources on the server nodes, also. 
In case of some buggy code that consumes many system resources(CPU, RAM, flood 
network) or heavy query the whole cluster can become unstable.

We should provide to the cluster administrator the ability to stop any user 
deployed task.

JMX beans to cancel listed tasks should be introduced:

* Compute task

In the scope of IEP-35 System view API introduced.
A new API should use the same identifier that is used in corresponding System 
View.



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

[jira] [Created] (IGNITE-12810) [IEP-39] Management API to cancel compute tasks.

[Nikolay Izhikov (Jira)]

Nikolay Izhikov created IGNITE-12810:


 Summary: [IEP-39] Management API to cancel compute tasks.
 Key: IGNITE-12810
 URL: https://issues.apache.org/jira/browse/IGNITE-12810
 Project: Ignite
  Issue Type: Sub-task
Reporter: Nikolay Izhikov






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

RE: Security Subject of thin client on remote nodes

[Veena Mithare]

Hi Alexei, Denis,

One of the main usecases of thin client authentication is to be able to audit 
the changes done using the thin client user.
To enable that :
We really need to resolve this concern as well :
https://issues.apache.org/jira/browse/IGNITE-12781

( Incorrect security subject id is  associated with a cache_put event  when the 
originator of the event is a thin client. )

Regards,
Veena


-Original Message-
From: Alexei Scherbakov 
Sent: 18 March 2020 08:11
To: dev 
Subject: Re: Security Subject of thin client on remote nodes

Denis Garus,

Both variants are capable of solving the thin client security context problem.

My approach doesn't require any IEPs, just minor change in code and to
org.apache.ignite.internal.processors.security.IgniteSecurity#authenticate(AuthenticationContext)
contract.
We can add appropriate documentation to emphasize this.
The argument "fragile" is not very convincing for me.

I think we should collect more opinions before proceeding with IEP.

Considering a fact we actually *may not care* about compatibility (I've already 
explained why), I'm thinking of another approach.
Let's get rid of SecurityContext and use SecuritySubject instead.
SecurityContext is just a POJO wrapper over SecuritySubject's 
org.apache.ignite.plugin.security.SecuritySubject#permissions.
It's functionality can be easily moved to SecuritySubject.

What do you think?



пн, 16 мар. 2020 г. в 15:47, Denis Garus :

>  Hello, Alexei!
>
> I agree with you if we may not care about compatibility at all, then
> we can solve the problem much more straightforward way.
>
> In your case, the method GridSecurityProcessor#authenticate will have
> an implicit contract:
> [ if actx.subject() != null then
>   returns SecurityContext
> else
>   do authenticate ]
>
> It looks fragile.
>
> When we extend the GridSecurityProcessor, there isn't this problem:
> we have the explicit contract and can make default implementation that
> throws an unsupported operation exception to enforcing compatibility
> check.
>
> In any case, we need to change GridSecurityProcessor implementation.
>
> But I think your proposal to try to find a security context in the
> node's attributes first is right for backward compatibility when
> Ignite users don't use thin clients.
>
> Summary:
> I suggest adding a new method to GridSecurityProcessor because it has
> a clear contract and enforces compatibility check natural way.
>
> вс, 15 мар. 2020 г. в 17:13, Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> >:
>
> > Denis Garus,
> >
> > I've looked at the IEP proposed by you and currently I'm thinking
> > it's
> not
> > immediately required.
> >
> > The problem of missing SecurityContexts of thin clients can be
> > solved
> much
> > easily.
> >
> > Below is the stub of a fix, it requires correct implementation of
> > method
> >
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor
> #authenticatedSubject
> > by GridSecurityProcessor:
> >
> > /** {@inheritDoc} */
> > @Override public OperationSecurityContext withContext(UUID nodeId) {
> > try {
> > SecurityContext ctx0 = secCtxs.get(nodeId);
> >
> > if (ctx0 == null) {
> > ClusterNode node =
> > Optional.ofNullable(ctx.discovery().node(nodeId))
> > .orElseGet(() ->
> > ctx.discovery().historicalNode(nodeId));
> >
> > // This is a cluster node.
> > if (node != null)
> > ctx0 = nodeSecurityContext(marsh,
> > U.resolveClassLoader(ctx.config()), findNode(nodeId));
> > else {
> > // This is already authenticated thin client.
> > SecuritySubject subj =
> > authenticatedSubject(nodeId);
> >
> > assert subj != null : "Subject is null " +
> > nodeId;
> >
> > AuthenticationContext actx = new
> > AuthenticationContext();
> > actx.subject(subj);
> >
> > ctx0 = secPrc.authenticate(actx);
> > }
> > }
> >
> > secCtxs.putIfAbsent(nodeId, ctx0);
> >
> > return withContext(ctx0);
> > } catch (IgniteCheckedException e) {
> > throw new IgniteException(e);
> > }
> >
> > The idea is to create a thin client SecurityContext on a node not
> > having
> a
> > local context using existing SecuritySubject data.
> >
> > Method
> >
> org.apache.ignite.internal.processors.security.GridSecurityProcessor#a
> uthenticate
> > should check for not null SecuritySubject field and just recreate
> > SecurityContext using passed info (because it's already authenticated).
> >
> > We have all necessary information in SecuritySubject returned by
> >
> >
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor
> #authenticatedSubject
> > by GridSecurityProcessor method.
> >
> > Because it is internal API,  we may not care about compatibility at
> 

Re: [DISCUSSION] Major changes in Ignite in 2020

[Pavel Tupitsyn]

My top priorities:

   - Thin Client API extension: Compute, Continuous Queries, Services
   - .NET Near Cache: soon to come in Thick API, to be investigated for
   Thin Clients
   - .NET Modernization for Ignite 3.0: drop legacy .NET Framework support,
   target .NET Standard 2.0, add nullable annotations to the API


On Fri, Mar 20, 2020 at 5:23 AM Saikat Maitra 
wrote:

> Hi Denis,
>
> Thank you for sharing the list of top changes. The list looks good.
>
> I wanted to share that efforts regarding IEP-36 is already underway and
> there are also open PRs under review and working through review feedback.
> One of the area that we are focussing is first we will merge changes in
> ignite-extensions repo before removing the specific migrated module from
> ignite repo.
>
> There are also contribution from community on bug fixes in
> ignite-extensions repo as well which we are verifying and merging in
> ignite-extensions repo after running through CI pipeline in teamcity.
>
> I like the focus area on docs and I really like the Apache Ignite Usecases
> page https://ignite.apache.org/provenusecases.html,  I would like to
> suggest if we can add a page like powered by Apache Ignite and list few Org
> who are already using Apache Ignite in prod.
>
> Something similar to this page https://flink.apache.org/poweredby.html
>
> Regards,
> Saikat
>
>
>
>
>
>
> On Thu, Mar 19, 2020 at 1:44 PM Denis Magda  wrote:
>
>> My top list of changes is as follows:
>>
>>- Feature: New lightweight Apache Ignite website with advanced search
>>engine optimizations and updated technical content. Why? Much better
>>discoverability of Ignite via search engines like Google to let many more
>>application developers learn about Ignite existence. This change is to be
>>brought to live soon:
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Website-New-Look-td46324.html
>>
>>
>>- Feature: New Ignite documentation on a new platform and with a new
>>structure. Why? Ignite documentation has to help new application 
>> developers
>>to get up and running as quickly as possible, it also has to become a
>>primary source that answers most of the questions. Our current docs have a
>>lot of gaps: https://issues.apache.org/jira/browse/IGNITE-7595
>>
>>
>>- Process Change: to be successful with the point above,
>>documentation should be created/updated before we close a JIRA ticket for
>>code/API/feature contribution. Why? First, application developers learn
>>Ignite and create their Ignite-apps referring to API reference and
>>technical documentation (and not to the source code), thus, documentation
>>needs to be treated as an integral part of the whole project. Second, 
>> while
>>writing a new documentation paragraph we could discover incompleteness of 
>> a
>>fix/feature or usability issues before the change is released publicly.
>>
>>
>>- Feature: complete the modularization project by defining the Ignite
>>core that will be released separately from Ignite extensions. The 'why' is
>>written here:
>>
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization
>>
>> -
>> Denis
>>
>>
>> On Thu, Mar 19, 2020 at 11:21 AM Denis Magda  wrote:
>>
>>> Dear Ignite community,
>>>
>>> Many of us want to see where Ignite is heading and ask for some sort of
>>> a 2020 course/plan/roadmap and a predictable schedule of major releases.
>>> Also, there are intentions to enhance some internal processes and
>>> collaboration approaches.
>>>
>>> Let's start moving in that direction by defining 3-5 major changes you
>>> would like to contribute this year personally or will be glad to drive
>>> (like processes changes) and work together with someone else. Dear, Ignite
>>> user community, please share your suggestions as well.
>>>
>>> Note, let's use this thread to collect major
>>> topics/directions/features/changes. Just respond with your proposals. Don't
>>> go into arguments if you don't agree with someone's opinions. Once the
>>> topics are collected, we'll create a wiki page and, most likely, will start
>>> working through specific items in focus groups and only then lay out a
>>> cohesive plan with some dates.
>>>
>>> -
>>> Denis
>>>
>>