[jira] [Created] (IGNITE-8155) Warning in log on opening of cluster tab in advanced mode

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8155:
-

 Summary: Warning in log on opening of cluster tab in advanced mode
 Key: IGNITE-8155
 URL: https://issues.apache.org/jira/browse/IGNITE-8155
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko
Assignee: Ilya Borisov


# Create new cluster
# Save cluster
# Open cluster tab in advanced mode
In browser console next message is shown:
{code}
The specified value "value" is not a valid number. The value must match to the 
following regular expression: -?(\d+|\d+\.\d+|\.\d+)([eE][-+]?\d+)?
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3763: Ignite-1.7.20

[sk0x50]

GitHub user sk0x50 opened a pull request:

https://github.com/apache/ignite/pull/3763

Ignite-1.7.20



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-1.7.20

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3763.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3763


commit 3e2ccfd30427ba0552eea8667c0129ae5ace9c0b
Author: Igor Sapego 
Date:   2016-11-25T11:26:54Z

IGNITE-4299: Fixes for examples.

commit 6fbaef45af8f40062a95058df7ec0984c99035b9
Author: Konstantin Dudkov 
Date:   2016-11-25T10:58:58Z

IGNITE-4305 marshalling fix in GridNearAtomicSingleUpdateInvokeRequest

commit 1a2de51f5807a91ce0d5dff28f24ed5bf7abebbc
Author: Konstantin Dudkov 
Date:   2016-11-28T09:59:02Z

IGNITE-4305 marshalling fix

commit c06e4017771603df7118974758d3d6b9cadc41b5
Author: Eduard Shangareev 
Date:   2016-11-30T11:34:47Z

ignite-4332 Usage of cache.getEntry inside GridCacheQueryManager.runQuery 
causes to remote operations

commit 066691098797be8c01daa0e8dc2ba94d4ad73561
Author: sboikov 
Date:   2016-12-01T14:16:28Z

ignite-4344 Do not create offheap map on client nodes.

commit e9ace7730773a6d4a1d30b271854f1fe8a7ba632
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:06:41Z

Improved exception handling.

commit 12bdd6a031a33eda004a66e73cee9628f073ed68
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:09:29Z

Updated classnames.properties for running nodes in IDE.

commit 33dda46061aae73e5c138851cfdd5f49a1c254cb
Author: sboikov 
Date:   2016-12-02T09:13:38Z

ignite-4285 For serializable txs allow multiple threads to get read lock 
for the same key

commit cc13d9d155f70e22e08ef203ac64e5cc0aa0a50f
Author: dkarachentsev 
Date:   2016-11-28T08:30:14Z

IGNITE-4026: Fixed BinaryObjectBuilder.build() can fail if one of the 
fields is Externalizable, enum from binary object. This closes #1281. This 
closes #1289.

(cherry picked from commit 0b7c62d)

commit b4aedfd5350b4a318f1608596a171789513835a4
Author: Igor Sapego 
Date:   2016-12-02T17:10:09Z

IGNITE-4347: Fixed NPE.

commit acf20b32d8fb68e42b904b091fb2b943f4558cef
Author: sboikov 
Date:   2016-12-05T11:01:28Z

ignite-4296 Optimize GridDhtPartitionsSingleMessage processing
- optimized processing of GridDhtPartitionsSingleMessage
- minor optimizations for RendezvousAffinityFunction
 - fixed heartbeats sending in tcp discovery

commit 6ba1711a1fa10d8276974227491136070c3ed43a
Author: Anton Vinogradov 
Date:   2016-12-06T09:55:41Z

IGNITE-4242 ExchangeManager should wait for cache rebalancing in async way

commit 0d4a1b7381fece47ee480f3a06bff7c51a7fead4
Author: Alexey Kuznetsov 
Date:   2016-12-07T11:02:49Z

Improved exception handling for failed queries.

commit ac8602dbdf2bbf5b16a611eaf6d520a0a7b0010b
Author: Sergi Vladykin 
Date:   2016-08-15T13:46:54Z

ignite-3685 - fixed

commit bbaa79af8ef526b5d2684db0e3d71d60a8f1ebe7
Author: agura 
Date:   2016-12-07T16:36:11Z

IGNITE-3770 GridLogThrottle.warn ignores the exception

commit 18598574bb2992aa193eed1d72ca333a1e21ad72
Author: Andrey V. Mashenkov 
Date:   2016-12-08T09:36:07Z

GG-11746: Backport of IGNITE-4379:  Fixed broken local SqlFieldsQuery.

commit 671a77a2d81cac401765dddf25f30fba4e4ab17f
Author: sboikov 
Date:   2016-12-08T09:56:46Z

ignite-4154 Fixed node version check for compression feature usage

commit 391f4be4c687a7f325aeec8b727c9c85ca003454
Author: agura 
Date:   2016-12-07T17:11:50Z

ignite-2358 toString() method for cache store implementations

commit bc977d3211906ef94e1f7d3f0f988efbed65034f
Author: Alexey Kuznetsov 
Date:   2016-12-09T09:11:31Z

IGNITE-4350 Reworked JdbcTypesDefaultTransformed logic. Improved improved 
error messages in CacheJdbcPojoStore.

commit b83ec8e57c7c48f2baa4780cf3b2e46df075f3df
Author: sboikov 
Date:   2016-12-09T11:32:42Z

IGNITE-500 CacheLoadingConcurrentGridStartSelfTest fails: prevent 
'localUpdate' execution while top read lock is held.

commit 6e485637e2738a7e809eac1a802f0964dc12383d
Author: Andrey V. Mashenkov 
Date:   2016-12-09T12:42:40Z

IGNITE-4379: Fixed local query execution. This closes #1323.

commit 6fd8bf6338470275e687a686044c7d935d3714ff
Author: Andrey V. Mashenkov 
Date:   2016-12-07T15:49:06Z

Fixed tests for IGNITE-4379 commit.

commit c143bc1a77baa13f61d6ba00509fa1fcb33757b1
Author: tledkov-gridgain 
Date:   2016-12-09T13:05:03Z

IGNITE-4063:  Preserved 

[jira] [Created] (IGNITE-8154) Add an ability to provide ExceptionListener to JmsStreamer

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-8154:
---

 Summary: Add an ability to provide ExceptionListener to JmsStreamer
 Key: IGNITE-8154
 URL: https://issues.apache.org/jira/browse/IGNITE-8154
 Project: Ignite
  Issue Type: Improvement
  Components: streaming
Affects Versions: 2.4
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
 Fix For: 2.5


JMS API allows to provide custom {{ExceptionListener}} that is invoked when an 
exception occurs within JMS queue/topic. Currently, {{JmsStreamer}} doesn't use 
this in any way which creates two issues:
* If there is an exception, it's lost and not even logged.
* User can't provide their own listener.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8153) Nodes fail to connect each other when SSL is enabled

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-8153:
-

 Summary: Nodes fail to connect each other when SSL is enabled
 Key: IGNITE-8153
 URL: https://issues.apache.org/jira/browse/IGNITE-8153
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Fix For: 2.5


Nodes can fail to connect each other when SSL is enabled under some 
circumstances.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IEP-18: Transparent Data Encryption

[Dmitriy Setrakyan]

Here is a correct link to IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-18%3A+Transparent+Data+Encryption

On Thu, Apr 5, 2018 at 12:01 PM, Nikolay Izhikov 
wrote:

> Hello, Igniters.
>
> Based on previous discussion [1] we've created "IEP-18: Transparent Data
> Encryption" [2]
> I've planned to start implementation of TDE in few weeks.
> I will create JIRA ticket for each piece of implementation.
>
> So, please, see IEP-18 and give us feedback.
>
> Dima Ryabov, huge thanks for pushing TDE IEP forward.
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.
> com/Transparent-Data-Encryption-TDE-in-Apache-Ignite-td18957.html
> [2] https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=75979078
>

Re: Data Loss while upgrading custom jar from old jar in server and client nodes

[Denis Magda]

Ivan,

How can we facilitate the user here? Can we generate a meaningful exception
that explains how to tackle the issue?

--
Denis

On Thu, Apr 5, 2018 at 2:49 AM, Ivan Rakov  wrote:

> Hi,
>
> Cache configuration is persisted in 
> db\{consistent-ID}\cache-{cache-name}\cache_data.dat
> file. It's just CacheConfiguration serialized by JDK marshaller.
> Try to delete this file and start cache with new configuration (with
> correct factory class names). All your data will persist as long as old
> ignite data is compatible with new configuration.
>
> Best Regards,
> Ivan Rakov
>
>
> On 04.04.2018 23:08, Denis Magda wrote:
>
>> Ivan R., Alex G., persistence experts,
>>
>> Please have a look at this question.
>>
>> --
>> Denis
>>
>> On Mon, Apr 2, 2018 at 6:15 AM, Andrey Mashenkov <
>> andrey.mashen...@gmail.com
>>
>>> wrote:
>>> Crossposting to dev.
>>>
>>> Guys,
>>> User use Ignite native persistence with CacheStore configured.
>>> Seems, changing CacheStore requires cache recreation in his case to
>>> changes
>>> can be applied.
>>>
>>> Does anybody has idea how it can be fixed?
>>>
>>> Do we allow to rewrite cache config in native store if it has minor
>>> changes
>>> that will not cause issues? E.g. changing cacheStore factory or changing
>>> number of backups?
>>> Otherwise, I'd suggest to deprecate such configuration.
>>>
>>>
>>> On Tue, Mar 27, 2018 at 4:18 PM, siva  wrote:
>>>
>>> Hi,

 Thanks for checking out issue. I think its not about IDE issue.
 Again same thing i have reproduce like bellow steps

 1.run the program from IDE as client
 2.copy jar to ignite libs folder and start the server
 3.Then check previous message steps so that can able to reproduce the
 issue.
 https://www.youtube.com/watch?v=COQiu2gi8ag=43s
 
 I have attached the video link.Can you go through that video and check

>>> the
>>>
 issue.


 Thanks



 --
 Sent from: http://apache-ignite-users.70518.x6.nabble.com/


>>>
>>> --
>>> Best regards,
>>> Andrey V. Mashenkov
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Andrey V. Mashenkov
>>>
>>>
>

Re: Service grid redesign

[Denis Magda]

Val,

Sounds like a great solution. I'm totally for it.

--
Denis

