Re: about AtomicConfiguration

[Dmitriy Setrakyan]

Valentin,

Can you please add more explanation to IGNITE-2096, so it will be more
clear what needs to be fixed?

Thanks,
D.

On Wed, Jan 13, 2016 at 8:09 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Hi,
>
> This behavior is correct and unfortunately your suggestion is not going to
> work. We create only one cache for all atomic structures, so you can't pass
> new configuration for each created atomic. It makes perfect sense to define
> all parameters that are not specific for a particular atomic during the
> node startup.
>
> As for the error message and the consistency check, I think the message is
> very confusing. And the ticket for this already exists for a while [1].
> It's assigned to me right now, but if you're interested, feel free to
> assign to yourself and provide a patch.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-2096
>
> -Val
>
> On Wed, Jan 13, 2016 at 5:09 AM, 李玉珏@163 <18624049...@163.com> wrote:
>
>> Hi：
>>
>> About AtomicConfiguration, I found the following issue:
>>
>> Configuration of node 1:
>>
>> AtomicConfiguration atomicCfg = new AtomicConfiguration();
>> atomicCfg.setBackups(1);
>> atomicCfg.setAtomicSequenceReserveSize(0);
>>
>> IgniteConfiguration cfg = new IgniteConfiguration();
>> cfg.setAtomicConfiguration(atomicCfg);
>> Ignite ignite = Ignition.start(cfg);
>>
>> Configuration of node 2:
>>
>> Ignite ignite = Ignition.start();
>>
>> Then there will be the following error:
>>
>> Only two nodes are configured in the same configuration to successfully
>> start up。
>>
>> AtomicConfiguration is the global configuration of the start, can not be
>> set dynamically after the start, and can not be set for a single sequence。
>>
>> CacheConfiguration can be configured separately, and can be dynamically
>> configured by ignite.getOrCreateCache(CacheConfiguration) after startup.
>>
>> I think AtomicConfiguration's design is not reasonable。
>> I propose to merge the three parameters of the atomicSequence method with
>> the AtomicConfiguration, and then add one：
>> Ignite.atomicSequence (AtomicConfiguration) method.
>>
>> Or communitity can consider a more elegant approach.
>>
>
>

[jira] [Created] (IGNITE-2376) .NET: UnmanagedUtils.IgnitionStart return value is never used

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2376:
--

 Summary: .NET: UnmanagedUtils.IgnitionStart return value is never 
used
 Key: IGNITE-2376
 URL: https://issues.apache.org/jira/browse/IGNITE-2376
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 1.6


UnmanagedUtils.IgnitionStart is used only once, and return value is not used.
Quick test to make it void resulted in OutOfMemory in tests on TC.
Need to investigate what is going on.



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

Re: New method in IgniteCache API.

[Alexey Goncharuk]

Dmitriy,

Are you suggesting that we need to pass partitions state to a topology
validator so that user needs to check it manually. I do not think this is
convenient for an end-user and like the approach with the policy that
Vladimir suggested better.

Raul,

I assume you want to add IgniteCacheEx interface? How one would get it?
Another thing that crossed my mind was that it may be more efficient to
reset the state of multiple caches simultaneously, so maybe we should add
this method to Ignite and pass a list of cache names?

Re: Binary ID mapper that uses a simple name of classes.

[Yakov Zhdanov]

I would suggest "SimpleClassNameBinaryIdMapper"

--Yakov

2016-01-14 4:59 GMT+03:00 Dmitriy Setrakyan :

> I like the last one too.
>
> On Wed, Jan 13, 2016 at 7:54 AM, Artem Shutak 
> wrote:
>
> > Igniters,
> >
> > I'm working on https://issues.apache.org/jira/browse/IGNITE-2191 (Binary
> > marshaller: support user classes with the same simple name) bug.
> >
> > The fix expects new BinaryIdMapper that uses a simple name of classes. It
> > is required for supporting of platforms (.Net. C++).
> >
> > I would be glade to hear suggestions about good name for this mapper.
> >
> > I propose the following:
> > - BinaryPlatformIdMapper
> > - BinaryInteropIdMapper
> > - SimpleNameBinaryIdMapper
> > - BinarySimpleNameIdMapper
> >
> > I like the last one, but it has a big length.
> >
> > Thanks,
> > -- Artem --
> >
>

[GitHub] ignite pull request: gg-8700

[ilantukh]

GitHub user ilantukh opened a pull request:

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

gg-8700



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

$ git pull https://github.com/ilantukh/ignite ignite-gg-8700

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

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


commit 161fe6cb1d44746bd90fca75cae0ff128b0f35ec
Author: Ilya Lantukh 
Date:   2016-01-14T12:17:53Z

gg-8700 : Added DR notification for case when cache receives the same 
update again.




---
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-2378) Data loss Part 2. Add flexible DataLoss Policy. Improve dataLoss event with batch.

[Vladimir Ershov (JIRA)]

Vladimir Ershov created IGNITE-2378:
---

 Summary: Data loss Part 2. Add flexible DataLoss Policy. Improve 
dataLoss event with batch.
 Key: IGNITE-2378
 URL: https://issues.apache.org/jira/browse/IGNITE-2378
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.6
Reporter: Vladimir Ershov
Assignee: Vladimir Ershov


Next steps for the data loss check functionality development:
# Introduce new DataLossPolicy, like read-only and others.
# Think of data restoration and implement if needed.
# Design solution for the reduce of the amount of 
EVT_CACHE_REBALANCE_PART_DATA_LOST. (Now it is possible to implement batching 
for those events). One has to be careful with backward compatibility here.



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

[GitHub] ignite pull request: IGNITE-2376 .NET: UnmanagedUtils.IgnitionStar...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-2376 .NET: UnmanagedUtils.IgnitionStart return value is never used



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

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

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

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


