Re: 1.5.final

[Alexey Goncharuk]

The fix for https://issues.apache.org/jira/browse/IGNITE-2200 has been
merged to ignite-1.5​

Re: 1.5.final

[Sergey Kozlov]

Hi Igniters
We've great progress and only two outstanding issues prevents to release:
IGNITE-2252 Add support for cache sql schema in REST topology command

IGNITE-2175 Not valid exceptions in case when example can't works with
remote node started with server classpath (Java 7)




On Wed, Dec 23, 2015 at 3:10 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> The fix for https://issues.apache.org/jira/browse/IGNITE-2200 has been
> merged to ignite-1.5​
>



-- 
Sergey Kozlov

[GitHub] ignite pull request: ignite-2175

[avinogradovgg]

GitHub user avinogradovgg opened a pull request:

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

ignite-2175



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

$ git pull https://github.com/avinogradovgg/ignite ignite-2175-2

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

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


commit bd05fa90b1d04c8c488717302d8d84fb02e1
Author: Anton Vinogradov 
Date:   2015-12-23T15:05:06Z

ignite-2175




---
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: IGNITE-2228 .NET: Ensure async Task can be ca...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-2228 .NET: Ensure async Task can be cancelled.



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

$ git pull https://github.com/ptupitsyn/ignite ignite-2228

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

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


commit 717dab259e3f0287046ffcefa28cf9214ab65ff7
Author: sboikov 
Date:   2015-12-14T07:00:57Z

ignite-1.5 Fixed TcpDiscoveryMulticastIpFinder to request address on each 
getRegisteredAddresses call

commit 6d96bb6a3219255b62af826e6806b1aa564bb005
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:00Z

Fix to GridBinaryWildcardsSelfTest.

commit 4ae6292cface325f21237db5d18ce77dee380072
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:29Z

Fixed failure in BinaryObjectBuilderSelfTest.testCopyFromInnerObject.

commit ed27fbdab9d8307b4db427866ed1094526c117c8
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:47Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 3db14482091d01e96e1ae40a15cb903c3adcddbd
Author: vozerov-gridgain 
Date:   2015-12-14T07:19:24Z

Fixed failure in BinaryObjectBuilderSelfTest.testSetBinaryObject.

commit acb57c5eb95d11ebde5557618226d80f25ac610c
Author: sboikov 
Date:   2015-12-14T07:40:57Z

ignite-1.5 Fixed NPE in IgniteKernal.dumpDebugInfo.

commit ec2a64714c176f3a5aca60a058686d3354dc6a76
Author: sboikov 
Date:   2015-12-14T07:41:18Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 484a3afd05b9ad5a524a28c517ddc0a6b9dffcbc
Author: sboikov 
Date:   2015-12-14T07:58:57Z

ignite-1.5 Added waitForCondition in tests with TTL.

commit 47f1ced214b4176b13293386c1e2042c9cc20b32
Author: sboikov 
Date:   2015-12-14T08:09:17Z

ignite-1.5 Fixed test to override correct 'getConfiguration' method.

commit 4d086734833d96b7e2403ce4f17f763a1c75caab
Author: sboikov 
Date:   2015-12-14T08:27:33Z

ignite-1.5 Use TcpDiscoveryVmIpFinder in test.

commit de0b1badbf34538e04e7cf4be5378ef929fb6201
Author: Alexey Kuznetsov 
Date:   2015-12-14T08:33:09Z

ignite-1.5 Updated classnames.properties

commit beb64c34c271b7eac1388179b11f042b34fa0d60
Author: sboikov 
Date:   2015-12-14T08:34:07Z

ignite-1.5 Increased test timeouts.

commit 72e5b9adfdcfcad4b0002bbfc1cf20fd3a0ed149
Author: sboikov 
Date:   2015-12-14T08:34:32Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 4291edca326be4eafde331001238a9181333fbfc
Author: sboikov 
Date:   2015-12-14T09:01:51Z

ignite-1.5 Fixed CacheContinuousQueryFailoverAbstractSelfTest to do not 
hang in case of errors.

commit 345fc27d90f8ae28697fc021d55c7b7a015faeee
Author: sboikov 
Date:   2015-12-14T09:18:16Z

ignite-1.5 Fixed test for offheap mode.

commit fdea7cfaf6ea26834d2694cbfc9634de8d24209b
Author: vozerov-gridgain 
Date:   2015-12-14T09:21:17Z

IGNITE-2150: Fixed invalid test scenario.

