date:20171011

Re: Persistence per memory policy configuration

2017-10-11 Thread Dmitriy Setrakyan

Is the storage path the root folder for the persistence or only the root
path for the main storage?

On Wed, Oct 11, 2017 at 3:54 PM, Denis Magda  wrote:

> Ivan,
>
> Instead of “setStoragePath” I would suggest “setPersistencePath”. Left
> some extra notes in the ticket.
>


> —
> Denis
>
> > On Oct 11, 2017, at 4:30 AM, Ivan Rakov  wrote:
> >
> > Vladimir,
> >
> > Thanks for focusing on existing namings. Most of your suggestions really
> sound better. I've posted my thoughts under your comment.
> >
> > By the way, we should decide two things:
> >
> > 1) Naming for methods for configuring store path. I suggest the
> following:
> >
> > *setStoragePath* - for partition and index files
> > *setWalPath* - for WAL files
> > *walArchivePath* - for WAL archive files
> >
> > 2) Renaming *checkpointingFrequency* to *checkpointFrequency* (same with
> *checkpointingPageBufferSize* and *checkpointingThreads*). Both options
> sounds ok to me, let's see what community thinks.
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 11.10.2017 14:05, Vladimir Ozerov wrote:
> >> Ivan,
> >>
> >> I left some comments in the ticket [1], please take a look.
> >>
> >> [1]
> >> https://issues.apache.org/jira/browse/IGNITE-6030?
> focusedCommentId=16200050=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16200050
> >>
> >> On Wed, Oct 11, 2017 at 12:04 PM, Ivan Rakov 
> wrote:
> >>
> >>> Igniters,
> >>>
> >>> https://issues.apache.org/jira/browse/IGNITE-6030 is ready and
> enqueued
> >>> for TC run.
> >>> PR: https://github.com/apache/ignite/pull/2828
> >>>
> >>> Everyone interested in new data storage configuration API, please pay
> >>> attention and review.
> >>>
> >>>
> >>> Best Regards,
> >>> Ivan Rakov
> >>>
> >>>
> >>> On 09.10.2017 12:40, Pavel Tupitsyn wrote:
> >>>
>  Sounds good to me.
> 
>  On Mon, Oct 9, 2017 at 12:35 PM, Ivan Rakov 
>  wrote:
> 
>  Pavel,
> > Sounds reasonable.
> > I suggest to include both "data" and "configuration" to make it even
> more
> > obvious:
> >
> > set/getDefaultDataRegionConfiguration
> > set/getDataRegionConfigurations
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 09.10.2017 10:51, Pavel Tupitsyn wrote:
> >
> > Sorry that I'm late to the party, but this looks inconsistent:
> >> DataStorageConfiguration defaultRegionConfiguration
> >> DataRegionConfiguration[] getDataRegions
> >>
> >> defaultRegionConfiguration + getRegionConfigurations
> >> - or -
> >> defaultDataRegion + getDataRegions
> >>
> >> Thoughts?
> >>
> >> On Mon, Oct 2, 2017 at 9:10 PM, Ivan Rakov 
> >> wrote:
> >>
> >> Denis,
> >>
> >>> Yes, you're right. All cache groups without specific data region
> >>> configured will be persistent.
> >>> And if you want to add another persistent data region, you should
> set
> >>> *isPeristenceEnabled* flag in its *DataRegionConfiguration*
> explictly.
> >>>
> >>> Best Regards,
> >>> Ivan Rakov
> >>>
> >>>
> >>> On 02.10.2017 21:01, Denis Magda wrote:
> >>>
> >>> Missed the point with defaults. Makes sense to me now. So to wrap
> this
> >>>
>  up, if I want to enable the persistence globally and don’t have
> any
>  regions
>  configured explicitly I need to take the default region and
> switch the
>  persistence on for it. Is my understanding correct?
> 
>  —
>  Denis
> 
>  On Oct 2, 2017, at 10:57 AM, Ivan Rakov 
>  wrote:
> 
>  Denis, why do you need to access an instance of the default region
> > bean?
> > If you want to set any parameter, just instantiate new bean with
> this
> > parameter set (like in XML snipped below). Other parameters will
> be
> > automatically initialized with their default values.
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 02.10.2017 19:28, Denis Magda wrote:
> >
> > 
> >
> >> 
>    value="#{100
>  *
>  1024 * 1024}"/>
>  
>  
>  
>  
>  
>  
>  
> 
>  In other data regions persistence will be disabled by default.
> 
> >>> Ivan, how to get an instance to the default region bean and
> change
> >>> a
> >>>
> >> parameter? Obviously, if the goal is to enable the persistence I
> >> don’t want
> >> to create the default region bean from scratch.
> >>
>

[jira] [Created] (IGNITE-6602) .NET: Improve LINQ documentation

2017-10-11 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6602:
--

 Summary: .NET: Improve LINQ documentation
 Key: IGNITE-6602
 URL: https://issues.apache.org/jira/browse/IGNITE-6602
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Document all recent improvements, in particular, IGNITE-4636, IGNITE-4425.

Look for others by linq tag.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Integration of Spark and Ignite. Prototype.

2017-10-11 Thread Valentin Kulichenko

Hi Nikolay,

Sorry for delay on this, got a little swamped lately. I will do my best to
review the code this week.

-Val

On Mon, Oct 9, 2017 at 11:48 AM, Николай Ижиков 
wrote:

> Hello, Valentin.
>
> Did you have a chance to look at my changes?
>
> Now I think I have done almost all required features.
> I want to make some performance test to ensure my implementation work
> properly with a significant amount of data.
> And I definitely need some feedback for my changes.
>
>
> 2017-10-09 18:45 GMT+03:00 Николай Ижиков :
>
>> Hello, guys.
>>
>> Which version of Spark do we want to use?
>>
>> 1. Currently, Ignite depends on Spark 2.1.0.
>>
>> * Can be run on JDK 7.
>> * Still supported: 2.1.2 will be released soon.
>>
>> 2. Latest Spark version is 2.2.0.
>>
>> * Can be run only on JDK 8+
>> * Released Jul 11, 2017.
>> * Already supported by huge vendors(Amazon for example).
>>
>> Note that in IGNITE-3084 I implement some internal Spark API.
>> So It will take some effort to switch between Spark 2.1 and 2.2
>>
>>
>> 2017-09-27 2:20 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com>:
>>
>>> I will review in the next few days.
>>>
>>> -Val
>>>
>>> On Tue, Sep 26, 2017 at 2:23 PM, Denis Magda  wrote:
>>>
>>> > Hello Nikolay,
>>> >
>>> > This is good news. Finally this capability is coming to Ignite.
>>> >
>>> > Val, Vladimir, could you do a preliminary review?
>>> >
>>> > Answering on your questions.
>>> >
>>> > 1. Yardstick should be enough for performance measurements. As a Spark
>>> > user, I will be curious to know what’s the point of this integration.
>>> > Probably we need to compare Spark + Ignite and Spark + Hive or Spark +
>>> > RDBMS cases.
>>> >
>>> > 2. If Spark community is reluctant let’s include the module in
>>> > ignite-spark integration.
>>> >
>>> > —
>>> > Denis
>>> >
>>> > > On Sep 25, 2017, at 11:14 AM, Николай Ижиков >> >
>>> > wrote:
>>> > >
>>> > > Hello, guys.
>>> > >
>>> > > Currently, I’m working on integration between Spark and Ignite [1].
>>> > >
>>> > > For now, I implement following:
>>> > >* Ignite DataSource implementation(IgniteRelationProvider)
>>> > >* DataFrame support for Ignite SQL table.
>>> > >* IgniteCatalog implementation for a transparent resolving of
>>> ignites
>>> > > SQL tables.
>>> > >
>>> > > Implementation of it can be found in PR [2]
>>> > > It would be great if someone provides feedback for a prototype.
>>> > >
>>> > > I made some examples in PR so you can see how API suppose to be used
>>> [3].
>>> > > [4].
>>> > >
>>> > > I need some advice. Can you help me?
>>> > >
>>> > > 1. How should this PR be tested?
>>> > >
>>> > > Of course, I need to provide some unit tests. But what about
>>> scalability
>>> > > tests, etc.
>>> > > Maybe we need some Yardstick benchmark or similar?
>>> > > What are your thoughts?
>>> > > Which scenarios should I consider in the first place?
>>> > >
>>> > > 2. Should we provide Spark Catalog implementation inside Ignite
>>> codebase?
>>> > >
>>> > > A current implementation of Spark Catalog based on *internal Spark
>>> API*.
>>> > > Spark community seems not interested in making Catalog API public or
>>> > > including Ignite Catalog in Spark code base [5], [6].
>>> > >
>>> > > *Should we include Spark internal API implementation inside Ignite
>>> code
>>> > > base?*
>>> > >
>>> > > Or should we consider to include Catalog implementation in some
>>> external
>>> > > module?
>>> > > That will be created and released outside Ignite?(we still can
>>> support
>>> > and
>>> > > develop it inside Ignite community).
>>> > >
>>> > > [1] https://issues.apache.org/jira/browse/IGNITE-3084
>>> > > [2] https://github.com/apache/ignite/pull/2742
>>> > > [3] https://github.com/apache/ignite/pull/2742/files#diff-
>>> > > f4ff509cef3018e221394474775e0905
>>> > > [4] https://github.com/apache/ignite/pull/2742/files#diff-
>>> > > f2b670497d81e780dfd5098c5dd8a89c
>>> > > [5] http://apache-spark-developers-list.1001551.n3.
>>> > > nabble.com/Spark-Core-Custom-Catalog-Integration-between-
>>> > > Apache-Ignite-and-Apache-Spark-td22452.html
>>> > > [6] https://issues.apache.org/jira/browse/SPARK-17767
>>> > >
>>> > > --
>>> > > Nikolay Izhikov
>>> > > nizhikov@gmail.com
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Nikolay Izhikov
>> nizhikov@gmail.com
>>
>
>
>
> --
> Nikolay Izhikov
> nizhikov@gmail.com
>

Re: Apache Ignite 2.3 release

2017-10-11 Thread Denis Magda

Absolutely, see no reason to rush with the release until these two tickets are 
finalized.

Ivan, Oleg, do you think you’ll be able to finalize the tickets assigned on you 
by the beginning of the next week?

—
Denis

> On Oct 11, 2017, at 6:20 AM, Vladimir Ozerov  wrote:
> 
> Igniters,
> 
> As far as I can see we almost ready with 2.3 scope, except of two major
> things:
> 1) New persistence configuration with ability to enable persistence on
> per-region basis [1]
> 2) And sqlline tool which will simplify SQL access to Ignite cluster [2]
> 
> Let's wait for these two tickets and then start testing.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-6030
> [2] https://issues.apache.org/jira/browse/IGNITE-5608
> 
> Vladimir.
> 
> On Tue, Oct 3, 2017 at 5:10 PM, Vladimir Ozerov 
> wrote:
> 
>> Folks,
>> 
>> I created the branch *ignite-2.3* to finalize release scope. Please make
>> sure that only tickets targeted for 2.3 release are merged to this branch.
>> Let's take a week for finalization and stabilization, and then start
>> testing.
>> 
>> On Thu, Sep 28, 2017 at 10:16 AM, Vladimir Ozerov 
>> wrote:
>> 
>>> Igniters,
>>> 
>>> I created our standard release page for AI 2.3 [1]. As nobody had
>>> objections on dates, I propose to dedicate next week for stabilization and
>>> start testing then.
>>> Also I created release branch ignite-2.3. Let's make sure that effective
>>> of next Tuesday, 3 Oct, we merge only release-related changes to this
>>> branch.
>>> 
>>> Vladimir.
>>> 
>>> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.3
>>> 
>>> On Thu, Sep 28, 2017 at 10:10 AM, Vladimir Ozerov 
>>> wrote:
>>> 
 Hi Pavel, Sergey.
 
 All mentioned tickets definitely important for the release. Let's do our
 best to fit them.
 
 On Mon, Sep 25, 2017 at 11:06 AM, schernolyas <
 sergey.chernol...@gmail.com> wrote:
 
> Hi Vladimir!
> 
> Could you add to future release by PR
> (http://apache-ignite-developers.2346864.n4.nabble.com/GitHu
> b-ignite-pull-request-2737-IGNITE-6286-fix-org-h2-jdbc-JdbcS
> QLException-td22625.html)?
> The PR is very important for project Hibernate OGM .
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
> 
 
 
>>> 
>>

Re: Avoid closing caches on client during cluster restart - determining it's the same cache

2017-10-11 Thread Denis Magda

Hello Ilya,

Isn’t the cache name itself sufficient to make all the validations? The cache 
name is a unique parameter.

Furthermore, we do not check CacheConfiguration settings provided by the client 
if CacheConfiguration.name is already deployed when the client tries to get a 
reference to the cache (Ignite.getOrCreateCache(cacheCfg)). Don’t think we 
should make any exception for the restart scenarios.

