[jira] [Created] (IGNITE-6616) WebConsole cache config parse

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6616:


 Summary: WebConsole cache config parse
 Key: IGNITE-6616
 URL: https://issues.apache.org/jira/browse/IGNITE-6616
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Minor
 Fix For: 2.4


1) Go to /monitoring/dashboard
2) Press Start cache button
3) Add  (without quotes in value)
4) Press Start button
Expected result: warning about xml format
Actual result: "Are you sure you want to start cache with name: ?" 
message



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

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

[Dmitriy Setrakyan]

Igniters, has anyone been able to review yet? Seems like a very useful
feature.

On Wed, Oct 11, 2017 at 1:44 AM, Nikita Amelchev 
wrote:

> 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 <
> nsamelc...@gmail.com
> > >
> > > > 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 <
> dsetrak...@apache.org
> > >:
> > > > > >
> > > > > >> 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, 

Re: Time units of AverageTxCommitTime and AverageTxRollbackTime in CacheMetrics.

[Dmitriy Setrakyan]

Absolutely, create a ticket. It would be even better if you picked it up
and contributed a fix :)

On Wed, Oct 11, 2017 at 6:06 AM, Pavel Pereslegin  wrote:

> 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
>

Re: Context switching for pessimistic transactions

[Dmitriy Setrakyan]

On Wed, Oct 11, 2017 at 9:00 AM, ALEKSEY KUZNETSOV  wrote:

> 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?


Alexey, I think you should ask the reviewer in the ticket to pay attention
to the tests and perhaps suggest some new ones. Without an actual review it
would be impossible to tell which tests need to be added.

Re: Persistence per memory policy configuration

[Dmitriy Setrakyan]

On Thu, Oct 12, 2017 at 7:01 PM, Denis Magda  wrote:

> From what I see after running an example they are under the same root
> folder and in different subdirectories. The root folder should be defined
> by setPersistencePath as I guess.
>

If that is the case, then you are right. Then we should not have
storagePath or WalPath, and store them both under "persistencePath" root.
However, I would need Alexey Goncharuk or Ivan Rakov to confirm this.

Re: Persistence per memory policy configuration

[Denis Magda]

>From what I see after running an example they are under the same root
folder and in different subdirectories. The root folder should be defined
by setPersistencePath as I guess.

Denis

On Thursday, October 12, 2017, Dmitriy Setrakyan 
wrote:

> On Thu, Oct 12, 2017 at 4:05 PM, Denis Magda  > wrote:
>
> > Both terms “persistence” and “storage” mean same to me. If to choose
> > between them I would go for “persistence” because this is how
> > we name the feature - “Ignite Persistence” [1]
>
>
> > Furthermore, by default WAL files, the archive and data/index files are
> > located under the same root which is “setPersistencePath” directory.
> >
>
> Denis, to my knowledge, WAL can span multiple caches, no? How can it end up
> in the same folder with data and indexes, if those are per cache?
>
>
> >
> > [1] https://ignite.apache.org/features/persistence.html <
> > https://ignite.apache.org/features/persistence.html>
> >
> > —
> > Denis
> >
> > > On Oct 12, 2017, at 12:00 AM, Ivan Rakov  > wrote:
> > >
> > > Name *setPersistencePath* looks confusing to me because both WAL and
> > index/partition files storage provide persistence. That's why we
> separated
> > API methods as *setWalPath* and *setStoragePath*.
> > > I think, *setStoragePath* is good enough as long as it's supported by
> > explaining javadoc.*
> > > *
> > >
> > > Best Regards,
> > > Ivan Rakov
> > >
> > > On 12.10.2017 8:05, Dmitriy Setrakyan wrote:
> > >> 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 <
> ivan.glu...@gmail.com >
> > >>> 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 <
> ivan.glu...@gmail.com 
> > >
> > >>> 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 <
> > ivan.glu...@gmail.com >
> > > wrote:
> > >
> > > Denis,
> > >
> > >> Yes, you're right. 

Re: Optimized DML execution: how to name it?

[Dmitriy Setrakyan]

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

> Igniters,
>
> We prepared optimization of DML processing. Instead of passing all data
> being updated through the client node, now we can optionally send SQL
> statement to data nodes and perform update locally. This could greatly
> improve performance of certain DML operations.
>
> Unfortunately we cannot enable this mode by default, because it is still a
> bit raw and there is a risk of regressions.


This feature should be enabled by default, as it should not be up to a user
to decide when to use it. Whatever name we come up with now will be
temporary, so it does not really matter.