commit f3cc98b189dd4c4a4ad6325e6b9a6fa6db795099
Author: vozerov-gridgain 
Date:   2015-12-14T09:21:38Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit f87b80f7bf6e38b3ebd21088d4e8aa11a505ed59
Author: vozerov-gridgain 
Date:   2015-12-14T09:40:22Z

IGNITE-2152: .NET: Intro text is added.

commit 6bf716afc490a3bec987e788d795fd979edbdd23
Author: sboikov 
Date:   2015-12-14T09:42:41Z

ignite-1.5 More info in GridPartitionedSingleGetFuture.toString.

commit 68d317952485dd0a4e09844a9cdbb3a0f23ae399
Author: sboikov 
Date:   2015-12-14T09:43:14Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 1224658fe0d4b572b9980fa5de65bbb043646377
Author: sboikov 
Date:   2015-12-14T10:17:06Z

ignite-1.5 Fixed NPE in GridPartitionedSingleGetFuture.

commit 3d9be34c104cc2e89e2422e4f9c3f126449c8162
Author: sboikov 
Date:   2015-12-14T10:31:40Z

ignite-1.5 Less unnecessary logging in test.

commit d6b46115147704f13c36aa59f307f77baf954e3f
Author: ashutak 
Date:   2015-12-14T11:17:37Z

ignite-2065: portable -> binary renaming (Fix platforms)

commit b906ed3f2e3c235ddaea9061af808e8e4b1c769c
Author: ashutak 
Date:   2015-12-14T12:09:46Z

IGNITE-2149: Fix compilation under Java 8

commit 84b9f58ebd1b07e88870c11973ce4e47d256a0b5

[GitHub] ignite pull request: ignite-2175

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: 1.5.final

[Dmitriy Setrakyan]

Got it. Looks like this is the only remaining issue. Please let us know
here once you fix it, so we could start voting on the final release.

On Wed, Dec 23, 2015 at 9:22 AM, Alexey Kuznetsov 
wrote:

> No, this is not old issue, new cache configuration property "SQL schema"
> was merged into ignite-1.5  two days ago.
>
> I would like to fix in ignite-1.5 in order to be able to execute SQL
> queries from Ignite console against ignite-1.5 cluster.
>
> New "SQL schema" cache configuration property implemented in such a way
> that if user specify it
>  then cache name can not be used as "schema name" any more only specified
> schema name.
>
> So, we need to show sql schema on web console UI and use it for building
> SQL queries.
>
> Please, take a look at this thread
>
> http://apache-ignite-developers.2346864.n4.nabble.com/sqlSchema-usability-question-td6133.html
> Where sql schema usability was discussed.
>
> On Thu, Dec 24, 2015 at 12:14 AM, Dmitriy Setrakyan  >
> wrote:
>
> > On Wed, Dec 23, 2015 at 5:30 AM, Alexey Kuznetsov <
> akuznet...@gridgain.com
> > >
> > wrote:
> >
> > > I think "IGNITE-2252 Add support for cache sql schema in REST topology
> > > command" will be fixed tomorrow in first half of a day.
> > >
> >
> > This looks like an old issue. Is there a reason why this ticket is so
> > critical for 1.5 release?
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: 1.5.final

[Anton Vinogradov]

The fix for https://issues.apache.org/jira/browse/IGNITE-2175 has been
merged to ignite-1.5​

On Wed, Dec 23, 2015 at 4:30 PM, Alexey Kuznetsov 
wrote:

> I think "IGNITE-2252 Add support for cache sql schema in REST topology
> command" will be fixed tomorrow in first half of a day.
>
> On Wed, Dec 23, 2015 at 7:14 PM, Sergey Kozlov 
> wrote:
>
> > Hi Igniters
> > We've great progress and only two outstanding issues prevents to release:
> > IGNITE-2252 Add support for cache sql schema in REST topology command
> > 
> > IGNITE-2175 Not valid exceptions in case when example can't works with
> > remote node started with server classpath (Java 7)
> > 
> >
> >
> >
> > On Wed, Dec 23, 2015 at 3:10 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > The fix for https://issues.apache.org/jira/browse/IGNITE-2200 has been
> > > merged to ignite-1.5​
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

[GitHub] ignite pull request: IGNITE-2168 Examples should destroy created c...

[VladimirErshov]

GitHub user VladimirErshov opened a pull request:

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

IGNITE-2168  Examples should destroy created caches: SpringBeanExample 
fails after CacheBinaryAutoStoreExample

IGNITE-2168
Examples should destroy created caches: SpringBeanExample fails after 
CacheBinaryAutoStoreExample

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

$ git pull https://github.com/VladimirErshov/ignite ignite-2168

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

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