commit ba1b0b17a1eb2a8af1497655d571316fa403e244
Author: Pavel Tupitsyn 
Date:   2016-01-14T11:35:59Z

IGNITE-2376 .NET: UnmanagedUtils.IgnitionStart return value is never used




---
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-2379) .NET: ASP.NET Output Cache provider

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2379:
--

 Summary: .NET: ASP.NET Output Cache provider
 Key: IGNITE-2379
 URL: https://issues.apache.org/jira/browse/IGNITE-2379
 Project: Ignite
  Issue Type: New Feature
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn


Implement System.Web.Caching.OutputCacheProvider 
(https://msdn.microsoft.com/en-us/library/system.web.caching.outputcacheprovider(v=vs.110).aspx)



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

[jira] [Created] (IGNITE-2380) .NET: Ignite configuration in app.config and web.config

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2380:
--

 Summary: .NET: Ignite configuration in app.config and web.config
 Key: IGNITE-2380
 URL: https://issues.apache.org/jira/browse/IGNITE-2380
 Project: Ignite
  Issue Type: New Feature
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn


* Define custom ConfigurationSection for IgniteConfiguration
* Extend Ignition class to be able to start Ignite from app.config / web.config 
configuration



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

[jira] [Created] (IGNITE-2381) Move Indexed key-value pairs from Cache Screen to Metadata Screen

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-2381:


 Summary: Move Indexed key-value pairs from Cache Screen to 
Metadata Screen
 Key: IGNITE-2381
 URL: https://issues.apache.org/jira/browse/IGNITE-2381
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.6
Reporter: Alexey Kuznetsov
Assignee: Vasiliy Sisko
 Fix For: 1.6


It is more logical to configure indexed key-value pairs on Metadata screen.



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

Re: GridFutureAdapter: deprecate startTime(), duration() and endTime()

[Vladimir Ozerov]

+1

BTW, corresponding ticket already exists. You can find it under umbrella
ticket IGNITE-2232
14 янв. 2016 г. 18:40 пользователь "Yakov Zhdanov" 
написал:

> Guys,
>
> We have startTime(), duration() and endTime() methods which have several
> usages each along internals of the project, but to support these methods we
> have 2 long fields in GridFutureAdapter which gives us 16 bytes.
>
> Other fields - res (reference 8 bytes at max), ignoreInterrupts (boolean 1
> byte) and resFlag (byte 1 byte) = 10 bytes
>
> I did quick tests and I see that removing these fields (i.e. making each
> future 16 bytes thinner) can give us 5-6% in performance results.
>
> I want to deprecate  startTime(), duration() and endTime() and therefore
> deprecate corresponding methods in IgniteFuture.
>
> Thoughts?
>
> --Yakov
>

Re: Json support in Ignite

[Dmitriy Setrakyan]

I would consider a case for generating hash-code by iterating through all
the fields by default. We need to make sure that the iteration order is the
same on both ends.

User can always override it, no?

D.

On Thu, Jan 14, 2016 at 8:10 AM, Andrey Gura  wrote:

> Hi,
>
>
> > > Also we need following functionality for json objects
> > >
> > > 1. Possibility to map json cache key to affinity key. This can be
> > achieved
> > > with custom affinity mapper:
> > >
> > > cache.setAffinityMapper(new AffinityKeyMapper() {
> > > @Override public Object affinityKey(Object key) {
> > > return
> ((JsonObject)key).getJsonNumber("orgId").longValue();
> > > }
> > > });
> > >
> >
> > We can also have a special field within JSON Object, called
> > ignite_affinity_field=bla
>
>
> +1
>
> It looks like we are over architecting here.
> >
> > Keys should not have many fields, and most likely will have one or two.
> > Iterating through fields and generating hash-code or equals the standard
> > way seems reasonable (as opposed to creating a whole architecture around
> > how to get hash and equals fields).
> >
> > If it makes sense, we should cache the hash code value inside the key
> > object after it has been generated once.
> >
>
> I don't think that we should have some constraints here. If user wants to
> use specific set of fields for hashCode/equals he should have such
> possibility.
>
> There is one more problem in hashCode/equals: how to handle cases when
> specified field isn't mandatory?
>
>
> On Wed, Jul 15, 2015 at 11:32 AM, Dmitriy Setrakyan  >
> wrote:
>
> > On Wed, Jul 15, 2015 at 12:00 AM, Semyon Boikov 
> > wrote:
> >
> > > Hi all,
> > >
> > > As part of integration with Node.Js (IGNITE-961) we age going to add in
> > > Ignite support for JSON (possibility for IgniteCache to put, get, index
> > and
> > > query JSON data).
> > >
> > > We can implement standard 'javax.json' API (JSR 353), with this API
> work
> > > with cache will look like in this example:
> > >
> > >
> > Are we going to implement JSON specification ourselves? Sounds a bit
> fishy.
> > Can we just take some available implementation (assuming that the license
> > fits)?
> >
> >
> >
> > > Ignite should somehow provide access to 'javax.json' API, unfortunately
> > > 'javax.json' is not part of JDK so we have several options how it can
> be
> > > added in Ignite:
> > >
> > > 1. Add dependency for 'javax.json-api' in core module, in this case we
> > can
> > > have method to get access for json API on 'org.apache.ignite.Ignite':
> > >
> > > * interface Ignite {*
> > > *...*
> > >
> > > *javax.json.JsonProvider json();*
> > > * }*
> > >
> > > * JsonProvider json = ignite.json();*
> > >
> > > Not sure it is ok, since now we don't have 3rd party dependencies in
> > ignite
> > > 'core' module except 'javax.cache' API.
> > >
> > > 2. Added another optional module 'json', this module will have
> dependency
> > > for 'javax.json' API, and in this module we can have factory providing
> > > access to 'javax.json' API:
> > >
> >
> > I think an optional module makes sense.
> >
> >
> >
> > >
> > > 3. Create plugin for json, in this case plugin will provide access to
> > > 'javax.json' API:
> > >
> > > * IgniteJsonPlugin jsonPlugin = ignite.plugin(IgniteJsonPlugin.NAME);*
> > >
> > > * javax.json.JsonProvider provider = jsonPlugin.json();*
> > >
> > >
> > > Not sure this aproach with plugin is ok, since now we don't have 'core'
> > > ignite functionality implemented as plugins.
> > >
> >
> > Agree, this probably won't work.
> >
> >
> >
> > > Also we need following functionality for json objects
> > >
> > > 1. Possibility to map json cache key to affinity key. This can be
> > achieved
> > > with custom affinity mapper:
> > >
> > > cache.setAffinityMapper(new AffinityKeyMapper() {
> > > @Override public Object affinityKey(Object key) {
> > > return
> ((JsonObject)key).getJsonNumber("orgId").longValue();
> > > }
> > > });
> > >
> >
> > We can also have a special field within JSON Object, called
> > ignite_affinity_field=bla
> >
> >
> > >
> > > 2. Efficient implementation for equals/hashCode for json cache keys.
> > >
> > > One option is just have equals/hashCode like in HashMap.
> > >
> > > Another option can be add special JsonConfiguration, it should be set
> in
> > > CacheConfiguration and can contain following settings:
> > > - list of fields to use in 'equals' and 'hashCode' calculation
> > > - alternatively for equals/hashCode we can provide possibility to
> > implement
> > > custom comparator/hash code calculator
> > > - JsonConfiguration can have setting for affinity key
> > >
> > > So JsonConfiguration can look like this:
> > >
> > > *class JsonConfiguration {*
> > > */***
> > > * * Field names for hash code calculation.*
> > > * */*
> > > *public Collection getKeyHashCodeFields();*
> > >
> > > *

Re: What is jdbc:ignite:cfg ??

[Andrey Gura]

Hello,

JFYI, I created ticket as result of this discussion:
https://issues.apache.org/jira/browse/IGNITE-2382



On Thu, Dec 10, 2015 at 10:29 PM, Dmitriy Setrakyan 
wrote:

> Andrey,
>
> I agree on both points. However, I still think that we should provide
> sample step-by-step guide with a sample configuration. This configuration
> should include a couple of data types, like Person and Organization, define
> indexes for them, etc.
>
> This guide should include:
>
> 1. Start Ignite Servers
> 2. Populate data - should have example with configuration.
> 3. Query data using JDBC driver - example code and, if needed,
> configuration to support it.
>
> Do you mind adding it?
>
> D.
>
> On Thu, Dec 10, 2015 at 7:50 AM, Andrey Gura  wrote:
>
> > I didn't think that we should force client mode at moment of
> > implementation. But I can't provide any reason not to do it.
> >
> > So we need two small improvements to JDBC driver:
> >
> > 1. Always force client mode.
> > 2. Use default configuration in cases when user did't specify any URL.
> This
> > configuration should just use client mode and default values for rest
> > properties.
> >
> > Right?
> >
> > On Thu, Dec 10, 2015 at 9:05 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Wed, Dec 9, 2015 at 10:04 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Actually, why don't we set it automatically? It doesn't make much
> sense
> > > to
> > > > have a server node in a JDBC driver.
> > > >
> > >
> > > Completely agree.
> > >
> > >
> > > >
> > > > -Val
> > > >
> > > > On Wed, Dec 9, 2015 at 10:02 PM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > On Wed, Dec 9, 2015 at 6:46 PM, Konstantin Boudnik  >
> > > > wrote:
> > > > >
> > > > > > On Wed, Dec 09, 2015 at 04:01PM, Dmitriy Setrakyan wrote:
> > > > > > > Thanks Andrey!
> > > > > > >
> > > > > > > Why are we enabling peer class loading for the JDBC driver in
> > your
> > > > > > example?
> > > > > > > To my knowledge, we are not deploying any classes, are we?
> Also,
> > > the
> > > > > TCP
> > > > > > > discovery with multicast is the default, so no reason to
> specify
> > it
> > > > > > either.
> > > > > > >
> > > > > > > It seems that the only properly required is clientMode=true,
> no?
> > > > > >
> > > > > > If this is the case, then _no_ config is really needed, perhaps?
> > > > > >
> > > > >
> > > > > Well, we still need to specify clientMode, no?
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Wed, Dec 9, 2015 at 8:54 AM, Andrey Gura <
> ag...@gridgain.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Configuration sample added.
> > > > > > > >
> > > > > > > > On Tue, Dec 8, 2015 at 10:20 PM, Dmitriy Setrakyan <
> > > > > > dsetrak...@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks Andrey!
> > > > > > > > >
> > > > > > > > > In my view, we should also provide a sample XML
> configuration
> > > > file,
> > > > > > > > > especially given that we refer to it in the sample URL.
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Tue, Dec 8, 2015 at 10:17 AM, Andrey Gura <
> > > ag...@gridgain.com
> > > > >
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Done. I hope that is more clear now.
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 8, 2015 at 1:14 AM, Dmitriy Setrakyan <
> > > > > > > > dsetrak...@apache.org
> > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Mon, Dec 7, 2015 at 10:17 AM, Andrey Gura <
> > > > > ag...@gridgain.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Cos,
> > > > > > > > > > > >
> > > > > > > > > > > >  sepcifies configuration file for Ignite
> > > client
> > > > > > node
> > > > > > > > that
> > > > > > > > > > > will
> > > > > > > > > > > > be started during connection establishing by JDBC
> > driver.
> > > > So
> > > > > > this
> > > > > > > > > file
> > > > > > > > > > > > should be available for JDBC driver client.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Andrey, should this be documented here?
> > > > > > > > > > > https://apacheignite.readme.io/docs/jdbc-driver
> > > > > > > > > > >
> > > > > > > > > > > D.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, Dec 7, 2015 at 8:59 PM, Konstantin Boudnik <
> > > > > > c...@apache.org
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Thanks Andrey!
> > > > > > > > > > > > >
> > > > > > > > > > > > > Still a bit unclear: the doc says
> > > > > > > > > > > > > " is required and represents any valid
> > URL
> > > > > which
> > > > > > > > points
> > > > > > > > > > to
> > > > > > > > > > > > > Ignite configuration file"
> > > > > > > > > > > > >
> > > > > > > > > > > 

Re: Json support in Ignite

[Andrey Gura]

Hi,


> > Also we need following functionality for json objects
> >
> > 1. Possibility to map json cache key to affinity key. This can be
> achieved
> > with custom affinity mapper:
> >
> > cache.setAffinityMapper(new AffinityKeyMapper() {
> > @Override public Object affinityKey(Object key) {
> > return ((JsonObject)key).getJsonNumber("orgId").longValue();
> > }
> > });
> >
>
> We can also have a special field within JSON Object, called
> ignite_affinity_field=bla


+1

It looks like we are over architecting here.
>
> Keys should not have many fields, and most likely will have one or two.
> Iterating through fields and generating hash-code or equals the standard
> way seems reasonable (as opposed to creating a whole architecture around
> how to get hash and equals fields).
>
> If it makes sense, we should cache the hash code value inside the key
> object after it has been generated once.
>

I don't think that we should have some constraints here. If user wants to
use specific set of fields for hashCode/equals he should have such
possibility.

There is one more problem in hashCode/equals: how to handle cases when
specified field isn't mandatory?


On Wed, Jul 15, 2015 at 11:32 AM, Dmitriy Setrakyan 
wrote:

> On Wed, Jul 15, 2015 at 12:00 AM, Semyon Boikov 
> wrote:
>
> > Hi all,
> >
> > As part of integration with Node.Js (IGNITE-961) we age going to add in
> > Ignite support for JSON (possibility for IgniteCache to put, get, index
> and
> > query JSON data).
> >
> > We can implement standard 'javax.json' API (JSR 353), with this API work
> > with cache will look like in this example:
> >
> >
> Are we going to implement JSON specification ourselves? Sounds a bit fishy.
> Can we just take some available implementation (assuming that the license
> fits)?
>
>
>
> > Ignite should somehow provide access to 'javax.json' API, unfortunately
> > 'javax.json' is not part of JDK so we have several options how it can be
> > added in Ignite:
> >
> > 1. Add dependency for 'javax.json-api' in core module, in this case we
> can
> > have method to get access for json API on 'org.apache.ignite.Ignite':
> >
> > * interface Ignite {*
> > *...*
> >
> > *javax.json.JsonProvider json();*
> > * }*
> >
> > * JsonProvider json = ignite.json();*
> >
> > Not sure it is ok, since now we don't have 3rd party dependencies in
> ignite
> > 'core' module except 'javax.cache' API.
> >
> > 2. Added another optional module 'json', this module will have dependency
> > for 'javax.json' API, and in this module we can have factory providing
> > access to 'javax.json' API:
> >
>
> I think an optional module makes sense.
>
>
>
> >
> > 3. Create plugin for json, in this case plugin will provide access to
> > 'javax.json' API:
> >
> > * IgniteJsonPlugin jsonPlugin = ignite.plugin(IgniteJsonPlugin.NAME);*
> >
> > * javax.json.JsonProvider provider = jsonPlugin.json();*
> >
> >
> > Not sure this aproach with plugin is ok, since now we don't have 'core'
> > ignite functionality implemented as plugins.
> >
>
> Agree, this probably won't work.
>
>
>
> > Also we need following functionality for json objects
> >
> > 1. Possibility to map json cache key to affinity key. This can be
> achieved
> > with custom affinity mapper:
> >
> > cache.setAffinityMapper(new AffinityKeyMapper() {
> > @Override public Object affinityKey(Object key) {
> > return ((JsonObject)key).getJsonNumber("orgId").longValue();
> > }
> > });
> >
>
> We can also have a special field within JSON Object, called
> ignite_affinity_field=bla
>
>
> >
> > 2. Efficient implementation for equals/hashCode for json cache keys.
> >
> > One option is just have equals/hashCode like in HashMap.
> >
> > Another option can be add special JsonConfiguration, it should be set in
> > CacheConfiguration and can contain following settings:
> > - list of fields to use in 'equals' and 'hashCode' calculation
> > - alternatively for equals/hashCode we can provide possibility to
> implement
> > custom comparator/hash code calculator
> > - JsonConfiguration can have setting for affinity key
> >
> > So JsonConfiguration can look like this:
> >
> > *class JsonConfiguration {*
> > */***
> > * * Field names for hash code calculation.*
> > * */*
> > *public Collection getKeyHashCodeFields();*
> >
> > */***
> > * * Field names to use .*
> > * */*
> > *public Collection getKeyEqualsFields();*
> >
> > */***
> > * * Field name to get key which will be used for node affinity
> > calculation.*
> > * */*
> > *public String getAffinityKeyField();*
> > *}*
> >
>
> It looks like we are over architecting here.
>
> Keys should not have many fields, and most likely will have one or two.
> Iterating through fields and generating hash-code or equals the standard
> way seems reasonable (as opposed to creating a whole architecture around
> how to get hash and equals 

[jira] [Created] (IGNITE-2385) Rename metadata to domain model

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-2385:
-

 Summary: Rename metadata to domain model
 Key: IGNITE-2385
 URL: https://issues.apache.org/jira/browse/IGNITE-2385
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko






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

[jira] [Created] (IGNITE-2387) Ignite puzzle picture on readme.io has broken size in FireFox

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2387:
--

 Summary: Ignite puzzle picture on readme.io has broken size in 
FireFox
 Key: IGNITE-2387
 URL: https://issues.apache.org/jira/browse/IGNITE-2387
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Priority: Minor






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

[GitHub] ignite pull request: Switch off update notifier

[vkulichenko]

GitHub user vkulichenko opened a pull request:

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

Switch off update notifier



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

$ git pull https://github.com/vkulichenko/incubator-ignite gg-10952

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

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


commit cd002f1fad3595d0b3a38f68ad36f1afc6f68da0
Author: Valentin Kulichenko 
Date:   2016-01-15T03:38:34Z

Switch off update notifier




---
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-2384) Notification missed in continuous query

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-2384:
---

 Summary: Notification missed in continuous query
 Key: IGNITE-2384
 URL: https://issues.apache.org/jira/browse/IGNITE-2384
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 1.6


Test reproducing the issue is attached, fails on assertion on line 76.



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

Re: Stupide question about Queue ?

[Valentin Kulichenko]

Agree with Denis. Sounds like this can be easily achieved by enabling swap
layer for queue cache. So we just need to put this on configuration.

-Val

On Thu, Jan 14, 2016 at 5:44 AM, Denis Magda  wrote:

> Hi,
>
> This seems to be an interesting functionality. As I understand you're
> referring to [1].
>
> Personally I think that it makes sense to support the same in Ignite.
> However I would just extend CollectionConfiguration adding ability to set
> an eviction policy and enable swap on demand. When eviction policy faces
> with a limit entries will be evicted to swap space.
> Don't think that we need to support other kind of storages here.
>
> Igniters, do you have other thoughts on this?
>
> [1] http://docs.hazelcast.org/docs/3.5/manual/html/queue-persistence.html
>
> --
> Denis
>
>
> On 1/14/2016 1:41 PM, Yann BLAZART wrote:
>
> Hello,
>
>
>
> In hazelcast we can persist Queues in Database, this  help me for example
> when consumer are down to no have OOM exception.
>
>
>
> But I don’t see this possibility in Ignite docs ?
>
>
>
> This message and any attachments (the "message") is
> intended solely for the intended addressees and is confidential.
> If you receive this message in error,or are not the intended recipient(s),
> please delete it and any copies from your systems and immediately notify
> the sender. Any unauthorized view, use that does not comply with its
> purpose,
> dissemination or disclosure, either whole or partial, is prohibited. Since
> the internet
> cannot guarantee the integrity of this message which may not be reliable,
> BNP PARIBAS
> (and its subsidiaries) shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary,consider the environment.
>
>
> --
>
> Ce message et toutes les pieces jointes (ci-apres le "message")
> sont etablis a l'intention exclusive de ses destinataires et sont
> confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
> merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
> immediatement l'expediteur. Toute lecture non autorisee, toute utilisation
> de
> ce message qui n'est pas conforme a sa destination, toute diffusion ou
> toute
> publication, totale ou partielle, est interdite. L'Internet ne permettant
> pas d'assurer
> l'integrite de ce message electronique susceptible d'alteration, BNP
> Paribas
> (et ses filiales) decline(nt) toute responsabilite au titre de ce message
> dans l'hypothese
> ou il aurait ete modifie, deforme ou falsifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
>
>
>

Re: Stupide question about Queue ?

[Murthy Kakarlamudi]

What are the possibilities for swap spaces? Can we persist the cache/queue
content to file system based on the eviction policy?

Thanks,
Murthy.

On Thu, Jan 14, 2016 at 5:23 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Agree with Denis. Sounds like this can be easily achieved by enabling swap
> layer for queue cache. So we just need to put this on configuration.
>
> -Val
>
> On Thu, Jan 14, 2016 at 5:44 AM, Denis Magda  wrote:
>
>> Hi,
>>
>> This seems to be an interesting functionality. As I understand you're
>> referring to [1].
>>
>> Personally I think that it makes sense to support the same in Ignite.
>> However I would just extend CollectionConfiguration adding ability to set
>> an eviction policy and enable swap on demand. When eviction policy faces
>> with a limit entries will be evicted to swap space.
>> Don't think that we need to support other kind of storages here.
>>
>> Igniters, do you have other thoughts on this?
>>
>> [1] http://docs.hazelcast.org/docs/3.5/manual/html/queue-persistence.html
>>
>> --
>> Denis
>>
>>
>> On 1/14/2016 1:41 PM, Yann BLAZART wrote:
>>
>> Hello,
>>
>>
>>
>> In hazelcast we can persist Queues in Database, this  help me for example
>> when consumer are down to no have OOM exception.
>>
>>
>>
>> But I don’t see this possibility in Ignite docs ?
>>
>>
>>
>> This message and any attachments (the "message") is
>> intended solely for the intended addressees and is confidential.
>> If you receive this message in error,or are not the intended
>> recipient(s),
>> please delete it and any copies from your systems and immediately notify
>> the sender. Any unauthorized view, use that does not comply with its
>> purpose,
>> dissemination or disclosure, either whole or partial, is prohibited.
>> Since the internet
>> cannot guarantee the integrity of this message which may not be reliable,
>> BNP PARIBAS
>> (and its subsidiaries) shall not be liable for the message if modified,
>> changed or falsified.
>> Do not print this message unless it is necessary,consider the environment.
>>
>>
>> --
>>
>> Ce message et toutes les pieces jointes (ci-apres le "message")
>> sont etablis a l'intention exclusive de ses destinataires et sont
>> confidentiels.
>> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
>> merci de le detruire ainsi que toute copie de votre systeme et d'en
>> avertir
>> immediatement l'expediteur. Toute lecture non autorisee, toute
>> utilisation de
>> ce message qui n'est pas conforme a sa destination, toute diffusion ou
>> toute
>> publication, totale ou partielle, est interdite. L'Internet ne permettant
>> pas d'assurer
>> l'integrite de ce message electronique susceptible d'alteration, BNP
>> Paribas
>> (et ses filiales) decline(nt) toute responsabilite au titre de ce message
>> dans l'hypothese
>> ou il aurait ete modifie, deforme ou falsifie.
>> N'imprimez ce message que si necessaire, pensez a l'environnement.
>>
>>
>>
>

[jira] [Created] (IGNITE-2388) Security issue in corner case

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2388:
--

 Summary: Security issue in corner case
 Key: IGNITE-2388
 URL: https://issues.apache.org/jira/browse/IGNITE-2388
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


To reproduce:
1) you should have admin rights
2) open admin page
3) become a ordinary user
4) click Back in browser