Also when transactional SQL is ready this feature will make no sense in TX
> mode. For this reason we
> disable it by default for now.
>

We should figure out a proper way to use it in transactional mode. I am
sure we can, once we think it through. But even if we cannot, the system
should automatically decide when to use this optimization and when not to
use it.


>
> It will be possible to enable it from JDBC/ODBC drivers using a flag.
> Question - how to name this flag? Current name is "*updateOnServer*". I
> doesn't like it much, but cannot do better. Please share other ideas.
>
> - "distributedDml"? No, every operation is distributed.
> - "serverDml"?
>

In my view, we should come up with a generic enable/disable switch for all
experimental features. For example,
"experimental=feature1,feature2,feature3". Then, once a feature stops being
experimental, we simply enable it in the system via normal Ignite
configuration or by default.

Re: Persistence per memory policy configuration

[Dmitriy Setrakyan]

On Thu, Oct 12, 2017 at 4:05 PM, Denis Magda  wrote:

> Both terms “persistence” and “storage” mean same to me. If to choose
> between them I would go for “persistence” because this is how
> we name the feature - “Ignite Persistence” [1]


> Furthermore, by default WAL files, the archive and data/index files are
> located under the same root which is “setPersistencePath” directory.
>

Denis, to my knowledge, WAL can span multiple caches, no? How can it end up
in the same folder with data and indexes, if those are per cache?


>
> [1] https://ignite.apache.org/features/persistence.html <
> https://ignite.apache.org/features/persistence.html>
>
> —
> Denis
>
> > On Oct 12, 2017, at 12:00 AM, Ivan Rakov  wrote:
> >
> > Name *setPersistencePath* looks confusing to me because both WAL and
> index/partition files storage provide persistence. That's why we separated
> API methods as *setWalPath* and *setStoragePath*.
> > I think, *setStoragePath* is good enough as long as it's supported by
> explaining javadoc.*
> > *
> >
> > Best Regards,
> > Ivan Rakov
> >
> > On 12.10.2017 8:05, Dmitriy Setrakyan wrote:
> >> 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 <
> ivan.glu...@gmail.com>
> > 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 

[Ignite 2.3 release]: Java 9 in compatibility mode

[Denis Magda]

Igniters,

If to put aside the compilation task [1] on Java 9, nobody can start Ignite 
even in the compatibility mode on that version of JDK. That’s the reason [2].

Let’s fix this for 2.3 by expanding the “if” close to - 
!U.jdkVersion().contains("1.9"))

Any objections?

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

[2] 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgnitionEx.java#L186
 


—
Denis


> Begin forwarded message:
> 
> From: Paolo Di Tommaso 
> Subject: Re: Java 9
> Date: October 11, 2017 at 11:41:24 PM PDT
> To: u...@ignite.apache.org
> Reply-To: u...@ignite.apache.org
> 
> Hi Denis, 
> 
> Neither in compatibility mode? I mean adding some --add-opens options 
> 
>  to access deprecated/internal apis? 
> 
> Almost any any existing Java app works in this way. I've tried that but it 
> seems Ignite is throwing an exception because the Java version number does 
> not match the expected pattern. 
> 
> Any workaround ?
> 
> Cheers,
> Paolo
> 
> 
> On Thu, Oct 12, 2017 at 1:25 AM, Denis Magda  > wrote:
> Hi Paolo,
> 
> There is some work to do to make Ignite running on Java 9:
> https://issues.apache.org/jira/browse/IGNITE-4615 
> 
> 
> Guess the version will be supported by the end of the year.
> 
> —
> Denis
> 
>> On Oct 11, 2017, at 2:08 PM, Paolo Di Tommaso > > wrote:
>> 
>> Hi, 
>> 
>> Which the minimal Ignite version that can run on Java 9 ? 
>> 
>> I'm trying Ignite 1.9 and I'm getting 
>> 
>> 
>> Caused by: java.lang.IllegalStateException: Ignite requires Java 7 or above. 
>> Current Java version is not supported: 9
>>  at org.apache.ignite.internal.IgnitionEx.(IgnitionEx.java:185)
>> 
>> 
>>  
>> 
>> Thanks,
>> Paolo
>> 
> 
> 

Re: Optimized DML execution: how to name it?

[Denis Magda]

How about “inPlaceUpdate”?

A side note, I see the feature documented for ODBC in our hidden SQL domain 
[1]. But it’s missing for JDBC. Did we forget to update the JDBC docs?

[1] 
https://apacheignite-sql.readme.io/docs/connection-string-and-dsn#section-supported-arguments

