Re: Custom string encoding

Val, do you know how we compare strings in SQL queries? Will we be able to use this encoder? Additionally, I think that the encoder is a bit too abstract. Why not go even further and allow users create their own ASCII table for encoding? D. On Fri, Jun 30, 2017 at 6:49 PM, Valentin Kulichenko <

Re: By bytes access to binary format

On Fri, Jun 30, 2017 at 10:35 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Vova, > > Generally this can be useful. If you have a read-only binary object with a > large blob as a field, you don't want to copy this array when reading it. > Instead, we can return a ByteBuffer or

Re: Distributed scheduling

On Fri, Jun 30, 2017 at 12:29 AM, Alexey Kuznetsov wrote: > Dmitriy, > > >> Can you provide a simple example of API calls that will make this > possible? > API could be like this: > 1) via scheduler: > Ignite ignite = Ignition.start(); > >

Re: Distributed scheduling

ew. > I'm talking only about periodical or one-time planned jobs on cluster that > will be executed with some guaranties. > > But we also can take into account that use-case. > > > On Fri, Jun 30, 2017 at 5:53 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: >

Re: Distributed scheduling

Alexey, why do you think it will be useful? On Thu, Jun 29, 2017 at 12:22 PM, Alexey Kuznetsov wrote: > Hi, All! > > I would like to start discussion about distributed scheduling. > > So, Ignite already has a module "ignite-schedule" that provide API for > LOCAL

Re: Ignite Teamcity email notifications

t; 'builds > > containing my changes'). > > > > Best Regards, > > Dmitriy Pavlov > > > > > > чт, 29 июн. 2017 г. в 21:21, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > >> Dmitry, I don't think ign...@apache.org is a valid email add

Re: Ignite Teamcity email notifications

Dmitry, I don't think ign...@apache.org is a valid email address. Why creating a mailing list for TC is not a good option? On Thu, Jun 29, 2017 at 8:17 AM, Dmitry Pavlov wrote: > Hi Igniters, > > I want to set up a email notifications from the public Teamcity about >

Re: Ignite Persistent Store: Ready for merge?

My vote would be to prepare the donation for the 2.1 release. It is been out for about 1.5 months and the community was given enough time to familiarize with the code. Denis has also conducted a well-attended community webinar explaining the donated code in detail. If there are no objections,

Re: golang client for Ignite

Denis, Perhaps adding the same level of support for Golang as we have for .NET or C++ would be asking too much. The reason we start a JVM in .NET and C++ is because we implemented the full Ignite API support, even including transactions and executing .NET closures on remote Java servers.

Re: daemon nodes

Daemon nodes are nodes that join the cluster, but do not store data or execute computations or perform any other of the Ignite API-based functionality. Visor node is a good example of a daemon node, because it wants to join the cluster and receive metrics from other nodes, but does not need to

Re: GridCacheAdapter#size() has O(n) complexity

On Mon, Jun 26, 2017 at 2:31 AM, Yakov Zhdanov wrote: > Guys, I see little inconsistency. Imagine user does 1000 puts with near > cache enabled. Then user does some gets() and size() returns 1000 + N, more > gets() and size() is 1000 + M. This is a bit weird. Can we have

Re: GridCacheAdapter#size() has O(n) complexity

Hm... why not just return the key count? Can we really have nulls in the near cache? On Fri, Jun 23, 2017 at 8:25 PM, Mikhail Cherkasov wrote: > Hi all, > > GridCacheAdapter#size() has O(n) complexity and this can lead for delays > during metric collection(

Re: Replace Cron4J with Quartz for ignite-schedule module.

Alexey, Can you remind what we use the schedule module in Ignite for? D. On Wed, Jun 21, 2017 at 7:26 AM, Alexey Kuznetsov wrote: > Hi! > > 1) Cron4J is very old: > Latest Cron4j 2.2.5 released: *28-Dec-2011 * > Latest Quarz 2.3.0 released: *20-Apr-2017* > > 2) Not

Re: Cassandra configuration SO question

Igor, which Igor are you asking? (no pun intended) Perhaps it makes sense to explicitly add him to CC. D. On Mon, Jun 19, 2017 at 4:17 PM, Igor Sapego wrote: > Igor, > > Can you please take a look at this question at SO? > >