Observed: ordinary user can get access to admin page
Expected:  admin page must be inaccessible for ordinary user 



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

Re: GridFutureAdapter: deprecate startTime(), duration() and endTime()

[Dmitriy Setrakyan]

Really hard to believe that removing 16 bytes in futures gives 5% of
performance. Yakov, are you certain about this?

If this turns out to be true, let’s see if we can slim down the futures
used internally, without breaking the public API.

D.

On Thu, Jan 14, 2016 at 8:36 AM, Vladimir Ozerov 
wrote:

> +1
>
> BTW, corresponding ticket already exists. You can find it under umbrella
> ticket IGNITE-2232
> 14 янв. 2016 г. 18:40 пользователь "Yakov Zhdanov" 
> написал:
>
> > Guys,
> >
> > We have startTime(), duration() and endTime() methods which have several
> > usages each along internals of the project, but to support these methods
> we
> > have 2 long fields in GridFutureAdapter which gives us 16 bytes.
> >
> > Other fields - res (reference 8 bytes at max), ignoreInterrupts (boolean
> 1
> > byte) and resFlag (byte 1 byte) = 10 bytes
> >
> > I did quick tests and I see that removing these fields (i.e. making each
> > future 16 bytes thinner) can give us 5-6% in performance results.
> >
> > I want to deprecate  startTime(), duration() and endTime() and therefore
> > deprecate corresponding methods in IgniteFuture.
> >
> > Thoughts?
> >
> > --Yakov
> >
>