> 
> Unfortunately we cannot enable this mode by default, because it is still a
> bit raw and there is a risk of regressions. Also when transactional SQL is
> ready this feature will make no sense in TX mode. For this reason we
> disable it by default for now


Does it mean that this kind of optimization is not feasible for transaction SQL 
or it will be just solved differently? Just trying to grasp if we are going to 
drop it after the TX SQL release.

—
Denis

> On Oct 11, 2017, at 11:45 PM, Vladimir Ozerov  wrote:
> 
> Igniters,
> 
> We prepared optimization of DML processing. Instead of passing all data
> being updated through the client node, now we can optionally send SQL
> statement to data nodes and perform update locally. This could greatly
> improve performance of certain DML operations.
> 
> Unfortunately we cannot enable this mode by default, because it is still a
> bit raw and there is a risk of regressions. Also when transactional SQL is
> ready this feature will make no sense in TX mode. For this reason we
> disable it by default for now.
> 
> It will be possible to enable it from JDBC/ODBC drivers using a flag.
> Question - how to name this flag? Current name is "*updateOnServer*". I
> doesn't like it much, but cannot do better. Please share other ideas.
> 
> - "distributedDml"? No, every operation is distributed.
> - "serverDml"?
> 
> Vladimir.

Re: Cluster name

[Denis Magda]

The system properties are a blackbox that few of the users are aware about. How 
do we decide where a property should go? Any rule for that? 

—
Denis

> On Oct 12, 2017, at 1:43 AM, Alexey Goncharuk  
> wrote:
> 
> The same way as if one node had cluster name in configuration and the other
> did not - they should not discover each other.
> 
> 2017-10-12 11:40 GMT+03:00 Alexey Kuznetsov :
> 
>> Alexey,
>> 
>> How we would handle situation if first node has one name in sys props and
>> second has another name or does not have any name?
>> 
>> On Thu, Oct 12, 2017 at 3:19 PM, Alexey Goncharuk <
>> alexey.goncha...@gmail.com> wrote:
>> 
>>> Personally, I would still add an ability to set cluster name via the
>> system
>>> property because in some cases this may be convenient (starting multiple
>>> clusters with the same configuration from ignite.sh, embedded deployments
>>> when configuration change is not available).
>>> 
>>> --AG
>>> 
>>> 2017-10-11 14:13 GMT+03:00 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 <
>> akuznet...@apache.org
 :
>> 
>>> 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

Re: Persistence per memory policy configuration

[Denis Magda]

Both terms “persistence” and “storage” mean same to me. If to choose between 
them I would go for “persistence” because this is how 
we name the feature - “Ignite Persistence” [1].

Furthermore, by default WAL files, the archive and data/index files are located 
under the same root which is “setPersistencePath” directory. 

[1] https://ignite.apache.org/features/persistence.html 

 
—
Denis

> On Oct 12, 2017, at 12:00 AM, Ivan Rakov  wrote:
> 
> Name *setPersistencePath* looks confusing to me because both WAL and 
> index/partition files storage provide persistence. That's why we separated 
> API methods as *setWalPath* and *setStoragePath*.
> I think, *setStoragePath* is good enough as long as it's supported by 
> explaining javadoc.*
> *
> 
> Best Regards,
> Ivan Rakov
> 
> On 12.10.2017 8:05, Dmitriy Setrakyan wrote:
>> 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
 

[GitHub] ignite pull request #2841: GG-12821 IGNITE-4642: Added "enforceJoinOrder" fl...

[alamar]

GitHub user alamar opened a pull request:

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

 GG-12821 IGNITE-4642: Added "enforceJoinOrder" flag to thick JDBC driver.



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

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

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

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


commit 2e6bc4416a1f2fa18dad78235b3f71f6fb58a98d
Author: dkarachentsev 
Date:   2017-03-30T14:36:22Z

Cleanup unused imports.

commit e01aee0b1bbdb8ff5583728e539df165029f682d
Author: nikolay_tikhonov 
Date:   2017-03-31T17:19:52Z

Fixed SSL issue.

Signed-off-by: nikolay_tikhonov 

commit ead9f2a595b91821b1b16627dd8d752897c24c03
Author: dkarachentsev 
Date:   2017-04-03T11:46:54Z

Merge branch 'ignite-1.8.4-p1' into ignite-1.8.6

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 925ee11c2002729b1264148ee5db5700ded5a7b7
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:06:01Z

Fixed typo.
(cherry picked from commit 3b84f34)

commit ce4b078c1c97cae4136c318ae38b27a50fe383cc
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:14:56Z

master Updated version.
(cherry picked from commit 5469626)