On Thu, Apr 5, 2018 at 12:32 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Denis,
>
> This is why I'm suggesting to use DeploymentSpi for this. The way I see
> this is that instead of deploying classes on local classpath, user can
> deploy them in the storage that SPI points to. If class is updated in the
> storage, Ignite detects this and automatically restarts the service. This
> is a very simple and straightforward approach that doesn't required a lot
> of changes on our side and allows to reuse existing implementation of
> DeploymentSpi.
>
> -Val
>
> On Thu, Apr 5, 2018 at 12:13 PM, Denis Magda  wrote:
>
> > >
> > > There is no need to deserialize services on the coordinator. It should
> > only
> > > be able to calculate the assignments.
> > > *LazyServiceConfiguration *should be used to deliver the service
> > > configurations, just like it is done right now.
> >
> >
> > Can that configuration be tweaked over the time requiring to update the
> > class on all the nodes (if, for instance, someone wants to deploy the
> next
> > version of a service)? Just want to be sure we don't need to restart the
> > cluster nodes (that won't be used for service deployments) on
> > services-related configurational changes.
> >
> > --
> > Denis
> >
> > On Thu, Apr 5, 2018 at 8:18 AM, Denis Mekhanikov 
> > wrote:
> >
> > > Denis,
> > > There is no need to deserialize services on the coordinator. It should
> > only
> > > be able to calculate the assignments.
> > > *LazyServiceConfiguration *should be used to deliver the service
> > > configurations, just like it is done right now.
> > >
> > > Val,
> > > Usage of DeploymentSpi is a good idea, I didn't think about this
> > > possibility.
> > > This is a viable alternative to peer-class-loading, not that
> > user-friendly
> > > though.
> > > But if peer-class-loading is that hard to implement, then I vote for
> > > DeploymentSpi.
> > > As far as I understand, it won't require us to do any additional
> changes
> > in
> > > Ignite, but will make users think about using a proper DeploymentSpi.
> > > Please correct me, if I'm wrong.
> > > It would be good, though, to add some examples on service redeployment,
> > > when implementation class changes.
> > >
> > > Denis
> > >
> > > чт, 5 апр. 2018 г. в 2:33, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > > I don't think peer class loading is even possible for services. I
> > believe
> > > > we should reuse DeploymentSpi [1] for versioning.
> > > >
> > > > [1] https://apacheignite.readme.io/docs/deployment-spi
> > > >
> > > > -Val
> > > >
> > > > On Wed, Apr 4, 2018 at 12:52 PM, Denis Magda 
> > > wrote:
> > > >
> > > > > Sorry, that was me who renamed the IEP to "Oil Change in Service
> > Grid".
> > > > Was
> > > > > writing this email after the renaming. Like that title more because
> > > it's
> > > > > fun and highlights what we're intended to do - cleaning of our
> > service
> > > > grid
> > > > > engine and powering it up with new "liquid" (new communication and
> > > > > deployment approach not available before).
> > > > >
> > > > > Denis
> > > > >
> > > > >
> > > > > > This message contains serialized service instance and its
> > > > configuration.
> > > > > > It is delivered to the coordinator node first, that calculates
> the
> > > > > service
> > > > > > deployment assignments and adds this information to the message.
> > > > >
> > > > >
> > > > > I would consider using a NodeFilter first to decide where a service
> > can
> > > > be
> > > > > potentially deployed.  Otherwise, we would require service classes
> to
> > > be
> > > > on
> > > > > every node (every node might become a coordinator) which is not the
> > > > desired
> > > > > requirement.
> > > > >
> > > > >
> > > > > As for the peer-class-loading, I would backup up Dmitriy here.
> Let's
> > at
> > > > > least not to focus on this task for now. We should design services
> > > > > versioning in the right way first and support it.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Apr 4, 2018 at 12:20 PM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Here is the correct link:
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > > 17%3A+Oil+Change+in+Service+Grid
> > > > > >
> > > > > > I have looked at the tickets there, and I believe that we should
> > not
> > > > > > support peer-deployment for services. It is very hard and I do
> not
> > > > think
> > > > > we
> > > > > > should even try.
> > > > > >
> > > > > > I am proposing closing this ticket as Won't Fix -
> > > > > > https://issues.apache.org/jira/browse/IGNITE-975
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov <
> > > > dmekhani...@gmail.com>
> > > > > > wrote:
> > > > > >
> 

Re: Breaking change in JDBC connection string format

[Denis Magda]

Vladimir, Igor,

Shouldn't we do the same for ODBC?

--
Denis

On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov 
wrote:

> I think colon is not very good candidate as it clashes with other
> properties (e.g. host-port delimiter). Semicolon looks good to me. I'll
> created a ticket [1] to address this.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8148
>
> On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura  wrote:
>
> > Denis,
> >
> > actually params (key-value pairs) are separated by colon in provided
> > JIRA issue comment.
> >
> > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda  wrote:
> > > Vladimir, Taras,
> > >
> > > Will "@" work for us as the delimiter? I would agree with Andrey to
> reuse
> > > this approach for the thin client.
> > >
> > > As for the breaking changes, if update the delimiter for the next
> driver
> > > version and make sure that version understands 2 delimiters for some
> time
> > > (& and the new one), then this would be ideal and not disrupting.
> > >
> > > --
> > > Denis
> > >
> > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura  wrote:
> > >
> > >> Hi,
> > >>
> > >> We've been solve this problem during JDBC2 driver implementation. And
> > >> I don't know any complains about connection string format. Why we can
> > >> just use the same approach? [1]
> > >>
> > >> [1] https://issues.apache.org/jira/browse/IGNITE-1250?
> > >> focusedCommentId=14706511=com.atlassian.jira.
> > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > >>
> > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > >>  wrote:
> > >> > Hello!
> > >> >
> > >> > I think semicolon is the way to go, since round brackets are often
> > >> > interpreted by shells and will need escaping on their own. Let's get
> > rid
> > >> of
> > >> > & and ?.
> > >> >
> > >> > jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
> > >> >
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> > 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :
> > >> >
> > >> >> Igniters,
> > >> >>
> > >> >> Thanks to Alex Kuznetsov, we revealed serious usability issue in
> our
> > >> thin
> > >> >> JDBC driver - we user ampersand character to delimit properties:
> > >> >>
> > >> >> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
> > >> >>
> > >> >> This leads to multiple problems:
> > >> >> 1) This format is unusable from many console environments and
> require
> > >> >> special escaping (PowerShell, bash)
> > >> >> 2) Also this causing issues when writing connection string is
> passed
> > to
> > >> >> some 3rd-party applications as sometimes they cannot escape it as
> > well.
> > >> >>
> > >> >> I performed investigation on how other vendors do that. Bottom
> line -
> > >> >> nobody use ampersand. Instead semicolon or parentheses are used:
> > >> >>
> > >> >> jdbc:ignite:thin://host:port/schema?param1=val1=val2
> > >> >> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
> > >> >>
> > >> >> I propose to do a breaking change in AI 2.5 and change the format
> to
> > >> >> *parentheses*. This would be a disruptive experience for existing
> > users,
> > >> >> but in the long term benefits will outweight. Also remember that we
> > do
> > >> not
> > >> >> offered officially any backward compatibility for our JDBC driver.
> > >> >>
> > >> >> Alternatively we may allow users to use previous format with help
> of
> > >> system
> > >> >> property or environment variable.
> > >> >>
> > >> >> Thoughts?
> > >> >>
> > >> >> Vladimir.
> > >> >>
> > >>
> >
>

Re: Service grid redesign

[Valentin Kulichenko]

Denis,

This is why I'm suggesting to use DeploymentSpi for this. The way I see
this is that instead of deploying classes on local classpath, user can
deploy them in the storage that SPI points to. If class is updated in the
storage, Ignite detects this and automatically restarts the service. This
is a very simple and straightforward approach that doesn't required a lot
of changes on our side and allows to reuse existing implementation of
DeploymentSpi.

-Val

On Thu, Apr 5, 2018 at 12:13 PM, Denis Magda  wrote:

> >
> > There is no need to deserialize services on the coordinator. It should
> only
> > be able to calculate the assignments.
> > *LazyServiceConfiguration *should be used to deliver the service
> > configurations, just like it is done right now.
>
>
> Can that configuration be tweaked over the time requiring to update the
> class on all the nodes (if, for instance, someone wants to deploy the next
> version of a service)? Just want to be sure we don't need to restart the
> cluster nodes (that won't be used for service deployments) on
> services-related configurational changes.
>
> --
> Denis
>
> On Thu, Apr 5, 2018 at 8:18 AM, Denis Mekhanikov 
> wrote:
>
> > Denis,
> > There is no need to deserialize services on the coordinator. It should
> only
> > be able to calculate the assignments.
> > *LazyServiceConfiguration *should be used to deliver the service
> > configurations, just like it is done right now.
> >
> > Val,
> > Usage of DeploymentSpi is a good idea, I didn't think about this
> > possibility.
> > This is a viable alternative to peer-class-loading, not that
> user-friendly
> > though.
> > But if peer-class-loading is that hard to implement, then I vote for
> > DeploymentSpi.
> > As far as I understand, it won't require us to do any additional changes
> in
> > Ignite, but will make users think about using a proper DeploymentSpi.
> > Please correct me, if I'm wrong.
> > It would be good, though, to add some examples on service redeployment,
> > when implementation class changes.
> >
> > Denis
> >
> > чт, 5 апр. 2018 г. в 2:33, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > I don't think peer class loading is even possible for services. I
> believe
> > > we should reuse DeploymentSpi [1] for versioning.
> > >
> > > [1] https://apacheignite.readme.io/docs/deployment-spi
> > >
> > > -Val
> > >
> > > On Wed, Apr 4, 2018 at 12:52 PM, Denis Magda 
> > wrote:
> > >
> > > > Sorry, that was me who renamed the IEP to "Oil Change in Service
> Grid".
> > > Was
> > > > writing this email after the renaming. Like that title more because
> > it's
> > > > fun and highlights what we're intended to do - cleaning of our
> service
> > > grid
> > > > engine and powering it up with new "liquid" (new communication and
> > > > deployment approach not available before).
> > > >
> > > > Denis
> > > >
> > > >
> > > > > This message contains serialized service instance and its
> > > configuration.
> > > > > It is delivered to the coordinator node first, that calculates the
> > > > service
> > > > > deployment assignments and adds this information to the message.
> > > >
> > > >
> > > > I would consider using a NodeFilter first to decide where a service
> can
> > > be
> > > > potentially deployed.  Otherwise, we would require service classes to
> > be
> > > on
> > > > every node (every node might become a coordinator) which is not the
> > > desired
> > > > requirement.
> > > >
> > > >
> > > > As for the peer-class-loading, I would backup up Dmitriy here. Let's
> at
> > > > least not to focus on this task for now. We should design services
> > > > versioning in the right way first and support it.
> > > >
> > > > --
> > > > Denis
> > > >
> > > >
> > > >
> > > > On Wed, Apr 4, 2018 at 12:20 PM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > Here is the correct link:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > 17%3A+Oil+Change+in+Service+Grid
> > > > >
> > > > > I have looked at the tickets there, and I believe that we should
> not
> > > > > support peer-deployment for services. It is very hard and I do not
> > > think
> > > > we
> > > > > should even try.
> > > > >
> > > > > I am proposing closing this ticket as Won't Fix -
> > > > > https://issues.apache.org/jira/browse/IGNITE-975
> > > > >
> > > > > D.
> > > > >
> > > > > On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > I've just posted my first draft of the IEP:
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > 17%3A+Service+grid+
> > > > > > improvements
> > > > > > It's not finished yet, but you can get the idea from it.
> > > > > > If you have some thoughts on your mind, please let me know, I'll
> > add
> > > > them
> > > > > > to the IEP.
> > > > > >
> > > > > > Denis
> > > > > 

Re: Service grid redesign

[Denis Magda]

>
> There is no need to deserialize services on the coordinator. It should only
> be able to calculate the assignments.
> *LazyServiceConfiguration *should be used to deliver the service
> configurations, just like it is done right now.


Can that configuration be tweaked over the time requiring to update the
class on all the nodes (if, for instance, someone wants to deploy the next
version of a service)? Just want to be sure we don't need to restart the
cluster nodes (that won't be used for service deployments) on
services-related configurational changes.

--
Denis

On Thu, Apr 5, 2018 at 8:18 AM, Denis Mekhanikov 
wrote:

> Denis,
> There is no need to deserialize services on the coordinator. It should only
> be able to calculate the assignments.
> *LazyServiceConfiguration *should be used to deliver the service
> configurations, just like it is done right now.
>
> Val,
> Usage of DeploymentSpi is a good idea, I didn't think about this
> possibility.
> This is a viable alternative to peer-class-loading, not that user-friendly
> though.
> But if peer-class-loading is that hard to implement, then I vote for
> DeploymentSpi.
> As far as I understand, it won't require us to do any additional changes in
> Ignite, but will make users think about using a proper DeploymentSpi.
> Please correct me, if I'm wrong.
> It would be good, though, to add some examples on service redeployment,
> when implementation class changes.
>
> Denis
>
> чт, 5 апр. 2018 г. в 2:33, Valentin Kulichenko <
> valentin.kuliche...@gmail.com>:
>
> > I don't think peer class loading is even possible for services. I believe
> > we should reuse DeploymentSpi [1] for versioning.
> >
> > [1] https://apacheignite.readme.io/docs/deployment-spi
> >
> > -Val
> >
> > On Wed, Apr 4, 2018 at 12:52 PM, Denis Magda 
> wrote:
> >
> > > Sorry, that was me who renamed the IEP to "Oil Change in Service Grid".
> > Was
> > > writing this email after the renaming. Like that title more because
> it's
> > > fun and highlights what we're intended to do - cleaning of our service
> > grid
> > > engine and powering it up with new "liquid" (new communication and
> > > deployment approach not available before).
> > >
> > > Denis
> > >
> > >
> > > > This message contains serialized service instance and its
> > configuration.
> > > > It is delivered to the coordinator node first, that calculates the
> > > service
> > > > deployment assignments and adds this information to the message.
> > >
> > >
> > > I would consider using a NodeFilter first to decide where a service can
> > be
> > > potentially deployed.  Otherwise, we would require service classes to
> be
> > on
> > > every node (every node might become a coordinator) which is not the
> > desired
> > > requirement.
> > >
> > >
> > > As for the peer-class-loading, I would backup up Dmitriy here. Let's at
> > > least not to focus on this task for now. We should design services
> > > versioning in the right way first and support it.
> > >
> > > --
> > > Denis
> > >
> > >
> > >
> > > On Wed, Apr 4, 2018 at 12:20 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > Here is the correct link:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > 17%3A+Oil+Change+in+Service+Grid
> > > >
> > > > I have looked at the tickets there, and I believe that we should not
> > > > support peer-deployment for services. It is very hard and I do not
> > think
> > > we
> > > > should even try.
> > > >
> > > > I am proposing closing this ticket as Won't Fix -
> > > > https://issues.apache.org/jira/browse/IGNITE-975
> > > >
> > > > D.
> > > >
> > > > On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov <
> > dmekhani...@gmail.com>
> > > > wrote:
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > I've just posted my first draft of the IEP:
> > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > 17%3A+Service+grid+
> > > > > improvements
> > > > > It's not finished yet, but you can get the idea from it.
> > > > > If you have some thoughts on your mind, please let me know, I'll
> add
> > > them
> > > > > to the IEP.
> > > > >
> > > > > Denis
> > > > >
> > > > > ср, 4 апр. 2018 г. в 13:09, Vyacheslav Daradur <
> daradu...@gmail.com
> > >:
> > > > >
> > > > > > Denis, thanks for the link.
> > > > > >
> > > > > > I looked through the task and I think that understand your
> redesign
> > > > point
> > > > > > now.
> > > > > >
> > > > > > Do you have a clear plan or IEP for the whole redesign?
> > > > > >
> > > > > > I'm interested in this component and I'd like to take part in the
> > > > > > development.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov <
> > > > dmekhani...@gmail.com>
> > > > > > wrote:
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > Service deployment design, based on replicated utility cache
> has
> > > > proven
> > > > > > to
> > > > > > > be unstable and deadlock-prone.
> > > 

Re: Ability to check and completely fill transactions on creation

[Denis Magda]

Guys,

Sorry for a dumb question but how the user is expected to use this event?

--
Denis

On Thu, Apr 5, 2018 at 6:06 AM, Anton Vinogradov  wrote:

> Igniters,
>
> As far as I know we're working on additional 'label' field for transactions
> [1].
> That's great and will be helpful for customers with huge deploymens to see
> reason of each transaction.
> But, since 'label' is optional field, there is no way to guarantee it will
> be filled.
>
> I'd like to propose an idea of brand new event EVT_USR_TX_CREATED (local
> transaction created).
>
> Local listener on such event will allow to guarantee tx's 'label' field
> filled, timeout is correct and so on.
>
> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-6827
>

IEP-18: Transparent Data Encryption

[Nikolay Izhikov]

Hello, Igniters.

Based on previous discussion [1] we've created "IEP-18: Transparent Data 
Encryption" [2]
I've planned to start implementation of TDE in few weeks.
I will create JIRA ticket for each piece of implementation.

So, please, see IEP-18 and give us feedback.

Dima Ryabov, huge thanks for pushing TDE IEP forward.

[1] 
http://apache-ignite-developers.2346864.n4.nabble.com/Transparent-Data-Encryption-TDE-in-Apache-Ignite-td18957.html
[2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75979078


signature.asc
Description: This is a digitally signed message part

Re: Apache Ignite 2.5 release

[Denis Magda]

Thanks Andrey!

Folks, if you'd like to add anything to 2.5 please make sure it gets merged
into 2.5 branch.

--
Denis

On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura  wrote:

> Hi,
>
> I've created branch ignite-2.5 for Apache Ignite 2.5 release.
>
> As always please follow the rules below when merging new commits to master:
>
> 1) If ticket is targeted for 2.5 release, please merge to master, then
> cherry-pick to ignite-2.5
> 2) Otherwise just merge to master.
>
>
>
> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura  wrote:
> > Igniters,
> >
> > It's time to create branch for upcoming Apache Ignite 2.5 release in
> > order to start stabilization process.
> >
> > If there are no any objections I'll create ignite-2.5 branch tomorrow.
> >
> > Also please check JIRA issues assigned to you and move it to the next
> > version if this issues shouldn't be included to 2.5 release.
> >
> > Release page on wiki [1] contains all issues targeted to 2.5 (fix
> > version field).
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.5
>