Re: IgniteCache#localEvict method

keep the method and add some note in javadoc. > > Best Regards, > Ivan Rakov > > On 19.06.2017 17:01, Igor Sapego wrote: > >> What if user enables on-heap cache? >> >> Best Regards, >> Igor >> >> On Mon, Jun 19, 2017 at 3:34 AM, Dmitriy Setrakyan

Re: BinaryObjects and hashCode()

Igor, As far as I know, the hash code would be calculated on the client side and sent over within the binary format. Server does not calculate the hash code. D. On Tue, Jun 20, 2017 at 12:08 AM, Igor Rudyak wrote: > Hi, > > I am using simple POJO objects as key/value pair

Re: IgniteCache#localEvict method

Doesn't look useful to me. On Mon, Jun 19, 2017 at 1:03 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > Does the subj make sense in 2.0? Before this method could be used to evict > from on-heap memory to off-heap or swap. What are the semantics now? > > -Val >

Re: Persistence enabled for all caches

Jun 13, 2017 at 12:38 PM, Dmitriy Setrakyan <dsetrak...@apache.org > > > wrote: > > > +1 > > > > On Tue, Jun 13, 2017 at 1:13 AM, Yakov Zhdanov <yzhda...@apache.org> > > wrote: > > > > > Sam, > > > > > > Absolutely agree. Good catch! > > > > > > --Yakov > > > > > > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com >

Re: Transaction Deadlock Detection exception is not wrapped by the timeout exception

. > Agree, looks odd, but because of JSR107 we cannot throw any additional type of exception. Can we simplify by having one getCause() instead of double getCause().getCause()? > — > Denis > > > On Jun 13, 2017, at 4:43 PM, Dmitriy Setrakyan <dsetrak...@apache.org> >

Re: Transaction Deadlock Detection exception is not wrapped by the timeout exception

This looks a bit confusing. Why is it not enough to have this check: e.getCause().getCause() instanceof TransactionDeadlockException ? On Tue, Jun 13, 2017 at 4:40 PM, Denis Magda wrote: > Pardon me, copy pasted the catch block twice. This how the block looked > like in

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

> If you post on the website, with instructions on how to join, it will make it easier for the community. On top of that, some folks who are not currently in the community may join as well. > — > Denis > > > On Jun 13, 2017, at 11:36 AM, Dmitriy Setrakyan <dsetrak...@apache.org>

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

Denis, any chance you can post info for this webinar on the website? On Tue, Jun 13, 2017 at 10:05 AM, Denis Magda wrote: > Roman, > > Sure, will do. > > — > Denis > > > On Jun 12, 2017, at 8:35 PM, Roman Shtykh > wrote: > > > > Denis, > > Can you

Re: Persistence enabled for all caches

+1 On Tue, Jun 13, 2017 at 1:13 AM, Yakov Zhdanov wrote: > Sam, > > Absolutely agree. Good catch! > > --Yakov >

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

Hm... we have only 3 community members who are interested so far. Anyone else who may be willing to attend? On Fri, Jun 9, 2017 at 12:03 AM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote: > +1 > > Sergi > > 2017-06-08 23:03 GMT+03:00 Dmitriy Setrakyan <dsetrak...@

Re: Data compression in Ignite 2.0

moment I have a desire and time to be engaged in development of > compression feature in Ignite. > Let's use this opportunity :) > > 2017-06-09 5:36 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Igniters, > > > > I have never seen a single Ignite

Re: Persistent Store Stabilization for release

n stable-enough state to continue. > > 2017-06-07 5:47 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Tue, Jun 6, 2017 at 1:21 AM, Semyon Boikov <sboi...@gridgain.com> > > wrote: > > > > > Does anybody monitor TeamCity for ignite-5267

Re: Data compression in Ignite 2.0

an, that users should make decision what is more > > > > important > > > > > > for > > > > > > > > > them: > > > > > > > > > > > throutput or memory/net usage. > > > > > > > > >

Re: Deprecate IgniteConfiguration.marshaller and make it no-op!

On Thu, Jun 8, 2017 at 2:30 PM, Vladimir Ozerov wrote: > Denis, > > I think we should not provide distinction between "data grid", "compute > grid" and other use case. We should have consistent product which just > works. > > Anyway,I am OK to just deprecate these property

