Re: SqlFields query result does not expose fields metadata.

[Vladimir Ozerov]

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 was to have a FieldsQueryCursor interface with
> getFieldName(int column) method, may be + some other methods we will add
> later. This does not require any complex code modifications or exposing
> internal APIs.
>
> I'm not against new SQL API, it is a good idea, but it should not prevent
> us from making easy fixes in existing API when we need it.
>
> Sergi
>
> 2017-05-18 23:20 GMT+03:00 Vladimir Ozerov :
>
> > Proposal is about returning GridQueryFieldMetadata from QueryCursor,
> which
> > is internal interface. This interface is counterintuitive and is not
> ready
> > to be exposed to users. For example, it has method "typeName" which
> > actually returns table name. And has method "fieldTypeName" which returns
> > something like "java.lang.Object". Add "type name" concept from our
> > BinaryConfiguration/QueryEntity, which have different semantics, and you
> > end up with totally confused users on what "type name" means in Ignite.
> >
> > Let's do not expose strange things to users, and accurately create new
> > clean SQL API instead. There is no strong demand for this feature.
> >
> > On Thu, May 18, 2017 at 7:39 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com>
> > wrote:
> >
> > > It should not require any internals movement, it must be an easy fix.
> > >
> > > Sergi
> > >
> > > 2017-05-18 15:36 GMT+03:00 Vladimir Ozerov :
> > >
> > > > With all the changes to internals we made, new API can be created
> very
> > > > quickly somewhere around AI 2.2 or AI 2.3. Currently the whole API is
> > > > located in the wrong place, as it is bounded to cache. So the more we
> > add
> > > > now, the more we will deprecate in several months. Remember, that
> this
> > > > feature will require not only new interface, but moving existing
> > > *internal*
> > > > metadata classes to public space. These classes were never designed
> to
> > be
> > > > exposed to users in the first place.
> > > >
> > > > This is why I am strongly against this change at the moment. No need
> to
> > > > make already outdated and complex API even more complex without
> strong
> > > > demand from users.
> > > >
> > > > On Thu, May 18, 2017 at 3:29 PM, Pavel Tupitsyn <
> ptupit...@apache.org>
> > > > wrote:
> > > >
> > > > > I agree that this change makes sense.
> > > > > With complex queries it may be non-trivial to get the right column
> by
> > > > index
> > > > > from results.
> > > > > With metadata user no longer needs to care about result column
> order,
> > > and
> > > > > refactorings are easier.
> > > > >
> > > > > Pavel
> > > > >
> > > > > On Thu, May 18, 2017 at 2:36 PM, Sergi Vladykin <
> > > > sergi.vlady...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I believe we will not see this new SQL API soon. It is not even
> in
> > > > design
> > > > > > stage.
> > > > > >
> > > > > > The change proposed by Andrey is very simple and our users will
> > > benefit
> > > > > > from it right away.
> > > > > >
> > > > > > I see no reasons to disallow this change.
> > > > > >
> > > > > > Sergi
> > > > > >
> > > > > > 2017-05-18 12:35 GMT+03:00 Vladimir Ozerov  >:
> > > > > >
> > > > > > > Result set metadata is exposed to JDBC and ODBC drivers because
> > it
> > > is
> > > > > > > required by JDBC specification and lot's external applications
> > use
> > > > it.
> > > > > I
> > > > > > do
> > > > > > > not see big demand for this feature in native SQL, where user
> > > > normally
> > > > > > > knows the model. Another point is that with changes introduced
> in
> > > > > recent
> > > > > > > versions (DML, DDL, shared schemas), we need brand new native
> SQL
> > > > API,
> > > > > as
> > > > > > > current IgniteCache.query() cannot conveniently reflect current
> > and
> > > > > > planned
> > > > > > > Ignite capabilities.
> > > > > > >
> > > > > > > For this reason I do not think we should do proposed change.
> > > Instead,
> > > > > we
> > > > > > > should add metadata retrieval to new SQL API.
> > > > > > >
> > > > > > > Vladimir.
> > > > > > >
> > > > > > > On Thu, May 18, 2017 at 12:19 PM, Andrey Mashenkov <
> > > > > > > andrey.mashen...@gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi Igniters,
> > > > > > > >
> > > > > > > > When user run Sql query via JDBC, he can get fields metadata
> > > (field
> > > > > > > names,
> > > > > > > > its types and etc.) from ResultSet.
> > > > > > > > With IgniteCache.query method he gets some QueryCursor
> > > > > implementation,
> > > > > > > but
> > > > > > > > QueryCursor interface doesn't have any methods for this.
> > > > > > > >
> > > > > > > > For now, the only way to get metadata is try to cast result
> to
> > > > > internal
> > > > > > > > QueryCursorImpl class.
> > > > > > > >
> > > > > > > > I think it should break nothing if we overload
> > > > > > > > IgniteCache.query(SqlFieldsQuery q) return type to a new
> > > > > > > FieldsQueryCursor
> > > > > > > > int

Re: No direct way to download Ignite Web Agent

[Alexey Kuznetsov]

Prachi,

We added "Download Web Agent" button on right top corner.
Please, try it.

On Thu, Apr 20, 2017 at 1:27 AM, Prachi Garg  wrote:

> Somewhere in the header would be more visible; I would prefer that.
>
> On Wed, Apr 19, 2017 at 12:37 AM, Alexey Kuznetsov 
> wrote:
>
> > Prachi,
> >
> > I think we could add such link in "User" menu just after "Getting
> started"
> > item.
> >
> > Or, may be, as some icon on header?
> >
> > Vica, do you have any UI/UX suggestion for this?
> >
> > On Wed, Apr 19, 2017 at 12:46 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > Prachi, I completely agree. We should provide a way to download the web
> > > agent, along with installation instructions.
> > >
> > > Alexey K, can you comment?
> > >
> > > D.
> > >
> > > On Tue, Apr 18, 2017 at 4:16 PM, Prachi Garg 
> wrote:
> > >
> > > > Engineers,
> > > >
> > > > I realized that from the Web Console there is no direct way to
> download
> > > > Ignite Web Agent. The only way to download it is by going to either
> > > Model,
> > > > Monitoring, or Queries page (It's odd that to download the web agent,
> > you
> > > > have to go to model -> import from db-> and then download when
> > prompted).
> > > > Since Ignite web agent is required for almost everything on the Web
> > > > Console, shouldn't we have an option to download it from somewhere in
> > the
> > > > top menu or side menu?
> > > >
> > > > -Prachi
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>



-- 
Alexey Kuznetsov

Re: Changing cache name when using Redis protocol

[Yakov Zhdanov]

Roman, your description seems fine to me. I don't like CLIENT SETNAME. This
may confuse redis users as well.

Why do you say that we will have only 8 databases. As far as I remember
there are 16 by default and this is configurable and can be increased as
well. Can you please check this?

To get access to per-connection meta you will need to add
"addMeta/meta/removeMeta" methods to
org.apache.ignite.internal.processors.rest.request.GridRestRequest to
provide access to org.apache.ignite.internal.util.nio.GridNioSession's meta
related methods or to attributes' related methods of HttpSession in
depending on where request is created..

--Yakov

Re: waiting for partition release question

[ALEKSEY KUZNETSOV]

If we acquired a lock and a new node is joining cluster, should it wait for
lock release?
May be it could proceed joining ?
The question comes from my ticket
https://issues.apache.org/jira/browse/IGNITE-2671

чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk :

> Hi Aleksey,
>
> The main purpose of this method is to wait for all ongoing updates
> (transactional and atomic), initiated on the previous topology version, to
> finish to prevent inconsistencies during rebalancing and to prevent two
> different simultaneous owners of the same lock.
>
> We will be adding documentation pages on Apache Ignite wiki which will
> explain transactions mechanics in greater detail.
>
> Hope this helps,
> AG
>
> 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Hi Igntrs!
> > What is the point of waiting partition release in the end of
> > GridDhtPartitionsExchangeFuture#init() method ?
> > In what scenarious do we need it ?
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: waiting for partition release question

[Дмитрий Рябов]

May be let second node to finish join and enter the ring, but start
rebalance after all lock will be released.

2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV :

> If we acquired a lock and a new node is joining cluster, should it wait for
> lock release?
> May be it could proceed joining ?
> The question comes from my ticket
> https://issues.apache.org/jira/browse/IGNITE-2671
>
> чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk :
>
> > Hi Aleksey,
> >
> > The main purpose of this method is to wait for all ongoing updates
> > (transactional and atomic), initiated on the previous topology version,
> to
> > finish to prevent inconsistencies during rebalancing and to prevent two
> > different simultaneous owners of the same lock.
> >
> > We will be adding documentation pages on Apache Ignite wiki which will
> > explain transactions mechanics in greater detail.
> >
> > Hope this helps,
> > AG
> >
> > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > Hi Igntrs!
> > > What is the point of waiting partition release in the end of
> > > GridDhtPartitionsExchangeFuture#init() method ?
> > > In what scenarious do we need it ?
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[jira] [Created] (IGNITE-5260) JDBC Driver: implement SQLWarning supportion

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-5260:


 Summary: JDBC Driver: implement SQLWarning supportion
 Key: IGNITE-5260
 URL: https://issues.apache.org/jira/browse/IGNITE-5260
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.0
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.1






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1559: IGNITE-4712 Memory leaks in PageMemory

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1559


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1672: MemoryMetrics to monitor how PageMemories perform...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1672


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1758: IGNITE-4534: Implement offheap eviction policies ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1758


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1781: Ignite 4950

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1781


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1756: IGNITE-4930

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1756


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1788: IGNITE-4952 swap/unswap functionality was removed

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1788


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: waiting for partition release question

[Alexey Goncharuk]

As I described before, one of the reasons behind the waiting is to switch
primary nodes to prevent two simultaneous lock owners.

Consider the following scenario:
* Client node c1 acquired a lock L1 on node A
* Topology changes and primary node for L1 is now new joined node B
* Client node c2 wants to acquire lock L1 and sends lock request to B
* Node B successfully grants the lock to c2 because it does not know about
the previous lock
*  Two threads now hold the lock

There is a theoretical possibility of transferring lock ownership
information during rebalancing, but this opens up whole lot new race
conditions and failover difficulties.


2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :

