Optimized DML execution: how to name it?
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: Persistence per memory policy configuration
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&page=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: > >>
[jira] [Created] (IGNITE-6602) .NET: Improve LINQ documentation
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.
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
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
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
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&page=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 thes
[GitHub] ignite pull request #2834: ignite-gg-12908 Sequential puts fail for keys imp...
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 3a1d560cd8741de9e7a6dd1110b42814d0ccff6b Author: dkarachentsev Date: 2017-06-06T14:13:52Z IGNITE-5259 Minor serialization fix commit 56d4ce8a042238654ab96235d1a2969107b8881c Author: devozerov Date: 2017-06-06T14:39:33Z GG-12244: Fixed a bug in GridH2IndexRangeRequest serialization mechanics. commit f1b8a7d8407fbc990e7027b17e366d30f05c1ab6 Author: devozerov Date: 2
Re: Why SQL_PUBLIC is appending to Cache name while using JDBC thin driver
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
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
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
Hi Denis, Sure, will do. Regards, Yury -- Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
[GitHub] ignite pull request #2780: Ignite 6123
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 Ignatenko Date: 2017-09-25T14:56:05Z IGNITE-6123 ML Grid benchmarks - draft implementation completed -- verified with diffs overview, clean build, trial execution of benchmark and studying results commit 82dd48c7b1b8b025ed9d706e3978190414d49065 Author: Oleg Ignatenko Date: 2017-09-26T10:57:22Z IGNITE-6123 ML Grid benchmarks - documentation updated -- verified with diffs o
[GitHub] ignite pull request #2780: Ignite 6123
Github user oignatenko closed the pull request at: https://github.com/apache/ignite/pull/2780 ---
Re: Context switching for pessimistic transactions
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
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
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
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
Github user apopovgg closed the pull request at: https://github.com/apache/ignite/pull/2804 ---
Refactoring of IgniteKernal ack methods
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
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
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.
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
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
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...
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
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
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
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&page=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
Re: Persistence per memory policy configuration
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&page=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 have a Boolean (non-primitive) for persistenceEnabled on DataRegionConfiguration, or introduce an enum for this
[GitHub] ignite pull request #2831: IGNITE-6270 Renamed user facing CREATE TABLE
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
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
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
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: > > > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > >
Re: Persistence per memory policy configuration
Ivan, I left some comments in the ticket [1], please take a look. [1] https://issues.apache.org/jira/browse/IGNITE-6030?focusedCommentId=16200050&page=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 > >> introduce just another field defaultRegionConfiguration and get >>> rid >>> of >>>
Re: Cluster name
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 wide name. > > > > > > > > > > > > > > > > > > So,
Re: Cluster name
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 Kuznetsov > > > > > > > > > > > > > > > > > > > >
Re: Cluster name
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 (may be 2.0) property > "Cluster > > > > Name
Re: Cluster name
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
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
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
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 enabled" for all regions. Instead, we should have "persistence enabled" flag for default region only. It should not be pr
[GitHub] ignite pull request #2807: IGNITE-6545: Failure during Ignite Service.cancel...
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
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
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
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 reflection > according > > to > > > > >> > current > > > > >> > > logic. I want to say that Aff
[GitHub] ignite pull request #2829: ignite-5714 removed unused GridCacheTxFinishSync
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
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 commit 689c204ae669579e18c4dd818e06203d9ef68b93 Author: Ivan Rakov Date: 2017-10-06T17:09:28Z IGNITE-6030 wip commit 8168232aeb5c6e6ac81dc8a13279c5a5263aece1 Author: Pavel Tupitsyn Date: 2017-10-09T07:10:58Z Merge branch 'master' into ignite-6030-master commit 905bb10103f4b975d64e41716c55afcb235e924e Author: Pavel Tupitsyn Date: 2017-10-09T07:13:25Z Revert platform changes commit 82c226a2bf9dc5ea496e739f124d9a0b1367c630 Author: Ivan Rakov
[GitHub] ignite pull request #2827: Ignite gg 12920
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 # 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/re