—
Denis
 
 
> On Oct 11, 2017, at 5:20 AM, Ilya Kasnacheev  
> wrote:
> 
> Hello Igniters!
> 
> I'm working on IGNITE-2766. We want caches opened on client to survive
> cluster restart (all nodes down, then some nodes up). Currently Ignite
> compares deploymentId which will not match with new cluster's caches.
> 
> But still we want to make sure it's still the same cache in the new
> cluster, and not a different one with the same name. One obvious idea is to
> look at CacheConfiguration. However I think a frequent scenario for cluster
> restart is a minor change of cache configuration (e.g. add or remove
> backup), and it will be a pity to lose client caches in this case.
> 
> So, what fields in CacheConfiguration should we compare upon to figure out
> if it's still the same cache? Name obviously. How does grpName work and
> should we compare on them too?
> 
> indexedTypes[] make sense because if it's a cache on different types it's
> not safe to be used where it was open. cache mode and atomicity mode make
> sence since cache should now be handled differently?
> 
> Any other fields in CacheConfiguration we should check because it's not
> safe to continue in case of mismatch? Some different approach? Suggestions
> are kindly welcome
> 
> -- 
> Ilya Kasnacheev

Re: Persistence per memory policy configuration

2017-10-11 Thread Denis Magda

Ivan,

Instead of “setStoragePath” I would suggest “setPersistencePath”. Left some 
extra notes in the ticket.

—
Denis

> On Oct 11, 2017, at 4:30 AM, Ivan Rakov  wrote:
> 
> Vladimir,
> 
> Thanks for focusing on existing namings. Most of your suggestions really 
> sound better. I've posted my thoughts under your comment.
> 
> By the way, we should decide two things:
> 
> 1) Naming for methods for configuring store path. I suggest the following:
> 
> *setStoragePath* - for partition and index files
> *setWalPath* - for WAL files
> *walArchivePath* - for WAL archive files
> 
> 2) Renaming *checkpointingFrequency* to *checkpointFrequency* (same with 
> *checkpointingPageBufferSize* and *checkpointingThreads*). Both options 
> sounds ok to me, let's see what community thinks.
> 
> Best Regards,
> Ivan Rakov
> 
> On 11.10.2017 14:05, Vladimir Ozerov wrote:
>> Ivan,
>> 
>> I left some comments in the ticket [1], please take a look.
>> 
>> [1]
>> https://issues.apache.org/jira/browse/IGNITE-6030?focusedCommentId=16200050=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16200050
>> 
>> On Wed, Oct 11, 2017 at 12:04 PM, Ivan Rakov  wrote:
>> 
>>> Igniters,
>>> 
>>> https://issues.apache.org/jira/browse/IGNITE-6030 is ready and enqueued
>>> for TC run.
>>> PR: https://github.com/apache/ignite/pull/2828
>>> 
>>> Everyone interested in new data storage configuration API, please pay
>>> attention and review.
>>> 
>>> 
>>> Best Regards,
>>> Ivan Rakov
>>> 
>>> 
>>> On 09.10.2017 12:40, Pavel Tupitsyn wrote:
>>> 
 Sounds good to me.
 
 On Mon, Oct 9, 2017 at 12:35 PM, Ivan Rakov 
 wrote:
 
 Pavel,
> Sounds reasonable.
> I suggest to include both "data" and "configuration" to make it even more
> obvious:
> 
> set/getDefaultDataRegionConfiguration
> set/getDataRegionConfigurations
> 
> Best Regards,
> Ivan Rakov
> 
> 
> On 09.10.2017 10:51, Pavel Tupitsyn wrote:
> 
> Sorry that I'm late to the party, but this looks inconsistent:
>> DataStorageConfiguration defaultRegionConfiguration
>> DataRegionConfiguration[] getDataRegions
>> 
>> defaultRegionConfiguration + getRegionConfigurations
>> - or -
>> defaultDataRegion + getDataRegions
>> 
>> Thoughts?
>> 
>> On Mon, Oct 2, 2017 at 9:10 PM, Ivan Rakov 
>> wrote:
>> 
>> Denis,
>> 
>>> Yes, you're right. All cache groups without specific data region
>>> configured will be persistent.
>>> And if you want to add another persistent data region, you should set
>>> *isPeristenceEnabled* flag in its *DataRegionConfiguration* explictly.
>>> 
>>> Best Regards,
>>> Ivan Rakov
>>> 
>>> 
>>> On 02.10.2017 21:01, Denis Magda wrote:
>>> 
>>> Missed the point with defaults. Makes sense to me now. So to wrap this
>>> 
 up, if I want to enable the persistence globally and don’t have any
 regions
 configured explicitly I need to take the default region and switch the
 persistence on for it. Is my understanding correct?
 
 —
 Denis
 
 On Oct 2, 2017, at 10:57 AM, Ivan Rakov 
 wrote:
 
 Denis, why do you need to access an instance of the default region
> bean?
> If you want to set any parameter, just instantiate new bean with this
> parameter set (like in XML snipped below). Other parameters will be
> automatically initialized with their default values.
> 
> Best Regards,
> Ivan Rakov
> 
> On 02.10.2017 19:28, Denis Magda wrote:
> 
> 
> 
>> 
 >>> value="#{100
 *
 1024 * 1024}"/>
 
 
 
 
 
 
 
 
 In other data regions persistence will be disabled by default.
 
>>> Ivan, how to get an instance to the default region bean and change
>>> a
>>> 
>> parameter? Obviously, if the goal is to enable the persistence I
>> don’t want
>> to create the default region bean from scratch.
>> 
>> —
>> Denis
>> 
>> On Oct 2, 2017, at 9:11 AM, Ivan Rakov 
>> wrote:
>> 
>> Agree with Alexey.
>>> Properties like *defaultDataRegionSize*,
>>> *isDefaultPersistenceEnabled*
>>> can confuse users who don't know that there's such thing as default
>>> data
>>> region. They can decide they are inherited by all data regions

[GitHub] ignite pull request #2834: ignite-gg-12908 Sequential puts fail for keys imp...

2017-10-11 Thread symbicator

GitHub user symbicator opened a pull request:

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

ignite-gg-12908 Sequential puts fail for keys implementing Externalizable

For CI

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

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

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

https://github.com/apache/ignite/pull/2834.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 #2834


commit abf4f325217c27cb5399aedc517e763092174d79
Author: Andrey V. Mashenkov 
Date:   2017-06-01T11:49:20Z

Revert snapshot fix and fix tests.

commit 705d9cfca519183fa9e79e0686c1db48c0f5afe2
Author: rfqu 
Date:   2017-06-01T16:31:11Z

ticket fixed: IGN-7062 (TcpDiscoverySpi ignores maxMissedClientHeartbeats 
property)

commit 95d55954de4d60cb1f1f46f19f1aa0b8a9821f16
Author: Evgenii Zhuravlev 
Date:   2017-06-01T16:56:34Z

SSL fix

commit 5f9dc362f82bc6351d01a77418e42c01db9391cf
Author: rfqu 
Date:   2017-06-02T09:11:40Z

code style fixed

commit 05c639f041ffbbc53678addaf46fc806fb7c168c
Author: rfqu 
Date:   2017-06-02T09:25:53Z

coding style fixed

commit 4d2c9ef1cd50be0a73cd8ac4a0edc809631b23a2
Author: rfqu 
Date:   2017-06-02T10:49:31Z

test added, taken from tiket IGNITE-5103

commit f0a7ac5709329f137ddfdbc07367394125212d27
Author: rfqu 
Date:   2017-06-02T12:12:56Z

Merge branch 'ignite-1.8.7' of https://github.com/gridgain/apache-ignite 
into ignite-1.7.11-IGN-7062

commit 744a81ba937ba83ecdefa7c71f198d92d21527bb
Author: Anton Vinogradov 
Date:   2017-05-31T12:27:33Z

IGNITE-5232 [BACKPORT] GridDhtPartitionDemander.requestPartitions invokes 
sendMessages consequently, which lead to significant increase of node start 
time on large clusters with ssl

commit 8220fb121eec86c18a711816f3db478b1d31a4e6
Author: agura 
Date:   2017-05-24T16:55:09Z

ignite-5283 Fix of transaction recovery on backup when primary node failed

commit 6c03cd4150ddc3f7c243f39387ada3b558055bff
Author: dkarachentsev 
Date:   2017-06-03T12:18:05Z

Merge branch 'ignite-1.7.11-p1' into ignite-1.7.12

commit 0c5bf92a56eb4df089291bafe4a2cf76bf14982c
Author: Andrey V. Mashenkov 
Date:   2017-06-05T09:48:44Z

Merge branch 'ignite-1.8.7' into ignite-1.9.4

# Conflicts:
#   
modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/datasource/DataSource.java
#   
modules/cassandra/store/src/test/java/org/apache/ignite/tests/IgnitePersistentStoreTest.java
#   
modules/clients/src/test/java/org/apache/ignite/internal/jdbc2/JdbcAbstractDmlStatementSelfTest.java
#   
modules/clients/src/test/java/org/apache/ignite/jdbc/suite/IgniteJdbcDriverTestSuite.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePreloaderAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPreloader.java
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/cache/CacheRebalancingSelfTest.java
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeConfigSelfTest.java
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeSelfTest.java

commit 374cba8a2b0d4438b46258a4ea89e43ab1e7989c
Author: dkarachentsev 
Date:   2017-06-06T13:17:01Z

IGNITE-5259 Minor serialization fix

commit 5cb580ad7043f27e4a0396aea1f877c21d49078e
Author: dkarachentsev 
Date:   2017-06-06T13:17:01Z

IGNITE-5259 Minor serialization fix

(cherry picked from commit 374cba8)

commit f03252f9b2c6f0e777f307fd85cc8bd20ab21423
Author: dkarachentsev 
Date:   2017-06-06T13:17:01Z

IGNITE-5259 Minor serialization fix

(cherry picked from commit 374cba8)

commit d2bf9619aaf867f251bc193d913dd4cc174a33a3
Author: Ivan Veselovskiy 
Date:   2017-06-06T13:56:09Z

IGNITE-5410: Fixed assertion in HadoopDataOutStream. This closes #2084.

commit 77ff30cc08dae653c0b914167088e9e90cdadd32
Author: dkarachentsev 
Date:   2017-06-06T14:12:27Z

IGNITE-5259 Minor serialization fix

commit be2bf6509816d2dc25fe9798b746a0f5c9014124
Author: dkarachentsev 
Date:   2017-06-06T14:12:42Z

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

commit

Re: Why SQL_PUBLIC is appending to Cache name while using JDBC thin driver

2017-10-11 Thread Vladimir Ozerov

Val,

You are right. Two tables with equal names in different schemas should
refer to two caches with unique names.

On Wed, Oct 11, 2017 at 7:48 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> I would let Vladimir confirm this, but I believe he talks about cache name,
> not table name. Cache name obviously has to be unique across all schemas,
> and attaching schema name to it makes sense to me.
>
> -Val
>
> On Mon, Oct 9, 2017 at 12:48 PM Dmitriy Setrakyan 
> wrote:
>
> > On Mon, Oct 9, 2017 at 12:05 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Because it should be possible to have two tables with the same name in
> > > different schemas.
> > >
> >
> > Still confused. If we have multiple schemas with the same table/cache
> name,
> > the schema name should be enough to identify a table. Currently, using
> your
> > words, the solution looks like a "hack". Why not just remove the prefix
> and
> > check for uniqueness within a schema?
> >
> > D.
> >
> >
> > >
> > > On Mon, Oct 9, 2017 at 9:21 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > > wrote:
> > >
> > > > On Mon, Oct 9, 2017 at 1:27 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > Hi Dima,
> > > > >
> > > > > To maintain unique cache names across the cluster.
> > > > >
> > > >
> > > > Why not simply check for uniqueness at creation time? Why introduce
> > some
> > > > automatic prefix?
> > > >
> > > >
> > > > >
> > > > > On Mon, Oct 9, 2017 at 7:34 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Cross-sending to dev@
> > > > > >
> > > > > > Why do we need to append SQL_PUBLIC_ to all table names?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > -- Forwarded message --
> > > > > > From: Denis Magda 
> > > > > > Date: Sun, Oct 8, 2017 at 7:01 AM
> > > > > > Subject: Re: Why SQL_PUBLIC is appending to Cache name while
> using
> > > JDBC
> > > > > > thin driver
> > > > > > To: "u...@ignite.apache.org" 
> > > > > >
> > > > > >
> > > > > > Hi Austin,
> > > > > >
> > > > > > Yes, it will be possible to pass a cache name you like into
> CREATE
> > > > TABLE
> > > > > > command in 2.3. The release should be available in a couple of
> > weeks.
> > > > > > Follow our announcements.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > On Saturday, October 7, 2017, austin solomon <
> > > > > austin.solomon...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am using Ignite version 2.2.0, and I have created a table
> using
> > > > > > > IgniteJdbcThinDriver.
> > > > > > >
> > > > > > > When I checked the cache in Ignite Visor I'm seeing
> > > > > > SQL_PUBLIC_{TABLE-NAME}
> > > > > > > is appended.
> > > > > > > Is their a way to get rid of this.
> > > > > > >
> > > > > > > I want to remove the SQL_PUBLIC from the cache name.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Austin
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Why SQL_PUBLIC is appending to Cache name while using JDBC thin driver

2017-10-11 Thread Valentin Kulichenko