> May be let second node to finish join and enter the ring, but start
> rebalance after all lock will be released.
>
> 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > If we acquired a lock and a new node is joining cluster, should it wait
> for
> > lock release?
> > May be it could proceed joining ?
> > The question comes from my ticket
> > https://issues.apache.org/jira/browse/IGNITE-2671
> >
> > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk  >:
> >
> > > Hi Aleksey,
> > >
> > > The main purpose of this method is to wait for all ongoing updates
> > > (transactional and atomic), initiated on the previous topology version,
> > to
> > > finish to prevent inconsistencies during rebalancing and to prevent two
> > > different simultaneous owners of the same lock.
> > >
> > > We will be adding documentation pages on Apache Ignite wiki which will
> > > explain transactions mechanics in greater detail.
> > >
> > > Hope this helps,
> > > AG
> > >
> > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Hi Igntrs!
> > > > What is the point of waiting partition release in the end of
> > > > GridDhtPartitionsExchangeFuture#init() method ?
> > > > In what scenarious do we need it ?
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>

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

[Raúl Kripalani]

Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate
additional components to the Ignite ecosystem.

IIUC:

   1) GG implemented PDS for a commercial customer, but it is now being
donated to the community => I assume GG has obtained clearance from that
customer first.

   2) It appears that PDS is a module of Ignite, but changes are required
to the core in the existing codebase for the integration to work => Correct?

   3) We use SemVer [1], and there have been talks about potentially
merging this into 2.1, rather than 3.x. => Is it safe to assume that
integrating the PDS will not lead to any *breaking changes* in APIs?

   4) I believe the VOTE to accept the donation should be *decoupled* from
any VOTEs –or decisions– on *what* to do with the donation and *when* to do
it. Although it's sane and healthy to discuss the future of the donation
inside its new home, ultimately there should be no time pressure by the
donor with regards to the ultimate destination of their donation.

   5) Normally the code belonging to the donation is first put in
"quarantine" inside the codebase, i.e. a separate repo or a separate
branch, where the community can review, test, peruse, integrate, 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 consensus?

[1] http://semver.org/

Cheers,
Raúl.


On Fri, May 19, 2017 at 2:36 AM, Dmitriy Setrakyan 
wrote:

> 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 process, run tests, stabilize, all while
> the community is getting familiar with it. Keeping the code base outside of
> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
> Moreover, if the code is in a separate Ignite branch, we can get the
> community help to work on it and discuss issues on the dev list.
>
> I would propose to move the code to a separate branch in Apache Ignite
> right now, especially given that the paperwork has already been taken care
> of. We can still decide within the Ignite community not to accept it down
> the road, in which case we can toss away the branch.
>
> Would you agree with this approach?
>
> D.
>
> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik  wrote:
>
> > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
> > wrote:
> > > Well, here's the issue with "simple move from private repo". This is a
> > > huge chunk of code. And while employees of Gridgain are quite familiar
> > > with it (or so I presume), the rest of the community is not. I, for
> > > one, don't consider that the fact it has been tested and integrated
> > > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
> > > criteria.
> >
> > Cos is absolutely correct here. Strong +1 to the above.
> >
> > > I am sorry that I have to repeat this after 1.5 years after project's
> > > graduation from the Incubator. However, I, personally and otherwise,
> > > feel like a community process of creating software should be thought
> > > through in the spirit of the community, rather than "release dates" or
> > > "feature richness". Which means that the community has to be on board
> > > with the decisions like this. And "on board" doesn't mean "majority of
> > > the votes" as we, fortunately, aren't playing in democracy @apache.
> > > Release dates are relevant to an entity, building and selling
> > > products. in Apache we're are working on projects, and while releases
> > > are important here, they convey a very different meaning.
> >
> > Which brings me to a related question: what exactly needs to be released
> > on this aggressive schedule and who is a beneficiary of this release?
> >
> > What I am trying to say is this: if GirdGain has a product delivery
> > deadline -- the
> > company can go ahead and release its product with whatever features it
> > needs to.
> >
> > But I'm with Cos -- the community has to be given time to get comfortable
> > with
> > the code base if for nothing else but for licensing implications.
> >
> > Thanks,
> > Roman.
> >
>

Re: waiting for partition release question

[ALEKSEY KUZNETSOV]

Now i see. So, may be i should drop the ticket and pick smth else ?

пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk :

> As I described before, one of the reasons behind the waiting is to switch
> primary nodes to prevent two simultaneous lock owners.
>
> Consider the following scenario:
> * Client node c1 acquired a lock L1 on node A
> * Topology changes and primary node for L1 is now new joined node B
> * Client node c2 wants to acquire lock L1 and sends lock request to B
> * Node B successfully grants the lock to c2 because it does not know about
> the previous lock
> *  Two threads now hold the lock
>
> There is a theoretical possibility of transferring lock ownership
> information during rebalancing, but this opens up whole lot new race
> conditions and failover difficulties.
>
>
> 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :
>
> > May be let second node to finish join and enter the ring, but start
> > rebalance after all lock will be released.
> >
> > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > If we acquired a lock and a new node is joining cluster, should it wait
> > for
> > > lock release?
> > > May be it could proceed joining ?
> > > The question comes from my ticket
> > > https://issues.apache.org/jira/browse/IGNITE-2671
> > >
> > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> > >
> > > > Hi Aleksey,
> > > >
> > > > The main purpose of this method is to wait for all ongoing updates
> > > > (transactional and atomic), initiated on the previous topology
> version,
> > > to
> > > > finish to prevent inconsistencies during rebalancing and to prevent
> two
> > > > different simultaneous owners of the same lock.
> > > >
> > > > We will be adding documentation pages on Apache Ignite wiki which
> will
> > > > explain transactions mechanics in greater detail.
> > > >
> > > > Hope this helps,
> > > > AG
> > > >
> > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > Hi Igntrs!
> > > > > What is the point of waiting partition release in the end of
> > > > > GridDhtPartitionsExchangeFuture#init() method ?
> > > > > In what scenarious do we need it ?
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: waiting for partition release question

[Alexey Goncharuk]

Well,

I don't have any clear plan for now on how to approach this issue, so if I
were you, I would pick something else :)

How about this one: https://issues.apache.org/jira/browse/IGNITE-5110? This
issue bugs us on TC, it is pretty important and there is quite enough
understanding on what to do.

2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV :

> Now i see. So, may be i should drop the ticket and pick smth else ?
>
> пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk :
>
> > As I described before, one of the reasons behind the waiting is to switch
> > primary nodes to prevent two simultaneous lock owners.
> >
> > Consider the following scenario:
> > * Client node c1 acquired a lock L1 on node A
> > * Topology changes and primary node for L1 is now new joined node B
> > * Client node c2 wants to acquire lock L1 and sends lock request to B
> > * Node B successfully grants the lock to c2 because it does not know
> about
> > the previous lock
> > *  Two threads now hold the lock
> >
> > There is a theoretical possibility of transferring lock ownership
> > information during rebalancing, but this opens up whole lot new race
> > conditions and failover difficulties.
> >
> >
> > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :
> >
> > > May be let second node to finish join and enter the ring, but start
> > > rebalance after all lock will be released.
> > >
> > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > If we acquired a lock and a new node is joining cluster, should it
> wait
> > > for
> > > > lock release?
> > > > May be it could proceed joining ?
> > > > The question comes from my ticket
> > > > https://issues.apache.org/jira/browse/IGNITE-2671
> > > >
> > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > > >
> > > > > Hi Aleksey,
> > > > >
> > > > > The main purpose of this method is to wait for all ongoing updates
> > > > > (transactional and atomic), initiated on the previous topology
> > version,
> > > > to
> > > > > finish to prevent inconsistencies during rebalancing and to prevent
> > two
> > > > > different simultaneous owners of the same lock.
> > > > >
> > > > > We will be adding documentation pages on Apache Ignite wiki which
> > will
> > > > > explain transactions mechanics in greater detail.
> > > > >
> > > > > Hope this helps,
> > > > > AG
> > > > >
> > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > Hi Igntrs!
> > > > > > What is the point of waiting partition release in the end of
> > > > > > GridDhtPartitionsExchangeFuture#init() method ?
> > > > > > In what scenarious do we need it ?
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: Changing cache name when using Redis protocol

[Roman Shtykh]

Yakov,
Thank you for the pointers! Let's implement it with SELECT then, with 
'redis-ignite-internal-cache-0' as a default one.
Sorry, I was wrong about the number of databases, just remembered there was a 
limit. I should have had to recheck.
-- Roman




On Friday, May 19, 2017 6:29 PM, Yakov Zhdanov  wrote:
 

 Roman, your description seems fine to me. I don't like CLIENT SETNAME. This
may confuse redis users as well.

Why do you say that we will have only 8 databases. As far as I remember
there are 16 by default and this is configurable and can be increased as
well. Can you please check this?

To get access to per-connection meta you will need to add
"addMeta/meta/removeMeta" methods to
org.apache.ignite.internal.processors.rest.request.GridRestRequest to
provide access to org.apache.ignite.internal.util.nio.GridNioSession's meta
related methods or to attributes' related methods of HttpSession in
depending on where request is created..

--Yakov


   

Re: waiting for partition release question

[ALEKSEY KUZNETSOV]

Ok, i pick it

пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk :

> Well,
>
> I don't have any clear plan for now on how to approach this issue, so if I
> were you, I would pick something else :)
>
> How about this one: https://issues.apache.org/jira/browse/IGNITE-5110?
> This
> issue bugs us on TC, it is pretty important and there is quite enough
> understanding on what to do.
>
> 2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Now i see. So, may be i should drop the ticket and pick smth else ?
> >
> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk  >:
> >
> > > As I described before, one of the reasons behind the waiting is to
> switch
> > > primary nodes to prevent two simultaneous lock owners.
> > >
> > > Consider the following scenario:
> > > * Client node c1 acquired a lock L1 on node A
> > > * Topology changes and primary node for L1 is now new joined node B
> > > * Client node c2 wants to acquire lock L1 and sends lock request to B
> > > * Node B successfully grants the lock to c2 because it does not know
> > about
> > > the previous lock
> > > *  Two threads now hold the lock
> > >
> > > There is a theoretical possibility of transferring lock ownership
> > > information during rebalancing, but this opens up whole lot new race
> > > conditions and failover difficulties.
> > >
> > >
> > > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :
> > >
> > > > May be let second node to finish join and enter the ring, but start
> > > > rebalance after all lock will be released.
> > > >
> > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > If we acquired a lock and a new node is joining cluster, should it
> > wait
> > > > for
> > > > > lock release?
> > > > > May be it could proceed joining ?
> > > > > The question comes from my ticket
> > > > > https://issues.apache.org/jira/browse/IGNITE-2671
> > > > >
> > > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > > >
> > > > > > Hi Aleksey,
> > > > > >
> > > > > > The main purpose of this method is to wait for all ongoing
> updates
> > > > > > (transactional and atomic), initiated on the previous topology
> > > version,
> > > > > to
> > > > > > finish to prevent inconsistencies during rebalancing and to
> prevent
> > > two
> > > > > > different simultaneous owners of the same lock.
> > > > > >
> > > > > > We will be adding documentation pages on Apache Ignite wiki which
> > > will
> > > > > > explain transactions mechanics in greater detail.
> > > > > >
> > > > > > Hope this helps,
> > > > > > AG
> > > > > >
> > > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com
> > > > >:
> > > > > >
> > > > > > > Hi Igntrs!
> > > > > > > What is the point of waiting partition release in the end of
> > > > > > > GridDhtPartitionsExchangeFuture#init() method ?
> > > > > > > In what scenarious do we need it ?
> > > > > > > --
> > > > > > >
> > > > > > > *Best Regards,*
> > > > > > >
> > > > > > > *Kuznetsov Aleksey*
> > > > > > >
> > > > > >
> > > > > --
> > > > >
> > > > > *Best Regards,*
> > > > >
> > > > > *Kuznetsov Aleksey*
> > > > >
> > > >
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: waiting for partition release question