commit 717dab259e3f0287046ffcefa28cf9214ab65ff7
Author: sboikov 
Date:   2015-12-14T07:00:57Z

ignite-1.5 Fixed TcpDiscoveryMulticastIpFinder to request address on each 
getRegisteredAddresses call

commit 6d96bb6a3219255b62af826e6806b1aa564bb005
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:00Z

Fix to GridBinaryWildcardsSelfTest.

commit 4ae6292cface325f21237db5d18ce77dee380072
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:29Z

Fixed failure in BinaryObjectBuilderSelfTest.testCopyFromInnerObject.

commit ed27fbdab9d8307b4db427866ed1094526c117c8
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:47Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 3db14482091d01e96e1ae40a15cb903c3adcddbd
Author: vozerov-gridgain 
Date:   2015-12-14T07:19:24Z

Fixed failure in BinaryObjectBuilderSelfTest.testSetBinaryObject.

commit acb57c5eb95d11ebde5557618226d80f25ac610c
Author: sboikov 
Date:   2015-12-14T07:40:57Z

ignite-1.5 Fixed NPE in IgniteKernal.dumpDebugInfo.

commit ec2a64714c176f3a5aca60a058686d3354dc6a76
Author: sboikov 
Date:   2015-12-14T07:41:18Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 484a3afd05b9ad5a524a28c517ddc0a6b9dffcbc
Author: sboikov 
Date:   2015-12-14T07:58:57Z

ignite-1.5 Added waitForCondition in tests with TTL.

commit 47f1ced214b4176b13293386c1e2042c9cc20b32
Author: sboikov 
Date:   2015-12-14T08:09:17Z

ignite-1.5 Fixed test to override correct 'getConfiguration' method.

commit 4d086734833d96b7e2403ce4f17f763a1c75caab
Author: sboikov 
Date:   2015-12-14T08:27:33Z

ignite-1.5 Use TcpDiscoveryVmIpFinder in test.

commit de0b1badbf34538e04e7cf4be5378ef929fb6201
Author: Alexey Kuznetsov 
Date:   2015-12-14T08:33:09Z

ignite-1.5 Updated classnames.properties

commit beb64c34c271b7eac1388179b11f042b34fa0d60
Author: sboikov 
Date:   2015-12-14T08:34:07Z

ignite-1.5 Increased test timeouts.

commit 72e5b9adfdcfcad4b0002bbfc1cf20fd3a0ed149
Author: sboikov 
Date:   2015-12-14T08:34:32Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 4291edca326be4eafde331001238a9181333fbfc
Author: sboikov 
Date:   2015-12-14T09:01:51Z

ignite-1.5 Fixed CacheContinuousQueryFailoverAbstractSelfTest to do not 
hang in case of errors.

commit 345fc27d90f8ae28697fc021d55c7b7a015faeee
Author: sboikov 
Date:   2015-12-14T09:18:16Z

ignite-1.5 Fixed test for offheap mode.

commit fdea7cfaf6ea26834d2694cbfc9634de8d24209b
Author: vozerov-gridgain 
Date:   2015-12-14T09:21:17Z

IGNITE-2150: Fixed invalid test scenario.

commit f3cc98b189dd4c4a4ad6325e6b9a6fa6db795099
Author: vozerov-gridgain 
Date:   2015-12-14T09:21:38Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit f87b80f7bf6e38b3ebd21088d4e8aa11a505ed59
Author: vozerov-gridgain 
Date:   2015-12-14T09:40:22Z

IGNITE-2152: .NET: Intro text is added.

commit 6bf716afc490a3bec987e788d795fd979edbdd23
Author: sboikov 
Date:   2015-12-14T09:42:41Z

ignite-1.5 More info in GridPartitionedSingleGetFuture.toString.

commit 68d317952485dd0a4e09844a9cdbb3a0f23ae399
Author: sboikov 
Date:   2015-12-14T09:43:14Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 1224658fe0d4b572b9980fa5de65bbb043646377
Author: sboikov 
Date:   2015-12-14T10:17:06Z

ignite-1.5 Fixed NPE in GridPartitionedSingleGetFuture.

commit 3d9be34c104cc2e89e2422e4f9c3f126449c8162
Author: sboikov 
Date:   2015-12-14T10:31:40Z

ignite-1.5 Less unnecessary logging in test.

commit d6b46115147704f13c36aa59f307f77baf954e3f
Author: ashutak 
Date:   2015-12-14T11:17:37Z

ignite-2065: portable -> binary renaming (Fix platforms)

commit 

Re: 1.5.final

[Alexey Kuznetsov]