Re: Deprecate IgniteConfiguration.marshaller and make it no-op!

On Thu, Jun 8, 2017 at 1:16 PM, Denis Magda wrote: > > >> It means that the binary marshaller is irreplaceable for Ignite as for a > >> SQL database. Which is fine and makes total sense to me. > >> > >> However, for Ignite as for a Data Grid use case it should be supported. >

Re: [DISCUSS] Webinar for Ignite Persistent Store walk-through

+1 (I will attend) On Thu, Jun 8, 2017 at 1:02 PM, Konstantin Boudnik wrote: > That'd be great! Thank you! > -- > Take care, > Konstantin (Cos) Boudnik > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622 > > Disclaimer: Opinions expressed in this email are those of the

Re: Deprecate IgniteConfiguration.marshaller and make it no-op!

On Thu, Jun 8, 2017 at 10:54 AM, Denis Magda wrote: > Vovan, > > My 5 cents. > > It means that the binary marshaller is irreplaceable for Ignite as for a > SQL database. Which is fine and makes total sense to me. > > However, for Ignite as for a Data Grid use case it should be

Re: Key type name and value type name for CREATE TABLE

Vova, I am not sure I like the key type name the way it is. Can we add some separator between the table name and key name, like "_". To me "PERSON_KEY" reads a lot better than "PERSONKey". D. On Tue, Jun 6, 2017 at 4:00 AM, Sergi Vladykin wrote: > Unique suffix is a

Re: Only lateAffinityAssignment for 2.1

On Tue, Jun 6, 2017 at 4:23 AM, Semyon Boikov wrote: > Now affinity version is switched only when migration for new primaries > finishes for all partitions and for all caches. > Sounds great. Semyon, is there documentation that needs to be updated as well?

Re: Data compression in Ignite 2.0

> >> > >> I'll be glad to see your thougths. > >> > >> > >> 2017-05-15 19:18 GMT+03:00 Vyacheslav Daradur <daradu...@gmail.com>: > >> > >>> Dmitriy, > >>> > >>> I have ready prototype. I want t

Re: Writing a helper for KafkaStreamer

Thanks, Mike! Sounds great. On Tue, Jun 6, 2017 at 12:26 AM, Michael Griggs wrote: > We made a change [1] that required users to re-write code that uses > KafkaStreamer to initialise tuple extractors. The re-write is not > immediately obvious, and for simple use

Fwd: Persistent Distributed Store Metrics

On Mon, Jun 5, 2017 at 6:46 PM, Konstantin Boudnik wrote: > Wow, hold on - as far as I remember there was a VOTE to accept the > contribution of the code into the project _on a branch_. We haven't vetted > its > inclusion into the next release, We are still at the phase of

Re: "Review workflow" changes to prevent "broken review" issues.

Wow, we have 66 tickets waiting for review this is pretty bad. Something must definitely change. >From my side, having a contributor shop around for a reviewer is not really fair. However, I would support the idea of Apache Ignite community electing a person responsible to find reviewers for

Re: [DISCUSS] Ignite memory -> virtual memory

> > 2017-06-01 2:07 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Igniters, > > > > With the newly donated persistence functionality in Ignite, I have been > > struggling a bit on how to fit the notion of persistence into the current >

Re: Libs with BSD license in dependencies

BSD is an official ASF-friendly license. It is OK to have it in dependencies. https://www.apache.org/legal/resolved.html#criteria D. On Fri, Jun 2, 2017 at 12:12 AM, Vyacheslav Daradur wrote: > And where I can read about this agrement is relative to the Ignite project. >

Re: Persistent Store Stabilization for release

On Fri, Jun 2, 2017 at 6:46 AM, Alexey Goncharuk wrote: > Dmitriy, > > The original idea behind moving persistence to a separate module was > easiness of review and the fact that it is likely that in the future it > will have some external dependencies. I guess we

Re: Summary of SQL changes in 2.1

0. > > > > On Thu, Jun 1, 2017 at 12:17 PM, Sergi Vladykin < > sergi.vlady...@gmail.com> > > wrote: > > > >> I think it makes sense to reserve IGNITE schema for future use as well. > >> > >> 2017-06-01 0:26 GMT+03:00 Dmitriy Setrakyan <dsetr