I would let Vladimir confirm this, but I believe he talks about cache name,
not table name. Cache name obviously has to be unique across all schemas,
and attaching schema name to it makes sense to me.

-Val

On Mon, Oct 9, 2017 at 12:48 PM Dmitriy Setrakyan 
wrote:

> On Mon, Oct 9, 2017 at 12:05 PM, Vladimir Ozerov 
> wrote:
>
> > Because it should be possible to have two tables with the same name in
> > different schemas.
> >
>
> Still confused. If we have multiple schemas with the same table/cache name,
> the schema name should be enough to identify a table. Currently, using your
> words, the solution looks like a "hack". Why not just remove the prefix and
> check for uniqueness within a schema?
>
> D.
>
>
> >
> > On Mon, Oct 9, 2017 at 9:21 PM, Dmitriy Setrakyan  >
> > wrote:
> >
> > > On Mon, Oct 9, 2017 at 1:27 AM, Vladimir Ozerov 
> > > wrote:
> > >
> > > > Hi Dima,
> > > >
> > > > To maintain unique cache names across the cluster.
> > > >
> > >
> > > Why not simply check for uniqueness at creation time? Why introduce
> some
> > > automatic prefix?
> > >
> > >
> > > >
> > > > On Mon, Oct 9, 2017 at 7:34 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Cross-sending to dev@
> > > > >
> > > > > Why do we need to append SQL_PUBLIC_ to all table names?
> > > > >
> > > > > D.
> > > > >
> > > > > -- Forwarded message --
> > > > > From: Denis Magda 
> > > > > Date: Sun, Oct 8, 2017 at 7:01 AM
> > > > > Subject: Re: Why SQL_PUBLIC is appending to Cache name while using
> > JDBC
> > > > > thin driver
> > > > > To: "u...@ignite.apache.org" 
> > > > >
> > > > >
> > > > > Hi Austin,
> > > > >
> > > > > Yes, it will be possible to pass a cache name you like into CREATE
> > > TABLE
> > > > > command in 2.3. The release should be available in a couple of
> weeks.
> > > > > Follow our announcements.
> > > > >
> > > > > Denis
> > > > >
> > > > >
> > > > > On Saturday, October 7, 2017, austin solomon <
> > > > austin.solomon...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am using Ignite version 2.2.0, and I have created a table using
> > > > > > IgniteJdbcThinDriver.
> > > > > >
> > > > > > When I checked the cache in Ignite Visor I'm seeing
> > > > > SQL_PUBLIC_{TABLE-NAME}
> > > > > > is appended.
> > > > > > Is their a way to get rid of this.
> > > > > >
> > > > > > I want to remove the SQL_PUBLIC from the cache name.
> > > > > >
> > > > > > Thanks,
> > > > > > Austin
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-6601) Describe walMode on readme.io

2017-10-11 Thread Ilya Kasnacheev (JIRA)

Ilya Kasnacheev created IGNITE-6601:
---

 Summary: Describe walMode on readme.io
 Key: IGNITE-6601
 URL: https://issues.apache.org/jira/browse/IGNITE-6601
 Project: Ignite
  Issue Type: Task
  Components: documentation
Affects Versions: 2.2
Reporter: Ilya Kasnacheev


walMode setting is essential to Persistence performance tuning:
default mode is defensive and switching to appropriate walMode easily gives 3x 
performance boost on real loads.

However, walMode is not described on readme.io, and Ignite users has no way of 
figuring why their persistence performance is unsatisfactory and what 
compromises they can make to improve it.

We should have a section on WAL modes on readme.io on topic of 
persistence/performance tuning.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Ignite ML news

2017-10-11 Thread Yury Babak

Hi Denis,

Sure, will do.

Regards,
Yury



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

[GitHub] ignite pull request #2780: Ignite 6123

2017-10-11 Thread oignatenko

GitHub user oignatenko reopened a pull request:

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

Ignite 6123



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

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

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

https://github.com/apache/ignite/pull/2780.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 #2780


commit af39147742c2368c3f643b161172152e1ad83db4
Author: Oleg Ignatenko 
Date:   2017-09-18T12:42:12Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, trial local build and execution of unit 
tests

commit 9e977575547b2bdbff205973738e1c1128127768
Author: Oleg Ignatenko 
Date:   2017-09-23T09:28:05Z

IGNITE-6123 ML Grid benchmarks
- temporarily tweaked config to simplify debugging
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit b304174d38b511573040ce44d5553c111fbb5709
Author: Oleg Ignatenko 
Date:   2017-09-23T10:28:57Z

IGNITE-6123 ML Grid benchmarks
- temporarily tweaked config to simplify debugging
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 9929b76aeed43920e13df3f580cdfc3d2ad261da
Author: Oleg Ignatenko 
Date:   2017-09-23T10:37:15Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview

commit 7dbd4c5768f554436569722a2a06f8f170614c15
Author: Oleg Ignatenko 
Date:   2017-09-23T10:46:41Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 309c8f327c0b053c7b7936849dca0598f48d8c0b
Author: Oleg Ignatenko 
Date:   2017-09-23T11:07:17Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit ce34c6b11c246943bd987ffec7d89ace436566a0
Author: Oleg Ignatenko 
Date:   2017-09-23T11:26:57Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 0d1a8bec37cece371b56037d45bc27200143c06e
Author: Oleg Ignatenko 
Date:   2017-09-23T11:34:25Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 31909049ada893fecfcbf07f0d70831d7a2d39a2
Author: Oleg Ignatenko 
Date:   2017-09-23T13:17:16Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 7f911c664c024742212df3652a59b4ad628ea124
Author: Oleg Ignatenko 
Date:   2017-09-23T14:15:32Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 8c777d8edc0d847b6c96dddb1281a1bd39741b52
Author: Oleg Ignatenko 
Date:   2017-09-24T04:24:30Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 60d98dbf194cc30530948892fc0f62a9f8f2b50e
Author: Oleg Ignatenko 
Date:   2017-09-24T15:21:43Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 2cd480b8ae571d1684dc7060b36d099651f3c7fd
Author: Oleg Ignatenko 
Date:   2017-09-24T17:04:19Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit da4a11c28133689dbbc40bae927483950e1ddad2
Author: Oleg Ignatenko 
Date:   2017-09-25T13:11:32Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 8ef25ab5b7019a956672ce5fcf407087beef2074
Author: Oleg Ignatenko 
Date:   2017-09-25T13:53:40Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 070d640477cd5f663682cc67ef8da3157b604dc0
Author: Oleg Ignatenko 
Date:   2017-09-25T14:45:19Z

IGNITE-6123 ML Grid benchmarks
- wip
-- verified with diffs overview, clean build, trial execution of benchmark 
and studying results

commit 66f063f9973e1841e94fd8c845fa89c50b136fd4
Author: Oleg

[GitHub] ignite pull request #2780: Ignite 6123

2017-10-11 Thread oignatenko

Github user oignatenko closed the pull request at:

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


---

Re: Context switching for pessimistic transactions

2017-10-11 Thread ALEKSEY KUZNETSOV

Hi, Igntrs!

For suspend\resume operations in pessimistic mode we want to write the same
tests as for optimistic mode.

What additional tests should we create for the task?


Thanks.


пт, 6 окт. 2017 г. в 11:08, Dmitriy Setrakyan :

> Thanks, Alexey.
>
> I doubt anyone in the community will be able to answer your question here.
> I am assuming that thread ID is not going to be enough to identify a
> transaction, given that suspend happens in one thread, and resume in
> another. However, to tell for sure would require a better understanding of
> the code internals.
>
> Perhaps it is best to summarize your thoughts in the ticket, before you
> start the implementation. If no one in the community has any feedback, then
> you can take a first crack at the code and submit a pull request.
>
> D.
>
>
> On Mon, Oct 2, 2017 at 3:49 PM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> wrote:
>
> > Hi, Igntrs!
> >
> > I’m working on a ticket "Context switching for pessimistic transactions"
> > [1].
> >
> > Goal of the ticket is to support transaction suspend()\resume()
> operations
> > for pessimistic transactions. Resume can be called in another thread.
> >
> > Imagine, we started pessimistic transaction in thread T1 and then perform
> > put operation, which leads to sending GridDistributedLockRequest to
> another
> > node. Lock request contains thread id of the transaction. Then we call
> > suspend, resume in another thread and we also must send messages to other
> > nodes to change thread id.
> >
> > It seems complicated task.It’s better to get rid of sending thread id to
> > the nodes.
> >
> > We can use transaction xid on other nodes instead of thread id. Xid is
> sent
> > to nodes in GridDistributedLockRequest#nearXidVer
> >
> > So I propose:
> >
> > 1) On remote nodes instead of thread id of near transaction
> > GridDistributedLockRequest#threadId use its xid
> > GridDistributedLockRequest#nearXidVer.
> >
> > 2) Remove usages of near transaction's thread id on remote nodes.
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5714
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: OpenSSL licence compatibility

2017-10-11 Thread Dmitriy Setrakyan

The license looks very much like FreeBSD license [1] with additional
clauses. I doubt that ASF will be receptive to the additional restriction
clauses in the license.

However, I came across this OpenSSL blog [2] which states that they are
relicensing under Apache v.2.0 license. If you are willing to wait for this
process to complete, then you can use OpenSSL in Apache Ignite.

Also, I would advise looking into how other Apache projects worked around
this issue. I am sure we are not the first ones.

[1] - https://en.wikipedia.org/wiki/BSD_licenses
[2] - https://www.openssl.org/blog/blog/2017/03/22/license/

On Wed, Oct 11, 2017 at 6:36 AM, Igor Sapego  wrote:

> Hi guys,
>
> Lately I've been wondering about adding SSL to our ODBC driver.
> Of course I'm not going to write my own SSL implementation from
> the scratch, and going to use third-party library for that instead.
> OpenSSL library is the standard de-facto for implementation of SSL
> connectivity, but it uses its own OpenSSL license [1].
>
> So, the question is, is it compatible with the Apache 2.0 license? Can
> we use it?
>
> [1] - https://github.com/openssl/openssl/blob/master/LICENSE
>
> Best Regards,
> Igor
>

Re: Refactoring of IgniteKernal ack methods

2017-10-11 Thread Dmitriy Setrakyan

On Wed, Oct 11, 2017 at 7:44 AM, Иван Федотов  wrote:

> Hello, Igniters!
>
> I found, that in several places of IgniteKernal class code blocks are huge
> and hard to understand and in other places methods have the same context
> and could be placed in their own class. For example methods:
> “ackAsciiLogo”, “ackConfigUrl”, “ackDaemon”, “ackOsInfo”,
> “ackLanguageRuntime”, “ackRemoteManagement”, “ackVmArguments”,
> “ackClassPaths”, “ackSystemProperties”, “ackEnviromentVariables”,
> “ackMemoryConfiguration”, “ackCacheConfiguration”, “ackP2PConfiguration”,
> “ackRebalanceConfiguration”, which are called in 800-813 lines and together
> contain over than 250 lines, can be placed in separate class
> “AckVariousInformation”.
>
> Do you think that it will be good to create task on such refactoring?
>

I think this is a matter of taste. One could argue that the code is more
readable now because these methods belong to IgniteKernal and are not
called from any other place. I would generally such changes.

[GitHub] ignite pull request #2833: IGNITE-6362 NPE in Log4J2Logger

2017-10-11 Thread apopovgg

GitHub user apopovgg opened a pull request:

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

IGNITE-6362 NPE in Log4J2Logger

Please review it

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

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

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

https://github.com/apache/ignite/pull/2833.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 #2833


commit 0559a4c128b51cf6c05b2c166a7b67bace51e166
Author: apopov 
Date:   2017-10-11T15:17:04Z

IGNITE-6362 NPE in Log4J2Logger




---

[GitHub] ignite pull request #2804: IGNITE-6362: NPE in Log4J2Logger

2017-10-11 Thread apopovgg

Github user apopovgg closed the pull request at:

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


---

Refactoring of IgniteKernal ack methods

2017-10-11 Thread Иван Федотов

Hello, Igniters!

I found, that in several places of IgniteKernal class code blocks are huge
and hard to understand and in other places methods have the same context
and could be placed in their own class. For example methods:
“ackAsciiLogo”, “ackConfigUrl”, “ackDaemon”, “ackOsInfo”,
“ackLanguageRuntime”, “ackRemoteManagement”, “ackVmArguments”,
“ackClassPaths”, “ackSystemProperties”, “ackEnviromentVariables”,
“ackMemoryConfiguration”, “ackCacheConfiguration”, “ackP2PConfiguration”,
“ackRebalanceConfiguration”, which are called in 800-813 lines and together
contain over than 250 lines, can be placed in separate class
“AckVariousInformation”.

Do you think that it will be good to create task on such refactoring?


-- 
Ivan Fedotov.

ivanan...@gmail.com

OpenSSL licence compatibility

2017-10-11 Thread Igor Sapego

Hi guys,

Lately I've been wondering about adding SSL to our ODBC driver.
Of course I'm not going to write my own SSL implementation from
the scratch, and going to use third-party library for that instead.
OpenSSL library is the standard de-facto for implementation of SSL
connectivity, but it uses its own OpenSSL license [1].

So, the question is, is it compatible with the Apache 2.0 license? Can
we use it?