[ALEKSEY KUZNETSOV]

How could i reproduce the issue ?

пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV :

> Ok, i pick it
>
> пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk :
>
>> Well,
>>
>> I don't have any clear plan for now on how to approach this issue, so if I
>> were you, I would pick something else :)
>>
>> How about this one: https://issues.apache.org/jira/browse/IGNITE-5110?
>> This
>> issue bugs us on TC, it is pretty important and there is quite enough
>> understanding on what to do.
>>
>> 2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV :
>>
>> > Now i see. So, may be i should drop the ticket and pick smth else ?
>> >
>> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
>> alexey.goncha...@gmail.com>:
>> >
>> > > As I described before, one of the reasons behind the waiting is to
>> switch
>> > > primary nodes to prevent two simultaneous lock owners.
>> > >
>> > > Consider the following scenario:
>> > > * Client node c1 acquired a lock L1 on node A
>> > > * Topology changes and primary node for L1 is now new joined node B
>> > > * Client node c2 wants to acquire lock L1 and sends lock request to B
>> > > * Node B successfully grants the lock to c2 because it does not know
>> > about
>> > > the previous lock
>> > > *  Two threads now hold the lock
>> > >
>> > > There is a theoretical possibility of transferring lock ownership
>> > > information during rebalancing, but this opens up whole lot new race
>> > > conditions and failover difficulties.
>> > >
>> > >
>> > > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :
>> > >
>> > > > May be let second node to finish join and enter the ring, but start
>> > > > rebalance after all lock will be released.
>> > > >
>> > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com
>> > >:
>> > > >
>> > > > > If we acquired a lock and a new node is joining cluster, should it
>> > wait
>> > > > for
>> > > > > lock release?
>> > > > > May be it could proceed joining ?
>> > > > > The question comes from my ticket
>> > > > > https://issues.apache.org/jira/browse/IGNITE-2671
>> > > > >
>> > > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
>> > > alexey.goncha...@gmail.com
>> > > > >:
>> > > > >
>> > > > > > Hi Aleksey,
>> > > > > >
>> > > > > > The main purpose of this method is to wait for all ongoing
>> updates
>> > > > > > (transactional and atomic), initiated on the previous topology
>> > > version,
>> > > > > to
>> > > > > > finish to prevent inconsistencies during rebalancing and to
>> prevent
>> > > two
>> > > > > > different simultaneous owners of the same lock.
>> > > > > >
>> > > > > > We will be adding documentation pages on Apache Ignite wiki
>> which
>> > > will
>> > > > > > explain transactions mechanics in greater detail.
>> > > > > >
>> > > > > > Hope this helps,
>> > > > > > AG
>> > > > > >
>> > > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
>> > > alkuznetsov...@gmail.com
>> > > > >:
>> > > > > >
>> > > > > > > Hi Igntrs!
>> > > > > > > What is the point of waiting partition release in the end of
>> > > > > > > GridDhtPartitionsExchangeFuture#init() method ?
>> > > > > > > In what scenarious do we need it ?
>> > > > > > > --
>> > > > > > >
>> > > > > > > *Best Regards,*
>> > > > > > >
>> > > > > > > *Kuznetsov Aleksey*
>> > > > > > >
>> > > > > >
>> > > > > --
>> > > > >
>> > > > > *Best Regards,*
>> > > > >
>> > > > > *Kuznetsov Aleksey*
>> > > > >
>> > > >
>> > >
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>> >
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: waiting for partition release question

[Alexey Goncharuk]

GridCacheContinuousQueryConcurrentTest hangs from time to time on TC, so I
would first run this test on repeat locally to see how easy it is to
reproduce this.

2017-05-19 14:54 GMT+03:00 ALEKSEY KUZNETSOV :

> How could i reproduce the issue ?
>
> пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV :
>
> > Ok, i pick it
> >
> > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk  >:
> >
> >> Well,
> >>
> >> I don't have any clear plan for now on how to approach this issue, so
> if I
> >> were you, I would pick something else :)
> >>
> >> How about this one: https://issues.apache.org/jira/browse/IGNITE-5110?
> >> This
> >> issue bugs us on TC, it is pretty important and there is quite enough
> >> understanding on what to do.
> >>
> >> 2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV  >:
> >>
> >> > Now i see. So, may be i should drop the ticket and pick smth else ?
> >> >
> >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
> >> alexey.goncha...@gmail.com>:
> >> >
> >> > > As I described before, one of the reasons behind the waiting is to
> >> switch
> >> > > primary nodes to prevent two simultaneous lock owners.
> >> > >
> >> > > Consider the following scenario:
> >> > > * Client node c1 acquired a lock L1 on node A
> >> > > * Topology changes and primary node for L1 is now new joined node B
> >> > > * Client node c2 wants to acquire lock L1 and sends lock request to
> B
> >> > > * Node B successfully grants the lock to c2 because it does not know
> >> > about
> >> > > the previous lock
> >> > > *  Two threads now hold the lock
> >> > >
> >> > > There is a theoretical possibility of transferring lock ownership
> >> > > information during rebalancing, but this opens up whole lot new race
> >> > > conditions and failover difficulties.
> >> > >
> >> > >
> >> > > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :
> >> > >
> >> > > > May be let second node to finish join and enter the ring, but
> start
> >> > > > rebalance after all lock will be released.
> >> > > >
> >> > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV <
> >> alkuznetsov...@gmail.com
> >> > >:
> >> > > >
> >> > > > > If we acquired a lock and a new node is joining cluster, should
> it
> >> > wait
> >> > > > for
> >> > > > > lock release?
> >> > > > > May be it could proceed joining ?
> >> > > > > The question comes from my ticket
> >> > > > > https://issues.apache.org/jira/browse/IGNITE-2671
> >> > > > >
> >> > > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
> >> > > alexey.goncha...@gmail.com
> >> > > > >:
> >> > > > >
> >> > > > > > Hi Aleksey,
> >> > > > > >
> >> > > > > > The main purpose of this method is to wait for all ongoing
> >> updates
> >> > > > > > (transactional and atomic), initiated on the previous topology
> >> > > version,
> >> > > > > to
> >> > > > > > finish to prevent inconsistencies during rebalancing and to
> >> prevent
> >> > > two
> >> > > > > > different simultaneous owners of the same lock.
> >> > > > > >
> >> > > > > > We will be adding documentation pages on Apache Ignite wiki
> >> which
> >> > > will
> >> > > > > > explain transactions mechanics in greater detail.
> >> > > > > >
> >> > > > > > Hope this helps,
> >> > > > > > AG
> >> > > > > >
> >> > > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
> >> > > alkuznetsov...@gmail.com
> >> > > > >:
> >> > > > > >
> >> > > > > > > Hi Igntrs!
> >> > > > > > > What is the point of waiting partition release in the end of
> >> > > > > > > GridDhtPartitionsExchangeFuture#init() method ?
> >> > > > > > > In what scenarious do we need it ?
> >> > > > > > > --
> >> > > > > > >
> >> > > > > > > *Best Regards,*
> >> > > > > > >
> >> > > > > > > *Kuznetsov Aleksey*
> >> > > > > > >
> >> > > > > >
> >> > > > > --
> >> > > > >
> >> > > > > *Best Regards,*
> >> > > > >
> >> > > > > *Kuznetsov Aleksey*
> >> > > > >
> >> > > >
> >> > >
> >> > --
> >> >
> >> > *Best Regards,*
> >> >
> >> > *Kuznetsov Aleksey*
> >> >
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Fwd: [jira] [Commented] (IGNITE-4052) Add ability to set up users for MESOS

[Вадим Опольский]

Hello Prachi!

Have you seen the edits  in readme.io for Mesos Deployment page:
https://dash.readme.io/project/apacheignite/v2.0/suggested

Vadim Opolski



-- Forwarded message --
From: Denis Magda (JIRA) 
Date: 2017-05-15 23:02 GMT+03:00
Subject: [jira] [Commented] (IGNITE-4052) Add ability to set up users for
MESOS
To: vaopols...@gmail.com