Re: contention on DataStructure creation/removing

t;> locks, because they >> prevent partition map exchange and as result don't allow new nodes join >> cluster. >> >> Throughput plot without any changes: >> >> [image: Inline image 1] >> >> the same plot with patched ignite: >> >>

Re: Expose SqlQueryFields flags as SQL hints

Vova, what custom params are you suggestion? Can you be more specific? How should they look in SQL? On Fri, Jun 2, 2017 at 8:06 AM, Sergi Vladykin wrote: > To be clear I mean not to add some creative stuff under Ignite mode, but > instead add generic hints in H2

Re: nested SQL sub-queries with non-collocated joins

On Thu, Jun 1, 2017 at 1:07 PM, Sergi Vladykin wrote: > If you don't see an exception then it must be supported. This is the whole > point of this exception, right? > Exception is just to enforce the constraint. We still must clearly document what is supported.

Re: nested SQL sub-queries with non-collocated joins

On Thu, Jun 1, 2017 at 12:32 PM, Sergi Vladykin wrote: > I guess it must work the following way: > > If distributed joins are enabled we can try to prove that the subquery is > collocated, if we can't then try to rewrite it, if we can't, then throw an > exception. > >

Re: nested SQL sub-queries with non-collocated joins

problems here: > > 1. We will not be able to rewrite all the queries. > 2. We should not rewrite queries like this by default because this will > have a noticeable performance penalty for correctly collocated subqueries. > Probably we will need some flag for that. > >

Re: Persistent Store Stabilization for release

ldTypeStatusDiv> > [3] Ignite OutOfMemory > <http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_ > IgnitePdsOutOfMemory_Ignite20Tests=ignite-5267= > buildTypeStatusDiv> > > On Thu, Jun 1, 2017 at 1:24 AM, Dmitriy Setrakyan <dsetrak...@apache.org>

Re: contention on DataStructure creation/removing

Won't it be confusing from a user stand point to have multiple data structures with the same name? Also, what is the performance impact of this change? D. On Wed, May 31, 2017 at 8:23 AM, Semyon Boikov wrote: > Hi Mikhail, > > As far as I remember for some reason we

Re: Persistent Store Stabilization for release

Thanks Denis. I also would like to encourage to post all the stabilization updates for the donated branch here. This will help the community to get familiar with the new code and functionality. In addition, everyone in the community should feel free to peruse through the code in this branch and

Re: Summary of SQL changes in 2.1

Vladmir, Thanks for the detailed email. My comments are inline... On Wed, May 31, 2017 at 11:21 AM, Vladimir Ozerov wrote: > Folks, > > Let me summarize all recent changes to our SQL engine which are important > from user perspective. Please think of them and let me know

Re: Persistent Distributed Store Metrics

yncTime(); > > public long getCheckpointingTotalPagesNumber(); > > public long[] getCheckpointingPagesByTypeNumber(); > > public long getCheckpointingCopiedOnWritePagesNumber(); > } > > Comments on the name of non released methods are welcomed. > > — > Denis &

Re: ALTER TABLE command support

I think a fully functional ALTER TABLE command may be hard to implement, as it includes changes of columns, types, constraints, etc... We should take a gradual approach here and implement this command by phases. I would propose that in the first phase we simply add the capability to add and

nested SQL sub-queries with non-collocated joins

Igniters (specifically Sergi), It has come to my attention today that nested sub-select statements, when used in combination with non-collocated joins do not work properly in Ignite. So a query like this, where A, B, and C are all stored in Partitioned caches and are **not** collocated at all,

Re: Persistent Distributed Store Metrics

o separate memory policy related metrics from the WAL or Checkpoint related metrics. How about we put them all together and have clear method names? > > — > Denis > > > On May 30, 2017, at 2:39 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > >

Re: Persistent Distributed Store Metrics

On Tue, May 30, 2017 at 1:22 PM, Denis Magda wrote: > I’m afraid that in the future we might need to add non WAL related metrics > under this interface. This is why it might make sense to keep the name > generic. > Hm... I am not sure we are going to have any other components

Re: Persistent Distributed Store Metrics

; > >>public double getWalFsyncAverage(); > >> > >>//checkpoint-related metrics > >>public double getCpTime(); > >> > >>public double getCpFsyncTime(); > >> > >>public long getCpTotalPages(); > >> > >>