[1] - https://github.com/openssl/openssl/blob/master/LICENSE

Best Regards,
Igor

Re: Apache Ignite 2.3 release

2017-10-11 Thread Vladimir Ozerov

Igniters,

As far as I can see we almost ready with 2.3 scope, except of two major
things:
1) New persistence configuration with ability to enable persistence on
per-region basis [1]
2) And sqlline tool which will simplify SQL access to Ignite cluster [2]

Let's wait for these two tickets and then start testing.

[1] https://issues.apache.org/jira/browse/IGNITE-6030
[2] https://issues.apache.org/jira/browse/IGNITE-5608

Vladimir.

On Tue, Oct 3, 2017 at 5:10 PM, Vladimir Ozerov 
wrote:

> Folks,
>
> I created the branch *ignite-2.3* to finalize release scope. Please make
> sure that only tickets targeted for 2.3 release are merged to this branch.
> Let's take a week for finalization and stabilization, and then start
> testing.
>
> On Thu, Sep 28, 2017 at 10:16 AM, Vladimir Ozerov 
> wrote:
>
>> Igniters,
>>
>> I created our standard release page for AI 2.3 [1]. As nobody had
>> objections on dates, I propose to dedicate next week for stabilization and
>> start testing then.
>> Also I created release branch ignite-2.3. Let's make sure that effective
>> of next Tuesday, 3 Oct, we merge only release-related changes to this
>> branch.
>>
>> Vladimir.
>>
>> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.3
>>
>> On Thu, Sep 28, 2017 at 10:10 AM, Vladimir Ozerov 
>> wrote:
>>
>>> Hi Pavel, Sergey.
>>>
>>> All mentioned tickets definitely important for the release. Let's do our
>>> best to fit them.
>>>
>>> On Mon, Sep 25, 2017 at 11:06 AM, schernolyas <
>>> sergey.chernol...@gmail.com> wrote:
>>>
 Hi Vladimir!

 Could you add to future release by PR
 (http://apache-ignite-developers.2346864.n4.nabble.com/GitHu
 b-ignite-pull-request-2737-IGNITE-6286-fix-org-h2-jdbc-JdbcS
 QLException-td22625.html)?
 The PR is very important for project Hibernate OGM .



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

>>>
>>>
>>
>

Time units of AverageTxCommitTime and AverageTxRollbackTime in CacheMetrics.

2017-10-11 Thread Pavel Pereslegin

Hello, Igniters.


I found that AverageTxCommitTime and AverageTxRollbackTime metrics in
CacheMetrics calculated in milliseconds instead of microseconds as
pointed in javadoc (simple reproducer [1]).


Seems that it’s happening due to incorrect time units conversion in
IgniteTxLocalStateAdapter#onTxEnd.


Should I create a ticket to fix this?


[1] 
https://github.com/xtern/ignite/blob/ignite-reproducer/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/CacheMetricsTxAvgTimeTest.java

[GitHub] ignite pull request #2832: IGNITE-6337 .NET: Thin client: SQL queries

2017-10-11 Thread ptupitsyn

GitHub user ptupitsyn opened a pull request:

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

IGNITE-6337 .NET: Thin client: SQL queries



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

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

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

https://github.com/apache/ignite/pull/2832.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 #2832


commit 06cad94bda0856f09d4b184bc88deb9c969b909d
Author: Pavel Tupitsyn 
Date:   2017-10-11T13:00:01Z

IGNITE-6337 .NET: Thin client: SQL queries




---

[jira] [Created] (IGNITE-6600) Web Console: Make a design of 403 and 404 pages

2017-10-11 Thread Vica Abramova (JIRA)

Vica Abramova created IGNITE-6600:
-

 Summary: Web Console: Make a design of 403 and 404 pages
 Key: IGNITE-6600
 URL: https://issues.apache.org/jira/browse/IGNITE-6600
 Project: Ignite
  Issue Type: Task
  Components: UI, wizards
Reporter: Vica Abramova
Assignee: Vica Abramova
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2787: IGNITE-6542 Reliably close SocketChannel in TcpCo...

2017-10-11 Thread asfgit

Github user asfgit closed the pull request at:

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


---

Avoid closing caches on client during cluster restart - determining it's the same cache

2017-10-11 Thread Ilya Kasnacheev

Hello Igniters!

I'm working on IGNITE-2766. We want caches opened on client to survive
cluster restart (all nodes down, then some nodes up). Currently Ignite
compares deploymentId which will not match with new cluster's caches.

But still we want to make sure it's still the same cache in the new
cluster, and not a different one with the same name. One obvious idea is to
look at CacheConfiguration. However I think a frequent scenario for cluster
restart is a minor change of cache configuration (e.g. add or remove
backup), and it will be a pity to lose client caches in this case.

So, what fields in CacheConfiguration should we compare upon to figure out
if it's still the same cache? Name obviously. How does grpName work and
should we compare on them too?

indexedTypes[] make sense because if it's a cache on different types it's
not safe to be used where it was open. cache mode and atomicity mode make
sence since cache should now be handled differently?

Any other fields in CacheConfiguration we should check because it's not
safe to continue in case of mismatch? Some different approach? Suggestions
are kindly welcome

-- 
Ilya Kasnacheev

[jira] [Created] (IGNITE-6599) .NET: IgniteConfiguration.ClusterName

2017-10-11 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6599:
--

 Summary: .NET: IgniteConfiguration.ClusterName
 Key: IGNITE-6599
 URL: https://issues.apache.org/jira/browse/IGNITE-6599
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor


Propagate from Java: IGNITE-6579



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Persistence per memory policy configuration

2017-10-11 Thread Ivan Rakov

Typo in my previous reply: *walArchivePath* -> *setWalArchivePath*

Best Regards,
Ivan Rakov

On 11.10.2017 14:30, Ivan Rakov wrote:

Vladimir,

Thanks for focusing on existing namings. Most of your suggestions
really sound better. I've posted my thoughts under your comment.

By the way, we should decide two things:

1) Naming for methods for configuring store path. I suggest the
following:

*setStoragePath* - for partition and index files
*setWalPath* - for WAL files
*walArchivePath* - for WAL archive files

2) Renaming *checkpointingFrequency* to *checkpointFrequency* (same
with *checkpointingPageBufferSize* and *checkpointingThreads*). Both
options sounds ok to me, let's see what community thinks.

Best Regards,
Ivan Rakov

On 11.10.2017 14:05, Vladimir Ozerov wrote:

Ivan,

I left some comments in the ticket [1], please take a look.

[1]
https://issues.apache.org/jira/browse/IGNITE-6030?focusedCommentId=16200050=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16200050

On Wed, Oct 11, 2017 at 12:04 PM, Ivan Rakov
wrote:

Igniters,

https://issues.apache.org/jira/browse/IGNITE-6030 is ready and enqueued
for TC run.
PR: https://github.com/apache/ignite/pull/2828

Everyone interested in new data storage configuration API, please pay
attention and review.

Best Regards,
Ivan Rakov

On 09.10.2017 12:40, Pavel Tupitsyn wrote:

Sounds good to me.

On Mon, Oct 9, 2017 at 12:35 PM, Ivan Rakov
wrote:

Pavel,

Sounds reasonable.
I suggest to include both "data" and "configuration" to make it
even more

obvious:

set/getDefaultDataRegionConfiguration
set/getDataRegionConfigurations

Best Regards,
Ivan Rakov

On 09.10.2017 10:51, Pavel Tupitsyn wrote:

Sorry that I'm late to the party, but this looks inconsistent:

DataStorageConfiguration defaultRegionConfiguration
DataRegionConfiguration[] getDataRegions

defaultRegionConfiguration + getRegionConfigurations
- or -
defaultDataRegion + getDataRegions

Thoughts?

On Mon, Oct 2, 2017 at 9:10 PM, Ivan Rakov
wrote:

Denis,

Yes, you're right. All cache groups without specific data region
configured will be persistent.
And if you want to add another persistent data region, you
should set
*isPeristenceEnabled* flag in its *DataRegionConfiguration*
explictly.

Best Regards,
Ivan Rakov

On 02.10.2017 21:01, Denis Magda wrote:

Missed the point with defaults. Makes sense to me now. So to
wrap this

up, if I want to enable the persistence globally and don’t have
any

regions
configured explicitly I need to take the default region and
switch the

persistence on for it. Is my understanding correct?

—
Denis

On Oct 2, 2017, at 10:57 AM, Ivan Rakov
wrote:

Denis, why do you need to access an instance of the default region

bean?
If you want to set any parameter, just instantiate new bean
with this
parameter set (like in XML snipped below). Other parameters
will be

automatically initialized with their default values.

Best Regards,
Ivan Rakov

On 02.10.2017 19:28, Denis Magda wrote:

guration.DataStorageConfiguration">

In other data regions persistence will be disabled by default.

Ivan, how to get an instance to the default region bean and
change

parameter? Obviously, if the goal is to enable the persistence I
don’t want
to create the default region bean from scratch.

—
Denis

On Oct 2, 2017, at 9:11 AM, Ivan Rakov
wrote:

Agree with Alexey.

Properties like *defaultDataRegionSize*,
*isDefaultPersistenceEnabled*
can confuse users who don't know that there's such thing as
default

data
region. They can decide they are inherited by all data regions
where
size
and persistence flag are not explicitly set.

Let's get rid of these properties and add
*defaultRegionConfiguration*
property with explicit configuration of default data region.

Regarding XML configuration, changing size or persistence
flag of

default data region will be just two lines longer (for bean
description):

guration.DataStorageConfiguration">

In other data regions persistence will be disabled by default.

I've updated draft in https://issues.apache.org/jira
/browse/IGNITE-6030 with these changes.

Best Regards,
Ivan Rakov

On 02.10.2017 18:35, Denis Magda wrote:

To resolve this, I suggest to

introduce just another field defaultRegionConfiguration and
get

rid
of
other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML
file? I’m

not
an expert in Spring so how do I get defaultRegionConfiguration
bean
first
to change any parameter?

—
Denis

Re: Persistence per memory policy configuration

2017-10-11 Thread Ivan Rakov

Vladimir,

Thanks for focusing on existing namings. Most of your suggestions really
sound better. I've posted my thoughts under your comment.

By the way, we should decide two things:

1) Naming for methods for configuring store path. I suggest the following:

*setStoragePath* - for partition and index files
*setWalPath* - for WAL files
*walArchivePath* - for WAL archive files

2) Renaming *checkpointingFrequency* to *checkpointFrequency* (same with
*checkpointingPageBufferSize* and *checkpointingThreads*). Both options
sounds ok to me, let's see what community thinks.

Best Regards,
Ivan Rakov

On 11.10.2017 14:05, Vladimir Ozerov wrote:

Ivan,

I left some comments in the ticket [1], please take a look.

[1]
https://issues.apache.org/jira/browse/IGNITE-6030?focusedCommentId=16200050=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16200050

On Wed, Oct 11, 2017 at 12:04 PM, Ivan Rakov wrote:

Igniters,

https://issues.apache.org/jira/browse/IGNITE-6030 is ready and enqueued
for TC run.
PR: https://github.com/apache/ignite/pull/2828

Everyone interested in new data storage configuration API, please pay
attention and review.

Best Regards,
Ivan Rakov

On 09.10.2017 12:40, Pavel Tupitsyn wrote:

Sounds good to me.

On Mon, Oct 9, 2017 at 12:35 PM, Ivan Rakov
wrote:

Pavel,

Sounds reasonable.
I suggest to include both "data" and "configuration" to make it even more
obvious:

set/getDefaultDataRegionConfiguration
set/getDataRegionConfigurations

Best Regards,
Ivan Rakov

On 09.10.2017 10:51, Pavel Tupitsyn wrote:

Sorry that I'm late to the party, but this looks inconsistent:

DataStorageConfiguration defaultRegionConfiguration
DataRegionConfiguration[] getDataRegions

defaultRegionConfiguration + getRegionConfigurations
- or -
defaultDataRegion + getDataRegions

Thoughts?

On Mon, Oct 2, 2017 at 9:10 PM, Ivan Rakov
wrote:

Denis,

Yes, you're right. All cache groups without specific data region
configured will be persistent.
And if you want to add another persistent data region, you should set
*isPeristenceEnabled* flag in its *DataRegionConfiguration* explictly.

Best Regards,
Ivan Rakov

On 02.10.2017 21:01, Denis Magda wrote:

Missed the point with defaults. Makes sense to me now. So to wrap this

up, if I want to enable the persistence globally and don’t have any
regions
configured explicitly I need to take the default region and switch the
persistence on for it. Is my understanding correct?

—
Denis

On Oct 2, 2017, at 10:57 AM, Ivan Rakov
wrote:

Denis, why do you need to access an instance of the default region

bean?
If you want to set any parameter, just instantiate new bean with this
parameter set (like in XML snipped below). Other parameters will be
automatically initialized with their default values.

Best Regards,
Ivan Rakov

On 02.10.2017 19:28, Denis Magda wrote:

guration.DataStorageConfiguration">

In other data regions persistence will be disabled by default.

Ivan, how to get an instance to the default region bean and change
a