Persistence in queues and sets

[Valentin Kulichenko]

Igniters,

It sounds like users could be interested in being able to persist the data
saved in queues and sets. See the thread on user list [1].

The obvious solution is to reuse our CacheStore interface, but I'm not sure
that this is possible because it's designed for key-value storage. E.g.,
what is the key for a set element? In case of a queue we also need to be
able to preserve order after writing to the database and reloading.

Any ideas how to achieve this?

-Val

[1]
http://apache-ignite-users.70518.x6.nabble.com/Stupide-question-about-Queue-td2557.html

[GitHub] ignite pull request: IGNITE-2099 - Fixing custom collections.

[asfgit]

Github user asfgit closed the pull request at:

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


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

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Persistence in queues and sets

[Dmitriy Setrakyan]

I think we need a specialized CollectionStore API for this. Something that
will receive an element value and its index (if index is required).

D.

On Thu, Jan 14, 2016 at 11:31 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igniters,
>
> It sounds like users could be interested in being able to persist the data
> saved in queues and sets. See the thread on user list [1].
>
> The obvious solution is to reuse our CacheStore interface, but I'm not sure
> that this is possible because it's designed for key-value storage. E.g.,
> what is the key for a set element? In case of a queue we also need to be
> able to preserve order after writing to the database and reloading.
>
> Any ideas how to achieve this?
>
> -Val
>
> [1]
>
> http://apache-ignite-users.70518.x6.nabble.com/Stupide-question-about-Queue-td2557.html
>