commit ae435fb5474429e7ac76faadd680c19a4c657371
Author: Sergi Vladykin 
Date:   2017-04-02T12:35:04Z

ignite-2913 - SQL: EXISTS support added

commit b7ab27301b59bf93fc73b52fdf8e0bcf124fec1d
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

commit b214211eb3461746b6931c0623e086bb208e5dda
Author: Anton Vinogradov 
Date:   2017-04-06T12:00:12Z

IGNITE-4644 Value from IgniteQueue in atomic mode could be lost

commit 014161427fb603b6df7c8ecc3c0904f5df47a21d
Author: Denis Magda 
Date:   2017-02-14T01:33:32Z

IGNITE-4159: Kubernetes IP finder.
(cherry picked from commit 37c0a22)

commit 1db238402f11c67d2b28bfb7ff47955415f00c25
Author: Denis Magda 
Date:   2017-02-16T04:37:26Z

IGNITE-4159: fixing logging
(cherry picked from commit 06908d2)
(cherry picked from commit fa27ee3)

commit 5dfe16f7e91374008b9f6dfbb899364f5b2e1164
Author: Denis Magda 
Date:   2017-02-14T06:03:30Z

IGNITE-4159: using logger instead of system.out.println
(cherry picked from commit b9bf77c)

commit 6e596d1ef426b66abd866d011a8f5cf5c5c25124
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

(cherry picked from commit b7ab273)

commit 443ac9a7aa82af1359a03bcfc8f9212b108300e4
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

commit 05f3c747921aed6838804d2f5f2c8d2bd7985337
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

(cherry picked from commit 443ac9a)

commit 3be4e00373ec5a2b49788d70eb0aebccc3cb6ccf
Author: Alexander Fedotov 
Date:   2017-04-07T11:59:00Z

Merge branch ignite-1.6.5 into ignite-1.8.5-p1

commit d81548d3a4e384e1a9b4adacf1fb487444bbfd33
Author: Alexander Fedotov 
Date:   2017-04-07T12:33:08Z

Merge branch ignite-1.6.6-p1 into ignite-1.8.5-p1

commit 6954ff0c85f2f75507ee0bd306c879f490b4201a
Author: Alexander Fedotov 
Date:   2017-04-07T12:44:48Z

Merge branch ignite-1.6.12 into ignite-1.8.5-p1

commit 62dbba81c009170ff6243a28d3ef12fa75b96225
Author: Alexander Fedotov 
Date:   2017-04-07T12:46:11Z

Merge branch ignite-1.7.4-p1 into ignite-1.8.5-p1

commit 4fce28054bc325741f65035ae384f9b4b9c3fee8
Author: Alexander Fedotov 
Date:   2017-04-07T13:06:34Z

Merge branch ignite-1.8.4-p1 into ignite-1.8.5-p1

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 3d616799efb472227b3b313516e6b40729654631
Author: dkarachentsev 

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

[voipp]

Github user voipp closed the pull request at:

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


---

[GitHub] ignite pull request #2840: Rebalancing optimizations.

[ilantukh]

GitHub user ilantukh opened a pull request:

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

Rebalancing optimizations.



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

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

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

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


commit b410fb676e0dda19e13bef9920862a3bbc86b75c
Author: Ilya Lantukh 
Date:   2017-09-13T15:34:10Z

gg-12001 : Migration to 2.1.5.

commit b1cb491b9760b7d02b50df2f606b94df17dc1589
Author: Ilya Lantukh 
Date:   2017-09-14T13:36:18Z

gg-12001 : Migration to 2.1.5.

commit c5aa606a23be2de93b3265eaaeebff7733d98a48
Author: Ilya Lantukh 
Date:   2017-09-14T14:17:48Z

gg-12001 : Removed incorrect assertion.

(cherry picked from commit 7e9ccbd)

commit 531bfd328a30a59ccda84d9710d7918b2584157b
Author: Ilya Lantukh 
Date:   2017-09-15T12:27:28Z

gg-12001 : Fixed serialVersionUid.

(cherry picked from commit 255db95)

commit ea7c67759ff32c0d86da249f3a62aab130a07784
Author: Ilya Lantukh 
Date:   2017-10-12T13:22:51Z

gg-12001 : Fix after review.

commit 2b1d32d039269a06d2167641c1ac1670fb8cc8e8
Author: Ilya Lantukh 
Date:   2017-10-12T15:00:47Z

gg-12001 : Fix after review.

commit 5ef171e2004e47a8885e3ef3151a8c2a39ce0a26
Author: Ilya Lantukh 
Date:   2017-10-12T16:00:24Z