Re: Apache Ignite 2.5 release

[Andrey Gura]

Hi,

I've created branch ignite-2.5 for Apache Ignite 2.5 release.

As always please follow the rules below when merging new commits to master:

1) If ticket is targeted for 2.5 release, please merge to master, then
cherry-pick to ignite-2.5
2) Otherwise just merge to master.



On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura  wrote:
> Igniters,
>
> It's time to create branch for upcoming Apache Ignite 2.5 release in
> order to start stabilization process.
>
> If there are no any objections I'll create ignite-2.5 branch tomorrow.
>
> Also please check JIRA issues assigned to you and move it to the next
> version if this issues shouldn't be included to 2.5 release.
>
> Release page on wiki [1] contains all issues targeted to 2.5 (fix
> version field).
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.5

[GitHub] ignite pull request #3762: Ignite-7772-review

[agura]

GitHub user agura opened a pull request:

https://github.com/apache/ignite/pull/3762

Ignite-7772-review



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/agura/incubator-ignite ignite-7772-review

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3762.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3762


commit 9b7659c54ff76a6ab06687b53d638c7f0380c443
Author: Andrey Kuznetsov 
Date:   2018-03-29T15:22:55Z

IGNITE-7772: Failure handler invocation for discovery threads.

commit eb79f1bd53293defd77e0aeaff388b8c85991cd9
Author: Andrey Kuznetsov 
Date:   2018-03-29T17:03:13Z

IGNITE-7772: Fix for failure handling in discovery threads.

commit 800bca17b07b0e8c946f7afc51066a084fca684f
Author: Andrey Kuznetsov 
Date:   2018-03-29T17:04:16Z

IGNITE-7772: Failure handler invocation in TCP communication SPI worker.

commit ec6117d47021b52e2bc515ea460b4ce19f96e9d1
Author: Andrey Kuznetsov 
Date:   2018-03-30T15:21:41Z

IGNITE-7772: WIP.

commit abf7490b64b6a032c3d2654c616412b4ffde
Author: Andrey Kuznetsov 
Date:   2018-03-30T15:49:48Z

IGNITE-7772: Added failure handling for grid-timeout-worker.

commit 2bdff512c9443f53c9a5bf8d36cf96dd8574f165
Author: Andrey Kuznetsov 
Date:   2018-04-02T06:34:01Z

IGNITE-7772: Added failure handling for db-checkpoint-thread.

commit 2aa930f896a9d236e09037ffeedd91ad95634882
Author: Andrey Kuznetsov 
Date:   2018-04-02T07:10:59Z

IGNITE-7772: Added failure handling for wal-file-archiver.

commit d3c99b432a8a359034c52c6997e56fc7aeedab76
Author: Andrey Kuznetsov 
Date:   2018-04-02T07:26:29Z

IGNITE-7772: Added failure handling for wal-write-worker.

commit 3eef4a94dee2f44c8f1744a465fad2a34a479ea0
Author: Andrey Kuznetsov 
Date:   2018-04-02T08:02:07Z

IGNITE-7772: Added failure handling for ttl-cleanup-worker.

commit 55093ce93eea43d860cd5856fb493438e9bb6b3d
Author: Andrey Kuznetsov 
Date:   2018-04-02T15:11:33Z

IGNITE-7772: Added failure handling for TcpCommunicationSPI.

commit 831d1193373c325d14b531159fce5863f3464bb6
Author: Andrey Kuznetsov 
Date:   2018-04-02T16:39:45Z

IGNITE-7772: Added failure handling to StripedExecutor.

commit b3b88afa94bbae85defb50eb636a4c2aaf3ae626
Author: Andrey Kuznetsov 
Date:   2018-04-03T08:08:27Z

IGNITE-7772: Dropped extra import.

commit b5fb0603fe12cd6ec483c803434a48bbcc08b6ce
Author: Andrey Kuznetsov 
Date:   2018-04-03T08:11:19Z

IGNITE-7772: Reverted original test state.

commit 9f4a5a6e4098adcdb0185119b5dcc96c32035360
Author: Andrey Kuznetsov 
Date:   2018-04-03T14:44:49Z

IGNITE-7772: Got rid of trivial utility method.

commit c130a3adb3e6acd7a73d8118fd8a1db1313a0e55
Author: Andrey Kuznetsov 
Date:   2018-04-03T20:59:53Z

IGNITE-7772: WIP.

commit 9947ed9879fba96258c46992b58b900f89002a95
Author: Andrey Kuznetsov 
Date:   2018-04-04T15:50:11Z

IGNITE-7772: Refined handling logic.

commit c31f7ff35dd02272060eab88b3de3a5315eecb17
Author: Andrey Kuznetsov 
Date:   2018-04-04T15:57:47Z

IGNITE-7772: Minor cleanup.

commit bf1206d7b16ad3e93569227cb2f41ead5dfd61cf
Author: Andrey Gura 
Date:   2018-04-05T18:15:49Z

code review




---

Re: Trimming exceptions in IgniteUtils::cast

[Alexey Goncharuk]

Stanislav,

Thanks for the patch. It is a bit complex change, I will try to review it
over the next weekend.

--AG