parameter? Obviously, if the goal is to enable the persistence I
don’t want
to create the default region bean from scratch.

—
Denis

On Oct 2, 2017, at 9:11 AM, Ivan Rakov
wrote:

Agree with Alexey.

Properties like *defaultDataRegionSize*,
*isDefaultPersistenceEnabled*
can confuse users who don't know that there's such thing as default
data
region. They can decide they are inherited by all data regions
where
size
and persistence flag are not explicitly set.

Let's get rid of these properties and add
*defaultRegionConfiguration*
property with explicit configuration of default data region.

Regarding XML configuration, changing size or persistence flag of
default data region will be just two lines longer (for bean
description):

guration.DataStorageConfiguration">

In other data regions persistence will be disabled by default.

I've updated draft in https://issues.apache.org/jira
/browse/IGNITE-6030 with these changes.

Best Regards,
Ivan Rakov

On 02.10.2017 18:35, Denis Magda wrote:

To resolve this, I suggest to

introduce just another field defaultRegionConfiguration and get

rid
of
other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m

not
an expert in Spring so how do I get defaultRegionConfiguration
bean
first
to change any parameter?

—
Denis

On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk <

alexey.goncha...@gmail.com> wrote:

Agree with Vladimir. If we are to implement this, we would either
need to

[GitHub] ignite pull request #2831: IGNITE-6270 Renamed user facing CREATE TABLE

2017-10-11 Thread alexpaschenko

GitHub user alexpaschenko opened a pull request:

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

IGNITE-6270 Renamed user facing CREATE TABLE



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

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

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

https://github.com/apache/ignite/pull/2831.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 #2831


commit 1da9f0e4adf922b11257cf5c3b93df7508f0ee7b
Author: Alexander Paschenko 
Date:   2017-10-11T11:18:29Z

IGNITE-6270 Renamed user facing CREATE TABLE




---

[jira] [Created] (IGNITE-6598) .NET: IIgnite.AddCacheConfiguration

2017-10-11 Thread Pavel Tupitsyn (JIRA)

Pavel Tupitsyn created IGNITE-6598:
--

 Summary: .NET: IIgnite.AddCacheConfiguration
 Key: IGNITE-6598
 URL: https://issues.apache.org/jira/browse/IGNITE-6598
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.4


Propagate {{Ignite.addCacheConfiguration}} to .NET.

This allows adding cache templates at runtime.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6597) Add cluster name to IgniteConfiguration

2017-10-11 Thread Alexey Kuznetsov (JIRA)

Alexey Kuznetsov created IGNITE-6597:


 Summary: Add cluster name to IgniteConfiguration
 Key: IGNITE-6597
 URL: https://issues.apache.org/jira/browse/IGNITE-6597
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov
 Fix For: 2.4


http://apache-ignite-developers.2346864.n4.nabble.com/Cluster-name-td15490.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Cluster name

2017-10-11 Thread Alexey Kuznetsov

Created issue: https://issues.apache.org/jira/browse/IGNITE-6597

On Wed, Oct 11, 2017 at 5:21 PM, Sasha Belyak  wrote:

> Cluster name - yes
> Limit cluster building by cluster name - yes
> env/system property - no, let's add cluster name to ignite configuration.
>
> 2017-10-11 17:08 GMT+07:00 Dmitry Pavlov :
>
> > I like this idea too. Some imdg have such feature and allow to limit
> > cluster building only within cluster name.
> >
> > ср, 11 окт. 2017 г. в 12:38, Alexey Kuznetsov :
> >
> > > Hi,
> > >
> > > I'd like to up this thread for discussion.
> > >
> > > It seems that cluster name could be very useful together with multicast
> > > discovery - do not accept nodes with different cluster name.
> > > By default, let's set cluster name to "DEFAULT_CLUSTER".
> > >
> > > Thoughts?
> > >
> > > On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > wrote:
> > >
> > > > I am not sure I like naming clusters from an agent. It just sounds
> > > counter
> > > > intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME
> env
> > > > property together with optional  -DCLUSTER_NAME system property and
> > > > reserved CLUSTER_NAME user attribute?
> > > >
> > > > If user fails to provide any of the above, then we automatically
> assign
> > > the
> > > > timestamp of the first node or some UUID as a cluster name.
> > > >
> > > > Thoughts?
> > > >
> > > > D.
> > > >
> > > > On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Alexey,
> > > > >
> > > > > Cluster doesn't know about the console, but web agent does, right?
> I
> > > > think
> > > > > it should be his responsibility to assign the name. I.e. when
> > starting
> > > > the
> > > > > agent next to a particular cluster, user has to specify the name.
> If
> > > the
> > > > > console already has the cluster with this name, agent should not
> > start
> > > > with
> > > > > an exception suggesting to provide another name.
> > > > >
> > > > > Will this work?
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> > > > akuznet...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Dmitriy, Sergi and Val.
> > > > > >
> > > > > > Web Console will be connected to several clusters at once.
> > > > > > And clusters do not know about Web Console, because Web Console
> > > collect
> > > > > > info from cluster via our REST-HTTP module.
> > > > > > So, I can distinguish clusters only by collection of node IDs and
> > > give
> > > > > them
> > > > > > names like: "Cluster1, Clsuter2,"
> > > > > > But if cluster restarted Web Console will detect it as new
> cluster
> > > and
> > > > > give
> > > > > > next auto-generated name "ClusterN".
> > > > > >
> > > > > > So, I'm not insist on adding "ClusterName" to
> IgniteConfiguration,
> > > but
> > > > > > could you give me a way
> > > > > >  some how "mark" clusters to detect them even after full restart.
> > > > > >
> > > > > > May be setting some sort of environment variable (it will be
> added
> > to
> > > > > node
> > > > > > attributes)?
> > > > > > So, if user need "Multi-cluster" support he should set different
> > > > > > CLUSTER_NAME environment variable for different clusters.
> > > > > >
> > > > > > Any other ideas are welcome.
> > > > > >
> > > > > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > >
> > > > > > > Alexey,
> > > > > > >
> > > > > > > How does the workflow look like? How do you add a cluster to
> this
> > > > > > dropdown
> > > > > > > on the console? I think that assigning a name should be part of
> > > this
> > > > > > > process and should happen on the console itself.
> > > > > > >
> > > > > > > Adding yet another "name" to configuration will only confuse
> > users
> > > > even
> > > > > > > more.
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I don't like to add anything like this into Ignite config. It
> > is
> > > a
> > > > > > > problem
> > > > > > > > of Web console how to name or rename different clusters for a
> > > user,
> > > > > but
> > > > > > > not
> > > > > > > > Ignite cluster itself.
> > > > > > > >
> > > > > > > > Sergi
> > > > > > > >
> > > > > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >:
> > > > > > > >
> > > > > > > > > I am OK with having a cluster name, but I would like us to
> > > > generate
> > > > > > one
> > > > > > > > > automatically, if users do not define one explicitly. How
> > about
> > > > > > > > > "cluster_timestamp"?
> > > > > > > > >
> > > > > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > > > > akuznet...@apache.org
> > > > > > > > >
> > > > > > > > > wrote:

Re: Persistence per memory policy configuration

2017-10-11 Thread Vladimir Ozerov

Ivan,

I left some comments in the ticket [1], please take a look.

[1]
https://issues.apache.org/jira/browse/IGNITE-6030?focusedCommentId=16200050=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16200050

On Wed, Oct 11, 2017 at 12:04 PM, Ivan Rakov  wrote:

> Igniters,
>
> https://issues.apache.org/jira/browse/IGNITE-6030 is ready and enqueued
> for TC run.
> PR: https://github.com/apache/ignite/pull/2828
>
> Everyone interested in new data storage configuration API, please pay
> attention and review.
>
>
> Best Regards,
> Ivan Rakov
>
>
> On 09.10.2017 12:40, Pavel Tupitsyn wrote:
>
>> Sounds good to me.
>>
>> On Mon, Oct 9, 2017 at 12:35 PM, Ivan Rakov 
>> wrote:
>>
>> Pavel,
>>>
>>> Sounds reasonable.
>>> I suggest to include both "data" and "configuration" to make it even more
>>> obvious:
>>>
>>> set/getDefaultDataRegionConfiguration
>>> set/getDataRegionConfigurations
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>>
>>> On 09.10.2017 10:51, Pavel Tupitsyn wrote:
>>>
>>> Sorry that I'm late to the party, but this looks inconsistent:

 DataStorageConfiguration defaultRegionConfiguration
 DataRegionConfiguration[] getDataRegions

 defaultRegionConfiguration + getRegionConfigurations
 - or -
 defaultDataRegion + getDataRegions

 Thoughts?

 On Mon, Oct 2, 2017 at 9:10 PM, Ivan Rakov 
 wrote:

 Denis,

> Yes, you're right. All cache groups without specific data region
> configured will be persistent.
> And if you want to add another persistent data region, you should set
> *isPeristenceEnabled* flag in its *DataRegionConfiguration* explictly.
>
> Best Regards,
> Ivan Rakov
>
>
> On 02.10.2017 21:01, Denis Magda wrote:
>
> Missed the point with defaults. Makes sense to me now. So to wrap this
>
>> up, if I want to enable the persistence globally and don’t have any
>> regions
>> configured explicitly I need to take the default region and switch the
>> persistence on for it. Is my understanding correct?
>>
>> —
>> Denis
>>
>> On Oct 2, 2017, at 10:57 AM, Ivan Rakov 
>> wrote:
>>
>> Denis, why do you need to access an instance of the default region
>>> bean?
>>> If you want to set any parameter, just instantiate new bean with this
>>> parameter set (like in XML snipped below). Other parameters will be
>>> automatically initialized with their default values.
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>> On 02.10.2017 19:28, Denis Magda wrote:
>>>
>>> 
>>>
 
>> > value="#{100
>> *
>> 1024 * 1024}"/>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> In other data regions persistence will be disabled by default.
>>
> Ivan, how to get an instance to the default region bean and change
> a
>
 parameter? Obviously, if the goal is to enable the persistence I
 don’t want
 to create the default region bean from scratch.

 —
 Denis

 On Oct 2, 2017, at 9:11 AM, Ivan Rakov 
 wrote:

 Agree with Alexey.
>
> Properties like *defaultDataRegionSize*,
> *isDefaultPersistenceEnabled*
> can confuse users who don't know that there's such thing as default
> data
> region. They can decide they are inherited by all data regions
> where
> size
> and persistence flag are not explicitly set.
>
> Let's get rid of these properties and add
> *defaultRegionConfiguration*
> property with explicit configuration of default data region.
>
> Regarding XML configuration, changing size or persistence flag of
> default data region will be just two lines longer (for bean
> description):
>
> 
>
> 
>> > value="#{100
>> *
>> 1024 * 1024}"/>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> In other data regions persistence will be disabled by default.
>>
> I've updated draft in https://issues.apache.org/jira
> /browse/IGNITE-6030 with these changes.
>
> Best Regards,
> Ivan Rakov
>
> On 02.10.2017 18:35, Denis Magda wrote:
>
> To resolve this, I suggest to
>

Re: Cluster name

2017-10-11 Thread Sasha Belyak

Cluster name - yes
Limit cluster building by cluster name - yes
env/system property - no, let's add cluster name to ignite configuration.

2017-10-11 17:08 GMT+07:00 Dmitry Pavlov :

> I like this idea too. Some imdg have such feature and allow to limit
> cluster building only within cluster name.
>
> ср, 11 окт. 2017 г. в 12:38, Alexey Kuznetsov :
>
> > Hi,
> >
> > I'd like to up this thread for discussion.
> >
> > It seems that cluster name could be very useful together with multicast
> > discovery - do not accept nodes with different cluster name.
> > By default, let's set cluster name to "DEFAULT_CLUSTER".
> >
> > Thoughts?
> >
> > On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > I am not sure I like naming clusters from an agent. It just sounds
> > counter
> > > intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
> > > property together with optional  -DCLUSTER_NAME system property and
> > > reserved CLUSTER_NAME user attribute?
> > >
> > > If user fails to provide any of the above, then we automatically assign
> > the
> > > timestamp of the first node or some UUID as a cluster name.
> > >
> > > Thoughts?
> > >
> > > D.
> > >
> > > On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Alexey,
> > > >
> > > > Cluster doesn't know about the console, but web agent does, right? I
> > > think
> > > > it should be his responsibility to assign the name. I.e. when
> starting
> > > the
> > > > agent next to a particular cluster, user has to specify the name. If
> > the
> > > > console already has the cluster with this name, agent should not
> start
> > > with
> > > > an exception suggesting to provide another name.
> > > >
> > > > Will this work?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> > > akuznet...@apache.org>
> > > > wrote:
> > > >
> > > > > Dmitriy, Sergi and Val.
> > > > >
> > > > > Web Console will be connected to several clusters at once.
> > > > > And clusters do not know about Web Console, because Web Console
> > collect
> > > > > info from cluster via our REST-HTTP module.
> > > > > So, I can distinguish clusters only by collection of node IDs and
> > give
> > > > them
> > > > > names like: "Cluster1, Clsuter2,"
> > > > > But if cluster restarted Web Console will detect it as new cluster
> > and
> > > > give
> > > > > next auto-generated name "ClusterN".
> > > > >
> > > > > So, I'm not insist on adding "ClusterName" to IgniteConfiguration,
> > but
> > > > > could you give me a way
> > > > >  some how "mark" clusters to detect them even after full restart.
> > > > >
> > > > > May be setting some sort of environment variable (it will be added
> to
> > > > node
> > > > > attributes)?
> > > > > So, if user need "Multi-cluster" support he should set different
> > > > > CLUSTER_NAME environment variable for different clusters.
> > > > >
> > > > > Any other ideas are welcome.
> > > > >
> > > > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > How does the workflow look like? How do you add a cluster to this
> > > > > dropdown
> > > > > > on the console? I think that assigning a name should be part of
> > this
> > > > > > process and should happen on the console itself.
> > > > > >
> > > > > > Adding yet another "name" to configuration will only confuse
> users
> > > even
> > > > > > more.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I don't like to add anything like this into Ignite config. It
> is
> > a
> > > > > > problem
> > > > > > > of Web console how to name or rename different clusters for a
> > user,
> > > > but
> > > > > > not
> > > > > > > Ignite cluster itself.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > > > >
> > > > > > > > I am OK with having a cluster name, but I would like us to
> > > generate
> > > > > one
> > > > > > > > automatically, if users do not define one explicitly. How
> about
> > > > > > > > "cluster_timestamp"?
> > > > > > > >
> > > > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > > > akuznet...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I'm planning to start working on multi cluster support for
> > Web
> > > > > > Console
> > > > > > > > > in order to be able to execute SQL queries on different
> > > clusters
> > > > > just
> > > > > > > by
> > > > > > > > > selecting
> > > > > > > > > target cluster from drop-down.
> > > > > > > > >
> > > > > > > > > But Ignite does not have any cluster

