[MTCGA]: new failures in builds [5620469] 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 Critical Failure in master PDS 1 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds1?branch=%3Cdefault%3E
 Changes may lead to failure were done by 
 - mikhail petrov <32207922+ololo3...@users.noreply.github.com> 
https://ci.ignite.apache.org/viewModification.html?modId=907615
 - tledkov  
https://ci.ignite.apache.org/viewModification.html?modId=907588
 - mikhail petrov <32207922+ololo3...@users.noreply.github.com> 
https://ci.ignite.apache.org/viewModification.html?modId=907603

 - 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 08:11:17 24-09-2020 

[MTCGA]: new failures in builds [5619418] 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 Critical Failure in master Cache (Restarts) 1 
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CacheRestarts1?branch=%3Cdefault%3E
 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 23:26:16 23-09-2020 

Re: [DISCUSSION] Renaming Ignite's product category

[Carbone, Adam]

Good Evening Denis,

I’m sure there are more out there as well,  I would consider platforms that the 
entire applications but that all the execution of code happens exclusively on 
the platform, and most of the applications are written to run in, not connected 
to the platform.

Hmmm by this criteria k8s could possible fit the bill…

Spark might even be considered a compute grid as well but it is not a generic 
compute framework and people don’t usually run there whole applications inside.

What is the vision for the platform? That might help in this discussion, set 
your category with the direction you are heading, and what you are trying to 
achieve.

Regards

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline 
Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



From: Denis Magda 
Date: Wednesday, September 23, 2020 at 4:14 PM
To: dev , "Carbone, Adam" 
Cc: "u...@ignite.apache.org" 
Subject: Re: [DISCUSSION] Renaming Ignite's product category

Adam,

You defined GigaSpaces as a true in-memory computing platform. What is the true 
platform for you?


-
Denis


On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam 
mailto:adam.carb...@bottomline.com>> wrote:
So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  
unique feature to Ignited, and the primary reason we ended up here; The 
integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline 
Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe" 
mailto:glenn.wi...@gridgain.com>> wrote:

I agree with Stephen about "database" devaluing what Ignite can do (though
it probably hits the majority of existing use cases). I tend to go with
"massively distributed storage and compute platform"

I know, I didn't take sides, I just have both.

Cheers,
  Glenn

On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
stephen.darling...@gridgain.com> 
wrote:

> I think this is a great question. Explaining what Ignite does is always a
> challenge, so having a useful “tag line” would be very valuable.
>
> I’m not sure what the answer is but I think calling it a “database”
> devalues all the compute facilities. "Computing platform” may be too vague
> but it at least says that we do more than “just” store data.
>
> On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> 
wrote:
>
> My vote is for the "distributed memory-first database". It clearly states
> that Ignite is a database (which is true at this point), while still
> emphasizing the in-memory computing power endorsed by the platform.
>
> The "in-memory computing platform" is an ambiguous term and doesn't really
> reflect what Ignite is, especially in its current state.
>
> -Val
>
> On Wed, Sep 16, 2020 at 3:53 PM Denis Magda 
mailto:dma...@apache.org>> wrote:
>
>> Igniters,
>>
>> Throughout the history of our project, we could see how the addition of
>> certain features required us to reassess the project's name and category.
>>
>> Before Ignite joined the ASF, it supported only compute APIs resembling
>> the
>> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as 
"a
>> distributed in-memory computing engine". Next, at the time of the project
>> donation, it already included key-value/SQL/transactional APIs, was used
>> as
>> a distributed cache, and significantly outgrew the "in-memory computing
>> engine" use case. That's how the project transitioned to the product
>> category of in-memory caches and we started to name it as an "in-memory
>> data grid" or "in-memory computing platform" to differentiate from
>> classical caching products such as Memcached and Redis.
>>
>> Nowadays, the project outgrew its caching use case, and the 
classification
>> of Ignite as an "in-memory data grid" or "in-memory computing platform"
>> doesn't sound accurate. We rebuilt our storage engine by replacing a
>> typical key-value engine with a B-tree engine that spans across memory 
and
>> disk tiers. And it's not surprising to see more deployments of Ignite as 
a
>> database on 