2018-03-12 21:34 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Generally, I think we should not trim any exceptions, because this way we
> can unexpectedly remove useful information. Do we know what was the
> original reasoning behind this logic?
>
> -Val
>
> On Mon, Mar 12, 2018 at 3:57 AM, Stanislav Lukyanov <
> stanlukya...@gmail.com>
> wrote:
>
> > Hi,
> >
> > IgniteUtils::cast method is used to cast an exception to
> > IgniteCheckedException. It is done by trimming the top exceptions in the
> > trace until we find IgniteCheckedException, or until we’ve found the last
> > one. As a result, IgniteUtils::cast generally can trim the whole stack
> > trace but the root exception.
> >
> > One problem caused by that is https://issues.apache.org/
> > jira/browse/IGNITE-7904.
> > ComputeTask::result may throw IgniteException which is to be rethrown by
> > the ComputeTaskFuture::get, but in fact the IgniteException and all its
> > causes (but the root one) are trimmed, and the exception that comes from
> > the ComputeTaskFuture::get is different than excepted.
> >
> > To fix that I want to change the IgniteUtils::cast not to remove any
> > exceptions from the stack trace and just wrap all arguments with
> > IgniteCheckException.
> > Of course, this will affect all places where IgniteUtils::cast is used
> > (mostly various futures completion).
> > Does anyone have concerns about this?
> >
> > To illustrate, a patch (untested!) for IgniteUtils is below.
> >
> > Thanks,
> > Stan
> >
> > diff --git a/modules/core/src/main/java/org/apache/ignite/internal/
> util/IgniteUtils.java
> > b/modules/core/src/main/java/org/apache/ignite/internal/
> > util/IgniteUtils.java
> > index cbe64cd97af..5e8d9c8f4d9 100755
> > --- a/modules/core/src/main/java/org/apache/ignite/internal/
> > util/IgniteUtils.java
> > +++ b/modules/core/src/main/java/org/apache/ignite/internal/
> > util/IgniteUtils.java
> > @@ -7256,26 +7256,16 @@ public abstract class IgniteUtils {
> >  public static IgniteCheckedException cast(Throwable t) {
> >  assert t != null;
> >
> > -while (true) {
> > -if (t instanceof Error)
> > -throw (Error)t;
> > +while (t instanceof GridClosureException)
> > +t = ((GridClosureException)t).unwrap();
> >
> > -if (t instanceof GridClosureException) {
> > -t = ((GridClosureException)t).unwrap();
> > +if (t instanceof Error)
> > +throw (Error)t;
> >
> > -continue;
> > -}
> > -
> > -if (t instanceof IgniteCheckedException)
> > -return (IgniteCheckedException)t;
> > -
> > -if (!(t instanceof IgniteException) || t.getCause() == null)
> > -return new IgniteCheckedException(t);
> > +if (t instanceof IgniteCheckedException)
> > +return (IgniteCheckedException)t;
> >
> > -assert t.getCause() != null; // ...and it is
> IgniteException.
> > -
> > -t = t.getCause();
> > -}
> > +return new IgniteCheckedException(t);
> >  }
> >
> >
>

[GitHub] ignite pull request #3761: sql schema validation on jdbc thin connects to no...

[pavel-kuznetsov]

GitHub user pavel-kuznetsov opened a pull request:

https://github.com/apache/ignite/pull/3761

sql schema validation on jdbc thin connects to node.

Now if we are connecting to node using thin driver and schema is incorrect, 
connection will be rejected
Specifying quoted empty string will result in SQL exception on client side.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7743

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3761.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3761






---

[jira] [Created] (IGNITE-8152) Forbid empty sql schema name

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-8152:
---

 Summary: Forbid empty sql schema name
 Key: IGNITE-8152
 URL: https://issues.apache.org/jira/browse/IGNITE-8152
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Kuznetsov
Assignee: Vladimir Ozerov


Currently we allow empty schema name (quoted) in cache configuration
org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
{noformat}
When sqlSchema is not specified, quoted cacheName is used instead.

sqlSchema could not be an empty string. Has to be "\"\"" instead.

Params:
sqlSchema - Schema name for current cache according to SQL ANSI-99. Should not 
be null.
{noformat}

Specifying schema \"\" results in empty string schema name.
No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.

It's better to disallow usage of \"\" schema




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Ability to check and completely fill transactions on creation

[Alexey Kuznetsov]

How about to set label name with some useful info if user does not provide
custom name?

For example thread name + global counter?

Thoughts?

-- 
Alexey Kuznetsov

[GitHub] ignite pull request #3760: IGNITE-8059 Integrate decision tree with partitio...

[dmitrievanthony]

GitHub user dmitrievanthony opened a pull request:

https://github.com/apache/ignite/pull/3760

IGNITE-8059 Integrate decision tree with partition based dataset



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8059

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3760.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3760


commit 820694f2e8a47847e43167cbbc30fbc7d9b47c7b
Author: Anton Dmitriev 
Date:   2018-04-05T08:16:28Z

IGNITE-8059 Initial version of decision trees implemented on top of
partition based dataset.

commit 3860e5a171c8cae1f38c73fe30c8d3d2e2a46246
Author: Anton Dmitriev 
Date:   2018-04-05T10:07:55Z

IGNITE-8059 Add tests for impurity (decision trees).

commit b8dbb817d288f3f57ed6373e76dacab5c48a68c1
Author: Anton Dmitriev 
Date:   2018-04-05T12:57:25Z

IGNITE-8059 Add tests for decision trees regression and classification
trainers, add special decision tree partition data class.

commit c3b54ed2663c8a8ab2697146f0437d9f104f25cf
Author: Anton Dmitriev 
Date:   2018-04-05T13:19:45Z

IGNITE-8059 Add step function compressor (initial version).

commit 08798caa274a60d065a7b716253b8c6fa54ee5b1
Author: Anton Dmitriev 
Date:   2018-04-05T14:04:13Z

IGNITE-8059 Add MNIST test for decision tree algorithm.

commit 01e9b1c6a7ed74ae5c71ecedc13aee7df341980a
Author: Anton Dmitriev 
Date:   2018-04-05T16:02:03Z

IGNITE-8059 Add MNIST tests and remove UI part of decision tree.




---

[jira] [Created] (IGNITE-8151) ODBC driver should scheck schema on connection start

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-8151:
---

 Summary: ODBC driver should scheck schema on connection start
 Key: IGNITE-8151
 URL: https://issues.apache.org/jira/browse/IGNITE-8151
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.5
Reporter: Pavel Kuznetsov
Assignee: Igor Sapego


We need to add validation of schema in odbc driver.
1) Need to update protocol to send schema with connection start.
2) Forbid empty sql id (\"\") as sql schema. 
see IGNITE-7743 for details




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3758: IGNITE-8150: Fix for release suite step 1

[isapego]

Github user isapego closed the pull request at:

https://github.com/apache/ignite/pull/3758


---

Re: Service grid redesign

[Denis Mekhanikov]

Denis,
There is no need to deserialize services on the coordinator. It should only
be able to calculate the assignments.
*LazyServiceConfiguration *should be used to deliver the service
configurations, just like it is done right now.

Val,
Usage of DeploymentSpi is a good idea, I didn't think about this
possibility.
This is a viable alternative to peer-class-loading, not that user-friendly
though.
But if peer-class-loading is that hard to implement, then I vote for
DeploymentSpi.
As far as I understand, it won't require us to do any additional changes in
Ignite, but will make users think about using a proper DeploymentSpi.
Please correct me, if I'm wrong.
It would be good, though, to add some examples on service redeployment,
when implementation class changes.

Denis

чт, 5 апр. 2018 г. в 2:33, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> I don't think peer class loading is even possible for services. I believe
> we should reuse DeploymentSpi [1] for versioning.
>
> [1] https://apacheignite.readme.io/docs/deployment-spi
>
> -Val
>
> On Wed, Apr 4, 2018 at 12:52 PM, Denis Magda  wrote:
>
> > Sorry, that was me who renamed the IEP to "Oil Change in Service Grid".
> Was
> > writing this email after the renaming. Like that title more because it's
> > fun and highlights what we're intended to do - cleaning of our service
> grid
> > engine and powering it up with new "liquid" (new communication and
> > deployment approach not available before).
> >
> > Denis
> >
> >
> > > This message contains serialized service instance and its
> configuration.
> > > It is delivered to the coordinator node first, that calculates the
> > service
> > > deployment assignments and adds this information to the message.
> >
> >
> > I would consider using a NodeFilter first to decide where a service can
> be
> > potentially deployed.  Otherwise, we would require service classes to be
> on
> > every node (every node might become a coordinator) which is not the
> desired
> > requirement.
> >
> >
> > As for the peer-class-loading, I would backup up Dmitriy here. Let's at
> > least not to focus on this task for now. We should design services
> > versioning in the right way first and support it.
> >
> > --
> > Denis
> >
> >
> >
> > On Wed, Apr 4, 2018 at 12:20 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > Here is the correct link:
> > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > 17%3A+Oil+Change+in+Service+Grid
> > >
> > > I have looked at the tickets there, and I believe that we should not
> > > support peer-deployment for services. It is very hard and I do not
> think
> > we
> > > should even try.
> > >
> > > I am proposing closing this ticket as Won't Fix -
> > > https://issues.apache.org/jira/browse/IGNITE-975
> > >
> > > D.
> > >
> > > On Wed, Apr 4, 2018 at 5:39 AM, Denis Mekhanikov <
> dmekhani...@gmail.com>
> > > wrote:
> > >
> > > > Vyacheslav,
> > > >
> > > > I've just posted my first draft of the IEP:
> > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > 17%3A+Service+grid+
> > > > improvements
> > > > It's not finished yet, but you can get the idea from it.
> > > > If you have some thoughts on your mind, please let me know, I'll add
> > them
> > > > to the IEP.
> > > >
> > > > Denis
> > > >
> > > > ср, 4 апр. 2018 г. в 13:09, Vyacheslav Daradur  >:
> > > >
> > > > > Denis, thanks for the link.
> > > > >
> > > > > I looked through the task and I think that understand your redesign
> > > point
> > > > > now.
> > > > >
> > > > > Do you have a clear plan or IEP for the whole redesign?
> > > > >
> > > > > I'm interested in this component and I'd like to take part in the
> > > > > development.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Apr 2, 2018 at 2:55 PM, Denis Mekhanikov <
> > > dmekhani...@gmail.com>
> > > > > wrote:
> > > > > > Vyacheslav,
> > > > > >
> > > > > > Service deployment design, based on replicated utility cache has
> > > proven
> > > > > to
> > > > > > be unstable and deadlock-prone.
> > > > > > You can find a list of JIRA issues, connected to it, in my
> previous
> > > > > letter.
> > > > > >
> > > > > > The intention behind it is similar to the binary metadata
> redesign,
> > > > that
> > > > > > happened in the following ticket: IGNITE-4157
> > > > > > 
> > > > > > This change in service deployment procedure will eliminate need
> for
> > > > > another
> > > > > > internal replicated cache
> > > > > > and make service deployment more reliable on unstable topology.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > вт, 27 мар. 2018 г. в 23:21, Vyacheslav Daradur <
> > daradu...@gmail.com
> > > >:
> > > > > >
> > > > > >> Hi, Denis Mekhanikov!
> > > > > >>
> > > > > >> As far as I know, Ignite services are based on IgniteCache and
> we
> > > have
> > > > > >> all its features. We can use listeners or continuous queries for
> > > > > >> 

[GitHub] ignite pull request #3759: ignite zk merged master

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

https://github.com/apache/ignite/pull/3759

ignite zk merged master



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-zk-merged-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3759.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3759


commit c55d5c2d039f58e3bd0d3ac089f2dfc09d6f90b9
Author: sboikov 
Date:   2017-11-15T11:20:08Z

zk

commit 11e2567fffa724e6b4af6021cda1bfbcf775370b
Author: sboikov 
Date:   2017-11-16T13:10:04Z

zk

commit 98a171c68a1f5610e5f5830144306ee73df866d6
Author: sboikov 
Date:   2017-11-16T14:42:05Z

zk

commit b389f38cbc59f41dc1c95854684059f15b225b8c
Author: sboikov 
Date:   2017-11-17T06:33:30Z

zk

commit 5793ffbe23a095127cc88c1962785cad7cf2432d
Author: sboikov 
Date:   2017-11-17T09:05:55Z

zk

commit 45e7e40603fa2b496b94f00fc287221d30073c98
Author: sboikov 
Date:   2017-11-20T08:14:36Z

zk

commit a4be5afd03fef3b3fa8ce8c017d24636859c82f3
Author: sboikov 
Date:   2017-11-20T10:27:23Z

zk

commit 97e85179418bc369066c26ec086edd138419c406
Author: sboikov 
Date:   2017-11-20T14:21:33Z

zk

commit fcee8c846274890f8eee8cc8f3644cdda912dedd
Author: sboikov 
Date:   2017-11-21T09:24:58Z

zk

commit fb6bd0ac39f97db0d7e347aff6fa26edda10f940
Author: sboikov 
Date:   2017-11-21T10:43:15Z

zk

commit 1f82a5311d099ad31c22deec391ad91d568f9705
Author: sboikov 
Date:   2017-11-21T12:09:27Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-zk

commit 18527db9ba5d13b0964ec9c87c8b155295921c9a
Author: sboikov 
Date:   2017-11-21T13:54:38Z

zk

commit 7ba0feb55d79794146ea4deb41be2560eec9e42d
Author: sboikov 
Date:   2017-11-21T15:36:29Z

zk

commit 4090eb717f25331c2967645a802714830ac0d4f7
Author: sboikov 
Date:   2017-11-21T15:37:35Z

Merge remote-tracking branch 'origin/ignite-zk' into ignite-zk

commit e0aba812643c0d773359a95b514daead9730ee6e
Author: sboikov 
Date:   2017-11-22T08:47:55Z

zk

commit a6b452823422290e19238238e119f5aaad87b6af
Author: sboikov 
Date:   2017-11-22T10:22:14Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-zk

commit 6cb8c06f73ace3030f47ccfe21e2f46d6b054e5f
Author: sboikov 
Date:   2017-11-22T10:28:51Z

zk

commit 9761a0294e3978120c471dc7bdaa5ad94bbaf1b3
Author: sboikov 
Date:   2017-11-22T10:41:16Z

zk

commit bc297aa4b47cae1e5cb87e5d7863900c82fa90ce
Author: sboikov 
Date:   2017-11-22T10:48:27Z

zk

commit 4749d332c7ec1b6d24f8a8d0f6d5abf50de5d71d
Author: sboikov 
Date:   2017-11-22T11:27:47Z

zk

commit f5f2060aa6978367d4bf160fd96dc4efa57a7a8c
Author: sboikov 
Date:   2017-11-22T13:13:18Z

zk

commit 93dd7ab79c6ed38c29a87ca7a676fbfcefd57273
Author: sboikov 
Date:   2017-11-22T13:22:17Z

zk

commit 8bd1e077aae4cbdd61e3c5ba1dfa1e1f0e18759c
Author: sboikov 
Date:   2017-11-22T13:22:36Z

Merge remote-tracking branch 'origin/ignite-zk' into ignite-zk

commit 42bbed0adda149acb098fddfc830bcea768697d7
Author: sboikov 
Date:   2017-11-22T14:08:56Z

zk

commit d9575aac6137a3d842cac3ba15dab591138c67e2
Author: sboikov 
Date:   2017-11-22T14:53:18Z

zk

commit 97486480276c0563fcebddb56c53130519456b35
Author: sboikov 
Date:   2017-11-23T08:12:52Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-zk

commit 5d8feab45346352aacf1285948c2c9c5125bbabf
Author: sboikov 
Date:   2017-11-23T08:24:26Z

zk

commit 9ffd603d217034247497b6c2734933872c8a78ed
Author: sboikov 
Date:   2017-11-23T09:04:42Z

zk

commit 7611371b94559e3934b1224a17aaf408c735b358
Author: sboikov 
Date:   2017-11-23T10:52:06Z

zk

commit aa78f5c43639526c1f914ca7e3b2d455e012a358
Author: sboikov 
Date:   2017-11-23T10:52:06Z

zk




---

Re: IGNITE-6879

[Вячеслав Коптилин]

Thank you, Roman!

2018-04-05 17:49 GMT+03:00 Роман Меерсон :

> Hi Slava,
>
> Fixed
>
> чт, 5 апр. 2018 г. в 18:41, Вячеслав Коптилин :
>
> > Hi Roman,
> >
> > please take into account my comment IgniteQueryGenerator.java
> > <
> > https://reviews.ignite.apache.org/ignite/review/IGNT-CR-541?
> commentId=de43c65f-9ac7-4080-9904-aec119138c94=/
> modules/spring-data-2.0/src/main/java/org/apache/ignite/
> springdata/repository/query/IgniteQueryGenerator.java
> > >
> >
> > Best regards,
> > Slava.
> >
> > 2018-04-05 14:59 GMT+03:00 Роман Меерсон :
> >
> > > Ok, so waiting for accept and commit
> > >
> > > чт, 5 апр. 2018 г. в 15:29, Alexey Kukushkin <
> kukushkinale...@gmail.com
> > >:
> > >
> > > > Roman,
> > > >
> > > > Just pay commiter's (Dmitry Pavlov will most likely commit your code)
> > > > attention to include the new test suite to TeamCity configuration.
> > > >
> > >
> >
>

Re: IGNITE-6879

[Роман Меерсон]

Hi Slava,

Fixed

чт, 5 апр. 2018 г. в 18:41, Вячеслав Коптилин :

> Hi Roman,
>
> please take into account my comment IgniteQueryGenerator.java
> <
> https://reviews.ignite.apache.org/ignite/review/IGNT-CR-541?commentId=de43c65f-9ac7-4080-9904-aec119138c94=/modules/spring-data-2.0/src/main/java/org/apache/ignite/springdata/repository/query/IgniteQueryGenerator.java
> >
>
> Best regards,
> Slava.
>
> 2018-04-05 14:59 GMT+03:00 Роман Меерсон :
>
> > Ok, so waiting for accept and commit
> >
> > чт, 5 апр. 2018 г. в 15:29, Alexey Kukushkin  >:
> >
> > > Roman,
> > >
> > > Just pay commiter's (Dmitry Pavlov will most likely commit your code)
> > > attention to include the new test suite to TeamCity configuration.
> > >
> >
>

Re: Ability to check and completely fill transactions on creation

[Dmitry Pavlov]

Hi Igniters,

I also do not see any reasons against this solution. But I have concern
about performance. How can you estimate impact to performance ?

Sincerely,
Dmitriy Pavlov

чт, 5 апр. 2018 г. в 17:20, Nikolay Izhikov :

> +1 from me.
>
> Let's have this events!
>
> I think `EVT_USR_TX_*START*` is more convinient name for it.
> As far as we have method `IgniteTransctions#txStart`
>
> В Чт, 05/04/2018 в 16:06 +0300, Anton Vinogradov пишет:
> > Igniters,
> >
> > As far as I know we're working on additional 'label' field for
> transactions
> > [1].
> > That's great and will be helpful for customers with huge deploymens to
> see
> > reason of each transaction.
> > But, since 'label' is optional field, there is no way to guarantee it
> will
> > be filled.
> >
> > I'd like to propose an idea of brand new event EVT_USR_TX_CREATED (local
> > transaction created).
> >
> > Local listener on such event will allow to guarantee tx's 'label' field
> > filled, timeout is correct and so on.
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-6827