[ https://issues.apache.org/jira/browse/IGNITE-4052?page=
com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=16011240#comment-16011240 ]

Denis Magda commented on IGNITE-4052:
-

[~pgarg], please review and apply the edits suggested by Vadim in readme.io
for Mesos Deployment page:
https://dash.readme.io/project/apacheignite/v2.0/suggested

> Add ability to set up users for MESOS
> -
>
> Key: IGNITE-4052
> URL: https://issues.apache.org/jira/browse/IGNITE-4052
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Affects Versions: 1.7
>Reporter: Nikolay Tikhonov
>Assignee: Prachi Garg
>Priority: Trivial
>
> In current implementation Ignite Mesos Framework connects to MESOS
cluster via current user. Need to add ability to configure this parameters
via system env properties. Also need to add properties for mesos role.
> See org/apache/ignite/mesos/IgniteFramework.java:537



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: waiting for partition release question

[ALEKSEY KUZNETSOV]

Don't you remember the day the test last failed?) Im trying to find it in
history of TC. Locally it doesn't fail

пт, 19 мая 2017 г. в 14:56, Alexey Goncharuk :

> GridCacheContinuousQueryConcurrentTest hangs from time to time on TC, so I
> would first run this test on repeat locally to see how easy it is to
> reproduce this.
>
> 2017-05-19 14:54 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > How could i reproduce the issue ?
> >
> > пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV  >:
> >
> > > Ok, i pick it
> > >
> > > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> > >
> > >> Well,
> > >>
> > >> I don't have any clear plan for now on how to approach this issue, so
> > if I
> > >> were you, I would pick something else :)
> > >>
> > >> How about this one: https://issues.apache.org/jira/browse/IGNITE-5110
> ?
> > >> This
> > >> issue bugs us on TC, it is pretty important and there is quite enough
> > >> understanding on what to do.
> > >>
> > >> 2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > >>
> > >> > Now i see. So, may be i should drop the ticket and pick smth else ?
> > >> >
> > >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
> > >> alexey.goncha...@gmail.com>:
> > >> >
> > >> > > As I described before, one of the reasons behind the waiting is to
> > >> switch
> > >> > > primary nodes to prevent two simultaneous lock owners.
> > >> > >
> > >> > > Consider the following scenario:
> > >> > > * Client node c1 acquired a lock L1 on node A
> > >> > > * Topology changes and primary node for L1 is now new joined node
> B
> > >> > > * Client node c2 wants to acquire lock L1 and sends lock request
> to
> > B
> > >> > > * Node B successfully grants the lock to c2 because it does not
> know
> > >> > about
> > >> > > the previous lock
> > >> > > *  Two threads now hold the lock
> > >> > >
> > >> > > There is a theoretical possibility of transferring lock ownership
> > >> > > information during rebalancing, but this opens up whole lot new
> race
> > >> > > conditions and failover difficulties.
> > >> > >
> > >> > >
> > >> > > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов :
> > >> > >
> > >> > > > May be let second node to finish join and enter the ring, but
> > start
> > >> > > > rebalance after all lock will be released.
> > >> > > >
> > >> > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV <
> > >> alkuznetsov...@gmail.com
> > >> > >:
> > >> > > >
> > >> > > > > If we acquired a lock and a new node is joining cluster,
> should
> > it
> > >> > wait
> > >> > > > for
> > >> > > > > lock release?
> > >> > > > > May be it could proceed joining ?
> > >> > > > > The question comes from my ticket
> > >> > > > > https://issues.apache.org/jira/browse/IGNITE-2671
> > >> > > > >
> > >> > > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
> > >> > > alexey.goncha...@gmail.com
> > >> > > > >:
> > >> > > > >
> > >> > > > > > Hi Aleksey,
> > >> > > > > >
> > >> > > > > > The main purpose of this method is to wait for all ongoing
> > >> updates
> > >> > > > > > (transactional and atomic), initiated on the previous
> topology
> > >> > > version,
> > >> > > > > to
> > >> > > > > > finish to prevent inconsistencies during rebalancing and to
> > >> prevent
> > >> > > two
> > >> > > > > > different simultaneous owners of the same lock.
> > >> > > > > >
> > >> > > > > > We will be adding documentation pages on Apache Ignite wiki
> > >> which
> > >> > > will
> > >> > > > > > explain transactions mechanics in greater detail.
> > >> > > > > >
> > >> > > > > > Hope this helps,
> > >> > > > > > AG
> > >> > > > > >
> > >> > > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
> > >> > > alkuznetsov...@gmail.com
> > >> > > > >:
> > >> > > > > >
> > >> > > > > > > Hi Igntrs!
> > >> > > > > > > What is the point of waiting partition release in the end
> of
> > >> > > > > > > GridDhtPartitionsExchangeFuture#init() method ?
> > >> > > > > > > In what scenarious do we need it ?
> > >> > > > > > > --
> > >> > > > > > >
> > >> > > > > > > *Best Regards,*
> > >> > > > > > >
> > >> > > > > > > *Kuznetsov Aleksey*
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > --
> > >> > > > >
> > >> > > > > *Best Regards,*
> > >> > > > >
> > >> > > > > *Kuznetsov Aleksey*
> > >> > > > >
> > >> > > >
> > >> > >
> > >> > --
> > >> >
> > >> > *Best Regards,*
> > >> >
> > >> > *Kuznetsov Aleksey*
> > >> >
> > >>
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: waiting for partition release question

[ALEKSEY KUZNETSOV]

oh, i've found

пт, 19 мая 2017 г. в 15:34, ALEKSEY KUZNETSOV :

> Don't you remember the day the test last failed?) Im trying to find it in
> history of TC. Locally it doesn't fail
>
> пт, 19 мая 2017 г. в 14:56, Alexey Goncharuk :
>
>> GridCacheContinuousQueryConcurrentTest hangs from time to time on TC, so I
>> would first run this test on repeat locally to see how easy it is to
>> reproduce this.
>>
>> 2017-05-19 14:54 GMT+03:00 ALEKSEY KUZNETSOV :
>>
>> > How could i reproduce the issue ?
>> >
>> > пт, 19 мая 2017 г. в 14:52, ALEKSEY KUZNETSOV > >:
>> >
>> > > Ok, i pick it
>> > >
>> > > пт, 19 мая 2017 г. в 14:39, Alexey Goncharuk <
>> alexey.goncha...@gmail.com
>> > >:
>> > >
>> > >> Well,
>> > >>
>> > >> I don't have any clear plan for now on how to approach this issue, so
>> > if I
>> > >> were you, I would pick something else :)
>> > >>
>> > >> How about this one:
>> https://issues.apache.org/jira/browse/IGNITE-5110?
>> > >> This
>> > >> issue bugs us on TC, it is pretty important and there is quite enough
>> > >> understanding on what to do.
>> > >>
>> > >> 2017-05-19 14:29 GMT+03:00 ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com
>> > >:
>> > >>
>> > >> > Now i see. So, may be i should drop the ticket and pick smth else ?
>> > >> >
>> > >> > пт, 19 мая 2017 г. в 13:20, Alexey Goncharuk <
>> > >> alexey.goncha...@gmail.com>:
>> > >> >
>> > >> > > As I described before, one of the reasons behind the waiting is
>> to
>> > >> switch
>> > >> > > primary nodes to prevent two simultaneous lock owners.
>> > >> > >
>> > >> > > Consider the following scenario:
>> > >> > > * Client node c1 acquired a lock L1 on node A
>> > >> > > * Topology changes and primary node for L1 is now new joined
>> node B
>> > >> > > * Client node c2 wants to acquire lock L1 and sends lock request
>> to
>> > B
>> > >> > > * Node B successfully grants the lock to c2 because it does not
>> know
>> > >> > about
>> > >> > > the previous lock
>> > >> > > *  Two threads now hold the lock
>> > >> > >
>> > >> > > There is a theoretical possibility of transferring lock ownership
>> > >> > > information during rebalancing, but this opens up whole lot new
>> race
>> > >> > > conditions and failover difficulties.
>> > >> > >
>> > >> > >
>> > >> > > 2017-05-19 12:52 GMT+03:00 Дмитрий Рябов > >:
>> > >> > >
>> > >> > > > May be let second node to finish join and enter the ring, but
>> > start
>> > >> > > > rebalance after all lock will be released.
>> > >> > > >
>> > >> > > > 2017-05-19 12:30 GMT+03:00 ALEKSEY KUZNETSOV <
>> > >> alkuznetsov...@gmail.com
>> > >> > >:
>> > >> > > >
>> > >> > > > > If we acquired a lock and a new node is joining cluster,
>> should
>> > it
>> > >> > wait
>> > >> > > > for
>> > >> > > > > lock release?
>> > >> > > > > May be it could proceed joining ?
>> > >> > > > > The question comes from my ticket
>> > >> > > > > https://issues.apache.org/jira/browse/IGNITE-2671
>> > >> > > > >
>> > >> > > > > чт, 18 мая 2017 г. в 20:05, Alexey Goncharuk <
>> > >> > > alexey.goncha...@gmail.com
>> > >> > > > >:
>> > >> > > > >
>> > >> > > > > > Hi Aleksey,
>> > >> > > > > >
>> > >> > > > > > The main purpose of this method is to wait for all ongoing
>> > >> updates
>> > >> > > > > > (transactional and atomic), initiated on the previous
>> topology
>> > >> > > version,
>> > >> > > > > to
>> > >> > > > > > finish to prevent inconsistencies during rebalancing and to
>> > >> prevent
>> > >> > > two
>> > >> > > > > > different simultaneous owners of the same lock.
>> > >> > > > > >
>> > >> > > > > > We will be adding documentation pages on Apache Ignite wiki
>> > >> which
>> > >> > > will
>> > >> > > > > > explain transactions mechanics in greater detail.
>> > >> > > > > >
>> > >> > > > > > Hope this helps,
>> > >> > > > > > AG
>> > >> > > > > >
>> > >> > > > > > 2017-05-18 16:50 GMT+03:00 ALEKSEY KUZNETSOV <
>> > >> > > alkuznetsov...@gmail.com
>> > >> > > > >:
>> > >> > > > > >
>> > >> > > > > > > Hi Igntrs!
>> > >> > > > > > > What is the point of waiting partition release in the
>> end of
>> > >> > > > > > > GridDhtPartitionsExchangeFuture#init() method ?
>> > >> > > > > > > In what scenarious do we need it ?
>> > >> > > > > > > --
>> > >> > > > > > >
>> > >> > > > > > > *Best Regards,*
>> > >> > > > > > >
>> > >> > > > > > > *Kuznetsov Aleksey*
>> > >> > > > > > >
>> > >> > > > > >
>> > >> > > > > --
>> > >> > > > >
>> > >> > > > > *Best Regards,*
>> > >> > > > >
>> > >> > > > > *Kuznetsov Aleksey*
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> > --
>> > >> >
>> > >> > *Best Regards,*
>> > >> >
>> > >> > *Kuznetsov Aleksey*
>> > >> >
>> > >>
>> > > --
>> > >
>> > > *Best Regards,*
>> > >
>> > > *Kuznetsov Aleksey*
>> > >
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>> >
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1974: IGNITE-4892 Support DML for thin client based JDB...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

https://github.com/apache/ignite/pull/1974

IGNITE-4892  Support DML for thin client based JDBC driver



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-4892

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1974.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 #1974


commit 3ce02a3331cfa38cdb29859b69d4a5cd5cfd6e5b
Author: tledkov-gridgain 
Date:   2017-04-26T14:42:16Z

IGNITE-4892: save the progress

commit 64ed8bdfe94ac01bd15f1e26a9b437ec13a511eb
Author: tledkov-gridgain 
Date:   2017-04-26T14:51:45Z

Merge branch '_master' into ignite-4892

commit 5e9a03cc36270d8bd6d4cc0eba800a9d23284988
Author: tledkov-gridgain 
Date:   2017-04-27T09:26:31Z

IGNITE-4892: save the progress

commit 7c394d1f79992a8e74a8bd021740e72732314e37
Author: tledkov-gridgain 
Date:   2017-04-27T15:36:31Z

IGNITE-4892: save the progress