Re: Persistent Distributed Store Metrics

Several questions: 1. What is "getWalFsyncAverage()"? Is it time? If yes, then it should be consistent with other time metrics, and should be called "getWalFsyncAverageTime()" 2. I see "getPagesOnDisk()", should we also have "getPagesInMemory()"? 3. Also, how about WAL total pages

Re: Persistent Store example fails with NPE

the persistent > store (simply ignore it if it’s defined in a client’s configuration). > Denis, are you absolutely 100% sure that there is no way to configure normal cache on the client nodes? If yes, then I agree with you. > Sounds reasonable? > > > — > Denis > > > On

Re: Persistent Store example fails with NPE

ehavior with persistence enabled. > > — > Denis > > > On May 26, 2017, at 11:46 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > Denis, > > > > I think I misunderstand the issue. How do we do it for caches? Caches are > > onl

Re: Reason for disabling @QuerySqlField and @AffinityKeyMapped annotations on methods

allers any more. > Agree, but let's Deprecate it, not remove. пт, 26 мая 2017 г. в 21:49, Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Fri, May 26, 2017 at 8:29 AM, Igor Rudyak <irud...@gmail.com> wrote: > > > > > If binary objects is the only option

Re: Reason for disabling @QuerySqlField and @AffinityKeyMapped annotations on methods

voze...@gridgain.com> wrote: > > Igor, > > One more reason why we disallowed both annotations on methods is that > binary objects doesn't have "method" concept, it only has fields. As binary > mode is the default one it doesn't make sense to allow these annotations

Re: Persistent Store example fails with NPE

e client side? What happened in your case was a mistake and you should have received a proper exception. I am simply suggesting that in the odd case that someone does need it, we provide proper error message explaining exactly what needs to be done. Why not? > > On May 26, 2017, at 11:02 AM, Dm

Re: AffinityKeyMapper

On Fri, May 26, 2017 at 8:48 AM, Sergi Vladykin wrote: > Guys, > > As I see we did not drop AffinityKeyMapper for 2.0. > > May be lets at least deprecate it? > I think we must. Any objections?

Re: Persistent Store example fails with NPE

I don't like ignoring any configuration, but I do agree that enabling persistence on the client side seems odd. Can we just fix the exception message to clearly state that client mode requires all explicit configuration for such and such functionality? D. On Fri, May 26, 2017 at 10:34 AM, Sergey

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,

Re: Inefficient approach to executing remote SQL queries

nnections. With a client > who connects and disconnects quickly, and frequently, a 30-second plus > connection time is not workable. > > Mike > > On 23 May 2017 6:51 pm, "Dmitriy Setrakyan" <dsetrak...@apache.org> wrote: > > > Why do we turn off the conne

Re: Inefficient approach to executing remote SQL queries

Why do we turn off the connections, once established? Why not keep them open, until an endpoint explicitly closes them? On Tue, May 23, 2017 at 2:16 AM, Sergi Vladykin wrote: > Michael, > > I see your point. I think it must not be too hard to start asynchronously >

Re: [VOTE] Accept Contribution of Ignite Persistent Store

+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 with the vote. If the vote is declined, then we will toss the branch. I believe that once this feature is fully

Re: SqlFields query result does not expose fields metadata.

I cannot find a ticket for it. Has it been filed? On Fri, May 19, 2017 at 12:38 AM, Vladimir Ozerov wrote: > Ah, got it. Then I am ok with the change as well. > > On Fri, May 19, 2017 at 9:24 AM, Sergi Vladykin > wrote: > > > Nope, the proposal

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dnik > > > On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan > <dsetrak...@apache.org> wrote: > > Cos, Roman, > > > > This has nothing to do with any deadlines, but rather with an easier and > > more efficient process. > > > > I am no

Re: Session Replication Update on spring boot platform

Hi Rishi, I think the best way is to file a ticket in Ignite Jira with your findings. This ticket does not seem tremendously difficult, so hopefully someone from the community will pick it up. All we need to do is to take our existing Web Session Clustering [1][2] code and port it to work with

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