[GitHub] ignite pull request: Switch off update notifier

[vkulichenko]

Github user vkulichenko closed the pull request at:

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


---
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: Stupide question about Queue ?

[Valentin Kulichenko]

Created ticket for queue swapping feature:
https://issues.apache.org/jira/browse/IGNITE-2389

Feel free to provide feedback.

-Val

On Thu, Jan 14, 2016 at 3:24 PM, Murthy Kakarlamudi 
wrote:

> What are the possibilities for swap spaces? Can we persist the cache/queue
> content to file system based on the eviction policy?
>
> Thanks,
> Murthy.
>
> On Thu, Jan 14, 2016 at 5:23 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Agree with Denis. Sounds like this can be easily achieved by enabling
>> swap layer for queue cache. So we just need to put this on configuration.
>>
>> -Val
>>
>> On Thu, Jan 14, 2016 at 5:44 AM, Denis Magda  wrote:
>>
>>> Hi,
>>>
>>> This seems to be an interesting functionality. As I understand you're
>>> referring to [1].
>>>
>>> Personally I think that it makes sense to support the same in Ignite.
>>> However I would just extend CollectionConfiguration adding ability to
>>> set an eviction policy and enable swap on demand. When eviction policy
>>> faces with a limit entries will be evicted to swap space.
>>> Don't think that we need to support other kind of storages here.
>>>
>>> Igniters, do you have other thoughts on this?
>>>
>>> [1]
>>> http://docs.hazelcast.org/docs/3.5/manual/html/queue-persistence.html
>>>
>>> --
>>> Denis
>>>
>>>
>>> On 1/14/2016 1:41 PM, Yann BLAZART wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> In hazelcast we can persist Queues in Database, this  help me for
>>> example when consumer are down to no have OOM exception.
>>>
>>>
>>>
>>> But I don’t see this possibility in Ignite docs ?
>>>
>>>
>>>
>>> This message and any attachments (the "message") is
>>> intended solely for the intended addressees and is confidential.
>>> If you receive this message in error,or are not the intended
>>> recipient(s),
>>> please delete it and any copies from your systems and immediately notify
>>> the sender. Any unauthorized view, use that does not comply with its
>>> purpose,
>>> dissemination or disclosure, either whole or partial, is prohibited.
>>> Since the internet
>>> cannot guarantee the integrity of this message which may not be
>>> reliable, BNP PARIBAS
>>> (and its subsidiaries) shall not be liable for the message if modified,
>>> changed or falsified.
>>> Do not print this message unless it is necessary,consider the
>>> environment.
>>>
>>>
>>> --
>>>
>>> Ce message et toutes les pieces jointes (ci-apres le "message")
>>> sont etablis a l'intention exclusive de ses destinataires et sont
>>> confidentiels.
>>> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
>>> merci de le detruire ainsi que toute copie de votre systeme et d'en
>>> avertir
>>> immediatement l'expediteur. Toute lecture non autorisee, toute
>>> utilisation de
>>> ce message qui n'est pas conforme a sa destination, toute diffusion ou
>>> toute
>>> publication, totale ou partielle, est interdite. L'Internet ne
>>> permettant pas d'assurer
>>> l'integrite de ce message electronique susceptible d'alteration, BNP
>>> Paribas
>>> (et ses filiales) decline(nt) toute responsabilite au titre de ce
>>> message dans l'hypothese
>>> ou il aurait ete modifie, deforme ou falsifie.
>>> N'imprimez ce message que si necessaire, pensez a l'environnement.
>>>
>>>
>>>
>>
>