No, this is not old issue, new cache configuration property "SQL schema"
was merged into ignite-1.5  two days ago.

I would like to fix in ignite-1.5 in order to be able to execute SQL
queries from Ignite console against ignite-1.5 cluster.

New "SQL schema" cache configuration property implemented in such a way
that if user specify it
 then cache name can not be used as "schema name" any more only specified
schema name.

So, we need to show sql schema on web console UI and use it for building
SQL queries.

Please, take a look at this thread
http://apache-ignite-developers.2346864.n4.nabble.com/sqlSchema-usability-question-td6133.html
Where sql schema usability was discussed.

On Thu, Dec 24, 2015 at 12:14 AM, Dmitriy Setrakyan 
wrote:

> On Wed, Dec 23, 2015 at 5:30 AM, Alexey Kuznetsov  >
> wrote:
>
> > I think "IGNITE-2252 Add support for cache sql schema in REST topology
> > command" will be fixed tomorrow in first half of a day.
> >
>
> This looks like an old issue. Is there a reason why this ticket is so
> critical for 1.5 release?
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Re: Dynamic caches creation

[Alexey Kuznetsov]

Cos,

In ignite-1.5 we introduced new binary marshaller.
And now you could load data into cache without having POJO classes on
server nodes.
Just describe them as JdbcTypes in CacheJdbcPojoStoreFactory.
The only thing that should be predefined on node start - is a data
source(s),
but I believe that data source is a kind of thing that is known when you
design app.

Make sense?

Re: Dynamic caches creation

[Konstantin Boudnik]

Let me try to restate what I've said earlier.

- I have a running cluster
- I want to create a new cache, configuration of which is totally unknown
  beforehand. Would be nice if I can do it by executing some custom java code
  from a client node
- I want to be able to load POJO model classes _without_ restating the nodes,
  but simply from say a network location (URL class loading?)
- once the cache is loaded and provisioned with some data (ie from stream?) I
  want to be able to store its configuration, so the next time I don't need to
  write and execute client Java code (as in the step above)

Am I making myself more clear now?

I believe the main snag, preventing us from getting on the same page is this.
Ignite as it stands right now, is very much oriented on the static cluster and
caches configurations. Even the auto-discovery from an external RDBMS is
semi-static as it requires some user input and pre-existing configuration
files. And that's the main issue IMO - the configuration is fundamentally
defines not only the caches, but the whole cluster. If I want to use slightly
different config to join a node to an existing cluster, it will be rejected.
In other words, the nodes are very homogeneous.

I am not saying it is a bad thing, but it is clearly a limiting factor for the
cases like I described above.

Cheers,
  Cos

On Wed, Dec 23, 2015 at 12:47AM, Dmitriy Setrakyan wrote:
> Cos, I am confused. What is the behavior you would like to see?
> 
> On Wed, Dec 23, 2015 at 12:01 AM, Konstantin Boudnik  wrote:
> 
> > What if I don't know the configuration in advance? Doesn't it mean that I
> > would have to restart the nodes whenever a new cache is configured and
> > needs
> > to be added to the cluster?
> >
> > Cos
> >
> > On Tue, Dec 22, 2015 at 10:37PM, Dmitriy Setrakyan wrote:
> > > Cos,
> > >
> > > As far as schema-on-read, you can set all your caches in XML
> > configuration,
> > > and they will be pre-created for you. Will this do the trick?
> > >
> > > D.
> > >
> > > On Tue, Dec 22, 2015 at 7:30 PM, Konstantin Boudnik 
> > wrote:
> > >
> > > > On Tue, Dec 22, 2015 at 03:45PM, Alexey Kuznetsov wrote:
> > > > > Cos,
> > > > >
> > > > > How you are going to create caches in already started cluster?
> > > > > I think you will create a cache configuration and after that will get
> > > > cache
> > > > > via Ignite.getOrCreateCache(ccfg).
> > > >
> > > > I would imagine that I can write some Java code to describe the
> > > > configuration
> > > > if needed. After all, Spring is all over the place. And while I am not
> > a
> > > > big
> > > > fun of overusing it, it's already there, so perhaps it can do something
> > > > useful ;)
> > > >
> > > > > So if you server cluster at some point was completely restarted, then
> > > > > executing getOrCreateCache(ccfg) will create cache again (if needed)
> > or
> > > > > return existing cache.
> > > >
> > > > I am trying to have an analogy with either RDBMS or a data processing
> > > > framework. I know the both of those aren't exact, but bear with me for
> > a
> > > > second. In RDBMS world the UX is to be able either to query existing
> > > > tables or
> > > > to create, populate and query new ones. No special auxiliary
> > configurations
> > > > are needed. In a data processing frameworks like Spark, Flink, etc. the
> > > > data
> > > > is originating the schema (aka schema on read) thus no special
> > preparation
> > > > steps is needed before the data could be read from a storage and
> > processed.
> > > >
> > > > Now, in the case of Ignite the data needs to be transferred to a RAM,
> > > > however
> > > > same schema-on-read (a parsing code) or an externalized metadata
> > (stored
> > > > config or something) could be used to structure it on-the-fly. Hence,
> > my
> > > > cluster would have a higher level of runtime dynamic as I now I can
> > create
> > > > new
> > > > caches as I go, without restarting the cluster nodes on every sneeze.
> > > >
> > > > > Also AFAIK CacheConfiguration class is serializable - you can save it
> > > > > somewhere and later load if needed.
> > > > > Or you may define some XML files with cache beans and load them with
> > > > > IgniteSpringHelper.
> > > > >
> > > > > Thoughts?
> > > >
> > > > Basically, I am trying to think of how to make this whole thing more
> > > > user-friendly and less middleware developers oriented. Wouldn't it be
> > > > great if
> > > > a user can load some external data and immediately start playing with
> > it
> > > > and
> > > > doing some OLAP or even - oh horror :) - OLTP on it?
> > > >
> > > > Does it make sense?
> > > >   Cos
> > > >
> > > > > On Tue, Dec 22, 2015 at 3:32 PM, Konstantin Boudnik 
> > > > wrote:
> > > > >
> > > > > > Guys,
> > > > > >
> > > > > > is it possible to configure caches dynamically and persist their
> > > > > > configuration
> > > > > > in some shape and form? Here's the use case:
> > > > > >  - we want to create some 

