Sergey, I do agree with you that Ignite’s REST API implementation has to be revisited. Your concerns sound reasonable. But personally I wouldn’t rush trying to release it under 2.0 because NodeJS won’t be a part of this release while it can propose additional requirements to the next generation of REST API implementation.
Does it make sense to you? — Denis > On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: > > Vova, > > There are more issues than processing (String, String) only: we can't > process JSON objects as values, current implementation doesn't follow > general RESTfull API requirements. > Moreover we're still have no connectors for PHP, Python and other popular > languages for web development of LAMP market and REST API is a single way > get access to Apache Ignite. > > On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > >> Denis, >> >> Very good catch! Our REST API in ir is current appearance are virtually >> useless because it only operates on strings. We'd better to design the new >> one.with blackjack and etc.. >> >> On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda <dma...@gridgain.com> wrote: >> >>> Basically, we can have two versions of the REST API if we want to care >>> about the compatibility and remove the old one (deprecated) at some point >>> of time. Moreover, NodeJS feature [1] can highly influence on the next >>> generation of our REST API implementation. So I wouldn’t introduce the >> next >>> version of REST API implementation before NodeJS component is done. >>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-961 >>> >>> — >>> Denis >>> >>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <skoz...@gridgain.com> >> wrote: >>>> >>>> I agree with Alexey. >>>> >>>> The key point is a chance to don't care for compatibility. >>>> >>>> >>>> >>>> On Thu, Sep 8, 2016 at 9:56 AM, Alexey Kuznetsov < >>> akuznet...@gridgain.com> >>>> wrote: >>>> >>>>> Just my opinion. If we move this to 2.1 that will result that we will >>> have >>>>> to support 2 versions of REST APIs. >>>>> In Ignite 2.0 we could break compatibility and redesign REST API from >>>>> scratch. >>>>> >>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dma...@gridgain.com> >>> wrote: >>>>> >>>>>> I would move it to 2.1 or 2.2. >>>>>> >>>>>> — >>>>>> Denis >>>>>> >>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan < >> dsetrak...@apache.org> >>>>>> wrote: >>>>>>> >>>>>>> Sergey, I don't think we can fit redesigning of HTTP/REST into our >> 2.0 >>>>>>> release. The 2.0 already looks pretty packed. Perhaps we should plan >>> it >>>>>> for >>>>>>> the release after, like 2.1? >>>>>>> >>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov <skoz...@gridgain.com >>> >>>>>> wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> I suppose we should redesign HTTP REST API. We've a dozen issues >>>>> around >>>>>> the >>>>>>>> REST implementation and the provided functionality is very limited >>> and >>>>>>>> doesn't follow last changes for Ignite. The most suitable ticket is >>>>>>>> IGNITE-1774 >>>>>>>> REST API should be implemented using Jersey >>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but probably >> we >>>>>> need >>>>>>>> to >>>>>>>> have a root ticket for that. >>>>>>>> >>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan < >>>>>> dsetrak...@apache.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. It is >>>>>>>>> definitely an important release for us and good supervision is >> going >>>>> to >>>>>>>> be >>>>>>>>> very helpful. >>>>>>>>> >>>>>>>>> I have looked at the tickets and the list seems nice. I would also >>>>> add >>>>>> a >>>>>>>>> ticket about migration of the JTA dependency to Geronimo as well, >>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to do >> it >>>>>> prior >>>>>>>>> to 2.0. >>>>>>>>> >>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793 >>>>>>>>> >>>>>>>>> D. >>>>>>>>> >>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda <dma...@gridgain.com> >>>>>> wrote: >>>>>>>>> >>>>>>>>>> Community, >>>>>>>>>> >>>>>>>>>> Let me take a role of the release manager for Apache Ignite 2.0 >> and >>>>>>>>>> coordinate the process. >>>>>>>>>> >>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be released >>> by >>>>>>>> the >>>>>>>>>> end of the year. This sounds like a good practice to make a major >>>>>>>> release >>>>>>>>>> once a year. I would suggest us following the same rule. >>>>>>>>>> >>>>>>>>>> Actual we have more than 3 month for development and I’ve prepare >>>>> the >>>>>>>>> wiki >>>>>>>>>> page that contains tickets that are required to be released in >> 2.0 >>>>> and >>>>>>>>> that >>>>>>>>>> are optional >>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/ >>>>> Apache+Ignite+2.0 >>>>>>>>>> >>>>>>>>>> Proposed release date is December 23rd, 2016. >>>>>>>>>> >>>>>>>>>> The tickets that are required for the release basically break the >>>>>>>>>> compatibility and we postpone fixing them in minor release or >> they >>>>>>>> bring >>>>>>>>>> significant improvements into the product. Please review the >> page, >>>>>>>>> provide >>>>>>>>>> your comments and assign the tickets on yourself if you’re ready >> to >>>>>>>> work >>>>>>>>> on >>>>>>>>>> them. >>>>>>>>>> >>>>>>>>>> — >>>>>>>>>> Denis >>>>>>>>>> >>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko < >>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> There is one more use case where several types per cache can be >>>>>>>> useful >>>>>>>>> (I >>>>>>>>>>> know that it's utilized by some of our users). The use case is >> the >>>>>>>>>>> following: transactional updates with write-behind and foreign >> key >>>>>>>>>>> constraints on the database. In case data within transaction is >>>>>>>>>> collocated >>>>>>>>>>> and all types are in the same cache, it works, because there is >>>>> only >>>>>>>>> one >>>>>>>>>>> write-behind queue. Once we split different types into different >>>>>>>>> caches, >>>>>>>>>>> there is no guarantee that objects will be written in the proper >>>>>>>> order >>>>>>>>>> and >>>>>>>>>>> that the constraints will not be violated. >>>>>>>>>>> >>>>>>>>>>> However, I think this is not a very clean way to achieve the >>>>> result. >>>>>>>>>>> Probably we should just provide better support for this use case >>> in >>>>>>>>> 2.0. >>>>>>>>>>> Basically, we somehow need to allow to share a single >> write-behind >>>>>>>>> queue >>>>>>>>>>> between different caches. >>>>>>>>>>> >>>>>>>>>>> Any thoughts? >>>>>>>>>>> >>>>>>>>>>> -Val >>>>>>>>>>> >>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan < >>>>>>>>>> dsetrak...@apache.org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov < >>>>>>>> skoz...@gridgain.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Alexey >>>>>>>>>>>>> >>>>>>>>>>>>> You're right. Of course I meant growth of caches number. >>>>>>>>>>>>> >>>>>>>>>>>>> I see a few points here: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. If a grid used by various applications the cache names may >>>>>>>> overlap >>>>>>>>>>>> (like >>>>>>>>>>>>> "accounts") and the application needs to use prefixed names >> and >>>>>>>> etc. >>>>>>>>>>>>> 2. For clear or destory caches I need to know their names (or >>>>>>>> iterate >>>>>>>>>>>> over >>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For >>>>>>>>> destroy/clear >>>>>>>>>>>>> caches belonging to same group we will do it by single >> operation >>>>>>>>>> without >>>>>>>>>>>>> knowledge of cache names. >>>>>>>>>>>>> 3. Cache group can have cache attributes which will be >> inherited >>>>>>>> by a >>>>>>>>>>>> cache >>>>>>>>>>>>> created in that group (like eviction policy or cache mode). >>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it >>>>> applicable >>>>>>>>> for >>>>>>>>>>>>> regular caches as well. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, as >>>>>>>> proposed >>>>>>>>>> by >>>>>>>>>>>> Sergi, solves a different problem of having too many SQL >> schemas >>>>> due >>>>>>>>> to >>>>>>>>>> too >>>>>>>>>>>> many different caches. I think Sergi proposed a good solution >> for >>>>>>>> it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov < >>>>>>>>>>>> akuznet...@gridgain.com >>>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of "reduce"? >>>>>>>>>>>>>> >>>>>>>>>>>>>> How grouping will help? >>>>>>>>>>>>>> To do some operation, for example, clear on group of cashes >> at >>>>>>>> once? >>>>>>>>>>>>>> >>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" < >>>>>>>>>>>> skoz...@gridgain.com> >>>>>>>>>>>>>> написал: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I mean not only SQL features for caches. Single type per >> cache >>>>>>>>>>>>> definitely >>>>>>>>>>>>>>> reduces number of caches for regular user and grouping >> caches >>>>>>>> will >>>>>>>>>>>> help >>>>>>>>>>>>>> to >>>>>>>>>>>>>>> manage caches in grid. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin < >>>>>>>>>>>>>> sergi.vlady...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm aware of this issue. My plan was to allow setting the >>> same >>>>>>>>>>>> schema >>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> to different caches using CacheConfiguration. >>>>> setSqlSchema(...). >>>>>>>>>>>> This >>>>>>>>>>>>>> way >>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>> will have separate caches but from SQL point of view >>>>> respective >>>>>>>>>>>>> tables >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> reside in the same schema. No need to introduce new >> concepts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sergi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov < >>>>> skoz...@gridgain.com >>>>>>>>> : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> HI >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Due to approach to disable to store more than one type per >>>>>>>> cache >>>>>>>>>>>>> the >>>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>>>> use becomes similar the table use for databases. >>>>>>>>>>>>>>>>> So I suppose would be good to introduce a >>>>>>>> database/schema-similar >>>>>>>>>>>>>>> concept >>>>>>>>>>>>>>>>> for caches. It may be implemented as a non-default >> behavior >>>>> for >>>>>>>>>>>>>>> backward >>>>>>>>>>>>>>>>> compatibility. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Sat, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan < >>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov < >>>>>>>>>>>>>>>>> akuznet...@gridgain.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I remember couple more thing for 2.0 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> How about to drop **ignite-scalar** module in Ignite >> 2.0? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Why? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> And may be drop **ignite-spark-2.10** module support as >> of >>>>>>>>>>>>>>> **Spark** >>>>>>>>>>>>>>>> 2 >>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>> on **scala 2.11**. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I would drop it only if it is difficult to support. Do we >>>>> know >>>>>>>>>>>>> what >>>>>>>>>>>>>>>> kind >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>>> impact will it have on the community? Anyone is still >> using >>>>>>>>>>>> 2.10? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda < >>>>>>>>>>>>>> dma...@gridgain.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Let’s add this [1] issue to the list because it >> requires >>>>>>>>>>>>>>>> significant >>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>> on the side of metrics SPI. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3495 >> < >>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/IGNITE-3495> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> — >>>>>>>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov < >>>>>>>>>>>>>>> yzhda...@apache.org> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Not yet. The thing is that our recent experience >> showed >>>>>>>>>>>>> that >>>>>>>>>>>>>> it >>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>> very good idea to go with caches. E.g. when you try to >>>>>>>>>>>>>>>> deserialize >>>>>>>>>>>>>>>>>>> inside >>>>>>>>>>>>>>>>>>>>> continuous query listener on client side it implicitly >>>>>>>>>>>>> calls >>>>>>>>>>>>>>>>>>> cache.get() >>>>>>>>>>>>>>>>>>>>> which in turn may cause deadlock under some >>>>>>>>>>>> circumstances. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> --Yakov >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2016-08-02 2:41 GMT+03:00 Dmitriy Setrakyan < >>>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov < >>>>>>>>>>>>>>>>> yzhda...@apache.org> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> One more point. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I insist on stop using marshaller and meta caches >> but >>>>>>>>>>>>>> switch >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> spreading >>>>>>>>>>>>>>>>>>>>>>> this info via custom discovery events. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Do we have a ticket explaining why this needs to be >>>>>>>>>>>> done? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> --Yakov >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan < >>>>>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < >>>>>>>>>>>>>>>>>>> yzhda...@apache.org> >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Guys, I think we can also split event notification >>>>>>>>>>>> for >>>>>>>>>>>>>> user >>>>>>>>>>>>>>>>>>> listeners >>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>> internal system listeners. I have been seeing a >> lot >>>>>>>>>>>> of >>>>>>>>>>>>>>> issues >>>>>>>>>>>>>>>>>>> caused >>>>>>>>>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>>>>>>>>>> some heavy or blocking operations in user-defined >>>>>>>>>>>>>>> listeners. >>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>>>>>>>>> block >>>>>>>>>>>>>>>>>>>>>>>>> internal component notification (e.g. on discovery >>>>>>>>>>>>> event) >>>>>>>>>>>>>>>>> causing >>>>>>>>>>>>>>>>>>>>>>>> topology >>>>>>>>>>>>>>>>>>>>>>>>> hangings. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sure. There are a lot of features being added. >> Would >>>>>>>>>>>> be >>>>>>>>>>>>>> nice >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>> assign >>>>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>>>>> release manager for Ignite 2.0 and document all the >>>>>>>>>>>>>>> discussed >>>>>>>>>>>>>>>>>>> features >>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>>> the Wiki. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> --Yakov >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk < >>>>>>>>>>>>>>>>>>>>>> alexey.goncha...@gmail.com >>>>>>>>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Folks, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Recently I have seen a couple of emails >> suggesting >>>>>>>>>>>>>>>>>>>>>> tasks/improvements >>>>>>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>>>>>>> we cannot do in 1.x releases due to API >>>>>>>>>>>> compatibility >>>>>>>>>>>>>>>> reasons, >>>>>>>>>>>>>>>>>> so >>>>>>>>>>>>>>>>>>>>>>> they >>>>>>>>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>>>>>>>>> postponed to 2.0. I would like to keep track of >>>>>>>>>>>> these >>>>>>>>>>>>>>> tasks >>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>>>>>>>> in >>>>>>>>>>>>>>>>>>>>>>>>>> our Jira to make sure we do not have anything >>>>>>>>>>>> obsolete >>>>>>>>>>>>>>> when >>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>> comes >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> next major version release. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> My question for now is how should we track such >>>>>>>>>>>> tasks? >>>>>>>>>>>>>>>> Should >>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>>>>>>> be a >>>>>>>>>>>>>>>>>>>>>>>>>> label, a parent task with subtasks, something >> else? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I would go with a label + release version. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> --AG >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Alexey Kuznetsov >>>>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sergey Kozlov >>>>>>>> GridGain Systems >>>>>>>> www.gridgain.com >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Alexey Kuznetsov >>>>> GridGain Systems >>>>> www.gridgain.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Sergey Kozlov >>>> GridGain Systems >>>> www.gridgain.com >>> >>> >> > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com