gg-12001 : Backward compatibility.




---

[GitHub] ignite pull request #2839: Ignite 1.9.7.b2

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite 1.9.7.b2



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

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

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

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


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
#   
modules/core/src/test/java/org/apache/ignite/internal/processors/service/GridServiceProcessorMultiNodeSelfTest.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteBinaryObjectsTestSuite.java

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

# Conflicts:
#   docs/RELEASE_NOTES.txt
#   docs/community/RELEASE_NOTES.txt
#   
modules/compatibility/src/test/java/org/gridgain/grid/compatibility/tests/GridCompatibilityAbstractTest.java
#   modules/core/src/main/resources/gridgain.properties

commit d77a134fffee431cd7fa0bae2349419bc97ec1cf
Author: dkarachentsev 
Date:   2017-05-30T16:00:47Z

IGNITE-5342 - Skip permission check for TASK_EXECUTE for service jobs

commit c33504d4d51682dfb27ee3d38b4625f0946f4719
Author: dkarachentsev 
Date:   2017-05-31T11:21:52Z

Merge branch 'ignite-1.7.11' into ignite-1.9.3

# Conflicts:
#   
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/test/java/org/apache/ignite/testsuites/IgniteBinaryObjectsTestSuite.java

commit d0186c368b12ab6893d0985e3fb92600708d5b65
Author: dkarachentsev 
Date:   2017-05-30T16:00:47Z

IGNITE-5342 - Skip permission check for TASK_EXECUTE for service jobs

(cherry picked from commit d77a134)

commit 0a0c5be1eb4793bc838da3184591d91537bd9cad
Author: dkarachentsev 

[GitHub] ignite pull request #2838: Ignite 1.9 master

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite 1.9 master



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

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

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

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


commit 950a07b48d0d1f7203834fff3306018cf4ff0cf4
Author: Andrey V. Mashenkov 
Date:   2017-06-01T11:17:52Z

Minor fix

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:   

[jira] [Created] (IGNITE-6615) .NET: Thin client: XML configuration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6615:
--

 Summary: .NET: Thin client: XML configuration
 Key: IGNITE-6615
 URL: https://issues.apache.org/jira/browse/IGNITE-6615
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
 Fix For: 2.4


Provide a way to configure {{IgniteClientConfiguration}} in XML, similar to 
{{IgniteConfiguration}}.



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

[GitHub] ignite pull request #2820: IGNITE-6234 Initialize schemaIds to empty set if ...

[mcherkasov]

Github user mcherkasov closed the pull request at:

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


---

Re: Refactoring of IgniteKernal ack methods

[Vladimir Ozerov]

Dmitry,

In my experience refactoring without a reasons often produces more harm
than benefits. Especially:
1) You may brake compatibility. E.g. moving anonymous inner class to the
top level will cause renames of all other anonymous classes.
2) This may interfere severely with other people's work. If someone works
on some issue in a separate branch, he will get a lot of severe conflicts
when trying to merge his branch with master.

So I do not think we should do refactoring for refactoring. We should do
this only for a strong reason.

On Thu, Oct 12, 2017 at 5:12 PM, Дмитрий Рябов 
wrote:

> IgniteKernal and some other classes have more places to refactor. At least
> for better readable form or to remove inner class [1]. May be create some
> tickets for refactoring such complex places? I mean to create main ticket
> like [2] or [3], and when someone see something complex *and* the way to
> refactor - he can create subtask/PR for refactoring. Thoughts?
>
> [1] - http://apache-ignite-developers.2346864.n4.nabble.com/Mini
> mize-amount-of-inner-classes-predicates-tuples-etc-td17689.html
> [2] - https://issues.apache.org/jira/browse/IGNITE-4575
> [3] - https://issues.apache.org/jira/browse/IGNITE-5156
>
>
> 2017-10-11 18:37 GMT+03:00 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.
> >
>

Re: Refactoring of IgniteKernal ack methods

[Дмитрий Рябов]

IgniteKernal and some other classes have more places to refactor. At least
for better readable form or to remove inner class [1]. May be create some
tickets for refactoring such complex places? I mean to create main ticket
like [2] or [3], and when someone see something complex *and* the way to
refactor - he can create subtask/PR for refactoring. Thoughts?

[1] - http://apache-ignite-developers.2346864.n4.nabble.com/Mini
mize-amount-of-inner-classes-predicates-tuples-etc-td17689.html
[2] - https://issues.apache.org/jira/browse/IGNITE-4575
[3] - https://issues.apache.org/jira/browse/IGNITE-5156