Re: Dynamic caches creation

[Konstantin Boudnik]

Yup, that makes a lot of sense. I've seen the conversation about the
marshaller, but somehow I blinded it off. Lemme check more on this

Appreciate the pointer!
  Cos

On Thu, Dec 24, 2015 at 07:28AM, Alexey Kuznetsov wrote:
> Cos,
> 
> In ignite-1.5 we introduced new binary marshaller.
> And now you could load data into cache without having POJO classes on
> server nodes.
> Just describe them as JdbcTypes in CacheJdbcPojoStoreFactory.
> The only thing that should be predefined on node start - is a data
> source(s),
> but I believe that data source is a kind of thing that is known when you
> design app.
> 
> Make sense?


signature.asc
Description: Digital signature

[jira] [Created] (IGNITE-2254) Need append nodeId for sql-query command in REST API

[Andrey Novikov (JIRA)]

Andrey Novikov created IGNITE-2254:
--

 Summary: Need append nodeId for sql-query command in REST API
 Key: IGNITE-2254
 URL: https://issues.apache.org/jira/browse/IGNITE-2254
 Project: Ignite
  Issue Type: Bug
  Components: clients
Reporter: Andrey Novikov
Assignee: Semen Boikov
 Fix For: 1.6


Query execute command should return nodeId for node where QueryCursor stored in 
nodeLocal
https://apacheignite.readme.io/v1.6/docs/rest-api#sql-query-execute

Query fetch command should resend job to node with nodeId
https://apacheignite.readme.io/v1.6/docs/rest-api#sql-query-fetch



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2252 Add support for cache sql schema ...

[nva]

GitHub user nva opened a pull request:

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

IGNITE-2252 Add support for cache sql schema in REST topology command



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

$ git pull https://github.com/nva/ignite ignite-2252

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

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


commit 97c9c0c115e2381bfd759b4fcf6712cfcd475e1f
Author: Andrey 
Date:   2015-12-24T06:04:56Z

IGNITE-2252 Added support for cache sql schema in REST topology command




---
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: Ignite 2032

[VladimirErshov]

GitHub user VladimirErshov opened a pull request:

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

Ignite 2032

IGNITE-2032 Filters passed to ScanQuery are not redeployed when originating 
from a client node
added undeploy for client nodes.

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

$ git pull https://github.com/VladimirErshov/ignite ignite-2032

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

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


commit 717dab259e3f0287046ffcefa28cf9214ab65ff7
Author: sboikov 
Date:   2015-12-14T07:00:57Z

ignite-1.5 Fixed TcpDiscoveryMulticastIpFinder to request address on each 
getRegisteredAddresses call

commit 6d96bb6a3219255b62af826e6806b1aa564bb005
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:00Z

Fix to GridBinaryWildcardsSelfTest.