[GitHub] ignite pull request #2651: Ignite-gg12701-

[AMashenkov]

Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2651


---

[GitHub] ignite pull request #2353: IGNITE-5813: Inconsistent cache store state when ...

[AMashenkov]

Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2353


---

[GitHub] ignite pull request #2262: IGNITE-5473: Create ignite troubleshooting logger...

[AMashenkov]

Github user AMashenkov closed the pull request at:

https://github.com/apache/ignite/pull/2262


---

Re: IGNITE-6879

[Вячеслав Коптилин]

Hi Roman,

please take into account my comment IgniteQueryGenerator.java


Best regards,
Slava.

2018-04-05 14:59 GMT+03:00 Роман Меерсон :

> Ok, so waiting for accept and commit
>
> чт, 5 апр. 2018 г. в 15:29, Alexey Kukushkin :
>
> > Roman,
> >
> > Just pay commiter's (Dmitry Pavlov will most likely commit your code)
> > attention to include the new test suite to TeamCity configuration.
> >
>

[GitHub] ignite pull request #3758: IGNITE-8150: Fix for release suite step 1

[isapego]

GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/3758

IGNITE-8150: Fix for release suite step 1



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8150

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3758.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3758


commit 981c5917372b15b2b4607e540de4b8c027dd5110
Author: Igor Sapego 
Date:   2018-04-05T14:31:32Z

IGNITE-8150: Fix




---

Re: Ability to check and completely fill transactions on creation

[Nikolay Izhikov]

+1 from me.

Let's have this events!

I think `EVT_USR_TX_*START*` is more convinient name for it.
As far as we have method `IgniteTransctions#txStart`

В Чт, 05/04/2018 в 16:06 +0300, Anton Vinogradov пишет:
> Igniters,
> 
> As far as I know we're working on additional 'label' field for transactions
> [1].
> That's great and will be helpful for customers with huge deploymens to see
> reason of each transaction.
> But, since 'label' is optional field, there is no way to guarantee it will
> be filled.
> 
> I'd like to propose an idea of brand new event EVT_USR_TX_CREATED (local
> transaction created).
> 
> Local listener on such event will allow to guarantee tx's 'label' field
> filled, timeout is correct and so on.
> 
> Thoughts?
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-6827

signature.asc
Description: This is a digitally signed message part

Re: Exploiting GP GPUs in Ignite ML

[Yury Babak]

Hi, Andrey

This is a very good question and a bit tricky one.

To start with, one can argue that you already can use GPU in Ignite ML. This
is because we support BLAS via netlib (IGNITE-5278) and netlib, in turn, can
be configured to use NVBLAS, as explained in this library documentation:
https://github.com/fommil/netlib-java/wiki/NVBLAS

However after you dig deeper you'll see that efficient support for GPU is
more complicated, specifically because of overhead involved in data
transfers between CPU and GPU memory. And this is much more complicated and
effort consuming because we need to design things to avoid redundant data
transfers which is likely to involve changes in a lot of ML Grid code.
Tentatively we plan to integrate JCuda library which exposes a fairly
straightforward API to control CPU-GPU data transfers (via JCuda.cudaMalloc
and JCuda.cudaFree). 

This is sort of design challenge though because we would like to have it
transparent for users who don't have CUDA. We're currently working on
transition to Dataset API which possibly can make it easier (IGNITE-8059 and
other tickets). After this is completed I would like to revisit the matters
of GPU integration.