Re: Cluster name

2017-10-11 Thread Dmitry Pavlov

I like this idea too. Some imdg have such feature and allow to limit
cluster building only within cluster name.

ср, 11 окт. 2017 г. в 12:38, Alexey Kuznetsov :

> Hi,
>
> I'd like to up this thread for discussion.
>
> It seems that cluster name could be very useful together with multicast
> discovery - do not accept nodes with different cluster name.
> By default, let's set cluster name to "DEFAULT_CLUSTER".
>
> Thoughts?
>
> On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I am not sure I like naming clusters from an agent. It just sounds
> counter
> > intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
> > property together with optional  -DCLUSTER_NAME system property and
> > reserved CLUSTER_NAME user attribute?
> >
> > If user fails to provide any of the above, then we automatically assign
> the
> > timestamp of the first node or some UUID as a cluster name.
> >
> > Thoughts?
> >
> > D.
> >
> > On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Alexey,
> > >
> > > Cluster doesn't know about the console, but web agent does, right? I
> > think
> > > it should be his responsibility to assign the name. I.e. when starting
> > the
> > > agent next to a particular cluster, user has to specify the name. If
> the
> > > console already has the cluster with this name, agent should not start
> > with
> > > an exception suggesting to provide another name.
> > >
> > > Will this work?
> > >
> > > -Val
> > >
> > > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> > akuznet...@apache.org>
> > > wrote:
> > >
> > > > Dmitriy, Sergi and Val.
> > > >
> > > > Web Console will be connected to several clusters at once.
> > > > And clusters do not know about Web Console, because Web Console
> collect
> > > > info from cluster via our REST-HTTP module.
> > > > So, I can distinguish clusters only by collection of node IDs and
> give
> > > them
> > > > names like: "Cluster1, Clsuter2,"
> > > > But if cluster restarted Web Console will detect it as new cluster
> and
> > > give
> > > > next auto-generated name "ClusterN".
> > > >
> > > > So, I'm not insist on adding "ClusterName" to IgniteConfiguration,
> but
> > > > could you give me a way
> > > >  some how "mark" clusters to detect them even after full restart.
> > > >
> > > > May be setting some sort of environment variable (it will be added to
> > > node
> > > > attributes)?
> > > > So, if user need "Multi-cluster" support he should set different
> > > > CLUSTER_NAME environment variable for different clusters.
> > > >
> > > > Any other ideas are welcome.
> > > >
> > > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Alexey,
> > > > >
> > > > > How does the workflow look like? How do you add a cluster to this
> > > > dropdown
> > > > > on the console? I think that assigning a name should be part of
> this
> > > > > process and should happen on the console itself.
> > > > >
> > > > > Adding yet another "name" to configuration will only confuse users
> > even
> > > > > more.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I don't like to add anything like this into Ignite config. It is
> a
> > > > > problem
> > > > > > of Web console how to name or rename different clusters for a
> user,
> > > but
> > > > > not
> > > > > > Ignite cluster itself.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > > >
> > > > > > > I am OK with having a cluster name, but I would like us to
> > generate
> > > > one
> > > > > > > automatically, if users do not define one explicitly. How about
> > > > > > > "cluster_timestamp"?
> > > > > > >
> > > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > > akuznet...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I'm planning to start working on multi cluster support for
> Web
> > > > > Console
> > > > > > > > in order to be able to execute SQL queries on different
> > clusters
> > > > just
> > > > > > by
> > > > > > > > selecting
> > > > > > > > target cluster from drop-down.
> > > > > > > >
> > > > > > > > But Ignite does not have any cluster wide name.
> > > > > > > >
> > > > > > > > So, how about to add to Ignite (may be 2.0) property "Cluster
> > > Name"
> > > > > to
> > > > > > > > Ignite configuration?
> > > > > > > >
> > > > > > > > Or as alternative way it could use "Mandatory User Defined
> > > > > Attribute".
> > > > > > > >
> > > > > > > > Node should be rejected to join cluster with different
> "Cluster
> > > > Name"
> > > > > > > >
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alexey

Re: Cluster name

2017-10-11 Thread Pavel Tupitsyn

Definitely useful, I've seen user requests about this a number of times.

On Wed, Oct 11, 2017 at 1:03 PM, Vladimir Ozerov 
wrote:

> Alex,
>
> Agree. Looks like a useful feature, especially for testing purposes.
>
> On Wed, Oct 11, 2017 at 12:38 PM, Alexey Kuznetsov 
> wrote:
>
> > Hi,
> >
> > I'd like to up this thread for discussion.
> >
> > It seems that cluster name could be very useful together with multicast
> > discovery - do not accept nodes with different cluster name.
> > By default, let's set cluster name to "DEFAULT_CLUSTER".
> >
> > Thoughts?
> >
> > On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > I am not sure I like naming clusters from an agent. It just sounds
> > counter
> > > intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
> > > property together with optional  -DCLUSTER_NAME system property and
> > > reserved CLUSTER_NAME user attribute?
> > >
> > > If user fails to provide any of the above, then we automatically assign
> > the
> > > timestamp of the first node or some UUID as a cluster name.
> > >
> > > Thoughts?
> > >
> > > D.
> > >
> > > On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Alexey,
> > > >
> > > > Cluster doesn't know about the console, but web agent does, right? I
> > > think
> > > > it should be his responsibility to assign the name. I.e. when
> starting
> > > the
> > > > agent next to a particular cluster, user has to specify the name. If
> > the
> > > > console already has the cluster with this name, agent should not
> start
> > > with
> > > > an exception suggesting to provide another name.
> > > >
> > > > Will this work?
> > > >
> > > > -Val
> > > >
> > > > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> > > akuznet...@apache.org>
> > > > wrote:
> > > >
> > > > > Dmitriy, Sergi and Val.
> > > > >
> > > > > Web Console will be connected to several clusters at once.
> > > > > And clusters do not know about Web Console, because Web Console
> > collect
> > > > > info from cluster via our REST-HTTP module.
> > > > > So, I can distinguish clusters only by collection of node IDs and
> > give
> > > > them
> > > > > names like: "Cluster1, Clsuter2,"
> > > > > But if cluster restarted Web Console will detect it as new cluster
> > and
> > > > give
> > > > > next auto-generated name "ClusterN".
> > > > >
> > > > > So, I'm not insist on adding "ClusterName" to IgniteConfiguration,
> > but
> > > > > could you give me a way
> > > > >  some how "mark" clusters to detect them even after full restart.
> > > > >
> > > > > May be setting some sort of environment variable (it will be added
> to
> > > > node
> > > > > attributes)?
> > > > > So, if user need "Multi-cluster" support he should set different
> > > > > CLUSTER_NAME environment variable for different clusters.
> > > > >
> > > > > Any other ideas are welcome.
> > > > >
> > > > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > How does the workflow look like? How do you add a cluster to this
> > > > > dropdown
> > > > > > on the console? I think that assigning a name should be part of
> > this
> > > > > > process and should happen on the console itself.
> > > > > >
> > > > > > Adding yet another "name" to configuration will only confuse
> users
> > > even
> > > > > > more.
> > > > > >
> > > > > > -Val
> > > > > >
> > > > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I don't like to add anything like this into Ignite config. It
> is
> > a
> > > > > > problem
> > > > > > > of Web console how to name or rename different clusters for a
> > user,
> > > > but
> > > > > > not
> > > > > > > Ignite cluster itself.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >:
> > > > > > >
> > > > > > > > I am OK with having a cluster name, but I would like us to
> > > generate
> > > > > one
> > > > > > > > automatically, if users do not define one explicitly. How
> about
> > > > > > > > "cluster_timestamp"?
> > > > > > > >
> > > > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > > > akuznet...@apache.org
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I'm planning to start working on multi cluster support for
> > Web
> > > > > > Console
> > > > > > > > > in order to be able to execute SQL queries on different
> > > clusters
> > > > > just
> > > > > > > by
> > > > > > > > > selecting
> > > > > > > > > target cluster from drop-down.
> > > > > > > > >
> > > > > > > > > But Ignite does not have any cluster wide name.
> > > > > > > > >
> > > > > > > > > So, how about to add to Ignite

Re: Cluster name

2017-10-11 Thread Vladimir Ozerov

Alex,

Agree. Looks like a useful feature, especially for testing purposes.

On Wed, Oct 11, 2017 at 12:38 PM, Alexey Kuznetsov 
wrote:

> Hi,
>
> I'd like to up this thread for discussion.
>
> It seems that cluster name could be very useful together with multicast
> discovery - do not accept nodes with different cluster name.
> By default, let's set cluster name to "DEFAULT_CLUSTER".
>
> Thoughts?
>
> On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan  >
> wrote:
>
> > I am not sure I like naming clusters from an agent. It just sounds
> counter
> > intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
> > property together with optional  -DCLUSTER_NAME system property and
> > reserved CLUSTER_NAME user attribute?
> >
> > If user fails to provide any of the above, then we automatically assign
> the
> > timestamp of the first node or some UUID as a cluster name.
> >
> > Thoughts?
> >
> > D.
> >
> > On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Alexey,
> > >
> > > Cluster doesn't know about the console, but web agent does, right? I
> > think
> > > it should be his responsibility to assign the name. I.e. when starting
> > the
> > > agent next to a particular cluster, user has to specify the name. If
> the
> > > console already has the cluster with this name, agent should not start
> > with
> > > an exception suggesting to provide another name.
> > >
> > > Will this work?
> > >
> > > -Val
> > >
> > > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> > akuznet...@apache.org>
> > > wrote:
> > >
> > > > Dmitriy, Sergi and Val.
> > > >
> > > > Web Console will be connected to several clusters at once.
> > > > And clusters do not know about Web Console, because Web Console
> collect
> > > > info from cluster via our REST-HTTP module.
> > > > So, I can distinguish clusters only by collection of node IDs and
> give
> > > them
> > > > names like: "Cluster1, Clsuter2,"
> > > > But if cluster restarted Web Console will detect it as new cluster
> and
> > > give
> > > > next auto-generated name "ClusterN".
> > > >
> > > > So, I'm not insist on adding "ClusterName" to IgniteConfiguration,
> but
> > > > could you give me a way
> > > >  some how "mark" clusters to detect them even after full restart.
> > > >
> > > > May be setting some sort of environment variable (it will be added to
> > > node
> > > > attributes)?
> > > > So, if user need "Multi-cluster" support he should set different
> > > > CLUSTER_NAME environment variable for different clusters.
> > > >
> > > > Any other ideas are welcome.
> > > >
> > > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Alexey,
> > > > >
> > > > > How does the workflow look like? How do you add a cluster to this
> > > > dropdown
> > > > > on the console? I think that assigning a name should be part of
> this
> > > > > process and should happen on the console itself.
> > > > >
> > > > > Adding yet another "name" to configuration will only confuse users
> > even
> > > > > more.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I don't like to add anything like this into Ignite config. It is
> a
> > > > > problem
> > > > > > of Web console how to name or rename different clusters for a
> user,
> > > but
> > > > > not
> > > > > > Ignite cluster itself.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > > >
> > > > > > > I am OK with having a cluster name, but I would like us to
> > generate
> > > > one
> > > > > > > automatically, if users do not define one explicitly. How about
> > > > > > > "cluster_timestamp"?
> > > > > > >
> > > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > > akuznet...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I'm planning to start working on multi cluster support for
> Web
> > > > > Console
> > > > > > > > in order to be able to execute SQL queries on different
> > clusters
> > > > just
> > > > > > by
> > > > > > > > selecting
> > > > > > > > target cluster from drop-down.
> > > > > > > >
> > > > > > > > But Ignite does not have any cluster wide name.
> > > > > > > >
> > > > > > > > So, how about to add to Ignite (may be 2.0) property "Cluster
> > > Name"
> > > > > to
> > > > > > > > Ignite configuration?
> > > > > > > >
> > > > > > > > Or as alternative way it could use "Mandatory User Defined
> > > > > Attribute".
> > > > > > > >
> > > > > > > > Node should be rejected to join cluster with different
> "Cluster
> > > > Name"
> > > > > > > >
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alexey Kuznetsov
> > > > > > > >