commit 4ae6292cface325f21237db5d18ce77dee380072
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:29Z

Fixed failure in BinaryObjectBuilderSelfTest.testCopyFromInnerObject.

commit ed27fbdab9d8307b4db427866ed1094526c117c8
Author: vozerov-gridgain 
Date:   2015-12-14T07:08:47Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 3db14482091d01e96e1ae40a15cb903c3adcddbd
Author: vozerov-gridgain 
Date:   2015-12-14T07:19:24Z

Fixed failure in BinaryObjectBuilderSelfTest.testSetBinaryObject.

commit acb57c5eb95d11ebde5557618226d80f25ac610c
Author: sboikov 
Date:   2015-12-14T07:40:57Z

ignite-1.5 Fixed NPE in IgniteKernal.dumpDebugInfo.

commit ec2a64714c176f3a5aca60a058686d3354dc6a76
Author: sboikov 
Date:   2015-12-14T07:41:18Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 484a3afd05b9ad5a524a28c517ddc0a6b9dffcbc
Author: sboikov 
Date:   2015-12-14T07:58:57Z

ignite-1.5 Added waitForCondition in tests with TTL.

commit 47f1ced214b4176b13293386c1e2042c9cc20b32
Author: sboikov 
Date:   2015-12-14T08:09:17Z

ignite-1.5 Fixed test to override correct 'getConfiguration' method.

commit 4d086734833d96b7e2403ce4f17f763a1c75caab
Author: sboikov 
Date:   2015-12-14T08:27:33Z

ignite-1.5 Use TcpDiscoveryVmIpFinder in test.

commit de0b1badbf34538e04e7cf4be5378ef929fb6201
Author: Alexey Kuznetsov 
Date:   2015-12-14T08:33:09Z

ignite-1.5 Updated classnames.properties

commit beb64c34c271b7eac1388179b11f042b34fa0d60
Author: sboikov 
Date:   2015-12-14T08:34:07Z

ignite-1.5 Increased test timeouts.

commit 72e5b9adfdcfcad4b0002bbfc1cf20fd3a0ed149
Author: sboikov 
Date:   2015-12-14T08:34:32Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 4291edca326be4eafde331001238a9181333fbfc
Author: sboikov 
Date:   2015-12-14T09:01:51Z

ignite-1.5 Fixed CacheContinuousQueryFailoverAbstractSelfTest to do not 
hang in case of errors.

commit 345fc27d90f8ae28697fc021d55c7b7a015faeee
Author: sboikov 
Date:   2015-12-14T09:18:16Z

ignite-1.5 Fixed test for offheap mode.

commit fdea7cfaf6ea26834d2694cbfc9634de8d24209b
Author: vozerov-gridgain 
Date:   2015-12-14T09:21:17Z

IGNITE-2150: Fixed invalid test scenario.

commit f3cc98b189dd4c4a4ad6325e6b9a6fa6db795099
Author: vozerov-gridgain 
Date:   2015-12-14T09:21:38Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit f87b80f7bf6e38b3ebd21088d4e8aa11a505ed59
Author: vozerov-gridgain 
Date:   2015-12-14T09:40:22Z

IGNITE-2152: .NET: Intro text is added.

commit 6bf716afc490a3bec987e788d795fd979edbdd23
Author: sboikov 
Date:   2015-12-14T09:42:41Z

ignite-1.5 More info in GridPartitionedSingleGetFuture.toString.

commit 68d317952485dd0a4e09844a9cdbb3a0f23ae399
Author: sboikov 
Date:   2015-12-14T09:43:14Z

Merge remote-tracking branch 'origin/ignite-1.5' into ignite-1.5

commit 1224658fe0d4b572b9980fa5de65bbb043646377
Author: sboikov 
Date:   2015-12-14T10:17:06Z

ignite-1.5 Fixed NPE in GridPartitionedSingleGetFuture.

commit 3d9be34c104cc2e89e2422e4f9c3f126449c8162
Author: sboikov 
Date:   2015-12-14T10:31:40Z

ignite-1.5 Less unnecessary logging in test.

commit d6b46115147704f13c36aa59f307f77baf954e3f
Author: ashutak 
Date:   2015-12-14T11:17:37Z

ignite-2065: portable -> binary renaming (Fix platforms)

commit b906ed3f2e3c235ddaea9061af808e8e4b1c769c
Author: ashutak 
Date:   

[GitHub] ignite pull request: ignite-2175

[avinogradovgg]

GitHub user avinogradovgg opened a pull request:

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

ignite-2175



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

$ git pull https://github.com/avinogradovgg/ignite ignite-2175

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

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


