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