2017-10-11 18:37 GMT+03:00 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.
>

[jira] [Created] (IGNITE-6614) .NET: DotNetCore examples

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6614:
--

 Summary: .NET: DotNetCore examples
 Key: IGNITE-6614
 URL: https://issues.apache.org/jira/browse/IGNITE-6614
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.4


.NET Thin Client works under .NET Core. Create separate examples project for 
that.



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

[jira] [Created] (IGNITE-6613) .NET: Thin client: Create dotnet core unit test project, run on Linux

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6613:
--

 Summary: .NET: Thin client: Create dotnet core unit test project, 
run on Linux
 Key: IGNITE-6613
 URL: https://issues.apache.org/jira/browse/IGNITE-6613
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Priority: Minor
 Fix For: 2.4


.NET Thin Client actually works on .NET Core and on Linux. Let's add unit tests 
for that and run them on Linux machines to avoid regression.



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

[jira] [Created] (IGNITE-6612) Wrap ack methods in their own class

[Ivan Fedotov (JIRA)]

Ivan Fedotov created IGNITE-6612:


 Summary: Wrap ack methods in their own class
 Key: IGNITE-6612
 URL: https://issues.apache.org/jira/browse/IGNITE-6612
 Project: Ignite
  Issue Type: Improvement
Affects Versions: None
Reporter: Ivan Fedotov
Assignee: Ivan Fedotov
Priority: Trivial
 Fix For: 2.3



Several methods in IgniteKernal implement similar functions: “ackAsciiLogo”, 
“ackConfigUrl”, “ackDaemon”, “ackOsInfo”, “ackLanguageRuntime”, 
“ackRemoteManagement”, “ackVmArguments”, “ackClassPaths”, 
“ackSystemProperties”, “ackEnviromentVariables”, “ackMemoryConfiguration”, 
“ackCacheConfiguration”, “ackP2PConfiguration”, “ackRebalanceConfiguration”. 

These methods should be placed in separate class “AckVariousInformation” and 
called from the class instance in IgniteKernal.





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

[jira] [Created] (IGNITE-6611) Optionally disable binary metadata for type

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6611:
---

 Summary: Optionally disable binary metadata for type
 Key: IGNITE-6611
 URL: https://issues.apache.org/jira/browse/IGNITE-6611
 Project: Ignite
  Issue Type: Task
  Components: binary, sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
Assignee: Alexander Paschenko
 Fix For: 2.4


We need to introduce special metadata mode for type - without metadata. This 
way we will have a kind of "flexible" type with no restrictions. This will be 
especially useful for SQL-related types where schema changes are possible (e.g. 
ADD COLUMN -> DROP COLUMN).

Public part should be exposed to:
1) {{BinaryTypeConfiguration}}
2) {{BinaryType}} - add a flag here.



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

[GitHub] ignite pull request #2837: IGNITE-6135

[NSAmelchev]

GitHub user NSAmelchev opened a pull request:

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

IGNITE-6135

- add new type SQL_DATE(for java.sql.Date class) into the Binary Marshaller.

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

$ git pull https://github.com/NSAmelchev/ignite ignite-6135

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

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


commit 27d01e55406df1b1f498b8c09c278c29a47ba038
Author: NSAmelchev 
Date:   2017-10-11T12:53:09Z

add test

commit ed8ec5d0a1e59f87e8dd0f7fba07bbfb117dcb47
Author: NSAmelchev 
Date:   2017-10-12T12:02:38Z

Fix




---

[jira] [Created] (IGNITE-6610) Unexpected error message 'Duplicate column name' in case if query has LIMIT

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6610:
---

 Summary: Unexpected error message 'Duplicate column name' in case 
if query has LIMIT 
 Key: IGNITE-6610
 URL: https://issues.apache.org/jira/browse/IGNITE-6610
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
 Fix For: 2.4


Reported by [~pkonstantinov], Try to execute the following query:
{{SELECT * FROM ( select p.id, d.id from Person p inner join Department d on 
d.id = p.depid ) LIMIT 50}}
This is valud query, but error message appears:
{{Duplicate column name "ID"; SQL statement: SELECT * FROM ( select p.id, d.id 
from Person p inner join Department d on d.id = p.depid ) LIMIT 50 [42121-195]}}



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

[jira] [Created] (IGNITE-6609) H2PkHashIndex.H2Cursor doesn't take in count expiration

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6609:
---

 Summary: H2PkHashIndex.H2Cursor doesn't take in count expiration
 Key: IGNITE-6609
 URL: https://issues.apache.org/jira/browse/IGNITE-6609
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
 Fix For: 2.4