Re: [DISCUSSION] Renaming Ignite's product category

[Denis Magda]

Adam,

You defined GigaSpaces as a true in-memory computing platform. What is the
true platform for you?


-
Denis


On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam 
wrote:

> So when I came across Ignite It was described as an In Memory Data Grid
>
> So one way to look at this is who do you fashion as Ignite competing
> against?
>
> Are competing against Redis, Aerospike - In Memory Databases
>
> Or are you more competing with
>
> Gigaspaces - True In memory Compute platform
>
> And then you have like of
>
> Hazelcast that started as a Distributed Hash and have gained some
> features...
>
> On thing that I think is a differentiator that isn't being highlighted but
> Is  unique feature to Ignited, and the primary reason we ended up here; The
> integration with spark and it's distributed/shared Datasets/Dataframes.
>
> I don't know for me the In Memory Data Grid I think fits what Ignite is...
>
> Regards
>
> ~Adam
>
> Adam Carbone | Director of Innovation – Intelligent Platform Team |
> Bottomline Technologies
> Office: 603-501-6446 | Mobile: 603-570-8418
> www.bottomline.com
>
>
>
> On 9/17/20, 11:45 AM, "Glenn Wiebe"  wrote:
>
> I agree with Stephen about "database" devaluing what Ignite can do
> (though
> it probably hits the majority of existing use cases). I tend to go with
> "massively distributed storage and compute platform"
>
> I know, I didn't take sides, I just have both.
>
> Cheers,
>   Glenn
>
> On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
> stephen.darling...@gridgain.com> wrote:
>
> > I think this is a great question. Explaining what Ignite does is
> always a
> > challenge, so having a useful “tag line” would be very valuable.
> >
> > I’m not sure what the answer is but I think calling it a “database”
> > devalues all the compute facilities. "Computing platform” may be too
> vague
> > but it at least says that we do more than “just” store data.
> >
> > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > My vote is for the "distributed memory-first database". It clearly
> states
> > that Ignite is a database (which is true at this point), while still
> > emphasizing the in-memory computing power endorsed by the platform.
> >
> > The "in-memory computing platform" is an ambiguous term and doesn't
> really
> > reflect what Ignite is, especially in its current state.
> >
> > -Val
> >
> > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda 
> wrote:
> >
> >> Igniters,
> >>
> >> Throughout the history of our project, we could see how the
> addition of
> >> certain features required us to reassess the project's name and
> category.
> >>
> >> Before Ignite joined the ASF, it supported only compute APIs
> resembling
> >> the
> >> MapReduce engine of Hadoop. Those days, it was fair to define
> Ignite as "a
> >> distributed in-memory computing engine". Next, at the time of the
> project
> >> donation, it already included key-value/SQL/transactional APIs, was
> used
> >> as
> >> a distributed cache, and significantly outgrew the "in-memory
> computing
> >> engine" use case. That's how the project transitioned to the product
> >> category of in-memory caches and we started to name it as an
> "in-memory
> >> data grid" or "in-memory computing platform" to differentiate from
> >> classical caching products such as Memcached and Redis.
> >>
> >> Nowadays, the project outgrew its caching use case, and the
> classification
> >> of Ignite as an "in-memory data grid" or "in-memory computing
> platform"
> >> doesn't sound accurate. We rebuilt our storage engine by replacing a
> >> typical key-value engine with a B-tree engine that spans across
> memory and
> >> disk tiers. And it's not surprising to see more deployments of
> Ignite as a
> >> database on its own. So, it feels like we need to reconsider Ignite
> >> positioning again so that a) application developers can discover it
> easily
> >> via search engines and b) the project can stand out from in-memory
> >> projects
> >> with intersecting capabilities.
> >>
> >> To the point, I'm suggesting to reposition Ignite in one of the
> following
> >> ways:
> >>
> >>1. Ignite is a "distributed X database". We are indeed a
> distributed
> >>partitioned database where X can be "multi-tiered" or
> "memory-first" to
> >>emphasize that we are more than an in-memory database.
> >>2. Keep defining Ignite as "an in-memory computing platform" but
> name
> >>our storage engine uniquely as "IgniteDB" to highlight that the
> >> platform is
> >>powered by a "distributed multi-tiered/memory-first database".
> >>
> >> What is your thinking?
> >>
> >>
> >> (Also, regardless of a selected name, Ignite still will be used as
> a 

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

[Alex Plehanov]

Igniters,

I've prepared release notes for the 2.9 release [1]. Can anyone review it,
please?

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

вт, 22 сент. 2020 г. в 09:39, Alex Plehanov :

> Guys,
>
> I've filled the ticket with reproducer [1] for the discovery bug. This bug
> caused by [2] ticket. We discussed with Vladimir Steshin privately and
> decided to revert this ticket. I will do it today (after TC bot visa) if
> there are no objections.
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-13465
> [2]: https://issues.apache.org/jira/browse/IGNITE-13134
>
> пн, 21 сент. 2020 г. в 11:08, Alex Plehanov :
>
>> Guys,
>>
>> During internal testing, we've found a critical bug with
>> discovery (cluster falls apart if two nodes segmented sequentially). This
>> problem is not reproduced in 2.8.1. I think we should fix it
>> before release. Under investigation now. I'll let you know when we get
>> something.
>>
>> чт, 17 сент. 2020 г. в 00:51, Andrey Gura :
>>
>>> > So what do you think? Should we proceed with a 'hacked' version of the
>>> message factory in 2.9 and go for the runtime message generation in later
>>> release, or keep the code clean and fix the regression in the next releases?
>>> > Andrey, can you take a look at my change? I think it is fairly
>>> straightforward and does not change the semantics, just skips the factory
>>> closures for certain messages.
>>>
>>> IMHO 2.5% isn't too much especially because it isn't actual for all
>>> workloads (I didn't get any significant drops during benchmarking). So
>>> I prefer the runtime generation in later releases.
>>>
>>> On Mon, Sep 14, 2020 at 12:41 PM Alexey Goncharuk
>>>  wrote:
>>> >
>>> > Alexey, Andrey, Igniters,
>>> >
>>> > So what do you think? Should we proceed with a 'hacked' version of the
>>> message factory in 2.9 and go for the runtime message generation in later
>>> release, or keep the code clean and fix the regression in the next releases?
>>> > Andrey, can you take a look at my change? I think it is fairly
>>> straightforward and does not change the semantics, just skips the factory
>>> closures for certain messages.
>>> >
>>> > Personally, I would prefer fixing the regression given that we also
>>> introduced tracing in this release.
>>> >
>>> >
>>> >
>>> > пт, 11 сент. 2020 г. в 12:09, Alex Plehanov :
>>> >>
>>> >> Alexey,
>>> >>
>>> >> We've benchmarked by yardstick commits 130376741bf vs ed52559eb95 and
>>> the performance of ed52559eb95 is better for about 2.5% on average on our
>>> environment (about the same results we got benchmarking 65c30ec6 vs
>>> 0606f03d). We've made 24 runs for each commit of
>>> IgnitePutTxImplicitBenchmark (we got maximum drop for 2.9 on this
>>> benchmark), 200 seconds warmup, 300 seconds benchmark, 6 servers, 5 clients
>>> 50 threads each. Yardstick results for this configuration:
>>> >> Commit 130376741bf: avg TPS=164096, avg latency=9173464 ns
>>> >> Commit ed52559eb95: avg TPS=168283, avg latency=8945908 ns
>>> >>
>>> >> пт, 11 сент. 2020 г. в 09:51, Artem Budnikov <
>>> a.budnikov.ign...@gmail.com>:
>>> >>>
>>> >>> Hi Everyone,
>>> >>>
>>> >>> I posted an instruction on how to publish the docs on
>>> ignite.apache.org/docs [1]. When you finish with Ignite 2.9, you can
>>> update the docs by following the instruction. Unfortunately, I won't be
>>> able to spend any time on this project any longer. You can send your pull
>>> requests and questions about the documentation to Denis Magda.
>>> >>>
>>> >>> -Artem
>>> >>>
>>> >>> [1] :
>>> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Document
>>> >>>
>>> >>> On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk <
>>> alexey.goncha...@gmail.com> wrote:
>>> 
>>>  Alexey,
>>> 
>>>  I've tried to play with message factories locally, but
>>> unfortunately, I
>>>  cannot spot the difference between old and new implementation in
>>>  distributed benchmarks. I pushed an implementation of
>>> MessageFactoryImpl
>>>  with the old switch statement to the ignite-2.9-revert-12568 branch
>>>  (discussed this with Andrey Gura, the change should be compatible
>>> with the
>>>  new metrics as we still use the register() mechanics).
>>> 
>>>  Can you check if this change makes any difference performance-wise
>>> in your
>>>  environment? If yes, we can go with runtime code generation in the
>>> long
>>>  term: register classes and generate a dynamic message factory with
>>> a switch
>>>  statement once all messages are registered (not in 2.9 though,
>>> obviously).
>>> 
>>>  ср, 9 сент. 2020 г. в 14:53, Alex Plehanov >> >:
>>> 
>>>  > Hello guys,
>>>  >
>>>  > I've tried to optimize tracing implementation (ticket [1]), it
>>> reduced the
>>>  > drop, but not completely removed it.
>>>  > Ivan Rakov, Alexander Lapin, can you please review the patch?
>>>  > Ivan Artiukhov, can you please benchmark the patch [2] against
>>> 2.8.1
>>>  > release on your 

[jira] [Created] (IGNITE-13480) Issue in SQLGetData when deleting binary data

[Abhay (Jira)]

Abhay created IGNITE-13480:
--

 Summary: Issue in SQLGetData when deleting binary data 
 Key: IGNITE-13480
 URL: https://issues.apache.org/jira/browse/IGNITE-13480
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.8.1
Reporter: Abhay


When we select a large value in ODBC and column type is varchar then we get the 
response like this 

[SQLGetData.c][237][SQLGetData.c][237] Entry: Statement = 0x1bc9d90 Column 
Number = 1 Target Type = -2 SQL_C_BINARY Buffer Length = 4096 Target Value = 
0x1bc1480 StrLen Or Ind = 0x7fffda3c96c0

[ODBC][722][1600757419.094829][SQLGetData.c][534] Exit:[SQL_SUCCESS]            
     Buffer = [BINARYDATA...]                 Strlen Or Ind = 0x7fffda3c96c0 -> 
4096

wherein it sends response as SQL_SUCCESS and strlen_or_ind as our buffer size = 
4096 and not SQL_SUCCESS_WITH_INFO and correct size in strlen_or_ind whereas in 
MS SQL server it shows like this 

 

{{[ODBC][2254][1600867369.318414][SQLGetData.c][237]
Entry:
Statement = 0x1a771d0
Column Number = 1
Target Type = -2 SQL_C_BINARY
Buffer Length = 4096
Target Value = 0x1a90d00
StrLen Or Ind = 0x7fff0908ece0
[ODBC][2254][1600867369.318866][SQLGetData.c][545]
Exit:[SQL_SUCCESS_WITH_INFO]
Buffer = [BINARYDATA...]
Strlen Or Ind = 0x7fff0908ece0 -> 11936}}



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

[jira] [Created] (IGNITE-13479) Both ignite.sh and control.sh use the same JVM_OPTS. Control.sh doesn't start if JMX port was set

[Semyon Danilov (Jira)]

Semyon Danilov created IGNITE-13479:
---

 Summary: Both ignite.sh and control.sh use the same JVM_OPTS. 
Control.sh doesn't start if JMX port was set
 Key: IGNITE-13479
 URL: https://issues.apache.org/jira/browse/IGNITE-13479
 Project: Ignite
  Issue Type: Bug
  Components: control.sh
Affects Versions: 2.8.1
Reporter: Semyon Danilov
Assignee: Semyon Danilov
 Fix For: 2.9


There is no other way to set parameters for docker images, so, when you set JMX 
port to JVM_OPTS, you can't start control.sh:

 

Error: Exception thrown by the agent : java.rmi.server.ExportException: Port 
already in use: 49112; nested exception is:
java.net.BindException: Address in use (Bind failed)
sun.management.AgentConfigurationError: java.rmi.server.ExportException: Port 
already in use: 49112; nested exception is:
java.net.BindException: Address in use (Bind failed)



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

[jira] [Created] (IGNITE-13478) Security issue in JMX configuration using ignite.sh

[Semyon Danilov (Jira)]

Semyon Danilov created IGNITE-13478:
---

 Summary: Security issue in JMX configuration using ignite.sh
 Key: IGNITE-13478
 URL: https://issues.apache.org/jira/browse/IGNITE-13478
 Project: Ignite
  Issue Type: Bug
  Components: control.sh
Affects Versions: 2.8.1
Reporter: Semyon Danilov
Assignee: Semyon Danilov
 Fix For: 2.9


At the moment we have the following code:

*functions.sh*

 

{{JMX_PORT=`"$JAVA" -cp "${IGNITE_LIBS}" 
org.apache.ignite.internal.util.portscanner.GridJmxPortFinder`
#
# This variable defines necessary parameters for JMX
# monitoring and management.
#
# This enables remote unsecure access to JConsole or VisualVM.
#
# ADD YOUR ADDITIONAL PARAMETERS/OPTIONS HERE
#
if [ -n "$JMX_PORT" ]; then
JMX_MON="-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=${JMX_PORT} \
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false"}}

So the properties -Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false will be set always and there is no way 
to change them.

 



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

Re: [DISCUSSION] Maintenance Mode feature

[Sergey Chugunov]

Ivan,

If you come up with any ideas that may make this feature better, don't
hesitate to share them!

Thank you!

On Tue, Sep 22, 2020 at 11:27 AM Ivan Pavlukhin  wrote:

> Sergey,
>
> Thank you for your answer. While I am not happy with the proposed
> approach but things never were easy. Unfortunately I cannot suggest
> 100% better approaches so far. So, I should trust your vision.
>
> 2020-09-22 10:29 GMT+03:00, Sergey Chugunov :
> > Ivan,
> >
> > Checkpointer in Maintenance Mode is started and allows normal operations
> as
> > it may be needed for defragmentation and possibly other cases.
> >
> > Discovery is started with a special implementation of SPI that doesn't
> make
> > attempts to seek and/or connect to the rest of the cluster. From that
> > perspective node in MM is totally isolated.
> >
> > Communication is started as usual but I believe it doesn't matter as
> > discovery no other nodes are observed in topology and connection attempt
> > should not happen. But it may make sense to implement isolated version of
> > communication SPI as well to have 100% guarantee that no communication
> with
> > other nodes will happen.
> >
> > It is important to note that GridRestProcessor is started normally as we
> > need it to connect to the node via control utility.
> >
> > On Mon, Sep 21, 2020 at 7:04 PM Ivan Pavlukhin 
> wrote:
> >
> >> Sergey,
> >>
> >> > From  the code complexity perspective I'm trying to design the feature
> >> in such a way that all maintenance code is as encapsulated as possible
> >> and
> >> avoids massive interventions into main workflows of components.
> >>
> >> Could please briefly tell what means do you use to achieve
> >> encapsulation? Are Discovery, Communication, Checkpointer and other
> >> components started in a maintenance mode in current design?
> >>
> >> 2020-09-21 15:19 GMT+03:00, Nikolay Izhikov :
> >> > Hello, Sergey.
> >> >
> >> >> At the moment I'm aware about two use cases for this feature:
> >> >> corrupted
> >> >> PDS cleanup and defragmentation.
> >> >
> >> > AFAIKU There is third use-case for this mode.
> >> >
> >> > Change encryption master key in case node was down during cluster
> >> > master
> >> key
> >> > change.
> >> > In this case, node can’t join to the cluster, because it’s master key
> >> > differs from the cluster.
> >> > To recover node Ignite should locally change master key before join.
> >> >
> >> > Please, take a look into source code [1]
> >> >
> >> > [1]
> >> >
> >>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/encryption/GridEncryptionManager.java#L710
> >> >
> >> >> 21 сент. 2020 г., в 14:37, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> >> >> написал(а):
> >> >>
> >> >> Ivan,
> >> >>
> >> >> Sorry for some confusion, MM indeed is not a normal mode. What I was
> >> >> trying
> >> >> to say is that when in MM node still starts and allows the user to
> >> >> perform
> >> >> actions with it like sending commands via control utility/JMX APIs or
> >> >> reading metrics.
> >> >>
> >> >> This is the key point: although the node is not in the cluster but it
> >> >> is
> >> >> still alive can be monitored and supports management to do
> >> >> maintenance.
> >> >>
> >> >> From  the code complexity perspective I'm trying to design the
> feature
> >> in
> >> >> such a way that all maintenance code is as encapsulated as possible
> >> >> and
> >> >> avoids massive interventions into main workflows of components.
> >> >> At the moment I'm aware about two use cases for this feature:
> >> >> corrupted
> >> >> PDS
> >> >> cleanup and defragmentation. As far as I know it won't bring too much
> >> >> complexity in both cases.
> >> >>
> >> >> I cannot say for other components but I believe it will be possible
> to
> >> >> integrate MM feature into their workflow as well with reasonable
> >> >> amount
> >> >> of
> >> >> refactoring.
> >> >>
> >> >> Does it make sense to you?
> >> >>
> >> >> On Sun, Sep 6, 2020 at 8:08 AM Ivan Pavlukhin 
> >> >> wrote:
> >> >>
> >> >>> Sergey,
> >> >>>
> >> >>> Thank you for your answer!
> >> >>>
> >> >>> Might be I am looking at the subject from a different angle.
> >> >>>
> >>  I think of a node in MM as an almost normal one
> >> >>> I cannot think of such a mode as a normal one, because it apparently
> >> >>> does not perform usual cluster node functions. It is not a part of a
> >> >>> cluster, caches data is not available, Discovery and Communication
> >> >>> are
> >> >>> not needed.
> >> >>>
> >> >>> I fear that with "node started in a special mode" approach we will
> >> >>> get
> >> >>> an additional flag in the code making the code more complex and
> >> >>> fragile. Should not I worry about it?
> >> >>>
> >> >>> 2020-09-02 10:45 GMT+03:00, Sergey Chugunov
> >> >>>  >> >:
> >>  Vladislav, Ivan,
> >> 
> >>  Thank you for your questions and suggestions. Let me answer them.
> >> 
> >>  Vladislav,
> >> 
> >>  If I understood 

[jira] [Created] (IGNITE-13477) Fix NPE in SQL tracing implementation.

[Mikhail Petrov (Jira)]

Mikhail Petrov created IGNITE-13477:
---

 Summary: Fix NPE in SQL tracing implementation.
 Key: IGNITE-13477
 URL: https://issues.apache.org/jira/browse/IGNITE-13477
 Project: Ignite
  Issue Type: Improvement
Reporter: Mikhail Petrov


MTC.support() can return null. So it's needed to check result of this method 
while in not try/catch block for null. 



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

[MTCGA]: new failures in builds [5616802] 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 
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQueryWithAffinityKeyNotQueryFieldEscapeAll
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5841412228383711289=%3Cdefault%3E=testDetails

 *New test failure in master 
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQueryWithAffinityKeyEscapeAll 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=6612151331394587964=%3Cdefault%3E=testDetails

 *New test failure in master 
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQuery 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=8486946345964854495=%3Cdefault%3E=testDetails

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

 *New test failure in master 
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQueryWithAffinityKeyNotQueryField
 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5465750471179820585=%3Cdefault%3E=testDetails

 *New test failure in master 
IgniteCacheJoinQueryWithAffinityKeyTest.testJoinQueryWithAffinityKey 
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=3900303108981187840=%3Cdefault%3E=testDetails
 Changes may lead to failure were done by 
 - pavel vinokurov  
https://ci.ignite.apache.org/viewModification.html?modId=907530
 - mikhail petrov <32207922+ololo3...@users.noreply.github.com> 
https://ci.ignite.apache.org/viewModification.html?modId=907525

 - 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 09:11:16 23-09-2020