commit 31cafbf1d4873aecafca5e7d49c6c6a2f27a53ef
Author: tledkov-gridgain 
Date:   2017-04-28T08:11:39Z

IGNITE-4892: save the progress

commit a6a3d1e34f70165fac1c2a8958a0a2060e83d0ae
Author: tledkov-gridgain 
Date:   2017-04-28T08:12:50Z

Merge branch '_master' into ignite-4892

commit 7dd7b7082b8831e649e634cfa2991db6a0512734
Author: tledkov-gridgain 
Date:   2017-05-02T08:05:50Z

IGNITE-4892: save the progress

commit 3f88d45fc0cdd9a579cf4483d062a8f5db4d6499
Author: tledkov-gridgain 
Date:   2017-05-19T12:56:27Z

Merge branch '_master' into ignite-4892

commit ecdd60d3cdf71b353c9edcd2e738b6dd2588ab37
Author: tledkov-gridgain 
Date:   2017-05-19T12:58:12Z

IGNITE-4892: save the progress

commit 11277385815bbbac9b3e78568c5962f866b03781
Author: tledkov-gridgain 
Date:   2017-05-19T12:58:40Z

Merge branch '_master' into ignite-4892

commit 075cc01aa4b885d26f41819b8d26459b5769a179
Author: tledkov-gridgain 
Date:   2017-05-19T13:00:35Z

IGNITE-4892: save the progress




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Message.directType

[Yury Babak]

Hi all!

I want to create new custom implementation of
org.apache.ignite.plugin.extensions.communication.Message and I want avoid
conflicts in message type. So did we have the list of all reserved types?

Thanks,
Yury



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Message-directType-tp17828.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Message.directType

[Ilya Lantukh]

Yury,

All message type IDs are listed in GridIoMessageFactory#create(...) method
in switch block. You can check there which IDs are still free.

On Fri, May 19, 2017 at 6:44 PM, Yury Babak  wrote:

> Hi all!
>
> I want to create new custom implementation of
> org.apache.ignite.plugin.extensions.communication.Message and I want avoid
> conflicts in message type. So did we have the list of all reserved types?
>
> Thanks,
> Yury
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Message-directType-tp17828.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>



-- 
Best regards,
Ilya

Re: Message.directType

[Yury Babak]

Thanks!



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Message-directType-tp17828p17830.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: No direct way to download Ignite Web Agent

[Prachi Garg]

Hi Alexey,

That's great! I checked it on GridGain deployment, it looks good. However,
I don't see it on my local deployment. Was it not part of 2.0 release?

-Prachi

On Fri, May 19, 2017 at 2:21 AM, Alexey Kuznetsov 
wrote:

> Prachi,
>
> We added "Download Web Agent" button on right top corner.
> Please, try it.
>
> On Thu, Apr 20, 2017 at 1:27 AM, Prachi Garg  wrote:
>
>> Somewhere in the header would be more visible; I would prefer that.
>>
>> On Wed, Apr 19, 2017 at 12:37 AM, Alexey Kuznetsov > >
>> wrote:
>>
>> > Prachi,
>> >
>> > I think we could add such link in "User" menu just after "Getting
>> started"
>> > item.
>> >
>> > Or, may be, as some icon on header?
>> >
>> > Vica, do you have any UI/UX suggestion for this?
>> >
>> > On Wed, Apr 19, 2017 at 12:46 PM, Dmitriy Setrakyan <
>> dsetrak...@apache.org
>> > >
>> > wrote:
>> >
>> > > Prachi, I completely agree. We should provide a way to download the
>> web
>> > > agent, along with installation instructions.
>> > >
>> > > Alexey K, can you comment?
>> > >
>> > > D.
>> > >
>> > > On Tue, Apr 18, 2017 at 4:16 PM, Prachi Garg 
>> wrote:
>> > >
>> > > > Engineers,
>> > > >
>> > > > I realized that from the Web Console there is no direct way to
>> download
>> > > > Ignite Web Agent. The only way to download it is by going to either
>> > > Model,
>> > > > Monitoring, or Queries page (It's odd that to download the web
>> agent,
>> > you
>> > > > have to go to model -> import from db-> and then download when
>> > prompted).
>> > > > Since Ignite web agent is required for almost everything on the Web
>> > > > Console, shouldn't we have an option to download it from somewhere
>> in
>> > the
>> > > > top menu or side menu?
>> > > >
>> > > > -Prachi
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Alexey Kuznetsov
>> >
>>
>
>
>
> --
> Alexey Kuznetsov
>

Re: Message.directType

[Alexey Goncharuk]

That's not entirely true, unfortunately. Note that there may be registered
a number of extensions, which may theoretically conflict with already
listed IDs. I think we should create some sort of lookup table and make
sure that there are no duplicates after all extensions are registered, this
will save us a lot of time during development.

Yury, would you mind filing a ticket?

2017-05-19 18:53 GMT+03:00 Yury Babak :

> Thanks!
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Message-directType-tp17828p17830.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

[GitHub] ignite pull request #1975: IGNITE-5113: Implemented basic distributed/local ...

[artemmalykh]

GitHub user artemmalykh opened a pull request:

https://github.com/apache/ignite/pull/1975

IGNITE-5113: Implemented basic distributed/local kmeans clusterizatio…

…n algorithm.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-5113

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1975.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 #1975


commit 48d8d73ca0744008cae09b6967d337d72fd2fa0e
Author: Artem Malykh 
Date:   2017-05-19T16:40:12Z

IGNITE-5113: Implemented basic distributed/local kmeans clusterization 
algorithm.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Persistent Distributed Store Metrics

[Denis Magda]

Dmitriy, 

I have some high level concerns.

Presently, Ignite already exposes memory/data related metrics via MemoryMetrics 
and CacheMetrics interface.

Looking at PersistentStoreMetrics interface I can’t get why methods like 
getMemorySize(), getPagesInMemory(), getPagesSizeInMemory(), etc. are NOT in 
MemoryMetrics interface.

Next, I wouldn’t make out PersistentStore*Cache*Metrics interface that contains 
a big subset of the methods from PersistentStoreMetric. There just should be 
some API call that either returns global metrics or cache specific ones. Plus, 
some of the methods might be added to existing CacheInterface. Why not.

I prefer to address this first. Guys, any other thoughts on this?

—
Denis

> On May 17, 2017, at 4:16 AM, Dmitriy Govorukhin 
>  wrote:
> 
> Folk,
> 
> As you know, ignite 2.1 will contain new module (pds), it will be
> provide ability to store data on disk. Let's discuss what type of
> metrics we need for this?
> I think it must be metrics per memory policy, per cache, checkpoint,
> and global metrics which will be aggregate all metrics.
> 
> I did sketch.
> 
> PersistentStoreMetrics.java
> 
> public interface PersistentStoreMetrics {
> 
>// Global metrics.
> 
>public long getMemorySize();
> 
>public long getDiskSize();
> 
>public long getPagesInMemory();
> 
>public long getPagesSizeInMemory();
> 
>public long getPagesOnDisk();
> 
>public long getPagesSizeOnDisk();
> 
>public long getFreePages();
> 
>public long getFreePagesSize();
> 
>public long getDirtyPages();
> 
>public long getDirtyPagesSize();
> 
>public long walLog();
> 
>public long walLogSize();
> 
>// Frequency.
> 
>public long getPagesRead();
> 
>public long getPagesWrite();
> 
>public long getFsync();
> 
>public long getWal();
> 
>public long getAverageWalFsyncTime();
> 
>// Per cache.
> 
>public PersistentStoreCacheMetrics cache(String name);
> 
>public PersistentStoreCacheMetrics cache(int cacheId);
> 
>// For last checkpoint.
> 
>public PersistentStoreCheckpointMetrics getLastCheckPoint();
> }
> 
 
> 
> PersistentStoreCacheMetrics.java
> 
> public interface PersistentStoreCacheMetrics {
> 
>public String name();
> 
>public double getFillFactor();
> 
>public double getFillFactor(int part);
> 
>public long getMemorySize();
> 
>public long getDiskSize();
> 
>public long getPagesInMemory();
> 
>public long getPagesSizeInMemory();
> 
>public long getPagesOnDisk();
> 
>public long getPagesSizeOnDisk();
> 
>public long getFreePages();
> 
>public long getFreePagesSize();
> 
>public long getDirtyPages();
> 
>public long getDirtyPagesSize();
> 
>public long getPagesRead();
> 
>public long getPagesWritten();
> }
> 
 
> 
> PersistentStoreCheckpointMetrics.java
> 
> public interface PersistentStoreCheckpointMetrics {
> 
>public long getTotalPages();
> 
>//TODO Page type is internal?
>public long[] pagesType();
> 
>public long getExecutingTime();
> 
>public long getFsyncTime();
> 
>public long getPagesCopyOnWrite();
> }

Session Replication Update on spring boot platform

[Rishi Yagnik]

Hello Val,

I tested out the session replication on spring boot cluster and here is the
result.

My finding were as follows with Ignite 2.0 on session replication and hope
that helps the team –

   - Spring Security Filters requires context to be set with Authentication
   object, later on when user authentication object is set on the ignite
   filter from Ignite cache, the spring security treat that as a new session
   just to prevent session fixation issue.
   - As spring security creates a new session and since there is no way to
   tell Ignite that user session has been changed, the user session is no good
   here despite the fact that user session holds by the ignite is a true
   session for that user.
   - Configuring web session filter does not work OOTB in spring boot
   platform, it require some additional tweaking in the code to make it work.


So in the nutshell, I would think having spring session on ignite platform
would support full session replication with spring boot platform.


Please note that we have 2 SB instances, serving request round robin via F5
( load balancers) supported by 2 node ignite cluster.

Any suggestions on how we want to conquer the issue ?

Thanks,

-- 
Rishi Yagnik

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

[Konstantin Boudnik]

Dmitriy,

no one has ever suggested to keep the code in a separate repository
(once the grant issues were sorted out). Not sure where you get this
impression. I don't think there's anything to argue about ;)

Cos


--
  Take care,
Konstantin (Cos) Boudnik


On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
 wrote:
> 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 process, run tests, stabilize, all while
> the community is getting familiar with it. Keeping the code base outside of
> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
> Moreover, if the code is in a separate Ignite branch, we can get the
> community help to work on it and discuss issues on the dev list.
>
> I would propose to move the code to a separate branch in Apache Ignite
> right now, especially given that the paperwork has already been taken care
> of. We can still decide within the Ignite community not to accept it down
> the road, in which case we can toss away the branch.
>
> Would you agree with this approach?
>
> D.
>
> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik  wrote:
>
>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
>> wrote:
>> > Well, here's the issue with "simple move from private repo". This is a
>> > huge chunk of code. And while employees of Gridgain are quite familiar
>> > with it (or so I presume), the rest of the community is not. I, for
>> > one, don't consider that the fact it has been tested and integrated
>> > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
>> > criteria.
>>
>> Cos is absolutely correct here. Strong +1 to the above.
>>
>> > I am sorry that I have to repeat this after 1.5 years after project's
>> > graduation from the Incubator. However, I, personally and otherwise,
>> > feel like a community process of creating software should be thought
>> > through in the spirit of the community, rather than "release dates" or
>> > "feature richness". Which means that the community has to be on board
>> > with the decisions like this. And "on board" doesn't mean "majority of
>> > the votes" as we, fortunately, aren't playing in democracy @apache.
>> > Release dates are relevant to an entity, building and selling
>> > products. in Apache we're are working on projects, and while releases
>> > are important here, they convey a very different meaning.
>>
>> Which brings me to a related question: what exactly needs to be released
>> on this aggressive schedule and who is a beneficiary of this release?
>>
>> What I am trying to say is this: if GirdGain has a product delivery
>> deadline -- the
>> company can go ahead and release its product with whatever features it
>> needs to.
>>
>> But I'm with Cos -- the community has to be given time to get comfortable
>> with
>> the code base if for nothing else but for licensing implications.
>>
>> Thanks,
>> Roman.
>>

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

[Konstantin Boudnik]

All great points, thank you Raúl!

+1
--
  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 author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Fri, May 19, 2017 at 4:08 AM, Raúl Kripalani  wrote:
> Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate
> additional components to the Ignite ecosystem.
>
> IIUC:
>
>1) GG implemented PDS for a commercial customer, but it is now being
> donated to the community => I assume GG has obtained clearance from that
> customer first.
>
>2) It appears that PDS is a module of Ignite, but changes are required
> to the core in the existing codebase for the integration to work => Correct?
>
>3) We use SemVer [1], and there have been talks about potentially
> merging this into 2.1, rather than 3.x. => Is it safe to assume that
> integrating the PDS will not lead to any *breaking changes* in APIs?
>
>4) I believe the VOTE to accept the donation should be *decoupled* from
> any VOTEs –or decisions– on *what* to do with the donation and *when* to do
> it. Although it's sane and healthy to discuss the future of the donation
> inside its new home, ultimately there should be no time pressure by the
> donor with regards to the ultimate destination of their donation.
>
>5) Normally the code belonging to the donation is first put in
> "quarantine" inside the codebase, i.e. a separate repo or a separate
> branch, where the community can review, test, peruse, integrate, 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 consensus?
>
> [1] http://semver.org/
>
> Cheers,
> Raúl.
>
>
> On Fri, May 19, 2017 at 2:36 AM, Dmitriy Setrakyan 
> wrote:
>
>> 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 process, run tests, stabilize, all while
>> the community is getting familiar with it. Keeping the code base outside of
>> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
>> Moreover, if the code is in a separate Ignite branch, we can get the
>> community help to work on it and discuss issues on the dev list.
>>
>> I would propose to move the code to a separate branch in Apache Ignite
>> right now, especially given that the paperwork has already been taken care
>> of. We can still decide within the Ignite community not to accept it down
>> the road, in which case we can toss away the branch.
>>
>> Would you agree with this approach?
>>
>> D.
>>
>> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik  wrote:
>>
>> > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
>> > wrote:
>> > > Well, here's the issue with "simple move from private repo". This is a
>> > > huge chunk of code. And while employees of Gridgain are quite familiar
>> > > with it (or so I presume), the rest of the community is not. I, for
>> > > one, don't consider that the fact it has been tested and integrated
>> > > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
>> > > criteria.
>> >
>> > Cos is absolutely correct here. Strong +1 to the above.
>> >
>> > > I am sorry that I have to repeat this after 1.5 years after project's
>> > > graduation from the Incubator. However, I, personally and otherwise,
>> > > feel like a community process of creating software should be thought
>> > > through in the spirit of the community, rather than "release dates" or
>> > > "feature richness". Which means that the community has to be on board
>> > > with the decisions like this. And "on board" doesn't mean "majority of
>> > > the votes" as we, fortunately, aren't playing in democracy @apache.
>> > > Release dates are relevant to an entity, building and selling
>> > > products. in Apache we're are working on projects, and while releases
>> > > are important here, they convey a very different meaning.
>> >
>> > Which brings me to a related question: what exactly needs to be released
>> > on this aggressive schedule and who is a beneficiary of this release?
>> >
>> > What I am trying to say is this: if GirdGain has a product delivery
>> > deadline -- the
>> > company can go ahead and release its product with whatever features it
>> > needs to.
>> >
>> > But I'm with Cos -- the community has to be given time to get comfortable
>> > with
>> > the code base if for nothing else but for licensing implications.
>> >
>> > Thanks,
>> > Roman.
>> >
>>

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

[Konstantin Boudnik]

Dmitriy,

no one has ever suggested to keep the code in a separate repository
(once the grant issues were sorted out). Not sure where you get this
impression. I don't think there's anything to argue about ;)
--
  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 author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
 wrote:
> 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 process, run tests, stabilize, all while
> the community is getting familiar with it. Keeping the code base outside of
> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
> Moreover, if the code is in a separate Ignite branch, we can get the
> community help to work on it and discuss issues on the dev list.
>
> I would propose to move the code to a separate branch in Apache Ignite
> right now, especially given that the paperwork has already been taken care
> of. We can still decide within the Ignite community not to accept it down
> the road, in which case we can toss away the branch.
>
> Would you agree with this approach?
>
> D.
>
> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik  wrote:
>
>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
>> wrote:
>> > Well, here's the issue with "simple move from private repo". This is a
>> > huge chunk of code. And while employees of Gridgain are quite familiar
>> > with it (or so I presume), the rest of the community is not. I, for
>> > one, don't consider that the fact it has been tested and integrated
>> > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
>> > criteria.
>>
>> Cos is absolutely correct here. Strong +1 to the above.
>>
>> > I am sorry that I have to repeat this after 1.5 years after project's
>> > graduation from the Incubator. However, I, personally and otherwise,
>> > feel like a community process of creating software should be thought
>> > through in the spirit of the community, rather than "release dates" or
>> > "feature richness". Which means that the community has to be on board
>> > with the decisions like this. And "on board" doesn't mean "majority of
>> > the votes" as we, fortunately, aren't playing in democracy @apache.
>> > Release dates are relevant to an entity, building and selling
>> > products. in Apache we're are working on projects, and while releases
>> > are important here, they convey a very different meaning.
>>
>> Which brings me to a related question: what exactly needs to be released
>> on this aggressive schedule and who is a beneficiary of this release?
>>
>> What I am trying to say is this: if GirdGain has a product delivery
>> deadline -- the
>> company can go ahead and release its product with whatever features it
>> needs to.
>>
>> But I'm with Cos -- the community has to be given time to get comfortable
>> with
>> the code base if for nothing else but for licensing implications.
>>
>> Thanks,
>> Roman.
>>

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

[Denis Magda]

Cos,

The folks just followed Roman’s suggestion:


So here's a set of steps you need to do:
   1. make code available some place on GitHub
   2. file and SGA with ASF pointing at a tag in that repo
   3. once both of these are done -- restart the discussion thread


Basically, if to take a look at the list of donations on this page [1] it’s up 
to a community to decide where to “incubate” a donation - on a private GitHub 
repo or in an ASF branch.

[1] http://incubator.apache.org/ip-clearance/index.html 


—
Denis

> On May 19, 2017, at 2:55 PM, Konstantin Boudnik  wrote:
> 
> Dmitriy,
> 
> no one has ever suggested to keep the code in a separate repository
> (once the grant issues were sorted out). Not sure where you get this
> impression. I don't think there's anything to argue about ;)
> --
>  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 author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
> 
> 
> On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
>  wrote:
>> 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 process, run tests, stabilize, all while
>> the community is getting familiar with it. Keeping the code base outside of
>> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
>> Moreover, if the code is in a separate Ignite branch, we can get the
>> community help to work on it and discuss issues on the dev list.
>> 
>> I would propose to move the code to a separate branch in Apache Ignite
>> right now, especially given that the paperwork has already been taken care
>> of. We can still decide within the Ignite community not to accept it down
>> the road, in which case we can toss away the branch.
>> 
>> Would you agree with this approach?
>> 
>> D.
>> 
>> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik  wrote:
>> 
>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
>>> wrote:
 Well, here's the issue with "simple move from private repo". This is a
 huge chunk of code. And while employees of Gridgain are quite familiar
 with it (or so I presume), the rest of the community is not. I, for
 one, don't consider that the fact it has been tested and integrated
 with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
 criteria.
>>> 
>>> Cos is absolutely correct here. Strong +1 to the above.
>>> 
 I am sorry that I have to repeat this after 1.5 years after project's
 graduation from the Incubator. However, I, personally and otherwise,
 feel like a community process of creating software should be thought
 through in the spirit of the community, rather than "release dates" or
 "feature richness". Which means that the community has to be on board
 with the decisions like this. And "on board" doesn't mean "majority of
 the votes" as we, fortunately, aren't playing in democracy @apache.
 Release dates are relevant to an entity, building and selling
 products. in Apache we're are working on projects, and while releases
 are important here, they convey a very different meaning.
>>> 
>>> Which brings me to a related question: what exactly needs to be released
>>> on this aggressive schedule and who is a beneficiary of this release?
>>> 
>>> What I am trying to say is this: if GirdGain has a product delivery
>>> deadline -- the
>>> company can go ahead and release its product with whatever features it
>>> needs to.
>>> 
>>> But I'm with Cos -- the community has to be given time to get comfortable
>>> with
>>> the code base if for nothing else but for licensing implications.
>>> 
>>> Thanks,
>>> Roman.
>>> 

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

[Dmitriy Setrakyan]

Hi Raul, thanks for jumping in! I agree on all points.

On Fri, May 19, 2017 at 4:08 AM, Raúl Kripalani 
wrote:

> Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate
> additional components to the Ignite ecosystem.
>
> IIUC:
>
>1) GG implemented PDS for a commercial customer, but it is now being
> donated to the community => I assume GG has obtained clearance from that
> customer first.
>
>2) It appears that PDS is a module of Ignite, but changes are required
> to the core in the existing codebase for the integration to work =>
> Correct?
>
>3) We use SemVer [1], and there have been talks about potentially
> merging this into 2.1, rather than 3.x. => Is it safe to assume that
> integrating the PDS will not lead to any *breaking changes* in APIs?
>
>4) I believe the VOTE to accept the donation should be *decoupled* from
> any VOTEs –or decisions– on *what* to do with the donation and *when* to do
> it. Although it's sane and healthy to discuss the future of the donation
> inside its new home, ultimately there should be no time pressure by the
> donor with regards to the ultimate destination of their donation.
>
>5) Normally the code belonging to the donation is first put in
> "quarantine" inside the codebase, i.e. a separate repo or a separate
> branch, where the community can review, test, peruse, integrate, 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 consensus?
>
> [1] http://semver.org/
>
> Cheers,
> Raúl.
>
>
> On Fri, May 19, 2017 at 2:36 AM, Dmitriy Setrakyan 
> wrote:
>
> > 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 process, run tests, stabilize, all while
> > the community is getting familiar with it. Keeping the code base outside
> of
> > Apache Ignite GIT makes it much more difficult to integrate or stabilize.
> > Moreover, if the code is in a separate Ignite branch, we can get the
> > community help to work on it and discuss issues on the dev list.
> >
> > I would propose to move the code to a separate branch in Apache Ignite
> > right now, especially given that the paperwork has already been taken
> care
> > of. We can still decide within the Ignite community not to accept it down
> > the road, in which case we can toss away the branch.
> >
> > Would you agree with this approach?
> >
> > D.
> >
> > On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik 
> wrote:
> >
> > > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
> > > wrote:
> > > > Well, here's the issue with "simple move from private repo". This is
> a
> > > > huge chunk of code. And while employees of Gridgain are quite
> familiar
> > > > with it (or so I presume), the rest of the community is not. I, for
> > > > one, don't consider that the fact it has been tested and integrated
> > > > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
> > > > criteria.
> > >
> > > Cos is absolutely correct here. Strong +1 to the above.
> > >
> > > > I am sorry that I have to repeat this after 1.5 years after project's
> > > > graduation from the Incubator. However, I, personally and otherwise,
> > > > feel like a community process of creating software should be thought
> > > > through in the spirit of the community, rather than "release dates"
> or
> > > > "feature richness". Which means that the community has to be on board
> > > > with the decisions like this. And "on board" doesn't mean "majority
> of
> > > > the votes" as we, fortunately, aren't playing in democracy @apache.
> > > > Release dates are relevant to an entity, building and selling
> > > > products. in Apache we're are working on projects, and while releases
> > > > are important here, they convey a very different meaning.
> > >
> > > Which brings me to a related question: what exactly needs to be
> released
> > > on this aggressive schedule and who is a beneficiary of this release?
> > >
> > > What I am trying to say is this: if GirdGain has a product delivery
> > > deadline -- the
> > > company can go ahead and release its product with whatever features it
> > > needs to.
> > >
> > > But I'm with Cos -- the community has to be given time to get
> comfortable
> > > with
> > > the code base if for nothing else but for licensing implications.
> > >
> > > Thanks,
> > > Roman.
> > >
> >
>

How to store Binary Object in Cassandra Backup Store

[fatih]

Hi 

I am working with BinaryObjects and i wanted to use Cassandra as a backup
store. However i could not manage. Could please explain how i can achieve
this.  

Persistence configuration i use is as below 




The error I get is as below 

2017-05-19 16:07:12,497 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: [14:07:12,493][SEVERE][flusher-0-#27%null%][CassandraCacheStore]
Failed to process 1 of 1 elements, during BULK_WRITE operation with
Cassandra
2017-05-19 16:07:12,497 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: class org.apache.ignite.IgniteException: Failed to execute Cassandra
BULK_WRITE operation
2017-05-19 16:07:12,497 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:262)
2017-05-19 16:07:12,497 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.writeAll(CassandraCacheStore.java:332)
2017-05-19 16:07:12,497 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.updateStore(GridCacheWriteBehindStore.java:685)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.applyBatch(GridCacheWriteBehindStore.java:618)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore.access$1700(GridCacheWriteBehindStore.java:69)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.flushCache(GridCacheWriteBehindStore.java:850)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.internal.processors.cache.store.GridCacheWriteBehindStore$Flusher.body(GridCacheWriteBehindStore.java:754)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at java.lang.Thread.run(Thread.java:745)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: Caused by: java.lang.IllegalArgumentException: Couldn't deserialize
instance of class 'org.apache.ignite.internal.binary.BinaryObjectImpl' using
PRIMITIVE strategy. Please use BLOB strategy for this case.
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindValues(PersistenceController.java:431)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.persistence.PersistenceController.bindKeyValue(PersistenceController.java:203)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:346)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.CassandraCacheStore$4.bindStatement(CassandraCacheStore.java:332)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: at
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:226)
2017-05-19 16:07:12,498 [dockerjava-netty-3-4] INFO  ignite@localhost -
STDERR: ... 8 more





--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/How-to-store-Binary-Object-in-Cassandra-Backup-Store-tp17827.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Session Replication Update on spring boot platform

[Dmitriy Setrakyan]

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 Spring Boot.

BTW, feel free to contribute it yourself if you have time.

[1] https://ignite.apache.org/use-cases/caching/web-session-clustering.html
[2] https://apacheignite-mix.readme.io/docs/web-session-clustering

D.

On Fri, May 19, 2017 at 11:43 AM, Rishi Yagnik 
wrote:

> Hello Val,
>
> I tested out the session replication on spring boot cluster and here is the
> result.
>
> My finding were as follows with Ignite 2.0 on session replication and hope
> that helps the team –
>
>- Spring Security Filters requires context to be set with Authentication
>object, later on when user authentication object is set on the ignite
>filter from Ignite cache, the spring security treat that as a new
> session
>just to prevent session fixation issue.
>- As spring security creates a new session and since there is no way to
>tell Ignite that user session has been changed, the user session is no
> good
>here despite the fact that user session holds by the ignite is a true
>session for that user.
>- Configuring web session filter does not work OOTB in spring boot
>platform, it require some additional tweaking in the code to make it
> work.
>
>
> So in the nutshell, I would think having spring session on ignite platform
> would support full session replication with spring boot platform.
>
>
> Please note that we have 2 SB instances, serving request round robin via F5
> ( load balancers) supported by 2 node ignite cluster.
>
> Any suggestions on how we want to conquer the issue ?
>
> Thanks,
>
> --
> Rishi Yagnik
>

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

[Dmitriy Setrakyan]

Hm... I think I misunderstood the issue.

In this case, since there is no disagreement, I would propose the following
steps then:

   1. We should merge the code into a separate Ignite branch and start
   stabilizing it.
   2. Let's start the VOTE to accept the donation once the code is merged.
   As Raul suggested, let's keep the VOTE to accept the donation separate from
   any decision on what to do with the donation or when to release it.
   3. I am hoping that once the donation is accepted, all the discussions
   about the new code, moving it to Ignite standards, stabilizing it, and
   eventually releasing it should happen on the dev list, which should allow
   everyone in the community to familiarize themselves with it.

Does this sound like an agreeable process to move forward?

D.

On Fri, May 19, 2017 at 11:53 AM, Konstantin Boudnik 
wrote:

> Dmitriy,
>
> no one has ever suggested to keep the code in a separate repository
> (once the grant issues were sorted out). Not sure where you get this
> impression. I don't think there's anything to argue about ;)
>
> Cos
>
>
> --
>   Take care,
> Konstantin (Cos) Boudnik
>
>
> On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan
>  wrote:
> > 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 process, run tests, stabilize, all while
> > the community is getting familiar with it. Keeping the code base outside
> of
> > Apache Ignite GIT makes it much more difficult to integrate or stabilize.
> > Moreover, if the code is in a separate Ignite branch, we can get the
> > community help to work on it and discuss issues on the dev list.
> >
> > I would propose to move the code to a separate branch in Apache Ignite
> > right now, especially given that the paperwork has already been taken
> care
> > of. We can still decide within the Ignite community not to accept it down
> > the road, in which case we can toss away the branch.
> >
> > Would you agree with this approach?
> >
> > D.
> >
> > On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik 
> wrote:
> >
> >> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik 
> >> wrote:
> >> > Well, here's the issue with "simple move from private repo". This is a
> >> > huge chunk of code. And while employees of Gridgain are quite familiar
> >> > with it (or so I presume), the rest of the community is not. I, for
> >> > one, don't consider that the fact it has been tested and integrated
> >> > with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
> >> > criteria.
> >>
> >> Cos is absolutely correct here. Strong +1 to the above.
> >>
> >> > I am sorry that I have to repeat this after 1.5 years after project's
> >> > graduation from the Incubator. However, I, personally and otherwise,
> >> > feel like a community process of creating software should be thought
> >> > through in the spirit of the community, rather than "release dates" or
> >> > "feature richness". Which means that the community has to be on board
> >> > with the decisions like this. And "on board" doesn't mean "majority of
> >> > the votes" as we, fortunately, aren't playing in democracy @apache.
> >> > Release dates are relevant to an entity, building and selling
> >> > products. in Apache we're are working on projects, and while releases
> >> > are important here, they convey a very different meaning.
> >>
> >> Which brings me to a related question: what exactly needs to be released
> >> on this aggressive schedule and who is a beneficiary of this release?
> >>
> >> What I am trying to say is this: if GirdGain has a product delivery
> >> deadline -- the
> >> company can go ahead and release its product with whatever features it
> >> needs to.
> >>
> >> But I'm with Cos -- the community has to be given time to get
> comfortable
> >> with
> >> the code base if for nothing else but for licensing implications.
> >>
> >> Thanks,
> >> Roman.
> >>
>

Re: How to store Binary Object in Cassandra Backup Store

[irudyak]

You are using invalid persistence descriptor. It should be something like:

*


*

You can find more details about persistence descriptor configuration here: 
https://apacheignite-mix.readme.io/docs/base-concepts#section-persistencesettingsbean

  



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/How-to-store-Binary-Object-in-Cassandra-Backup-Store-tp17827p17843.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Session Replication Update on spring boot platform

[Rishi Yagnik]

Hello Dmitriy,

Thank you for the response, I would await for Val's feedback.

I would like to discuss the possible approach for implementation here, and
it could be one of this -

https://issues.apache.org/jira/browse/IGNITE-2741

Hope we all come on to conclusion here.

Thanks,

On Fri, May 19, 2017 at 3:57 PM, Dmitriy Setrakyan 
wrote:

> 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
> Spring Boot.
>
> BTW, feel free to contribute it yourself if you have time.
>
> [1] https://ignite.apache.org/use-cases/caching/web-session-
> clustering.html
> [2] https://apacheignite-mix.readme.io/docs/web-session-clustering
>
> D.
>
> On Fri, May 19, 2017 at 11:43 AM, Rishi Yagnik 
> wrote:
>
>> Hello Val,
>>
>> I tested out the session replication on spring boot cluster and here is
>> the
>> result.
>>
>> My finding were as follows with Ignite 2.0 on session replication and hope
>> that helps the team –
>>
>>- Spring Security Filters requires context to be set with
>> Authentication
>>object, later on when user authentication object is set on the ignite
>>filter from Ignite cache, the spring security treat that as a new
>> session
>>just to prevent session fixation issue.
>>- As spring security creates a new session and since there is no way to
>>tell Ignite that user session has been changed, the user session is no
>> good
>>here despite the fact that user session holds by the ignite is a true
>>session for that user.
>>- Configuring web session filter does not work OOTB in spring boot
>>platform, it require some additional tweaking in the code to make it
>> work.
>>
>>
>> So in the nutshell, I would think having spring session on ignite platform
>> would support full session replication with spring boot platform.
>>
>>
>> Please note that we have 2 SB instances, serving request round robin via
>> F5
>> ( load balancers) supported by 2 node ignite cluster.
>>
>> Any suggestions on how we want to conquer the issue ?
>>
>> Thanks,
>>
>> --
>> Rishi Yagnik
>>
>
>


-- 
Rishi Yagnik

Re: SqlFields query result does not expose fields metadata.

[Dmitriy Setrakyan]

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 was to have a FieldsQueryCursor interface with
> > getFieldName(int column) method, may be + some other methods we will add
> > later. This does not require any complex code modifications or exposing
> > internal APIs.
> >
> > I'm not against new SQL API, it is a good idea, but it should not prevent
> > us from making easy fixes in existing API when we need it.
> >
> > Sergi
> >
> > 2017-05-18 23:20 GMT+03:00 Vladimir Ozerov :
> >
> > > Proposal is about returning GridQueryFieldMetadata from QueryCursor,
> > which
> > > is internal interface. This interface is counterintuitive and is not
> > ready
> > > to be exposed to users. For example, it has method "typeName" which
> > > actually returns table name. And has method "fieldTypeName" which
> returns
> > > something like "java.lang.Object". Add "type name" concept from our
> > > BinaryConfiguration/QueryEntity, which have different semantics, and
> you
> > > end up with totally confused users on what "type name" means in Ignite.
> > >
> > > Let's do not expose strange things to users, and accurately create new
> > > clean SQL API instead. There is no strong demand for this feature.
> > >
> > > On Thu, May 18, 2017 at 7:39 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com>
> > > wrote:
> > >
> > > > It should not require any internals movement, it must be an easy fix.
> > > >
> > > > Sergi
> > > >
> > > > 2017-05-18 15:36 GMT+03:00 Vladimir Ozerov :
> > > >
> > > > > With all the changes to internals we made, new API can be created
> > very
> > > > > quickly somewhere around AI 2.2 or AI 2.3. Currently the whole API
> is
> > > > > located in the wrong place, as it is bounded to cache. So the more
> we
> > > add
> > > > > now, the more we will deprecate in several months. Remember, that
> > this
> > > > > feature will require not only new interface, but moving existing
> > > > *internal*
> > > > > metadata classes to public space. These classes were never designed
> > to
> > > be
> > > > > exposed to users in the first place.
> > > > >
> > > > > This is why I am strongly against this change at the moment. No
> need
> > to
> > > > > make already outdated and complex API even more complex without
> > strong
> > > > > demand from users.
> > > > >
> > > > > On Thu, May 18, 2017 at 3:29 PM, Pavel Tupitsyn <
> > ptupit...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > I agree that this change makes sense.
> > > > > > With complex queries it may be non-trivial to get the right
> column
> > by
> > > > > index
> > > > > > from results.
> > > > > > With metadata user no longer needs to care about result column
> > order,
> > > > and
> > > > > > refactorings are easier.
> > > > > >
> > > > > > Pavel
> > > > > >
> > > > > > On Thu, May 18, 2017 at 2:36 PM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I believe we will not see this new SQL API soon. It is not even
> > in
> > > > > design
> > > > > > > stage.
> > > > > > >
> > > > > > > The change proposed by Andrey is very simple and our users will
> > > > benefit
> > > > > > > from it right away.
> > > > > > >
> > > > > > > I see no reasons to disallow this change.
> > > > > > >
> > > > > > > Sergi
> > > > > > >
> > > > > > > 2017-05-18 12:35 GMT+03:00 Vladimir Ozerov <
> voze...@gridgain.com
> > >:
> > > > > > >
> > > > > > > > Result set metadata is exposed to JDBC and ODBC drivers
> because
> > > it
> > > > is
> > > > > > > > required by JDBC specification and lot's external
> applications
> > > use
> > > > > it.
> > > > > > I
> > > > > > > do
> > > > > > > > not see big demand for this feature in native SQL, where user
> > > > > normally
> > > > > > > > knows the model. Another point is that with changes
> introduced
> > in
> > > > > > recent
> > > > > > > > versions (DML, DDL, shared schemas), we need brand new native
> > SQL
> > > > > API,
> > > > > > as
> > > > > > > > current IgniteCache.query() cannot conveniently reflect
> current
> > > and
> > > > > > > planned
> > > > > > > > Ignite capabilities.
> > > > > > > >
> > > > > > > > For this reason I do not think we should do proposed change.
> > > > Instead,
> > > > > > we
> > > > > > > > should add metadata retrieval to new SQL API.
> > > > > > > >
> > > > > > > > Vladimir.
> > > > > > > >
> > > > > > > > On Thu, May 18, 2017 at 12:19 PM, Andrey Mashenkov <
> > > > > > > > andrey.mashen...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > Hi Igniters,
> > > > > > > > >
> > > > > > > > > When user run Sql query via JDBC, he can get fields
> metadata
> > > > (field
> > > > > > > > names,
> > > > > > > > > its types and etc.) from ResultSet.
> > > > > > > > > With IgniteCache.query method he gets some QueryCursor
> > > > > > implementation,
> > > > > > > > but
>

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

[Roman Shaposhnik]

On Fri, May 19, 2017 at 2:08 PM, Dmitriy Setrakyan
 wrote:
> Hm... I think I misunderstood the issue.
>
> In this case, since there is no disagreement, I would propose the following
> steps then:
>
>1. We should merge the code into a separate Ignite branch and start
>stabilizing it.

Wait! Before that happens -- has there SGA been filed already? I apologize
if it has and I missed it.

Just trying to make sure we only land code on ASF infrastructure once proper
legal paperwork has been received by the secretary@

Thanks,
Roman.

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

[Denis Magda]

Roman, yes the software grant was acknowledged by Craig Russel. I mentioned
this earlier in the discussion.

On Friday, May 19, 2017, Roman Shaposhnik  wrote:

> On Fri, May 19, 2017 at 2:08 PM, Dmitriy Setrakyan
> > wrote:
> > Hm... I think I misunderstood the issue.
> >
> > In this case, since there is no disagreement, I would propose the
> following
> > steps then:
> >
> >1. We should merge the code into a separate Ignite branch and start
> >stabilizing it.
>
> Wait! Before that happens -- has there SGA been filed already? I apologize
> if it has and I missed it.
>
> Just trying to make sure we only land code on ASF infrastructure once
> proper
> legal paperwork has been received by the secretary@
>
> Thanks,
> Roman.
>

Re: No direct way to download Ignite Web Agent

[Alexey Kuznetsov]

Hi Prachi,

Code merged to master branch and it will be a part of 2.1 release.
You can check from master.

On Fri, May 19, 2017 at 11:35 PM, Prachi Garg  wrote:

> Hi Alexey,
>
> That's great! I checked it on GridGain deployment, it looks good. However,
> I don't see it on my local deployment. Was it not part of 2.0 release?
>
> -Prachi
>
> On Fri, May 19, 2017 at 2:21 AM, Alexey Kuznetsov 
> wrote:
>
>> Prachi,
>>
>> We added "Download Web Agent" button on right top corner.
>> Please, try it.
>>
>> On Thu, Apr 20, 2017 at 1:27 AM, Prachi Garg  wrote:
>>
>>> Somewhere in the header would be more visible; I would prefer that.
>>>
>>> On Wed, Apr 19, 2017 at 12:37 AM, Alexey Kuznetsov <
>>> akuznet...@apache.org>
>>> wrote:
>>>
>>> > Prachi,
>>> >
>>> > I think we could add such link in "User" menu just after "Getting
>>> started"
>>> > item.
>>> >
>>> > Or, may be, as some icon on header?
>>> >
>>> > Vica, do you have any UI/UX suggestion for this?
>>> >
>>> > On Wed, Apr 19, 2017 at 12:46 PM, Dmitriy Setrakyan <
>>> dsetrak...@apache.org
>>> > >
>>> > wrote:
>>> >
>>> > > Prachi, I completely agree. We should provide a way to download the
>>> web
>>> > > agent, along with installation instructions.
>>> > >
>>> > > Alexey K, can you comment?
>>> > >
>>> > > D.
>>> > >
>>> > > On Tue, Apr 18, 2017 at 4:16 PM, Prachi Garg 
>>> wrote:
>>> > >
>>> > > > Engineers,
>>> > > >
>>> > > > I realized that from the Web Console there is no direct way to
>>> download
>>> > > > Ignite Web Agent. The only way to download it is by going to either
>>> > > Model,
>>> > > > Monitoring, or Queries page (It's odd that to download the web
>>> agent,
>>> > you
>>> > > > have to go to model -> import from db-> and then download when
>>> > prompted).
>>> > > > Since Ignite web agent is required for almost everything on the Web
>>> > > > Console, shouldn't we have an option to download it from somewhere
>>> in
>>> > the
>>> > > > top menu or side menu?
>>> > > >
>>> > > > -Prachi
>>> > > >
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Alexey Kuznetsov
>>> >
>>>
>>
>>
>>
>> --
>> Alexey Kuznetsov
>>
>
>


-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

[GitHub] ignite pull request #1973: IGNITE-5238: Resolved dependency problems of Igni...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/1973


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #1976: IGNITE-5248: Detect a 32-bit JVM using too large ...

[vinx13]

GitHub user vinx13 opened a pull request:

https://github.com/apache/ignite/pull/1976

IGNITE-5248: Detect a 32-bit JVM using too large init page size



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vinx13/ignite ignite-5248

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/1976.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 #1976


commit f797eb6a2d18275877fd36574ec4477f0b4d14b5
Author: Wuwei Lin 
Date:   2017-05-20T06:38:19Z

IGNITE-5248: Detect a 32-bit JVM trying to allocate too big amount of 
memory in memory policy




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---