Correct: {{H2Cursor#next}} - expire time is checked;
Incorrect: {{H2PkHashIndex.H2Cursor#next}} - expired time is ignored.



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

Re: Optimized DML execution: how to name it?

[Igor Sapego]

Here is the link for the ticket [1] If someone else was wandering
about what kind of optimization we are talking.

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

Best Regards,
Igor

On Thu, Oct 12, 2017 at 9:45 AM, Vladimir Ozerov 
wrote:

> Igniters,
>
> We prepared optimization of DML processing. Instead of passing all data
> being updated through the client node, now we can optionally send SQL
> statement to data nodes and perform update locally. This could greatly
> improve performance of certain DML operations.
>
> Unfortunately we cannot enable this mode by default, because it is still a
> bit raw and there is a risk of regressions. Also when transactional SQL is
> ready this feature will make no sense in TX mode. For this reason we
> disable it by default for now.
>
> It will be possible to enable it from JDBC/ODBC drivers using a flag.
> Question - how to name this flag? Current name is "*updateOnServer*". I
> doesn't like it much, but cannot do better. Please share other ideas.
>
> - "distributedDml"? No, every operation is distributed.
> - "serverDml"?
>
> Vladimir.
>

[jira] [Created] (IGNITE-6608) .NET: Thin client documentation

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6608:
--

 Summary: .NET: Thin client documentation
 Key: IGNITE-6608
 URL: https://issues.apache.org/jira/browse/IGNITE-6608
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Document new Thin Client API on readme.io: 
https://apacheignite-net.readme.io/docs



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

[jira] [Created] (IGNITE-6607) Thin client: protocol documentation

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6607:
--

 Summary: Thin client: protocol documentation
 Key: IGNITE-6607
 URL: https://issues.apache.org/jira/browse/IGNITE-6607
 Project: Ignite
  Issue Type: Task
  Components: documentation, platforms
Affects Versions: 2.3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Document thin client protocol on Ignite wiki: 
https://cwiki.apache.org/confluence/display/IGNITE/Design+Documents

* Common message format (length, flags)
* Data types (endianness, strings, etc)
* Request/Response format for each message type
* How to connect



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

[GitHub] ignite pull request #2835: IGNITE-5928 .NET: Get rid of BinaryStreamBase

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-6606) Web console agent download

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6606:


 Summary: Web console agent download
 Key: IGNITE-6606
 URL: https://issues.apache.org/jira/browse/IGNITE-6606
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Affects Versions: 2.1
Reporter: Alexander Belyak
Assignee: Alexey Kuznetsov
Priority: Minor
 Fix For: 2.4


To connect web console to ignite cluster I must use web-agent, but in first 
time its not oblivious where to get it.
1) Documentation ( https://apacheignite-tools.readme.io/docs/getting-started ) 
say "Ignite Web Agent zip ships with ignite-web-agent.{sh|bat} script" It's 
wrong.
2) In web console cluster configure screen I see big red buttons "Save project" 
and "Save and download projects", but to download web-agent I must found small 
link in bottom "Download agent" (near Feedback and Apache Ignite logo, it's 
wrong place) Moreover, agent configuration contain one parameter from cluster 
configuration (IGNITE_JETTY_PORT) so download link should be cluster wide, not 
web console wide.



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

[GitHub] ignite pull request #2836: IGNITE-6605

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-6605



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

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

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

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


commit c4f0895aa71db35e684de210915a7ccd41ef514c
Author: devozerov 
Date:   2017-10-12T08:11:32Z

Removed unused method.

commit 046ecb254628ee6fe2471b11f2f5da665b802b78
Author: devozerov 
Date:   2017-10-12T09:10:47Z

WIP.

commit 35999f4fffc433294057b40a925227e3882a
Author: devozerov 
Date:   2017-10-12T09:19:21Z

Fixed compilation.

commit cf16a5181c02df8c16d310a8d94310e01d458d09
Author: devozerov 
Date:   2017-10-12T09:21:17Z

Fix.




---

[jira] [Created] (IGNITE-6605) SQL: Merge and optimize backup query filter

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6605:
---

 Summary: SQL: Merge and optimize backup query filter
 Key: IGNITE-6605
 URL: https://issues.apache.org/jira/browse/IGNITE-6605
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.3
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.4


1) Merge two anonymous implementations as they does the same things.
2) Get rid of binary search in favor of hash-based lookup.
3) Do not create a filter for {{PARTITIONED}} cache with no backups when there 
are no explicit partitions.



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

