Re: New thin JDBC driver

> 1) Let's have separate connection string "jdbc:ignite:*thin*://" to avoid > any confusion and interference with old drivers. I would use “jdbc:ignite://“ for the newest driver not forcing to use “thin” in the connection string. I think it’s fine to break the compatibility there since

Re: IgfsPerBlockLruEvictionPolicy does not work as expected any more, what shall we do with it?

Hi Ivan, I’m for this approach > 2) leave it as is, but explain in javadocs that it only works for on-heap > layer, that does not in fact evict blocks from the underlying offheap > layer. because it should be feasible to enable on-heap caching for IGFS, right? Using the memory policies. So,

Re: IGNITE-5124 is ready for review

Sergey, Looks good to me. Please ask Alex G. to review the implementation part. I’ve taken look at the interfaces only. — Denis > On May 24, 2017, at 9:04 AM, Sergey Chugunov > wrote: > > Denis, > > Thanks for your comments, I've addressed them and pushed

Re: IGNITE-532 ready for review

Got you. Alex K., could you review the integration then? You are an experienced Scala developer as I know. — Denis > On May 24, 2017, at 12:37 AM, Roman Shtykh wrote: > > Denis, > Lately I don't use Scala. Probably someone with more Scala experience will be > a

Re: [VOTE] Accept Contribution of Ignite Persistent Store

> > Raul, I think everyone got confused on the process. At this point, the code > has not been merged to master, and is sitting in a separate branch. I would > recommend that we proceed with the vote. If the vote is declined, then we > will toss the branch. Just for the record. I don't want to

Re: Geo spatial index

Sergi, While we are figuring this out, what happens to the GeoSpatial functionality in the mean time? Is it going to work at all? If not, should we throw some sort of exception? D. On Wed, May 24, 2017 at 1:44 AM, Sergi Vladykin wrote: > Though this may require some

Re: New thin JDBC driver

Vladimir, In general, all good ideas. However, I am concerned about having SQL embedded into the server side configuration. I think we need to combine JDBC, ODBC, REST, and Thin Client into the same approach and have the same configuration for all of them. What do you think? D. On Wed, May 24,

[GitHub] ignite pull request #2002: Ignite 5267

GitHub user iveselovskiy opened a pull request: https://github.com/apache/ignite/pull/2002 Ignite 5267 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/ignite ignite-5267 Alternatively you can review and apply these

[jira] [Created] (IGNITE-5289) SQL: forbid WITH queries

Alexander Paschenko created IGNITE-5289: --- Summary: SQL: forbid WITH queries Key: IGNITE-5289 URL: https://issues.apache.org/jira/browse/IGNITE-5289 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-5288) Inconsistency of committed and the max memory numbers should not cause stopping cluster

Dmitriy Pavlov created IGNITE-5288: -- Summary: Inconsistency of committed and the max memory numbers should not cause stopping cluster Key: IGNITE-5288 URL: https://issues.apache.org/jira/browse/IGNITE-5288

Re: Negative non-heap memory maximum

I think it makes sense to switch non-heap memory metrics to new page memory semantics, this should show a clean picture in the node output and will also protect us from ambiguous -1 output. 2017-05-24 18:45 GMT+03:00 Dmitry Pavlov : > Igniters, > > > > On my jdk 1.8.0_131

Re: IgfsPerBlockLruEvictionPolicy does not work as expected any more, what shall we do with it?

As for me, there's no reason to store IGFS blocks in cache with on-heap layer enabled. I vote for the first option: deprecate/remove IgfsPerBlockLruEvictionPolicy (along with tests), recommend users to use page-based eviction if they need to evict blocks from primary IGFS. -- Best Regards,

[GitHub] ignite pull request #2001: ignite-5283 Transaction recovery works incorrectl...

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/2001 ignite-5283 Transaction recovery works incorrectly with cache store and writeThrough enabled You can merge this pull request into a Git repository by running: $ git pull

Re: Minimize amount of inner classes, predicates, tuples, etc

Hi Vladimir, Do you have any idea how this rules may be automatically controlled by, for example, code inspections and/or TeamCity? I do beleive if rule is controlled by some automatic way (not only by argreement) it has a chance to become true practice in real life. If this excellent idea

IgfsPerBlockLruEvictionPolicy does not work as expected any more, what shall we do with it?