commit 60eec118428bc06f3107fee3ad55dd9a1c6d5cf3
Author: Anton Vinogradov 
Date:   2015-12-23T10:35:14Z

ignite-2175




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

[jira] [Created] (IGNITE-2253) Refactoring fields on cluster page

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-2253:
-

 Summary: Refactoring fields on cluster page
 Key: IGNITE-2253
 URL: https://issues.apache.org/jira/browse/IGNITE-2253
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitriyff
Assignee: Dmitriyff






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2252) Add support for cache sql schema in REST topology command

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-2252:


 Summary: Add support for cache sql schema in REST topology command
 Key: IGNITE-2252
 URL: https://issues.apache.org/jira/browse/IGNITE-2252
 Project: Ignite
  Issue Type: Task
Affects Versions: 1.5
Reporter: Alexey Kuznetsov
Assignee: Andrey Novikov
Priority: Blocker
 Fix For: 1.5






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: IGNITE-2200 - Fixed deployment and added a te...

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

IGNITE-2200 - Fixed deployment and added a test.



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

$ git pull https://github.com/agoncharuk/ignite ignite-2200

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

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


commit 24953d0b62db9cf036a9400fdb955815b6d09fa0
Author: Alexey Goncharuk 
Date:   2015-12-23T09:09:08Z

IGNITE-2200 - Fixed deployment and added a test.




---
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: Dynamic caches creation

[Konstantin Boudnik]

What if I don't know the configuration in advance? Doesn't it mean that I
would have to restart the nodes whenever a new cache is configured and needs
to be added to the cluster?

Cos

On Tue, Dec 22, 2015 at 10:37PM, Dmitriy Setrakyan wrote:
> Cos,
> 
> As far as schema-on-read, you can set all your caches in XML configuration,
> and they will be pre-created for you. Will this do the trick?
> 
> D.
> 
> On Tue, Dec 22, 2015 at 7:30 PM, Konstantin Boudnik  wrote:
> 
> > On Tue, Dec 22, 2015 at 03:45PM, Alexey Kuznetsov wrote:
> > > Cos,
> > >
> > > How you are going to create caches in already started cluster?
> > > I think you will create a cache configuration and after that will get
> > cache
> > > via Ignite.getOrCreateCache(ccfg).
> >
> > I would imagine that I can write some Java code to describe the
> > configuration
> > if needed. After all, Spring is all over the place. And while I am not a
> > big
> > fun of overusing it, it's already there, so perhaps it can do something
> > useful ;)
> >
> > > So if you server cluster at some point was completely restarted, then
> > > executing getOrCreateCache(ccfg) will create cache again (if needed) or
> > > return existing cache.
> >
> > I am trying to have an analogy with either RDBMS or a data processing
> > framework. I know the both of those aren't exact, but bear with me for a
> > second. In RDBMS world the UX is to be able either to query existing
> > tables or
> > to create, populate and query new ones. No special auxiliary configurations
> > are needed. In a data processing frameworks like Spark, Flink, etc. the
> > data
> > is originating the schema (aka schema on read) thus no special preparation
> > steps is needed before the data could be read from a storage and processed.
> >
> > Now, in the case of Ignite the data needs to be transferred to a RAM,
> > however
> > same schema-on-read (a parsing code) or an externalized metadata (stored
> > config or something) could be used to structure it on-the-fly. Hence, my
> > cluster would have a higher level of runtime dynamic as I now I can create
> > new
> > caches as I go, without restarting the cluster nodes on every sneeze.
> >
> > > Also AFAIK CacheConfiguration class is serializable - you can save it
> > > somewhere and later load if needed.
> > > Or you may define some XML files with cache beans and load them with
> > > IgniteSpringHelper.
> > >
> > > Thoughts?
> >
> > Basically, I am trying to think of how to make this whole thing more
> > user-friendly and less middleware developers oriented. Wouldn't it be
> > great if
> > a user can load some external data and immediately start playing with it
> > and
> > doing some OLAP or even - oh horror :) - OLTP on it?
> >
> > Does it make sense?
> >   Cos
> >
> > > On Tue, Dec 22, 2015 at 3:32 PM, Konstantin Boudnik 
> > wrote:
> > >
> > > > Guys,
> > > >
> > > > is it possible to configure caches dynamically and persist their
> > > > configuration
> > > > in some shape and form? Here's the use case:
> > > >  - we want to create some caches in the already running cluster for a
> > data
> > > > set
> > > >  - once it is done, we'll run some SQL queries on top of those
> > > >  - ideally, we'd like to be able to safe the cache configurations so
> > next
> > > >time, we don't need to do the structures and field types discovery,
> > but
> > > >instead be able to load it on (re)start
> > > >
> > > > Is this a supported use-case or everything should be defined statically
> > > > before
> > > > nodes start? Looks like the latter, but perhaps we are missing
> > something.
> > > >
> > > > Thanks in advance for any info,
> > > >   Cos
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > > GridGain Systems
> > > www.gridgain.com
> >