egrate, etc. In > this sense, I agree with Dmitriy. The natural fit seems to be a branch in > this case. > > If we just focus on whether to accept the donation and place the code into > a separate branch –without pressure to release for 2.1, just a vision to do > so– would there be co

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Cos, Roman, This has nothing to do with any deadlines, but rather with an easier and more efficient process. I am not sure how keeping the code in a separate code base is better for the community than keeping it in a separate Apache Ignite branch, where we can integrate it into Ignite CI

Re: A feedback on WebConsole

Thanks Denis! Always nice to hear that our community is growing :) On Thu, May 18, 2017 at 5:40 PM, Denis Magda wrote: > Had a pleasure to present Ignite at ApacheCon. In addition to the positive > feedback I received at the show here is the one spotted in twitter: >

Re: SQL usability issue: unclear exception when a key of a wrong type is used

Vova, Sergi, Any chance we can provide a proper error message in the exception? D. On Wed, May 17, 2017 at 8:50 PM, Denis Magda wrote: > Sergi, Vovan, > > One of Ignite users struggled with an SQL issue and asked me to help him > troubleshooting it. The root of the issue

Re: Apache Ignite 2.1 scope

ncy does not look important to me, we can reschedule it for > > later versions. > > > > On Thu, May 11, 2017 at 12:01 PM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > >> Vyacheslav, I think it is worth the research, but you should al

Re: Data compression in Ignite 2.0

Vyacheslav, I think it is a bit premature to provide a PR without getting a community consensus on the dev list. Please allow some time for the community to respond. D. On Mon, May 15, 2017 at 6:36 AM, Vyacheslav Daradur wrote: > I created the ticket:

Re: 10X decrease in performance with Ignite 2.0.0

Chris, After looking at your code, the only slow down that may have occurred between 1.9 and 2.0 is the actual cache "get(...)" operation. As you may already know, Ignite 2.0 has moved data off-heap completely, so we do not cache data in the deserialized form any more, by default. However, you

Re: Apache Ignite 2.1 scope

compression for string fileds. > > I'm researching the new page-memory architecture as applied to by-page > compression. > > 2017-05-11 11:30 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > On Thu, May 11, 2017 at 12:44 AM, Vyacheslav Daradur < >

Re: Apache Ignite 2.1 scope

On Thu, May 11, 2017 at 12:44 AM, Vyacheslav Daradur wrote: > Denis, > > The described roadmap looks great! > > Additional, I vote for introducing an ability (OOTB) to store objects in a > cache in a compressed form. > This will allow to store more data at the cost of

Re: dynamic cache creation question

Alexey, I am not sure I understand the question. This message is obviously necessary. Can you clarify? D. On Thu, May 4, 2017 at 2:19 AM, ALEKSEY KUZNETSOV wrote: > Hello, Igntrs! > When node dinamically creates new cache it sends > GridDhtPartitionsSingleMessage to

Re: joining exchange

On Wed, Apr 26, 2017 at 1:06 PM, ALEKSEY KUZNETSOV wrote: > Hi, Igntrs! > When new node joins topology, it sends join TcpDiscoveryJoinRequestMessage > to arbitrary node N1. > If N1 is not coordinator, then it will resend to all nodes. > > Why doesn't N1 send the

Re: Cluster metrics - review for PageMemory

Is there a way to provide such metrics for a specific memory policy? On Tue, Apr 25, 2017 at 4:53 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Igniters, > > Since we moved to the PageMemory architecture, several ClusterMetrics > methods became questionable, so I would like to

Re: Improve binary enum handling

L. > > On Tue, Apr 25, 2017 at 3:06 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Vladimir, can you please share your thoughts here? > > > > On Mon, Apr 24, 2017 at 5:21 PM, Sergi Vladykin < > sergi.vlady...@gmail.com> > > wrote: > &g

Re: Improve binary enum handling

gt; CREATE TABLE person ( > > name text, > > current_mood mood > > ); > > > > We will do the same at some point. That is, in future users will register > > enums from SQL, not from native API or configuration. > > > > Vladimir. > > > > On Mon

Re: SQL usability: catalogs, schemas and tables

Vladimir, great suggestions. Can you please make an umbrella ticket with sub-tasks, so we can tackle some of them for 2.1? D. On Mon, Apr 24, 2017 at 5:28 PM, Sergi Vladykin wrote: > Yes, we need to move on making Ignite work as any usual SQL db. > > But please avoid