[GitHub] ignite pull request #2830: IGNITE-6371 .NET: Thin client example

2017-10-11 Thread ptupitsyn

GitHub user ptupitsyn opened a pull request:

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

IGNITE-6371 .NET: Thin client example



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

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

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

https://github.com/apache/ignite/pull/2830.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 #2830






---

Re: Cluster name

2017-10-11 Thread Alexey Kuznetsov

Hi,

I'd like to up this thread for discussion.

It seems that cluster name could be very useful together with multicast
discovery - do not accept nodes with different cluster name.
By default, let's set cluster name to "DEFAULT_CLUSTER".

Thoughts?

On Fri, Mar 17, 2017 at 12:30 AM, Dmitriy Setrakyan 
wrote:

> I am not sure I like naming clusters from an agent. It just sounds counter
> intuitive for me. How about adding an optional IGNITE_CLUSTER_NAME env
> property together with optional  -DCLUSTER_NAME system property and
> reserved CLUSTER_NAME user attribute?
>
> If user fails to provide any of the above, then we automatically assign the
> timestamp of the first node or some UUID as a cluster name.
>
> Thoughts?
>
> D.
>
> On Thu, Mar 16, 2017 at 5:01 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Alexey,
> >
> > Cluster doesn't know about the console, but web agent does, right? I
> think
> > it should be his responsibility to assign the name. I.e. when starting
> the
> > agent next to a particular cluster, user has to specify the name. If the
> > console already has the cluster with this name, agent should not start
> with
> > an exception suggesting to provide another name.
> >
> > Will this work?
> >
> > -Val
> >
> > On Thu, Mar 16, 2017 at 12:07 PM, Alexey Kuznetsov <
> akuznet...@apache.org>
> > wrote:
> >
> > > Dmitriy, Sergi and Val.
> > >
> > > Web Console will be connected to several clusters at once.
> > > And clusters do not know about Web Console, because Web Console collect
> > > info from cluster via our REST-HTTP module.
> > > So, I can distinguish clusters only by collection of node IDs and give
> > them
> > > names like: "Cluster1, Clsuter2,"
> > > But if cluster restarted Web Console will detect it as new cluster and
> > give
> > > next auto-generated name "ClusterN".
> > >
> > > So, I'm not insist on adding "ClusterName" to IgniteConfiguration, but
> > > could you give me a way
> > >  some how "mark" clusters to detect them even after full restart.
> > >
> > > May be setting some sort of environment variable (it will be added to
> > node
> > > attributes)?
> > > So, if user need "Multi-cluster" support he should set different
> > > CLUSTER_NAME environment variable for different clusters.
> > >
> > > Any other ideas are welcome.
> > >
> > > On Thu, Mar 16, 2017 at 5:57 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Alexey,
> > > >
> > > > How does the workflow look like? How do you add a cluster to this
> > > dropdown
> > > > on the console? I think that assigning a name should be part of this
> > > > process and should happen on the console itself.
> > > >
> > > > Adding yet another "name" to configuration will only confuse users
> even
> > > > more.
> > > >
> > > > -Val
> > > >
> > > > On Thu, Mar 16, 2017 at 9:59 AM, Sergi Vladykin <
> > > sergi.vlady...@gmail.com>
> > > > wrote:
> > > >
> > > > > I don't like to add anything like this into Ignite config. It is a
> > > > problem
> > > > > of Web console how to name or rename different clusters for a user,
> > but
> > > > not
> > > > > Ignite cluster itself.
> > > > >
> > > > > Sergi
> > > > >
> > > > > 2017-03-16 4:21 GMT+03:00 Dmitriy Setrakyan  >:
> > > > >
> > > > > > I am OK with having a cluster name, but I would like us to
> generate
> > > one
> > > > > > automatically, if users do not define one explicitly. How about
> > > > > > "cluster_timestamp"?
> > > > > >
> > > > > > On Wed, Mar 15, 2017 at 5:38 PM, Alexey Kuznetsov <
> > > > akuznet...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I'm planning to start working on multi cluster support for Web
> > > > Console
> > > > > > > in order to be able to execute SQL queries on different
> clusters
> > > just
> > > > > by
> > > > > > > selecting
> > > > > > > target cluster from drop-down.
> > > > > > >
> > > > > > > But Ignite does not have any cluster wide name.
> > > > > > >
> > > > > > > So, how about to add to Ignite (may be 2.0) property "Cluster
> > Name"
> > > > to
> > > > > > > Ignite configuration?
> > > > > > >
> > > > > > > Or as alternative way it could use "Mandatory User Defined
> > > > Attribute".
> > > > > > >
> > > > > > > Node should be rejected to join cluster with different "Cluster
> > > Name"
> > > > > > >
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > --
> > > > > > > Alexey Kuznetsov
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>



-- 
Alexey Kuznetsov

Re: Persistence per memory policy configuration

2017-10-11 Thread Ivan Rakov


Igniters,

https://issues.apache.org/jira/browse/IGNITE-6030 is ready and enqueued 
for TC run.

PR: https://github.com/apache/ignite/pull/2828

Everyone interested in new data storage configuration API, please pay 
attention and review.



Best Regards,
Ivan Rakov

On 09.10.2017 12:40, Pavel Tupitsyn wrote:

Sounds good to me.

On Mon, Oct 9, 2017 at 12:35 PM, Ivan Rakov  wrote:


Pavel,

Sounds reasonable.
I suggest to include both "data" and "configuration" to make it even more
obvious:

set/getDefaultDataRegionConfiguration
set/getDataRegionConfigurations

Best Regards,
Ivan Rakov


On 09.10.2017 10:51, Pavel Tupitsyn wrote:


Sorry that I'm late to the party, but this looks inconsistent:

DataStorageConfiguration defaultRegionConfiguration
DataRegionConfiguration[] getDataRegions

defaultRegionConfiguration + getRegionConfigurations
- or -
defaultDataRegion + getDataRegions

Thoughts?

On Mon, Oct 2, 2017 at 9:10 PM, Ivan Rakov  wrote:

Denis,

Yes, you're right. All cache groups without specific data region
configured will be persistent.
And if you want to add another persistent data region, you should set
*isPeristenceEnabled* flag in its *DataRegionConfiguration* explictly.

Best Regards,
Ivan Rakov


On 02.10.2017 21:01, Denis Magda wrote:

Missed the point with defaults. Makes sense to me now. So to wrap this

up, if I want to enable the persistence globally and don’t have any
regions
configured explicitly I need to take the default region and switch the
persistence on for it. Is my understanding correct?

—
Denis

On Oct 2, 2017, at 10:57 AM, Ivan Rakov  wrote:


Denis, why do you need to access an instance of the default region
bean?
If you want to set any parameter, just instantiate new bean with this
parameter set (like in XML snipped below). Other parameters will be
automatically initialized with their default values.

Best Regards,
Ivan Rakov

On 02.10.2017 19:28, Denis Magda wrote:




guration.DataStorageConfiguration">









In other data regions persistence will be disabled by default.

Ivan, how to get an instance to the default region bean and change a

parameter? Obviously, if the goal is to enable the persistence I
don’t want
to create the default region bean from scratch.

—
Denis

On Oct 2, 2017, at 9:11 AM, Ivan Rakov  wrote:


Agree with Alexey.

Properties like *defaultDataRegionSize*,
*isDefaultPersistenceEnabled*
can confuse users who don't know that there's such thing as default
data
region. They can decide they are inherited by all data regions where
size
and persistence flag are not explicitly set.

Let's get rid of these properties and add
*defaultRegionConfiguration*
property with explicit configuration of default data region.

Regarding XML configuration, changing size or persistence flag of
default data region will be just two lines longer (for bean
description):














In other data regions persistence will be disabled by default.

I've updated draft in https://issues.apache.org/jira
/browse/IGNITE-6030 with these changes.

Best Regards,
Ivan Rakov

On 02.10.2017 18:35, Denis Magda wrote:

To resolve this, I suggest to

introduce just another field defaultRegionConfiguration and get rid
of
other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m

not
an expert in Spring so how do I get defaultRegionConfiguration bean
first
to change any parameter?

—
Denis

On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk <


alexey.goncha...@gmail.com> wrote:

Agree with Vladimir. If we are to implement this, we would either
need to
have a Boolean (non-primitive) for persistenceEnabled on
DataRegionConfiguration, or introduce an enum for this field which
is also
an overkill. On the other hand, one can assume that the defaults we
are
talking about are actually inherited. To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid
of
other defaults in DataStorageConfiguration.

Thoughts?

2017-10-02 15:19 GMT+03:00 Ivan Rakov :

Vladimir,


I like your approach because it's easier to implement.

However, user may be confused by setting
*isDefaultPersistenceEnabled*
flag and seeing that persistence is not enabled by default in
custom memory
region. I'll add clarifying Javadoc at this place.

Best Regards,
Ivan Rakov


On 02.10.2017 11:28, Vladimir Ozerov wrote:

Ivan,


I do not think this is correct approach, because it will be hard
to
explain, and you will have to use "Boolean" instead of "boolean"
for
DataRegionConfiguration. I do not think we need default
"persistence

[GitHub] ignite pull request #2807: IGNITE-6545: Failure during Ignite Service.cancel...

2017-10-11 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-6596) A safer way for user re-login in kerberized cluster

2017-10-11 Thread Reid Chan (JIRA)

Reid Chan created IGNITE-6596:
-

 Summary: A safer way for user re-login in kerberized cluster
 Key: IGNITE-6596
 URL: https://issues.apache.org/jira/browse/IGNITE-6596
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 2.2
Reporter: Reid Chan


I'm running kerberos related tests before putting ignite into productions. And 
accidentally found that the re-login user (login through keytab), somehow, was 
replaced by system-wide user (login through kinit).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-6595) rebuildIndexesFromHash does not touch cache entries

2017-10-11 Thread Alexey Goncharuk (JIRA)

Alexey Goncharuk created IGNITE-6595:


 Summary: rebuildIndexesFromHash does not touch cache entries
 Key: IGNITE-6595
 URL: https://issues.apache.org/jira/browse/IGNITE-6595
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.2
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
Priority: Critical
 Fix For: 2.4


rebuildIndexesFromHash does not touch cache entry after ensureIndex(), which 
leads to memory leak.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: IGNITE-2894 - Binary object inside of Externalizable still serialized with OptimizedMarshaller

2017-10-11 Thread Nikita Amelchev

Hello, Igniters.

I have implemented support for the Externalizable interface in the
BinaryMarshaller without deserialization on servers.[1,2] I have made it
like the Binarylizable does in a raw writer.

Please, review.

[1]: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-278
[2]: https://issues.apache.org/jira/browse/IGNITE-2894