signature.asc
Description: Digital signature

Re: Dynamic caches creation

[Dmitriy Setrakyan]

Cos, I am confused. What is the behavior you would like to see?

On Wed, Dec 23, 2015 at 12:01 AM, Konstantin Boudnik  wrote:

> What if I don't know the configuration in advance? Doesn't it mean that I
> would have to restart the nodes whenever a new cache is configured and
> needs
> to be added to the cluster?
>
> Cos
>
> On Tue, Dec 22, 2015 at 10:37PM, Dmitriy Setrakyan wrote:
> > Cos,
> >
> > As far as schema-on-read, you can set all your caches in XML
> configuration,
> > and they will be pre-created for you. Will this do the trick?
> >
> > D.
> >
> > On Tue, Dec 22, 2015 at 7:30 PM, Konstantin Boudnik 
> wrote:
> >
> > > On Tue, Dec 22, 2015 at 03:45PM, Alexey Kuznetsov wrote:
> > > > Cos,
> > > >
> > > > How you are going to create caches in already started cluster?
> > > > I think you will create a cache configuration and after that will get
> > > cache
> > > > via Ignite.getOrCreateCache(ccfg).
> > >
> > > I would imagine that I can write some Java code to describe the
> > > configuration
> > > if needed. After all, Spring is all over the place. And while I am not
> a
> > > big
> > > fun of overusing it, it's already there, so perhaps it can do something
> > > useful ;)
> > >
> > > > So if you server cluster at some point was completely restarted, then
> > > > executing getOrCreateCache(ccfg) will create cache again (if needed)
> or
> > > > return existing cache.
> > >
> > > I am trying to have an analogy with either RDBMS or a data processing
> > > framework. I know the both of those aren't exact, but bear with me for
> a
> > > second. In RDBMS world the UX is to be able either to query existing
> > > tables or
> > > to create, populate and query new ones. No special auxiliary
> configurations
> > > are needed. In a data processing frameworks like Spark, Flink, etc. the
> > > data
> > > is originating the schema (aka schema on read) thus no special
> preparation
> > > steps is needed before the data could be read from a storage and
> processed.
> > >
> > > Now, in the case of Ignite the data needs to be transferred to a RAM,
> > > however
> > > same schema-on-read (a parsing code) or an externalized metadata
> (stored
> > > config or something) could be used to structure it on-the-fly. Hence,
> my
> > > cluster would have a higher level of runtime dynamic as I now I can
> create
> > > new
> > > caches as I go, without restarting the cluster nodes on every sneeze.
> > >
> > > > Also AFAIK CacheConfiguration class is serializable - you can save it
> > > > somewhere and later load if needed.
> > > > Or you may define some XML files with cache beans and load them with
> > > > IgniteSpringHelper.
> > > >
> > > > Thoughts?
> > >
> > > Basically, I am trying to think of how to make this whole thing more
> > > user-friendly and less middleware developers oriented. Wouldn't it be
> > > great if
> > > a user can load some external data and immediately start playing with
> it
> > > and
> > > doing some OLAP or even - oh horror :) - OLTP on it?
> > >
> > > Does it make sense?
> > >   Cos
> > >
> > > > On Tue, Dec 22, 2015 at 3:32 PM, Konstantin Boudnik 
> > > wrote:
> > > >
> > > > > Guys,
> > > > >
> > > > > is it possible to configure caches dynamically and persist their
> > > > > configuration
> > > > > in some shape and form? Here's the use case:
> > > > >  - we want to create some caches in the already running cluster
> for a
> > > data
> > > > > set
> > > > >  - once it is done, we'll run some SQL queries on top of those
> > > > >  - ideally, we'd like to be able to safe the cache configurations
> so
> > > next
> > > > >time, we don't need to do the structures and field types
> discovery,
> > > but
> > > > >instead be able to load it on (re)start
> > > > >
> > > > > Is this a supported use-case or everything should be defined
> statically
> > > > > before
> > > > > nodes start? Looks like the latter, but perhaps we are missing
> > > something.
> > > > >
> > > > > Thanks in advance for any info,
> > > > >   Cos
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > > GridGain Systems
> > > > www.gridgain.com
> > >
>