[jira] [Created] (IGNITE-6604) Log exchange progress

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6604:


 Summary: Log exchange progress
 Key: IGNITE-6604
 URL: https://issues.apache.org/jira/browse/IGNITE-6604
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 2.1
Reporter: Alexander Belyak
Priority: Minor


Sometimes exchange process hangs (because some errors, OOMe, deadlocks, etc), 
sometimes it require significant time to finish (finish eviction, long Full GC, 
etc).
We need some logging, that will show progress, because often exchange is block 
whole cluster and support team wanna know what's happen and how many time it 
will continue. Main point - simplify throubleshooting, just as grep standard 
message/logging class, for example: "Exchange progress: evicting partition 
" or "Exchange progress: waiting for response from  nodes".



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

[jira] [Created] (IGNITE-6603) .NET: EntityFramework Core Data Provider

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6603:
--

 Summary: .NET: EntityFramework Core Data Provider
 Key: IGNITE-6603
 URL: https://issues.apache.org/jira/browse/IGNITE-6603
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


Create a Data Provider for Entity Framework Core, so that Ignite can be used as 
a database transparently: 
https://docs.microsoft.com/en-us/ef/core/providers/writing-a-provider



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

Re: Cluster name

[Alexey Goncharuk]

The same way as if one node had cluster name in configuration and the other
did not - they should not discover each other.

2017-10-12 11:40 GMT+03:00 Alexey Kuznetsov :

> Alexey,
>
> How we would handle situation if first node has one name in sys props and
> second has another name or does not have any name?
>
> On Thu, Oct 12, 2017 at 3:19 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Personally, I would still add an ability to set cluster name via the
> system
> > property because in some cases this may be convenient (starting multiple
> > clusters with the same configuration from ignite.sh, embedded deployments
> > when configuration change is not available).
> >
> > --AG
> >
> > 2017-10-11 14:13 GMT+03:00 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 <
> akuznet...@apache.org
> > >:
> > > > >
> > > > > > 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 

[GitHub] ignite pull request #2835: IGNITE-5928 .NET: Get rid of BinaryStreamBase

[apopovgg]

GitHub user apopovgg opened a pull request:

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

IGNITE-5928 .NET: Get rid of BinaryStreamBase

Please review

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

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

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

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


commit 92bdcb407a9fc1a06964b44329608ad629aecbf2
Author: apopov 
Date:   2017-10-12T08:40:30Z

IGNITE-5928 .NET: Get rid of BinaryStreamBase




---

Re: Cluster name

[Alexey Kuznetsov]

Alexey,

How we would handle situation if first node has one name in sys props and
second has another name or does not have any name?

On Thu, Oct 12, 2017 at 3:19 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Personally, I would still add an ability to set cluster name via the system
> property because in some cases this may be convenient (starting multiple
> clusters with the same configuration from ignite.sh, embedded deployments
> when configuration change is not available).
>
> --AG
>
> 2017-10-11 14:13 GMT+03:00 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 

Re: Cluster name

[Alexey Goncharuk]

Personally, I would still add an ability to set cluster name via the system
property because in some cases this may be convenient (starting multiple
clusters with the same configuration from ignite.sh, embedded deployments
when configuration change is not available).

--AG

2017-10-11 14:13 GMT+03:00 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
> 

Re: Persistence per memory policy configuration

[Ivan Rakov]

Name *setPersistencePath* looks confusing to me because both WAL and 
index/partition files storage provide persistence. That's why we 
separated API methods as *setWalPath* and *setStoragePath*.
I think, *setStoragePath* is good enough as long as it's supported by 
explaining javadoc.*

*

Best Regards,
Ivan Rakov

On 12.10.2017 8:05, Dmitriy Setrakyan wrote:

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:

 


 
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">
 
 
 
 
 
   

Optimized DML execution: how to name it?

[Vladimir Ozerov]

Igniters,

We prepared optimization of DML processing. Instead of passing all data
being updated through the client node, now we can optionally send SQL
statement to data nodes and perform update locally. This could greatly
improve performance of certain DML operations.

Unfortunately we cannot enable this mode by default, because it is still a
bit raw and there is a risk of regressions. Also when transactional SQL is
ready this feature will make no sense in TX mode. For this reason we
disable it by default for now.

It will be possible to enable it from JDBC/ODBC drivers using a flag.
Question - how to name this flag? Current name is "*updateOnServer*". I
doesn't like it much, but cannot do better. Please share other ideas.

- "distributedDml"? No, every operation is distributed.
- "serverDml"?

Vladimir.