[jira] [Created] (IGNITE-2390) IGFS path modes are not honored

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2390:
---

 Summary: IGFS path modes are not honored
 Key: IGNITE-2390
 URL: https://issues.apache.org/jira/browse/IGNITE-2390
 Project: Ignite
  Issue Type: Bug
  Components: IGFS
Affects Versions: 1.5
Reporter: Denis Magda
 Fix For: 1.6


The following configuration is used with some specific path modes.












On running a simple MR job an output dir is set under /tmp
e.g.
/tmp/denis2

as such I would expect this to be in memory only, and no changes seen on the 
secondary file system as path is set to PRIMARY.

On checking HDFS I find that these files are created by Ignite on the secondary 
file system.

Found that document here:
http://apacheignite.gridgain.org/docs/modes

is incorrect, the paths are not regex patterns as this document implies, but 
simply the code checks if path string starts with.
Have removed /.* from the above config and seems to be resolved.

The configuration must be fixed or the code.



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

Re: Binary ID mapper that uses a simple name of classes.

[Dmitriy Setrakyan]

On Thu, Jan 14, 2016 at 3:39 AM, Yakov Zhdanov  wrote:

> I would suggest "SimpleClassNameBinaryIdMapper"
>

Is it consistent? Do we have other classes in the same package that start
with word Binary? If not, then I agree.