Re: Null cache names

Can we just use the name "default" in such cases? On Mon, Apr 24, 2017 at 6:33 AM, Seliverstov Igor wrote: > Dear Igniters, > > Seems we have almost the same issue with Memcached protocol. > > There is an ability to define a cache name via operation extras message > part (

Re: Improve binary enum handling

H2 > part, but Ignite's part is not ready yet and is managed in IGNITE-4575 [1]. > Ticket you mentioned was an umbrella. > > [1] https://issues.apache.org/jira/browse/IGNITE-4575 > > On Mon, Apr 24, 2017 at 4:28 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Vl

Re: Improve binary enum handling

Vladimir, I am very confused. I thought we already had resolved this issue in this ticket: https://issues.apache.org/jira/browse/IGNITE-3595 Can you clarify? D. On Mon, Apr 24, 2017 at 5:58 AM, Vladimir Ozerov wrote: > Igniters, > > Currently we have limited support of

Re: Windows XP support

Agree, let's drop XP support. D. On Fri, Apr 21, 2017 at 8:03 AM, Pavel Tupitsyn wrote: > I don't think we should bother with supporting 16 year old discontinued OS. > Vista support has also ended (just 10 days ago). > > We should put Windows 7 there as the oldest

Re: Page Memory behavior with default memory policy

nce TC > passes, I will merge the changes, should not take too long, so hopefully, > the change will make it to the release. > > 2017-04-20 20:40 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > How long will it take to make the memory expandable? Can it be done for

Re: Apache Ignite Nabble is Down

Denis, I think it is working now. Can you check? On Thu, Apr 20, 2017 at 5:48 PM, Denis Magda wrote: > Igniters, > > Nabble no longer aggregates our discussions. The latest discussions are > dated by April 19th. > http://apache-ignite-developers.2346864.n4.nabble.com < >

Re: Tickets for work

Denis, can you publish these tickets on the Ignite website? On Thu, Apr 20, 2017 at 10:40 AM, Denis Magda wrote: > Nikita, > > Please find more tickets below: > https://issues.apache.org/jira/browse/IGNITE-2190 < > https://issues.apache.org/jira/browse/IGNITE-2190> >

Re: Page Memory behavior with default memory policy

How long will it take to make the memory expandable? Can it be done for 2.0? On Thu, Apr 20, 2017 at 5:25 AM, Sergey Chugunov <sergey.chugu...@gmail.com> wrote: > Dmitriy, > > Replied in the ticket. > > Thanks, > Sergey. > > On Wed, Apr 19, 2017 at 10:20

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <c...@apache.org> wrote: > On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote: > > > > Would a standard SGA suffice here? > > > > I believe that ASF guidelines suggest that a discussion should happen &

Re: Deprecate CacheConfiguration.setIndexedTypes

Vladimir, I am not sure I understand the issue here. Why would the Example 1 result in an exception? On Wed, Apr 19, 2017 at 1:22 PM, Vladimir Ozerov wrote: > Igniters, > > I'd like to propose to deprecate infamous CacheConfiguration.setIndexedT > ypes > method. It has

Re: Allow only one SQL table per cache

Can we make cache-per-table a requirement only for CREATE TABLE command? Not sure why would we have to prohibit the current behavior. On Wed, Apr 19, 2017 at 4:15 PM, Denis Magda wrote: > Alex F., > > Once we introduce true “schema name” as a part of DDL activities this will

Re: Page Memory behavior with default memory policy

without having to use verbose syntax of > *memoryPolicyConfiguration > *section. > > Any thoughts on this? > > Thanks, > Sergey. > > > > On Tue, Apr 18, 2017 at 12:12 PM, Dmitriy Setrakyan <dsetrak...@apache.org > > > wrote: > > > On Tue, Apr 18, 2017 at 2:

Re: Remove IGFS map-reduce in 2.0

Vladimir, I am against removing any public APIs in general. Why not deprecate it, especially if it does not have any maintenance overhead? We should clear explain the new alternative to this API in Javadoc. On Wed, Apr 19, 2017 at 2:47 AM, Vladimir Ozerov wrote: > Nobody

<    4   5   6   7   8   9   10   11   12   13   >