2017-09-22 18:46 GMT+03:00 Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> Nikita,
>
> I think it should be consistent with Binarylizable.
>
> -Val
>
> On Fri, Sep 22, 2017 at 7:12 AM Nikita Amelchev 
> wrote:
>
> > Another problem is support BinaryObject methods, for example, when we
> need
> > to get a field(often case in queries with annotation QuerySqlField). In a
> > binary object, fields are getting from the schema, which I don't have
> > (BinaryObjectException: Cannot find schema for object with compact
> footer).
> >
> > I see such ways to resolve it:
> >
> > 1. Deserialize object and get a field.
> >
> > 2. Make methods like BinaryFieldImpl.value(obj) unavailable. I tried to
> > reproduce similar behavior with Binarylizable(rawWriter) and it throws
> the
> > same exception.
> >
> > Therefore, if we want to avoid deserialization we should get a format
> that
> > is similar to Binarylizable with a raw writer. Is it right?
> >
> > What are your thoughts?
> >
> >
> > 2017-09-19 20:10 GMT+03:00 Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > > Nikita,
> > >
> > > It sounds like the test should be changed, no? In case I'm missing
> > > something, can you please give more details about the scenario which
> > > requires deserialization? Generally, this sounds weird - in cases when
> we
> > > can get advantage of binary format and avoid deserialization, we
> > definitely
> > > should not deserialize.
> > >
> > > -Val
> > >
> > > On Tue, Sep 19, 2017 at 6:17 AM, Nikita Amelchev  >
> > > wrote:
> > >
> > > > I have some problem when we don't deserialize Externalizable. Some
> > > messages
> > > > require deserializing in GridCacheIoManager.message0(). For example,
> > > tests
> > > > like testResponseMessageOnUnmarshallingFailed where readExternal
> throws
> > > an
> > > > exception. A message containing Externalizable is deserialized and
> > > > processed as a failed message. If we do not deserialize here, we
> won't
> > > > process this message as failed. What way to resolve it? I see we can
> > try
> > > to
> > > > deserialize after a check on Externalizable in a finishUnmarshall
> > method,
> > > > but it looks bad. What are your thoughts?
> > > >
> > > > 2017-09-07 12:57 GMT+03:00 Nikita Amelchev :
> > > >
> > > > > I also agree that we should try to use Externalizable without
> > > > > deserialization on servers. I will do it in a way suggested in the
> > > > review.
> > > > > The Externalizable will marshal through type
> > GridBinaryMarshaller.OBJ,
> > > in
> > > > > addition, I’ll add a flag in BinaryConfiguration which will be used
> > to
> > > > turn
> > > > > on the old way with OptimizedMarshaller for compatibility with the
> > > > current
> > > > > data format.
> > > > >
> > > > > 2017-09-06 4:21 GMT+03:00 Dmitriy Setrakyan  >:
> > > > >
> > > > >> Vova, I agree. Let's stay loyal to our binary serialization
> > protocol.
> > > > >>
> > > > >> Do you know if we will be loosing any functionality available in
> > > > >> Externalizable, but not present in our binary protocol?
> > > > >>
> > > > >> D.
> > > > >>
> > > > >> On Mon, Sep 4, 2017 at 11:38 PM, Vladimir Ozerov <
> > > voze...@gridgain.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Folks,
> > > > >> >
> > > > >> > Let's discuss how this should be handled properly. I proposed to
> > use
> > > > the
> > > > >> > same format as regular binary object, with all data being
> written
> > in
> > > > >> "raw"
> > > > >> > form. This would give us one critical advantage - we will be
> able
> > to
> > > > >> work
> > > > >> > with such objects without deserialization on the server. Hence,
> no
> > > > >> classes
> > > > >> > will be needed on the server side. Current implementation (see
> PR
> > in
> > > > the
> > > > >> > ticket) defines separate format which require deserialization, I
> > am
> > > > not
> > > > >> OK
> > > > >> > with it.
> > > > >> >
> > > > >> > Thoughts?
> > > > >> >
> > > > >> > On Wed, Aug 23, 2017 at 6:11 PM, Nikita Amelchev <
> > > > nsamelc...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hello, Igniters!
> > > > >> > >
> > > > >> > > I've developed Externalizable interface support using
> > > > BinaryMarshaller
> > > > >> > [1].
> > > > >> > >
> > > > >> > > I have a misunderstanding with defining BinaryWriteMode in
> > > > >> > > BinaryUtils.mode(cls): there is AffinityKey class which
> > implements
> > > > >> > > Externalizable and registered with ReflectiveSerialize,
> > > > >> BinaryMarshaller
> > > > >> > > defines it as BinaryWriteMode.OBJ and uses

[GitHub] ignite pull request #2829: ignite-5714 removed unused GridCacheTxFinishSync

2017-10-11 Thread voipp

GitHub user voipp opened a pull request:

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

ignite-5714 removed unused GridCacheTxFinishSync



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

$ git pull https://github.com/voipp/ignite ignite-5714-remove-tx-sync

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

https://github.com/apache/ignite/pull/2829.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 #2829


commit 775e03424207581fa64441c1af3f6d38f4faa582
Author: voipp 
Date:   2017-10-10T14:37:59Z

removed unused GridCacheTxFinishSync




---

[GitHub] ignite pull request #2828: Ignite 6030 master

2017-10-11 Thread glukos

GitHub user glukos opened a pull request:

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

Ignite 6030 master



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

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

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

https://github.com/apache/ignite/pull/2828.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 #2828


commit 27416a7e2a741190c225af7ae1329ab45f4d85df
Author: Konstantin Dudkov 
Date:   2017-09-08T13:00:57Z

IGNITE-6030 Persistence per memoryPolicy (first working test)

commit 572671877ca84ba9991213f382e47171bf625012
Author: Konstantin Dudkov 
Date:   2017-09-11T15:25:52Z

IGNITE-6030 Remove WAL writes if persistence is disabled for memoryPolicy

commit 20524f8e522d37ad17a7f1016bc16c09d511ffa5
Author: Alexey Goncharuk 
Date:   2017-09-12T10:02:54Z

IGNITE-6030 - Persistence per memory policy

commit 38d336c192d75d4d0462864c7e728c4f80e15a3a
Author: Ivan Rakov 
Date:   2017-09-27T13:01:01Z

Merge branch 'master' into ignite-6030-master

# Conflicts:
#   
modules/indexing/src/test/java/org/apache/ignite/testsuites/IgnitePdsWithIndexingCoreTestSuite.java

commit 8490e97385764ef83952c412d9f79e3f58b79680
Author: Ivan Rakov 
Date:   2017-09-29T14:17:24Z

Merge branch 'master' into ignite-6030-master

commit be8f6b1746b964e89a473bffafe8723d4645a781
Author: Ivan Rakov 
Date:   2017-10-02T13:52:37Z

Merge branch 'master' into ignite-6030-master

commit ee0504396dae5dd3c460778ef4c7c813483326a3
Author: Ivan Rakov 
Date:   2017-10-03T14:52:04Z

IGNITE-6030 Phase 1 - classes renamed

commit 40473bd0bfe9487432e6ed289d950a0a30b53727
Author: Ivan Rakov 
Date:   2017-10-03T15:05:43Z

IGNITE-6030 Phase 2 - merge of MemoryConfiguration and 
PersistenceConfiguration

commit 2d39d9028983c81fb16f8677742a61dfc10b8b57
Author: Ivan Rakov 
Date:   2017-10-03T15:19:03Z

IGNITE-6030 Phase 3 - renamings of IgniteConfiguration methods

commit 40bf903c743f2e61f935d47b798619b1b034a2a8
Author: Ivan Rakov 
Date:   2017-10-04T09:27:57Z

IGNITE-6030 Phase 4 - Old classes are added as deprecated, 
getDefaultRegionConfiguration is added to DataStorageConfiguration. Public API 
is complete.

commit 6b77cbaf07857f5cd55352e515fcca9ad56fefea
Author: Ivan Rakov 
Date:   2017-10-04T13:27:13Z

IGNITE-6030 Phase 5 - Old MBeans are added as deprecated just in case.

commit c2fe58a89fc5f4e3378403776d4ef662c4acf900
Author: Ivan Rakov 
Date:   2017-10-04T14:14:17Z

Merge branch 'master' into ignite-6030-master

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/GridCacheDatabaseSharedManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/IgniteCacheDatabaseSharedManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java

commit c9811e4f5f27ac2ef39fbc554223b58f10d07534
Author: Ivan Rakov 
Date:   2017-10-05T10:03:18Z

IGNITE-6030 Phase 6 - Internal implementation classes renamed

commit b7bece04793e27857aa69dbf5cf2d4daafd1a141
Author: Ivan Rakov 
Date:   2017-10-05T10:11:37Z

Merge branch 'master' into ignite-6030-master

commit 4d6af4d2a4c400a6f0598835ad84cde4f9e1837b
Author: Ivan Rakov 
Date:   2017-10-05T13:08:38Z

IGNITE-6030 Phase 7 - "PersistentStoreConfiguration" use cases of 
DataStorageConfiguration fixed

commit 450d444cc4e2bf45cf2e2e8d0c41b2a4c7b61d02
Author: Ivan Rakov 
Date:   2017-10-05T14:50:25Z

IGNITE-6030 Phase 8 - default DataRegionConfiguration is used project-wide

commit 1f94e9ee5f34b261bdbe4656e5043d81b057cd1e
Author: Pavel Tupitsyn 
Date:   2017-10-06T09:40:49Z

Merge branch 'master' into ignite-6030-master

commit f15de9e99de5d6529bba04fbd6cbf72f8aa5273a
Author: Pavel Tupitsyn 
Date:   2017-10-06T09:54:21Z

Merge branch 'master' into ignite-6030-master

commit fb3399b7ea1a0fc9a42781f95cb56b85a5f56706
Author: Ivan Rakov 
Date:   2017-10-06T11:05:14Z

IGNITE-6030 default persistence enabled should be false

commit 740be150b9ebc6606fe527683a31d59d21626dcb
Author: Ivan Rakov 
Date:   2017-10-06T15:57:36Z

IGNITE-6030 wip

commit c940b722fec5e15a1e8561ec1c940f38c279eae7
Author: Ivan Rakov 
Date:   2017-10-06T16:00:05Z

IGNITE-6030 systemCache -> systemRegion

[GitHub] ignite pull request #2827: Ignite gg 12920

2017-10-11 Thread dkarachentsev

GitHub user dkarachentsev opened a pull request:

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

Ignite gg 12920



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

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

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

https://github.com/apache/ignite/pull/2827.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 #2827


commit 43bcc15127bd3fd7ac4e277da6da9e5fb6a855c0
Author: Vasiliy Sisko 
Date:   2017-03-30T04:08:10Z

IGNITE-4838 Fixed internal task detection logic. Added tests.
(cherry picked from commit ba68c6c)

commit 5b692317a3a93d36c39db503300f6ae7e0dc29d1
Author: dkarachentsev 
Date:   2017-05-18T06:39:36Z

Merge branch 'ignite-1.8.6' into ignite-1.9.3

# Conflicts:
#   modules/kubernetes/config/ignite-deployment.yaml
#   modules/kubernetes/config/ignite-service.yaml
#   modules/kubernetes/pom.xml

commit 72882126c047b937bd5ed93c85e28262530e4977
Author: Vasiliy Sisko 
Date:   2017-03-30T04:08:10Z

IGNITE-4838 Fixed internal task detection logic. Added tests.
(cherry picked from commit ba68c6c)

commit 0d3d93cd4eeb589f1b6a11b48e429defad01c82f
Author: dkarachentsev 
Date:   2017-05-18T16:11:08Z

IGNITE-4842 Now containsKey() respects isReadFromBackup() flag.

(cherry picked from commit d84fd29)

commit 4bf9123a6cff3b1fd17e8772bb0496108fce3f5e
Author: dkarachentsev 
Date:   2017-05-18T16:13:47Z

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

commit 2a818d36395dd1af23acf444adf396b2e2edbede
Author: Konstantin Dudkov 
Date:   2017-05-22T13:28:07Z

Fixed "IGNITE-4205 CassandraCacheStore should start IiteThread threads in 
loadCache() method"

Signed-off-by: nikolay_tikhonov 

commit 04fadd4a499239176ba21c390d93e30809abb4c1
Author: dkarachentsev 
Date:   2017-05-23T12:42:20Z

IGNITE-5223 Allow use local binary metadata cache if it's possible

commit b2040b7a95e421609bcf7ae05b56dc623310b409
Author: dkarachentsev 
Date:   2017-05-23T13:14:08Z

IGNITE-5259 Minor serialization fix

commit b77428d12658b3ab2cdd43ca61ed71d329e83283
Author: sboikov 
Date:   2017-01-10T13:59:17Z

Do not evict removed entries, otherwise removes can be lost.

(cherry picked from commit 55ac6e7)

commit 29187ef6b663eafe67eaaaf38e4c09fc244ac7aa
Author: dkarachentsev 
Date:   2017-05-24T14:31:27Z

Do not evict removed entries, otherwise removes can be lost.

Rollback due to test failings.

commit 442aac2507210d39b7f30ab8f8d9a3dbe2610cae
Author: Andrey V. Mashenkov 
Date:   2017-05-24T15:32:11Z

IGNITE-5225: Fix NPE caused by changes in IGNITE-4577.

(cherry picked from commit d463840)

commit b1736c0bd87d6cfb65f9ef422241e0f1aba04c8d
Author: Andrey V. Mashenkov 
Date:   2017-05-24T15:48:52Z

Fixed thread pools incorrect shutdown.

(cherry picked from commit 66cef22)

commit 15d94b432fdfe458a826df6ad3c30a0408a93f49
Author: Andrey V. Mashenkov 
Date:   2017-05-25T11:27:08Z

Backport of IGNITE-4336: Manual rebalance can't be requested twice.
(cherry picked from commit 9a691c4)

commit 3a12fee29625de8d75a291e39b7d52c5f5111fb4
Author: Andrey V. Mashenkov 
Date:   2017-05-25T16:38:59Z

Minors fix segmented indices snapshots.

commit 7362d3c692c28245b193658d727b20caa62ffd38
Author: dkarachentsev 
Date:   2017-05-25T17:13:01Z

Merge compilation fix

commit 26072dffb8f5b28693731f8367872a8e1e6dfe7e
Author: agura 
Date:   2017-05-18T16:40:09Z

ignite-5203 Simple BLOB support added

commit e105b4e5c9c04f966fa4ffcff0e49dc253f4f050
Author: Andrey V. Mashenkov 
Date:   2017-05-30T13:40:24Z

Merge remote-tracking branch 'origin/ignite-1.7.11' into ignite-1.8.7

# Conflicts:
#   
modules/cassandra/store/src/main/java/org/apache/ignite/cache/store/cassandra/datasource/DataSource.java
#   
modules/cassandra/store/src/test/java/org/apache/ignite/tests/IgnitePersistentStoreTest.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeConfigSelfTest.java
#

48 matches

Mail list logo