Best regards,
Yury



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-8150) Fix suite [Prepare Vote #1] .Net & C++

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-8150:
---

 Summary: Fix suite [Prepare Vote #1] .Net & C++
 Key: IGNITE-8150
 URL: https://issues.apache.org/jira/browse/IGNITE-8150
 Project: Ignite
  Issue Type: Task
  Components: build, odbc
Affects Versions: 2.4
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.5


There is two different OpenSSL versions for Win32 and Win64 suites. However, 
there is only one environment variable - {{OPENSSL_HOME}}, which can not be set 
to different values during build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3757: SqlQuery hangs indefinitely with additional not r...

[EdShangGG]

GitHub user EdShangGG opened a pull request:

https://github.com/apache/ignite/pull/3757

SqlQuery hangs indefinitely with additional not registered in baseline node.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-gg-13679

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3757.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3757


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

Merge remote-tracking branch 'professional/ignite-2.4.1' into ignite-2.4.1

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit 

[jira] [Created] (IGNITE-8149) MVCC TX Size method should use tx snapshot

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-8149:


 Summary: MVCC TX Size method should use tx snapshot
 Key: IGNITE-8149
 URL: https://issues.apache.org/jira/browse/IGNITE-8149
 Project: Ignite
  Issue Type: Task
  Components: cache
Reporter: Igor Seliverstov


Currently cache.size() returns number of entries in cache trees while there can 
be several versions of one key-value pairs.

We should use tx snapshot and count all passed mvcc filter entries instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Ability to check and completely fill transactions on creation

[Anton Vinogradov]

Igniters,

As far as I know we're working on additional 'label' field for transactions
[1].
That's great and will be helpful for customers with huge deploymens to see
reason of each transaction.
But, since 'label' is optional field, there is no way to guarantee it will
be filled.

I'd like to propose an idea of brand new event EVT_USR_TX_CREATED (local
transaction created).

Local listener on such event will allow to guarantee tx's 'label' field
filled, timeout is correct and so on.

Thoughts?

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

Re: Breaking change in JDBC connection string format

[Vladimir Ozerov]

I mentioned this in the ticket. Hopefully, yes. There is a corner case when
both ampersands and semicolons are there - need to think better how to
handle this.

On Thu, Apr 5, 2018 at 3:56 PM, Dmitriy Setrakyan 
wrote:

> Vladimir, my older email got kind of lost. Can you please clarify, will we
> be able to support both, older and newer formats, to avoid a breaking
> compatibility change between releases?
>
> D.
>
> On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov 
> wrote:
>
> > I think colon is not very good candidate as it clashes with other
> > properties (e.g. host-port delimiter). Semicolon looks good to me. I'll
> > created a ticket [1] to address this.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-8148
> >
> > On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura  wrote:
> >
> > > Denis,
> > >
> > > actually params (key-value pairs) are separated by colon in provided
> > > JIRA issue comment.
> > >
> > > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda  wrote:
> > > > Vladimir, Taras,
> > > >
> > > > Will "@" work for us as the delimiter? I would agree with Andrey to
> > reuse
> > > > this approach for the thin client.
> > > >
> > > > As for the breaking changes, if update the delimiter for the next
> > driver
> > > > version and make sure that version understands 2 delimiters for some
> > time
> > > > (& and the new one), then this would be ideal and not disrupting.
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura 
> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> We've been solve this problem during JDBC2 driver implementation.
> And
> > > >> I don't know any complains about connection string format. Why we
> can
> > > >> just use the same approach? [1]
> > > >>
> > > >> [1] https://issues.apache.org/jira/browse/IGNITE-1250?
> > > >> focusedCommentId=14706511=com.atlassian.jira.
> > > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > > >>
> > > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > > >>  wrote:
> > > >> > Hello!
> > > >> >
> > > >> > I think semicolon is the way to go, since round brackets are often
> > > >> > interpreted by shells and will need escaping on their own. Let's
> get
> > > rid
> > > >> of
> > > >> > & and ?.
> > > >> >
> > > >> > jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
> > > >> >
> > > >> > --
> > > >> > Ilya Kasnacheev
> > > >> >
> > > >> > 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov  >:
> > > >> >
> > > >> >> Igniters,
> > > >> >>
> > > >> >> Thanks to Alex Kuznetsov, we revealed serious usability issue in
> > our
> > > >> thin
> > > >> >> JDBC driver - we user ampersand character to delimit properties:
> > > >> >>
> > > >> >> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
> > > >> >>
> > > >> >> This leads to multiple problems:
> > > >> >> 1) This format is unusable from many console environments and
> > require
> > > >> >> special escaping (PowerShell, bash)
> > > >> >> 2) Also this causing issues when writing connection string is
> > passed
> > > to
> > > >> >> some 3rd-party applications as sometimes they cannot escape it as
> > > well.
> > > >> >>
> > > >> >> I performed investigation on how other vendors do that. Bottom
> > line -
> > > >> >> nobody use ampersand. Instead semicolon or parentheses are used:
> > > >> >>
> > > >> >> jdbc:ignite:thin://host:port/schema?param1=val1=val2
> > > >> >> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
> > > >> >>
> > > >> >> I propose to do a breaking change in AI 2.5 and change the format
> > to
> > > >> >> *parentheses*. This would be a disruptive experience for existing
> > > users,
> > > >> >> but in the long term benefits will outweight. Also remember that
> we
> > > do
> > > >> not
> > > >> >> offered officially any backward compatibility for our JDBC
> driver.
> > > >> >>
> > > >> >> Alternatively we may allow users to use previous format with help
> > of
> > > >> system
> > > >> >> property or environment variable.
> > > >> >>
> > > >> >> Thoughts?
> > > >> >>
> > > >> >> Vladimir.
> > > >> >>
> > > >>
> > >
> >
>

Re: Breaking change in JDBC connection string format

[Dmitriy Setrakyan]

Vladimir, my older email got kind of lost. Can you please clarify, will we
be able to support both, older and newer formats, to avoid a breaking
compatibility change between releases?

D.

On Thu, Apr 5, 2018 at 5:53 AM, Vladimir Ozerov 
wrote:

> I think colon is not very good candidate as it clashes with other
> properties (e.g. host-port delimiter). Semicolon looks good to me. I'll
> created a ticket [1] to address this.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8148
>
> On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura  wrote:
>
> > Denis,
> >
> > actually params (key-value pairs) are separated by colon in provided
> > JIRA issue comment.
> >
> > On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda  wrote:
> > > Vladimir, Taras,
> > >
> > > Will "@" work for us as the delimiter? I would agree with Andrey to
> reuse
> > > this approach for the thin client.
> > >
> > > As for the breaking changes, if update the delimiter for the next
> driver
> > > version and make sure that version understands 2 delimiters for some
> time
> > > (& and the new one), then this would be ideal and not disrupting.
> > >
> > > --
> > > Denis
> > >
> > > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura  wrote:
> > >
> > >> Hi,
> > >>
> > >> We've been solve this problem during JDBC2 driver implementation. And
> > >> I don't know any complains about connection string format. Why we can
> > >> just use the same approach? [1]
> > >>
> > >> [1] https://issues.apache.org/jira/browse/IGNITE-1250?
> > >> focusedCommentId=14706511=com.atlassian.jira.
> > >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> > >>
> > >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> > >>  wrote:
> > >> > Hello!
> > >> >
> > >> > I think semicolon is the way to go, since round brackets are often
> > >> > interpreted by shells and will need escaping on their own. Let's get
> > rid
> > >> of
> > >> > & and ?.
> > >> >
> > >> > jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
> > >> >
> > >> > --
> > >> > Ilya Kasnacheev
> > >> >
> > >> > 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :
> > >> >
> > >> >> Igniters,
> > >> >>
> > >> >> Thanks to Alex Kuznetsov, we revealed serious usability issue in
> our
> > >> thin
> > >> >> JDBC driver - we user ampersand character to delimit properties:
> > >> >>
> > >> >> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
> > >> >>
> > >> >> This leads to multiple problems:
> > >> >> 1) This format is unusable from many console environments and
> require
> > >> >> special escaping (PowerShell, bash)
> > >> >> 2) Also this causing issues when writing connection string is
> passed
> > to
> > >> >> some 3rd-party applications as sometimes they cannot escape it as
> > well.
> > >> >>
> > >> >> I performed investigation on how other vendors do that. Bottom
> line -
> > >> >> nobody use ampersand. Instead semicolon or parentheses are used:
> > >> >>
> > >> >> jdbc:ignite:thin://host:port/schema?param1=val1=val2
> > >> >> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
> > >> >>
> > >> >> I propose to do a breaking change in AI 2.5 and change the format
> to
> > >> >> *parentheses*. This would be a disruptive experience for existing
> > users,
> > >> >> but in the long term benefits will outweight. Also remember that we
> > do
> > >> not
> > >> >> offered officially any backward compatibility for our JDBC driver.
> > >> >>
> > >> >> Alternatively we may allow users to use previous format with help
> of
> > >> system
> > >> >> property or environment variable.
> > >> >>
> > >> >> Thoughts?
> > >> >>
> > >> >> Vladimir.
> > >> >>
> > >>
> >
>

Re: Breaking change in JDBC connection string format

[Vladimir Ozerov]

I think colon is not very good candidate as it clashes with other
properties (e.g. host-port delimiter). Semicolon looks good to me. I'll
created a ticket [1] to address this.

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

On Wed, Apr 4, 2018 at 12:35 AM, Andrey Gura  wrote:

> Denis,
>
> actually params (key-value pairs) are separated by colon in provided
> JIRA issue comment.
>
> On Tue, Apr 3, 2018 at 7:55 PM, Denis Magda  wrote:
> > Vladimir, Taras,
> >
> > Will "@" work for us as the delimiter? I would agree with Andrey to reuse
> > this approach for the thin client.
> >
> > As for the breaking changes, if update the delimiter for the next driver
> > version and make sure that version understands 2 delimiters for some time
> > (& and the new one), then this would be ideal and not disrupting.
> >
> > --
> > Denis
> >
> > On Tue, Apr 3, 2018 at 2:39 AM, Andrey Gura  wrote:
> >
> >> Hi,
> >>
> >> We've been solve this problem during JDBC2 driver implementation. And
> >> I don't know any complains about connection string format. Why we can
> >> just use the same approach? [1]
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-1250?
> >> focusedCommentId=14706511=com.atlassian.jira.
> >> plugin.system.issuetabpanels:comment-tabpanel#comment-14706511
> >>
> >> On Tue, Apr 3, 2018 at 12:20 PM, Ilya Kasnacheev
> >>  wrote:
> >> > Hello!
> >> >
> >> > I think semicolon is the way to go, since round brackets are often
> >> > interpreted by shells and will need escaping on their own. Let's get
> rid
> >> of
> >> > & and ?.
> >> >
> >> > jdbc:ignite:thin://host:port/schema:param1=val1:param2=val2
> >> >
> >> > --
> >> > Ilya Kasnacheev
> >> >
> >> > 2018-04-03 11:30 GMT+03:00 Vladimir Ozerov :
> >> >
> >> >> Igniters,
> >> >>
> >> >> Thanks to Alex Kuznetsov, we revealed serious usability issue in our
> >> thin
> >> >> JDBC driver - we user ampersand character to delimit properties:
> >> >>
> >> >> jdbc:ignite:thin://host:port/schema?param1=val1*&*param2=val2
> >> >>
> >> >> This leads to multiple problems:
> >> >> 1) This format is unusable from many console environments and require
> >> >> special escaping (PowerShell, bash)
> >> >> 2) Also this causing issues when writing connection string is passed
> to
> >> >> some 3rd-party applications as sometimes they cannot escape it as
> well.
> >> >>
> >> >> I performed investigation on how other vendors do that. Bottom line -
> >> >> nobody use ampersand. Instead semicolon or parentheses are used:
> >> >>
> >> >> jdbc:ignite:thin://host:port/schema?param1=val1=val2
> >> >> jdbc:ignite:thin://host:port/schema?(param1=val1)(param2=val2)
> >> >>
> >> >> I propose to do a breaking change in AI 2.5 and change the format to
> >> >> *parentheses*. This would be a disruptive experience for existing
> users,
> >> >> but in the long term benefits will outweight. Also remember that we
> do
> >> not
> >> >> offered officially any backward compatibility for our JDBC driver.
> >> >>
> >> >> Alternatively we may allow users to use previous format with help of
> >> system
> >> >> property or environment variable.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Vladimir.
> >> >>
> >>
>

[GitHub] ignite pull request #3752: IGNITE-8139

[devozerov]

Github user devozerov closed the pull request at:

https://github.com/apache/ignite/pull/3752


---

Re: Upgrade from 2.1.0 to 2.4.0 resulting in error within transaction block

[Vladimir Ozerov]

I've just fixed possible root cause in master [1]. However, as exact use
case details is not known, may be it was something else.
Is it possible to provide more info on the use case: cache configuratioh,
model classes?

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

On Mon, Apr 2, 2018 at 12:21 PM, Yakov Zhdanov  wrote:

> Cross posting to dev.
>
> Vladimir Ozerov, can you please take a look at NPE from query processor
> (see below - GridQueryProcessor.typeByValue(GridQueryProcessor.java:1901)
> )?
>
> --Yakov
>
> 2018-03-29 0:19 GMT+03:00 smurphy :
>
>> Code works in Ignite 2.1.0. Upgrading to 2.4.0 produces the stack trace
>> below. The delete statement that is causing the error is:
>>
>> SqlFieldsQuery sqlQuery = new SqlFieldsQuery("delete from EngineFragment
>> where " + criteria());
>> fragmentCache.query(sqlQuery.setArgs(criteria.getArgs()));
>>
>> The code above is called from within a transactional block managed by a
>> PlatformTransactionManager which is in turn managed by Spring's
>> ChainedTransactionManager. If the @Transactional annotation is removed
>> from
>> the surrounding code, then the code works ok...
>>
>> 2018-03-28 15:50:05,748 WARN  [engine 127.0.0.1] progress_monitor_2
>> unknown
>> unknown {ProgressMonitorImpl.java:112} - Scan
>> [ec7af5e8-a773-40fd-9722-f81103de73dc] is unable to process!
>> javax.cache.CacheException: Failed to process key '247002'
>> at
>> org.apache.ignite.internal.processors.cache.IgniteCacheProxy
>> Impl.query(IgniteCacheProxyImpl.java:618)
>> at
>> org.apache.ignite.internal.processors.cache.IgniteCacheProxy
>> Impl.query(IgniteCacheProxyImpl.java:557)
>> at
>> org.apache.ignite.internal.processors.cache.GatewayProtected
>> CacheProxy.query(GatewayProtectedCacheProxy.java:382)
>> at
>> com.company.core.dao.ignite.IgniteFragmentDao.delete(IgniteF
>> ragmentDao.java:143)
>> at
>> com.company.core.dao.ignite.IgniteFragmentDao$$FastClassBySp
>> ringCGLIB$$c520aa1b.invoke()
>> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodPro
>> xy.java:204)
>> at
>> org.springframework.aop.framework.CglibAopProxy$CglibMethodI
>> nvocation.invokeJoinpoint(CglibAopProxy.java:720)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation
>> .proceed(ReflectiveMethodInvocation.java:157)
>> at
>> org.springframework.dao.support.PersistenceExceptionTranslat
>> ionInterceptor.invoke(PersistenceExceptionTranslationInterce
>> ptor.java:136)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation
>> .proceed(ReflectiveMethodInvocation.java:179)
>> at
>> org.springframework.aop.framework.CglibAopProxy$DynamicAdvis
>> edInterceptor.intercept(CglibAopProxy.java:655)
>> at
>> com.company.core.dao.ignite.IgniteFragmentDao$$EnhancerBySpr
>> ingCGLIB$$ce60f71c.delete()
>> at
>> com.company.core.core.service.impl.InternalScanServiceImpl.p
>> urgeScanFromGrid(InternalScanServiceImpl.java:455)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at
>> org.springframework.aop.support.AopUtils.invokeJoinpointUsin
>> gReflection(AopUtils.java:302)
>> at
>> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
>> JdkDynamicAopProxy.java:202)
>> at com.sun.proxy.$Proxy417.purgeScanFromGrid(Unknown Source)
>> at com.company.core.core.async.tasks.PurgeTask.process(PurgeTas
>> k.java:85)
>> at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at
>> org.springframework.aop.support.AopUtils.invokeJoinpointUsin
>> gReflection(AopUtils.java:302)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation
>> .invokeJoinpoint(ReflectiveMethodInvocation.java:190)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation
>> .proceed(ReflectiveMethodInvocation.java:157)
>> at
>> org.springframework.transaction.interceptor.TransactionInter
>> ceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
>> at
>> org.springframework.transaction.interceptor.TransactionAspec
>> tSupport.invokeWithinTransaction(TransactionAspectSupport.java:281)
>> at
>> org.springframework.transaction.interceptor.TransactionInter
>> ceptor.invoke(TransactionInterceptor.java:96)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation
>> .proceed(ReflectiveMethodInvocation.java:179)
>> at
>> 

[jira] [Created] (IGNITE-8147) SQL: NPE during key/value pair validation

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-8147:
---

 Summary: SQL: NPE during key/value pair validation
 Key: IGNITE-8147
 URL: https://issues.apache.org/jira/browse/IGNITE-8147
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.4
Reporter: Vladimir Ozerov
 Fix For: 2.5


NPE is possible during DELETE command. Exact use case is unknown, but from code 
it is obvious that it is possible when entry processor return's {{null}}.

{code}
2018-03-28 15:50:05,748 WARN  [engine 127.0.0.1] progress_monitor_2 unknown
unknown {ProgressMonitorImpl.java:112} - Scan
[ec7af5e8-a773-40fd-9722-f81103de73dc] is unable to process!
javax.cache.CacheException: Failed to process key '247002'
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:618)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:557)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
at
com.company.core.dao.ignite.IgniteFragmentDao.delete(IgniteFragmentDao.java:143)
at
com.company.core.dao.ignite.IgniteFragmentDao$$FastClassBySpringCGLIB$$c520aa1b.invoke()
at 
org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at
org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at
org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
at
com.company.core.dao.ignite.IgniteFragmentDao$$EnhancerBySpringCGLIB$$ce60f71c.delete()
at
com.company.core.core.service.impl.InternalScanServiceImpl.purgeScanFromGrid(InternalScanServiceImpl.java:455)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
at com.sun.proxy.$Proxy417.purgeScanFromGrid(Unknown Source)
at 
com.company.core.core.async.tasks.PurgeTask.process(PurgeTask.java:85)
at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:302)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at
org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208)
at com.sun.proxy.$Proxy418.process(Unknown Source)
at
com.company.core.core.async.impl.ProgressMonitorImpl._runTasks(ProgressMonitorImpl.java:128)
at
com.company.core.core.async.impl.ProgressMonitorImpl.lambda$null$0(ProgressMonitorImpl.java:98)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:108)
at
com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:41)
at
com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:77)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at

[GitHub] ignite pull request #3756: IGNITE-8101: Ability to terminate system workers ...

[x-kreator]

GitHub user x-kreator opened a pull request:

https://github.com/apache/ignite/pull/3756

IGNITE-8101: Ability to terminate system workers by JMX for test purp…

…oses.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/x-kreator/ignite ignite-8101

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3756.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3756


commit 0a749fae51398184fd9964961880af2ab0ecad73
Author: Dmitriy Sorokin 
Date:   2018-04-05T04:42:54Z

IGNITE-8101: Ability to terminate system workers by JMX for test purposes.




---

[GitHub] ignite pull request #3755: Ignite 7712v1

[alamar]

GitHub user alamar opened a pull request:

https://github.com/apache/ignite/pull/3755

Ignite 7712v1



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7712v1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3755.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3755


commit ee02d6da2ed3e079c7480dc577ddef0748e58fbf
Author: Alexey Kuznetsov 
Date:   2017-10-06T10:00:39Z

IGNITE-6570 Web Console: Move parsing of JSON to pool of workers.
(cherry picked from commit 74f0400)

commit e5b2e3a9fa4aca6f74b58bad5b1e58afda39f257
Author: Alexey Kuznetsov 
Date:   2017-10-06T17:11:37Z

IGNITE-6463 Web Console: Fixed output of big numbers in SQL query results.
(cherry picked from commit 35589a7)

commit c32f0af1c2dfb14dc4d52a282c1d2e50bddcd066
Author: Alexey Kuznetsov 
Date:   2017-10-06T18:10:08Z

IGNITE-6574 Remove pending requests in case STATUS_AUTH_FAILURE && 
credentials == null.
(cherry picked from commit 85261a3)

commit f62884b63663bebd9630ef01df59550033b85f1c
Author: Vasiliy Sisko 
Date:   2017-10-09T10:55:23Z

IGNITE-5767 Web console: Use byte array type instead of java.lang.Object 
for binary JDBC types.
(cherry picked from commit 3184437)

commit aa9093a26ddaf91e7f068663c52e090480cdfe6d
Author: Vasiliy Sisko 
Date:   2017-10-09T12:23:23Z

IGNITE-6287 Web Console: Improved DDL support: added checkbox "Use selected 
cache as default schema name".
(cherry picked from commit a45677c)

commit 912ae4b0fa3971499c1e8f9c4272c9b56b0355d2
Author: Sergey Chugunov 
Date:   2017-10-09T15:35:11Z

IGNITE-6583 Proper getters for rebalance metrics were added; ignite-style 
getters (without get) were deprecated

Signed-off-by: Andrey Gura 

commit aceed9498550833f5a0dcf7fcc003ea2f83378fa
Author: AMRepo 
Date:   2017-10-10T08:57:20Z

IGNITE-6545: Failure during Ignite Service.cancel() can break normal 
shutdown process.

commit f006500391c9712d68d5b90f3da72a421fbda48a
Author: vsisko 
Date:   2017-10-02T16:08:40Z

IGNITE-6422 Visor CMD: Fixed cache statistics output.
(cherry picked from commit 16d2370)

commit 252cb5d2a1962731b39505d6c0d711701a525724
Author: Krzysztof Chmielewski 
Date:   2017-10-10T14:50:59Z

Fixed "IGNITE-6234 Initialize schemaIds to empty set if schemas field is 
null during the deserialization".

Signed-off-by: nikolay_tikhonov 

commit 8eaacd10953f31e75433847747ea7fcf4f129d3b
Author: Alexey Kuznetsov 
Date:   2017-10-12T15:48:35Z

IGNITE-6127 Fixed bytes encoding.
(cherry picked from commit 0f3f7d2)

commit d9bba724c841e99d1374368654ddaa95cacf2ba9
Author: Alexey Popov 
Date:   2017-10-06T09:18:38Z

IGNITE-5224 .NET: PadLeft and PadRight support in LINQ

This closes #2808

commit d2b0986d516503ebb46dac19ea1cb074efacc865
Author: Alexey Popov 
Date:   2017-10-13T11:19:14Z

IGNITE-4723 .NET: Support REGEXP_LIKE in LINQ

This closes #2842

commit 0f0194d5e254181afd7f4a4745899d87f5430861
Author: NSAmelchev 
Date:   2017-09-06T14:32:42Z

Backport of IGNITE-2779 BinaryMarshaller caches must be cleaned during 
client reconnect

(cherry picked from commit c6ac6a5)

commit 9b730195dda83820479415abc3569c6076b69b44
Author: Pavel Tupitsyn 
Date:   2017-08-04T09:34:05Z

IGNITE-5927 .NET: Fix DataTable serialization

This closes #2395

commit 3906e5e1abe2d50996d449748be68d5667c0f34d
Author: Alexey Popov 
Date:   2017-10-17T11:45:42Z

IGNITE-6627 .NET: Fix serialization of enums within generic collections

* Fix EnumEqualityComparer serialization
* Fix enum arrays serialization
* Fix empty objects missing metadata

This closes #2864

commit 949bfcca99348c010fcf4a1251c6057911c77db2
Author: Sergey Chugunov 
Date:   2017-10-11T12:33:23Z

IGNITE-6536 Node fails when detects mapping storage corruption

Signed-off-by: Andrey Gura 

commit 0a2ef5929d0453957debdf743cabd46d041c72ae
Author: Alexey Kuznetsov 
Date:   2017-10-19T02:43:20Z

IGNITE-6647 Web Console: Implemented support of schema migration scripts.
(cherry picked from commit c65399c)

commit a16e9d92a57e39ec3d380ce8af9f97250c91594f
Author: Pavel Tupitsyn 
Date:   2017-10-19T09:36:39Z

IGNITE-6627 .NET: Fix repeated known metadata updates

This closes #2876

commit fadad75d80f76569afb3aa9e2dbf0c47a1d1d6af
Author: apopov 
Date:   2017-10-19T10:07:13Z

  

[GitHub] ignite pull request #3747: IGNITE-5978

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3747


---

Re: IGNITE-6879

[Роман Меерсон]

Ok, so waiting for accept and commit

чт, 5 апр. 2018 г. в 15:29, Alexey Kukushkin :

> Roman,
>
> Just pay commiter's (Dmitry Pavlov will most likely commit your code)
> attention to include the new test suite to TeamCity configuration.
>

[GitHub] ignite pull request #3750: Ignite PDS 1 (Direct IO): failed test IgnitePdsCh...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3750


---

Re: IGNITE-6879

[Alexey Kukushkin]

Roman,

Just pay commiter's (Dmitry Pavlov will most likely commit your code)
attention to include the new test suite to TeamCity configuration.

[GitHub] ignite pull request #3514: IGNITE-7481 suspended tx timeout rollback fix

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3514


---

[jira] [Created] (IGNITE-8146) IgniteUtils classLoaderUrls() JDK9 bug

[Sujit Kumar Mahapatra (JIRA)]

Sujit Kumar Mahapatra created IGNITE-8146:
-

 Summary: IgniteUtils classLoaderUrls() JDK9 bug
 Key: IGNITE-8146
 URL: https://issues.apache.org/jira/browse/IGNITE-8146
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 2.4
Reporter: Sujit Kumar Mahapatra


Reporting a probable miss that breaks JDK9 compatibility.