Hi, colleagues, as Ignite caches moved to paged offheap memory , the IgfsPerBlockLruEvictionPolicy does not seem to work as expected any more, because 1) interface org.apache.ignite.cache.eviction.EvictionPolicy now only defines "eviction from on-heap", not a real eviction, because each on-heap

[GitHub] ignite pull request #2000: IGNITE-3355: Implemented Compute::Call() for C++

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/2000 IGNITE-3355: Implemented Compute::Call() for C++ You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3355

Re: IGNITE-5124 is ready for review

Denis, Thanks for your comments, I've addressed them and pushed changes. Could you please review one more time? Thanks, Sergey. On Wed, May 24, 2017 at 12:20 AM, Denis Magda wrote: > Sergey, > > Thanks, reviewed and left the notes in the upsource. > > — > Denis > > > On

Negative non-heap memory maximum

Igniters, On my jdk 1.8.0_131 there is negative amount of maximum non heap memory returned by following code: ManagementFactory.getMemoryMXBean().getNonHeapMemoryUsage().getMax()); returns -1. And this value is used in ignite metrics in GridLocalMetrics.getNonHeapMemoryMaximum() which

Re: [VOTE] Accept Contribution of Ignite Persistent Store

+1 On Wed, May 24, 2017 at 3:35 PM, Igor Sapego wrote: > +1 > > Best Regards, > Igor > > On Tue, May 23, 2017 at 7:04 PM, Dmitriy Setrakyan > wrote: > > > +1 > > > > Raul, I think everyone got confused on the process. At this point, the > code > > has

New thin JDBC driver

Igniters, Currently we have two JDBC drivers: v1 - old thin driver, deprecated, works over GridClient v2 - fat driver, works over Ignite started in "client" mode. Both of them have the same connection string "jdbc:ignite://" Now we are working on new thin driver. It will use almost the same

Re: [VOTE] Accept Contribution of Ignite Persistent Store

+1 Best Regards, Igor On Tue, May 23, 2017 at 7:04 PM, Dmitriy Setrakyan wrote: > +1 > > Raul, I think everyone got confused on the process. At this point, the code > has not been merged to master, and is sitting in a separate branch. I would > recommend that we proceed

[GitHub] ignite pull request #1999: IGNITE-5284

Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/1999 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: Remove/deprecate CacheConfiguration.sqlEscapeAll property

I found the solution - no changes to public API, just rework how we treat this flag internally. On Tue, May 23, 2017 at 10:15 PM, Vladimir Ozerov wrote: > Igniters, > > We have a property "CacheConfiguration.sqlEscapeAll". When enabled, all > database objects belonging to

[jira] [Created] (IGNITE-5287) SQL: CacheConfiguration.sqlEscapeAll must affect only predefined objects

Vladimir Ozerov created IGNITE-5287: --- Summary: SQL: CacheConfiguration.sqlEscapeAll must affect only predefined objects Key: IGNITE-5287 URL: https://issues.apache.org/jira/browse/IGNITE-5287

Re: Geo spatial index

Though this may require some changes in BPlusTree. Let me think. Sergi 2017-05-24 8:58 GMT+03:00 Sergi Vladykin : > It must not be too hard to implement kd-tree over b+tree [1]. Depending on > level we have to compare either X or Y coordinate. > > I think we will even

[GitHub] ignite pull request #1920: IGNITE-5121: REST API call with empty cache name ...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1920 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is

Re: IGNITE-532 ready for review

Denis, Lately I don't use Scala. Probably someone with more Scala experience will be a better reviewer. Roman On Wednesday, May 24, 2017 1:03 AM, Denis Magda wrote: Roman, Would you mind reviewing the contribution? — Denis > On May 23, 2017, at 8:38 AM, Kozlov

[jira] [Created] (IGNITE-5286) Reconsider deferredDelete implementation

Alexey Goncharuk created IGNITE-5286: Summary: Reconsider deferredDelete implementation Key: IGNITE-5286 URL: https://issues.apache.org/jira/browse/IGNITE-5286 Project: Ignite Issue

Re: Data compression in Ignite 2.0

Guys, any thoughts? 2017-05-16 13:40 GMT+03:00 Vyacheslav Daradur : > Hi guys, > > I've prepared the PR to show my idea. > https://github.com/apache/ignite/pull/1951/files > > About querying - I've just copied existing tests and have annotated the > testing data. >