>
> --Yakov
>
> 2016-01-14 4:59 GMT+03:00 Dmitriy Setrakyan :
>
> > I like the last one too.
> >
> > On Wed, Jan 13, 2016 at 7:54 AM, Artem Shutak 
> > wrote:
> >
> > > Igniters,
> > >
> > > I'm working on https://issues.apache.org/jira/browse/IGNITE-2191
> (Binary
> > > marshaller: support user classes with the same simple name) bug.
> > >
> > > The fix expects new BinaryIdMapper that uses a simple name of classes.
> It
> > > is required for supporting of platforms (.Net. C++).
> > >
> > > I would be glade to hear suggestions about good name for this mapper.
> > >
> > > I propose the following:
> > > - BinaryPlatformIdMapper
> > > - BinaryInteropIdMapper
> > > - SimpleNameBinaryIdMapper
> > > - BinarySimpleNameIdMapper
> > >
> > > I like the last one, but it has a big length.
> > >
> > > Thanks,
> > > -- Artem --
> > >
> >
>

Re: What is jdbc:ignite:cfg ??

[Dmitriy Setrakyan]

Andrey, I am still a bit unclear. Why not have ability to specify a default
cache per notebook, not per-interpreter?

On Thu, Jan 14, 2016 at 8:42 AM, Andrey Gura  wrote:

> Hello,
>
> JFYI, I created ticket as result of this discussion:
> https://issues.apache.org/jira/browse/IGNITE-2382
>
>
>
> On Thu, Dec 10, 2015 at 10:29 PM, Dmitriy Setrakyan  >
> wrote:
>
> > Andrey,
> >
> > I agree on both points. However, I still think that we should provide
> > sample step-by-step guide with a sample configuration. This configuration
> > should include a couple of data types, like Person and Organization,
> define
> > indexes for them, etc.
> >
> > This guide should include:
> >
> > 1. Start Ignite Servers
> > 2. Populate data - should have example with configuration.
> > 3. Query data using JDBC driver - example code and, if needed,
> > configuration to support it.
> >
> > Do you mind adding it?
> >
> > D.
> >
> > On Thu, Dec 10, 2015 at 7:50 AM, Andrey Gura  wrote:
> >
> > > I didn't think that we should force client mode at moment of
> > > implementation. But I can't provide any reason not to do it.
> > >
> > > So we need two small improvements to JDBC driver:
> > >
> > > 1. Always force client mode.
> > > 2. Use default configuration in cases when user did't specify any URL.
> > This
> > > configuration should just use client mode and default values for rest
> > > properties.
> > >
> > > Right?
> > >
> > > On Thu, Dec 10, 2015 at 9:05 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > On Wed, Dec 9, 2015 at 10:04 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Actually, why don't we set it automatically? It doesn't make much
> > sense
> > > > to
> > > > > have a server node in a JDBC driver.
> > > > >
> > > >
> > > > Completely agree.
> > > >
> > > >
> > > > >
> > > > > -Val
> > > > >
> > > > > On Wed, Dec 9, 2015 at 10:02 PM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > On Wed, Dec 9, 2015 at 6:46 PM, Konstantin Boudnik <
> c...@apache.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > On Wed, Dec 09, 2015 at 04:01PM, Dmitriy Setrakyan wrote:
> > > > > > > > Thanks Andrey!
> > > > > > > >
> > > > > > > > Why are we enabling peer class loading for the JDBC driver in
> > > your
> > > > > > > example?
> > > > > > > > To my knowledge, we are not deploying any classes, are we?
> > Also,
> > > > the
> > > > > > TCP
> > > > > > > > discovery with multicast is the default, so no reason to
> > specify
> > > it
> > > > > > > either.
> > > > > > > >
> > > > > > > > It seems that the only properly required is clientMode=true,
> > no?
> > > > > > >
> > > > > > > If this is the case, then _no_ config is really needed,
> perhaps?
> > > > > > >
> > > > > >
> > > > > > Well, we still need to specify clientMode, no?
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Wed, Dec 9, 2015 at 8:54 AM, Andrey Gura <
> > ag...@gridgain.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Configuration sample added.
> > > > > > > > >
> > > > > > > > > On Tue, Dec 8, 2015 at 10:20 PM, Dmitriy Setrakyan <
> > > > > > > dsetrak...@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Thanks Andrey!
> > > > > > > > > >
> > > > > > > > > > In my view, we should also provide a sample XML
> > configuration
> > > > > file,
> > > > > > > > > > especially given that we refer to it in the sample URL.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 8, 2015 at 10:17 AM, Andrey Gura <
> > > > ag...@gridgain.com
> > > > > >
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Done. I hope that is more clear now.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 8, 2015 at 1:14 AM, Dmitriy Setrakyan <
> > > > > > > > > dsetrak...@apache.org
> > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Mon, Dec 7, 2015 at 10:17 AM, Andrey Gura <
> > > > > > ag...@gridgain.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Cos,
> > > > > > > > > > > > >
> > > > > > > > > > > > >  sepcifies configuration file for
> Ignite
> > > > client
> > > > > > > node
> > > > > > > > > that
> > > > > > > > > > > > will
> > > > > > > > > > > > > be started during connection establishing by JDBC
> > > driver.
> > > > > So
> > > > > > > this
> > > > > > > > > > file
> > > > > > > > > > > > > should be available for JDBC driver client.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Andrey, should this be documented here?
> > > > > > > > > > > > https://apacheignite.readme.io/docs/jdbc-driver
> > > > > > > > > > > >
> > > > > > > > > > > > D.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 

[GitHub] ignite pull request: ignite-2080 Data alignment issues with Unsafe

[agura]

Github user agura closed the pull request at:

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


---
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-2080 Data alignment issues with Unsafe

[agura]

GitHub user agura opened a pull request:

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

ignite-2080 Data alignment issues with Unsafe



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

$ git pull https://github.com/agura/incubator-ignite ignite-2080

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

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


commit 55dcf76515eb3bf136c33baf5ac42ab01bdbc352
Author: agura 
Date:   2016-01-11T11:53:02Z

ignite-2080 Data alignment issues with Unsafe




---
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-2382) Force client mode in JDBC driver and provide default configuration file

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-2382:
---

 Summary: Force client mode in JDBC driver and provide default 
configuration file
 Key: IGNITE-2382
 URL: https://issues.apache.org/jira/browse/IGNITE-2382
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Gura
Assignee: Andrey Gura
Priority: Minor
 Fix For: 1.6


#. There is no reason to start server node during creation JDBC connection. So 
client mode should be forced.
#. If user didn't specify any configuration file in JDBC URL then default 
configuration file should be used.
#. Remove multicast IP finder from example because it is default IP finder.

See laso discussion here: 
http://apache-ignite-developers.2346864.n4.nabble.com/What-is-jdbc-ignite-cfg-td5573.html



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

GridFutureAdapter: deprecate startTime(), duration() and endTime()

[Yakov Zhdanov]

Guys,

We have startTime(), duration() and endTime() methods which have several
usages each along internals of the project, but to support these methods we
have 2 long fields in GridFutureAdapter which gives us 16 bytes.

Other fields - res (reference 8 bytes at max), ignoreInterrupts (boolean 1
byte) and resFlag (byte 1 byte) = 10 bytes

I did quick tests and I see that removing these fields (i.e. making each
future 16 bytes thinner) can give us 5-6% in performance results.

I want to deprecate  startTime(), duration() and endTime() and therefore
deprecate corresponding methods in IgniteFuture.

Thoughts?

--Yakov

Re: Ignite as Big Data project built on Mesos

[Vinod Kone]

Can you send a PR on github/apache/mesos or submit a review
?.

On Wed, Jan 13, 2016 at 6:30 PM, Dmitriy Setrakyan 
wrote:

> Hello Mesos community!
>
> Ignite community would like to add Apache Ignite to this page on Mesos
> website:
> http://mesos.apache.org/documentation/latest/frameworks/
>
> Ignite integrates and runs on top of Mesos very well. Here is the
> documentation for it:
> https://apacheignite.readme.io/docs/mesos-deployment
>
> Can you please advise on what needs to be done to add Ignite on that page?
>
> Thanks,
> D.
>