As part of [this 
commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6]
 [this 
commit|https://github.com/apache/ignite/commit/ee2a6f7c3f2e3c9bd8dc61c8dbdf171e933d9481#diff-309ab4ef2fc61d6b2570d390acfb9bd6]
  in 
[ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52]/[modules|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules]/[core|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core]/[src|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src]/[main|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main]/[java|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main/java]/[org|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main/java/org]/[apache|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main/java/org/apache]/[ignite|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main/java/org/apache/ignite]/[internal|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main/java/org/apache/ignite/internal]/[util|https://github.com/apache/ignite/tree/f1a853ded8e835ce8c98c029cce7d5d17fbd3f52/modules/core/src/main/java/org/apache/ignite/internal/util]/*IgniteUtils.java,*
 below lines will throw *ClassCastException* in JDK9 during runtime.

_return ((URLClassLoader)urlClsLdrField.get(clsLdr)).getURLs();_

 

Here, _urlClsLdrField.get(clsLdr)_ return an object of type 
"___java.base/jdk.internal.loader.URLClassPath_" which can't be cast to 
"_URLClassLoader"._

 

The fix seems to be to introduce another reflection call to invoke _getURLs_  
method of the internal _URLClassPath ++_++class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3542: IGNITE-6842: stopAllGrids for afterTestsStop

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3542


---

Re: IGNITE-6879

[Роман Меерсон]

Alexey,

1) Fixed
2) How could i be sure? What do i need to do?

чт, 5 апр. 2018 г. в 14:24, Alexey Kukushkin :

> Roman,
>
> Just two small comments from me:
>
>1. I suggest renaming IgniteSpringDataTestSuite to
>IgniteSpringData2TestSuite: we must be able to test both spring-data and
>spring-data-2 JARs with single "mvn test"
>2. Make sure "Ignite Spring Data" test job in TeamCity is extended to
>run the new test suite after the code is committed.
>
> Other than that the new module looks OK to me.
>

Re: IGNITE-6879

[Alexey Kukushkin]

Roman,

Just two small comments from me:

   1. I suggest renaming IgniteSpringDataTestSuite to
   IgniteSpringData2TestSuite: we must be able to test both spring-data and
   spring-data-2 JARs with single "mvn test"
   2. Make sure "Ignite Spring Data" test job in TeamCity is extended to
   run the new test suite after the code is committed.

Other than that the new module looks OK to me.

[GitHub] ignite pull request #3754: fix to avoid race between auto-activation and exp...

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

https://github.com/apache/ignite/pull/3754

fix to avoid race between auto-activation and explicit activation



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-pds-hang-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3754.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3754


commit a765ef4d0fd9de0d011f7f4346844116c29c4c27
Author: Sergey Chugunov 
Date:   2018-04-05T10:07:13Z

pds-hang-fix fix to avoid race between auto-activation and explicit 
activation




---

[GitHub] ignite pull request #3684: IGNITE-7712 Server-side system property IGNITE_SQ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3684


---

[GitHub] ignite pull request #3666: IGNITE-7712 Add flag IGNITE_SQL_LAZY_RESULT_SET f...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3666


---

Re: Data Loss while upgrading custom jar from old jar in server and client nodes

[Ivan Rakov]

Hi,

Cache configuration is persisted in 
db\{consistent-ID}\cache-{cache-name}\cache_data.dat file. It's just 
CacheConfiguration serialized by JDK marshaller.
Try to delete this file and start cache with new configuration (with 
correct factory class names). All your data will persist as long as old 
ignite data is compatible with new configuration.


Best Regards,
Ivan Rakov

On 04.04.2018 23:08, Denis Magda wrote:

Ivan R., Alex G., persistence experts,

Please have a look at this question.

--
Denis

On Mon, Apr 2, 2018 at 6:15 AM, Andrey Mashenkov  wrote:


Hi,

Thanks for checking out issue. I think its not about IDE issue.
Again same thing i have reproduce like bellow steps

1.run the program from IDE as client
2.copy jar to ignite libs folder and start the server
3.Then check previous message steps so that can able to reproduce the
issue.
https://www.youtube.com/watch?v=COQiu2gi8ag=43s

I have attached the video link.Can you go through that video and check

the

issue.


Thanks



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/




--
Best regards,
Andrey V. Mashenkov



--
Best regards,
Andrey V. Mashenkov

[GitHub] ignite pull request #3753: Attempting to fix hanging suite

[agoncharuk]

GitHub user agoncharuk opened a pull request:

https://github.com/apache/ignite/pull/3753

Attempting to fix hanging suite



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-gg-13667

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3753.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3753


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

Merge remote-tracking branch 'professional/ignite-2.4.1' into ignite-2.4.1

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578
Author: 

[GitHub] ignite pull request #3752: IGNITE-8139

[devozerov]

GitHub user devozerov opened a pull request:

https://github.com/apache/ignite/pull/3752

IGNITE-8139



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8139

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3752.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3752


commit 4a4c4818a7ec9c1d8c30c33f77e2d104d2efe2ee
Author: devozerov 
Date:   2018-04-05T09:16:48Z

Done.




---

[jira] [Created] (IGNITE-8145) Web console: Implement test to check missed new fields in configurations, and SPIs, and...

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-8145:
-

 Summary: Web console: Implement test to check missed new fields in 
configurations, and SPIs, and...
 Key: IGNITE-8145
 URL: https://issues.apache.org/jira/browse/IGNITE-8145
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.5
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8144) Web console: UI issue in tables

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8144:
--

 Summary: Web console: UI issue in tables
 Key: IGNITE-8144
 URL: https://issues.apache.org/jira/browse/IGNITE-8144
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Dmitriy Shabalin
 Attachments: screenshot-1.png





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3751: IGNITE-8143: Modified fetching EXTERNAL_LIBS for ...

[shroman]

GitHub user shroman opened a pull request:

https://github.com/apache/ignite/pull/3751

IGNITE-8143: Modified fetching EXTERNAL_LIBS for docker container.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shroman/ignite IGNITE-8143

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3751.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3751


commit 7420b7702c66e996345b24c294c14ef25f923234
Author: shroman 
Date:   2018-04-05T08:21:33Z

IGNITE-8143: Modified fetching EXTERNAL_LIBS for docker container.




---

Re: IGNITE-6879

[Роман Меерсон]

I`ve finished with new module:

https://github.com/apache/ignite/pull/3704

чт, 5 апр. 2018 г. в 12:06, Роман Меерсон :

> Ok guys, I`ll made changes but what should we do with examples and with
> Spring module version?
>
> Exemples couldn`t support both versions, so should i leave upgraded to 2.0
> version?
> Spring module was upgraded to newest version, so should i leave it on
> newest version?
>
> чт, 5 апр. 2018 г. в 0:17, Denis Magda :
>
>> Hi guys,
>>
>> According to ASF stats our spring data integration is 2 times more popular
>> than spark integraion - 900 maven downloads vs. 400.
>>
>> So I would suggest us creating ignite-spring-data-2.0 module to support
>> new
>> deployments and leave ignite-spring-data to not break existing ones.
>>
>> --
>> Denis
>>
>>
>>
>> On Wed, Apr 4, 2018 at 7:33 AM, Dmitry Pavlov 
>> wrote:
>>
>> > Hi Igniters,
>> >
>> > I am going to review these changes in 3-4 days. If everything is ok and
>> if
>> > there is no objections, I will merge it.
>> >
>> > Hi Denis,
>> >
>> > are you agree with proposed change?
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > ср, 4 апр. 2018 г. в 14:26, Дмитрий Рябов :
>> >
>> > > I agree that increasing complexity isn't good idea. Roman, can you
>> > document
>> > > the migration guide?
>> > >
>> > > 2018-04-04 13:41 GMT+03:00 Alexey Kukushkin <
>> kukushkinale...@gmail.com>:
>> > >
>> > > > Roman, Dmitry,
>> > > >
>> > > > I also reviewed the fix and the code looks OK to me. But the fix has
>> > > > significant implication - Ignite no longer can be used with
>> spring-data
>> > > 1.0
>> > > > due to no backward compatibility between spring 2.0 and 1.0 APIs.
>> With
>> > > this
>> > > > approach we must remember to add corresponding spring-data migration
>> > > > instructions to the future ignite 2.5 migration guide.
>> > > >
>> > > > We could keep spring 1 support and backward compatibility by
>> creating a
>> > > new
>> > > > module "ignite-spring-2-data" and keeping existing
>> ignite-spring-data
>> > as
>> > > > is. I do not like this option since to me increased complexity and
>> > > > maintainability costs overweight the benefits of protecting
>> > > > "Ignite-spring-1" users.
>> > > >
>> > > > I suggest you find a committer (see this list
>> > > > ),
>> > > communicate
>> > > > the implication I mentioned above and say that two people already
>> > > approved
>> > > > the code providing we are OK with the chosen approach.
>> > > >
>> > >
>> >
>>
>

[jira] [Created] (IGNITE-8143) Feching EXTERNAL_LIBS for docker container fails

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-8143:


 Summary: Feching EXTERNAL_LIBS for docker container fails
 Key: IGNITE-8143
 URL: https://issues.apache.org/jira/browse/IGNITE-8143
 Project: Ignite
  Issue Type: Improvement
Reporter: Roman Shtykh
Assignee: Roman Shtykh


*EXTERNAL_LIBS* are fetched by _wget_ with *-i* option, which does not exist in 
CoreOS(busybox).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IGNITE-6879

[Роман Меерсон]

Ok guys, I`ll made changes but what should we do with examples and with
Spring module version?

Exemples couldn`t support both versions, so should i leave upgraded to 2.0
version?
Spring module was upgraded to newest version, so should i leave it on
newest version?

чт, 5 апр. 2018 г. в 0:17, Denis Magda :

> Hi guys,
>
> According to ASF stats our spring data integration is 2 times more popular
> than spark integraion - 900 maven downloads vs. 400.
>
> So I would suggest us creating ignite-spring-data-2.0 module to support new
> deployments and leave ignite-spring-data to not break existing ones.
>
> --
> Denis
>
>
>
> On Wed, Apr 4, 2018 at 7:33 AM, Dmitry Pavlov 
> wrote:
>
> > Hi Igniters,
> >
> > I am going to review these changes in 3-4 days. If everything is ok and
> if
> > there is no objections, I will merge it.
> >
> > Hi Denis,
> >
> > are you agree with proposed change?
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 4 апр. 2018 г. в 14:26, Дмитрий Рябов :
> >
> > > I agree that increasing complexity isn't good idea. Roman, can you
> > document
> > > the migration guide?
> > >
> > > 2018-04-04 13:41 GMT+03:00 Alexey Kukushkin  >:
> > >
> > > > Roman, Dmitry,
> > > >
> > > > I also reviewed the fix and the code looks OK to me. But the fix has
> > > > significant implication - Ignite no longer can be used with
> spring-data
> > > 1.0
> > > > due to no backward compatibility between spring 2.0 and 1.0 APIs.
> With
> > > this
> > > > approach we must remember to add corresponding spring-data migration
> > > > instructions to the future ignite 2.5 migration guide.
> > > >
> > > > We could keep spring 1 support and backward compatibility by
> creating a
> > > new
> > > > module "ignite-spring-2-data" and keeping existing ignite-spring-data
> > as
> > > > is. I do not like this option since to me increased complexity and
> > > > maintainability costs overweight the benefits of protecting
> > > > "Ignite-spring-1" users.
> > > >
> > > > I suggest you find a committer (see this list
> > > > ),
> > > communicate
> > > > the implication I mentioned above and say that two people already
> > > approved
> > > > the code providing we are OK with the chosen approach.
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-8142) Web Console: Fix change detection logic on configuration.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8142:


 Summary: Web Console: Fix change detection logic on configuration.
 Key: IGNITE-8142
 URL: https://issues.apache.org/jira/browse/IGNITE-8142
 Project: Ignite
  Issue Type: Task
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Ilya Borisov
 Fix For: 2.5


How to reproduce:
 # Input value in some EMPTY input.
 # Delete content.
 # Click on Profile link.
 # You will see question about unsaved changes (see image attached).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)