[jira] [Created] (IGNITE-2741) Ignite as Spring Session data store

[Roman Shtykh (JIRA)]

Roman Shtykh created IGNITE-2741:


 Summary: Ignite as Spring Session data store
 Key: IGNITE-2741
 URL: https://issues.apache.org/jira/browse/IGNITE-2741
 Project: Ignite
  Issue Type: New Feature
Reporter: Roman Shtykh


On Spring Session: 
http://docs.spring.io/spring-session/docs/current/reference/html5/#
How to contribute the integration: 
http://docs.spring.io/spring-session/docs/current/reference/html5/#community-contributing

_From 1.1.0 Gemfire and Hazelcast are supported and can be used for reference, 
if needed._



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

[GitHub] ignite pull request: IGNITE-2705 .NET: Add a test to verify ToolsV...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 2718: Missing ZookeeperIpFinder depend...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2710: Proper invalidation of session w...

[shroman]

GitHub user shroman opened a pull request:

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

Ignite-2710: Proper invalidation of session within a request.



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

$ git pull https://github.com/shroman/ignite ignite-2710

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

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


commit 827d7ff5ce08c70e3980910b02310d840c341976
Author: shtykh_roman 
Date:   2016-03-01T09:22:55Z

IGNITE-2710: Proper invalidation of session within a request.

commit 828fa8c7b73750b247316ef0d668cd4cb49df410
Author: shtykh_roman 
Date:   2016-03-01T09:58:42Z

IGNITE-2710: Proper invalidation of session within a request. Disabled 
testInvalidatedSession for transactional cache.




---
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: Binary comparator

[Valentin Kulichenko]

Andrey,

Any comparable object can be used as a field. You can execute a query like
'my_object > ?' and provide the instance of the object as an argument. Of
course, this is not something that everyone does, but it can be useful in
some cases. And now it's fully supported with JDK or optimized
serialization, but not with binary format.

I agree with all points, the simple approach doesn't really work here. And
I like the idea of a string-based configuration, I will try to provide
design in the ticket.

-Val

On Tue, Mar 1, 2016 at 7:42 AM, Andrey Kornev 
wrote:

> Val,
>
> Just to clarify, are you talking about indexing a whole binary object as a
> single entity (rather than individually indexing its fields)? If so, how
> would one then use such "field" in a SQL query?
>
> Thanks
> Andrey
>
> > From: valentin.kuliche...@gmail.com
> > Date: Mon, 29 Feb 2016 21:18:39 -0800
> > Subject: Binary comparator
> > To: dev@ignite.apache.org
> >
> > Igniters,
> >
> > We currently have a pretty serious limitation for binary objects: they
> can
> > be used as SQL fields and can't be indexed, because we don't know how to
> > compare them. And it seems to me that it can be easily fixed by adding an
> > optional comparator to BinaryConfiguration and BinaryTypeConfiguration:
> >
> > public void setComparator(Comparator comparator)
> >
> > Are there any pitfalls that I'm missing?
> >
> > -Val
>
>

Re: Beta-releases for particular features.

[Dmitriy Setrakyan]

In my opinion, if a certain feature is experimental, we should simply
mention it in the release notes and/or documentation. I would not create a
separate beta release just for a certain feature.

D.

On Tue, Mar 1, 2016 at 6:57 AM, Pavel Tupitsyn 
wrote:

> Hi,
>
> I don't think that features like LINQ and ODBC need the same approach
> as IDEA EAP. IntelliJ has EAP because new features may have bugs
> or usability issues. With LINQ and ODBC our main concern are not bugs,
> but unsupported use cases that we did not think of. Known use cases
> are covered with tests.
>
> Beta releases may not get enough attention to gather feedback.
> I think we should release these features right away and gradually add
> support
> for missing use cases, if any emerge. We are not going to change API or
> break compatibility while adding these things in future.
>
> Furthermore, LINQ is only a usability feature. Users can always switch to
> raw SQL
> if something can't be expressed in LINQ.
>
> On Tue, Mar 1, 2016 at 10:44 AM, Vladimir Ozerov 
> wrote:
>
> > Igniters,
> >
> > I want to circulate again an idea of "betas" for particular product
> > features.
> >
> > For now we have several pretty cool features which are to be released
> soon:
> > ODBC driver and LINQ in .NET. Features like this include potentially
> > infinite amount of use cases and of course we cannot test all of them. I
> > believe things like this should go through extended release cycle so that
> > we have time to get user's feedback before officially announcing them. It
> > could be betas, early previews, whatever.
> >
> > The main idea is that we have a time window to obtain a feedback and
> > stabilize the feature.
> >
> > This is a common practice for more or less big products. E.g. see
> Hazelcast
> > python client [1] and Intellij IDEA EAP 16 [2].
> >
> > Thoughts?
> >
> > [1] https://pypi.python.org/pypi/hazelcast-python-client
> > [2] https://confluence.jetbrains.com/display/IDEADEV/IDEA+16+EAP
> >
> > Vladimir.
> >
>

[jira] [Created] (IGNITE-2740) .NET: IGNITE_HOME resolution restricts custom deployment

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2740:
--

 Summary: .NET: IGNITE_HOME resolution restricts custom deployment
 Key: IGNITE-2740
 URL: https://issues.apache.org/jira/browse/IGNITE-2740
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Blocker
 Fix For: 1.6


Need to make sure that users may deploy Ignite JARs with their applications in 
any way they want.

Currently we have quite restrictive checks in IgniteHome.IsIgniteHome method.

Documentation should also be updated.



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

[GitHub] ignite pull request: IGNITE-2705 .NET: Add a test to verify ToolsV...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-2705 .NET: Add a test to verify ToolsVersion in project and solution 
files



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

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

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

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


commit a541b6ca6844b7884a2dd7cb2df205149454f1de
Author: Pavel Tupitsyn 
Date:   2016-03-01T16:12:05Z

IGNITE-2705 .NET: Add a test to verify ToolsVersion in project and solution 
files




---
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: Fix for jCache TCK

[ashutakGG]

GitHub user ashutakGG opened a pull request:

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

Fix for jCache TCK



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

$ git pull https://github.com/ashutakGG/incubator-ignite jcache-tck-fix

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

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


commit 31360c8e12757d3ae084f6d43af9ebc0a9bd27ec
Author: ashutak 
Date:   2016-03-01T15:50:09Z

jcache tck fix




---
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-2739) .NET: AffinityKey support

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2739:
--

 Summary: .NET: AffinityKey support
 Key: IGNITE-2739
 URL: https://issues.apache.org/jira/browse/IGNITE-2739
 Project: Ignite
  Issue Type: Task
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
 Fix For: 1.6


Add AffinityKey to allow custom affinity mapping.
This is crucial for SQL joins to work properly.
See org.apache.ignite.cache.affinity.AffinityKey in Java.



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

Multimap implementation attempt

[Konstantin Margorin]

Hello Igniters.

I'm trying now to implement Multimap datastructure. I wrote a comment about
implementation details here:

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

Now I got Multimap prototype with put/get methods:

https://github.com/apache/ignite/compare/master...ruskim:ignite-640?expand=1

This basic test for put/get successfully passed:

https://github.com/ruskim/ignite/blob/2af6274f9234dda1550696014ffd8e327d75da57/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/datastructures/GridCacheMultimapSelfTest.java

A lot of thing I did by analogy with IgniteQueue and IgniteSet. I realize,
that most probably I made a lot of errors.

Before moving further I want to be sure that basic things, like put/get,
implemented properly.

Probably someone could look at my code and point me at most serious errors.

Thank you!

Konstantin

Re: Binary comparator

[Yakov Zhdanov]

Vladimir,

1. Comparator can be included to ignite and may be configured with a string
like: "this.a > other.a && (this.b + 1 < other.b)". String may be parsed
and interpreted. We can also have JavaScript comparator.
2. Agree, but cannot say how to avoid it. Actually, comparison logic may
not be needed on client.
3. I would avoid requirement to have any classes on server. Let's think how
to support object comparison without forcing class presence. This will make
Ignite cluster more flexible.

Frankly speaking, object comparison can be avoided and replaced by inlining
the fields and defining group index. Am I right?

--Yakov

2016-03-01 9:23 GMT+03:00 Vladimir Ozerov :

> Val,
>
> Comparator has two problems from user perspective:
> 1) User will be obligated to have comparator classes on servers.
> BinaryMarshaller was designed to avoid this.
> 2) Code duplication - user will have to support two implementations - one
> for deserialized form, and one for binary form.
>
> As it appears that user is going to have some kind of classes on the
> server, why not simply deserialize cache objects and perform normal
> comparison?
>
> Vladimir.
>
> On Tue, Mar 1, 2016 at 9:06 AM, Dmitriy Setrakyan 
> wrote:
>
> > Why can’t we simply compare the binary arrays?
> >
> > On Mon, Feb 29, 2016 at 9:18 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > We currently have a pretty serious limitation for binary objects: they
> > can
> > > be used as SQL fields and can't be indexed, because we don't know how
> to
> > > compare them. And it seems to me that it can be easily fixed by adding
> an
> > > optional comparator to BinaryConfiguration and BinaryTypeConfiguration:
> > >
> > > public void setComparator(Comparator comparator)
> > >
> > > Are there any pitfalls that I'm missing?
> > >
> > > -Val
> > >
> >
>

[GitHub] ignite pull request: Ignite 2650

[avinogradovgg]

Github user avinogradovgg closed the pull request at:

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


---
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: Full API coverage enhancement

[Artem Shutak]

>> Is this suite turned on by default?

Yes, see "Ignite Cache Full API Basic Config Variations" [1].

[1]
http://204.14.53.151/viewType.html?buildTypeId=IgniteTests_IgniteCacheFullApiNewBasicCfgDynamicCacheStartNotReady_IgniteTests=%3Cdefault%3E=buildTypeStatusDiv

Thanks,
-- Artem --

On Tue, Mar 1, 2016 at 11:48 AM, Artem Shutak  wrote:

>
>
> -- Artem --
>
> On Tue, Mar 1, 2016 at 1:31 AM, Dmitriy Setrakyan 
> wrote:
>
>> Thanks Artem! I think this test suite should go a long way towards
>> removing
>> issues with different configuration property permutations.
>>
>> Is this suite turned on by default?
>>
>> D.
>>
>> On Mon, Feb 29, 2016 at 7:07 AM, Artem Shutak 
>> wrote:
>>
>> > Igniters,
>> >
>> > I'm glad to announce that Configuration Variations test framework has
>> been
>> > merged to master and is ready to use.
>> >
>> > The framework provides an opportunity to write a test-case once and to
>> run
>> > it in many Ignite and Cache configuration variations, for different
>> Ignite
>> > topologies (with and without clients) and execute the same test scenario
>> > from different Ignite nodes (server and client) automatically.
>> >
>> > Another useful feature is "runInAllDataModes" functionality that allows
>> to
>> > run test-case and run it in all supported by framework data modes (like
>> > Serializable, Externalizable, plane, mixed and etc. objects).
>> >
>> > I've added the framework description on "Implementing Tests" [1] page.
>> > Please, feel free to comment.
>> >
>> > As proof-of-concept I've
>> > added IgniteCacheBasicConfigVariationsFullApiTestSuite and add it on TC.
>> >
>> > It does not mean that the work on IGNITE-2521
>> >  is completed and we
>> > have coverage for full Ignite API, but I think it is a good improvement
>> for
>> > Ignite's test framework and Igniters can test functionality better and
>> > simpler.
>> >
>> > [1]
>> https://cwiki.apache.org/confluence/display/IGNITE/Implementing+Tests
>> > (see "Configuration variations test framework" section).
>> >
>> > Thanks,
>> > -- Artem --
>> >
>> > On Thu, Feb 11, 2016 at 12:29 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org
>> > >
>> > wrote:
>> >
>> > > Agree about separation. I think we need to define some internal
>> > > permutations that keep coming up with bugs. I can start the list here:
>> > >
>> > >1. Serializable, Externalizable, neither.
>> > >1. We should run the whole suite 3 times, once for each
>> serialization
>> > >   mode. Having 2 or 3 nodes in the cluster here should be enough.
>> > > No need to
>> > >   test it on the changing cluster.
>> > >2. On-heap and off-heap with entry processor and peer-deployment
>> > >1. on-heap, entry-processor, peer-deployment=true/false
>> > >   2. off-heap, entry-processor, peer-deployment=true/false
>> > >3. On-heap and off-heap with eviction policies
>> > >   1. eviction policy, memory-mode=on-heap
>> > >   2. eviction policy, memory-mode=off-heap
>> > >   3. eviction policy, memory-mode=off-heap-values
>> > >4. On-heap and off-heap with continuous queries and
>> > >peer-deployment=true/false
>> > >5. …
>> > >
>> > > I think we can come up with about 20 most important permutations.
>> > Thoughts?
>> > >
>> > > D.
>> > >
>> > >
>> > > On Wed, Feb 10, 2016 at 9:24 AM, Alexey Goncharuk <
>> > > alexey.goncha...@gmail.com> wrote:
>> > >
>> > > > Dmitriy, the size of the circular buffer can be decreased by setting
>> > > > IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE system property.
>> > > >
>> > > > I was wondering what our next steps will be after implementing the
>> > > > framework. From the initial discussion I thought we want to convert
>> > some
>> > > > older tests to this new framework and run all new tests using this
>> > > > framework. However, from what Artem already has written, this sounds
>> > > > unrealistic because adding even a simple test case will induce
>> hours of
>> > > run
>> > > > time. I think we still need to separate more important and less
>> > important
>> > > > configurations, run important ones on a daily basis, and use all
>> others
>> > > for
>> > > > after-code-freeze runs, for example.
>> > > >
>> > > > Thoughts?
>> > > >
>> > >
>> >
>>
>
>

Re: Full API coverage enhancement

[Artem Shutak]

-- Artem --

On Tue, Mar 1, 2016 at 1:31 AM, Dmitriy Setrakyan 
wrote:

> Thanks Artem! I think this test suite should go a long way towards removing
> issues with different configuration property permutations.
>
> Is this suite turned on by default?
>
> D.
>
> On Mon, Feb 29, 2016 at 7:07 AM, Artem Shutak 
> wrote:
>
> > Igniters,
> >
> > I'm glad to announce that Configuration Variations test framework has
> been
> > merged to master and is ready to use.
> >
> > The framework provides an opportunity to write a test-case once and to
> run
> > it in many Ignite and Cache configuration variations, for different
> Ignite
> > topologies (with and without clients) and execute the same test scenario
> > from different Ignite nodes (server and client) automatically.
> >
> > Another useful feature is "runInAllDataModes" functionality that allows
> to
> > run test-case and run it in all supported by framework data modes (like
> > Serializable, Externalizable, plane, mixed and etc. objects).
> >
> > I've added the framework description on "Implementing Tests" [1] page.
> > Please, feel free to comment.
> >
> > As proof-of-concept I've
> > added IgniteCacheBasicConfigVariationsFullApiTestSuite and add it on TC.
> >
> > It does not mean that the work on IGNITE-2521
> >  is completed and we
> > have coverage for full Ignite API, but I think it is a good improvement
> for
> > Ignite's test framework and Igniters can test functionality better and
> > simpler.
> >
> > [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Implementing+Tests
> > (see "Configuration variations test framework" section).
> >
> > Thanks,
> > -- Artem --
> >
> > On Thu, Feb 11, 2016 at 12:29 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > wrote:
> >
> > > Agree about separation. I think we need to define some internal
> > > permutations that keep coming up with bugs. I can start the list here:
> > >
> > >1. Serializable, Externalizable, neither.
> > >1. We should run the whole suite 3 times, once for each
> serialization
> > >   mode. Having 2 or 3 nodes in the cluster here should be enough.
> > > No need to
> > >   test it on the changing cluster.
> > >2. On-heap and off-heap with entry processor and peer-deployment
> > >1. on-heap, entry-processor, peer-deployment=true/false
> > >   2. off-heap, entry-processor, peer-deployment=true/false
> > >3. On-heap and off-heap with eviction policies
> > >   1. eviction policy, memory-mode=on-heap
> > >   2. eviction policy, memory-mode=off-heap
> > >   3. eviction policy, memory-mode=off-heap-values
> > >4. On-heap and off-heap with continuous queries and
> > >peer-deployment=true/false
> > >5. …
> > >
> > > I think we can come up with about 20 most important permutations.
> > Thoughts?
> > >
> > > D.
> > >
> > >
> > > On Wed, Feb 10, 2016 at 9:24 AM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > Dmitriy, the size of the circular buffer can be decreased by setting
> > > > IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE system property.
> > > >
> > > > I was wondering what our next steps will be after implementing the
> > > > framework. From the initial discussion I thought we want to convert
> > some
> > > > older tests to this new framework and run all new tests using this
> > > > framework. However, from what Artem already has written, this sounds
> > > > unrealistic because adding even a simple test case will induce hours
> of
> > > run
> > > > time. I think we still need to separate more important and less
> > important
> > > > configurations, run important ones on a daily basis, and use all
> others
> > > for
> > > > after-code-freeze runs, for example.
> > > >
> > > > Thoughts?
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-2738) Ignite-YARN custom queue name

[Luca Rea (JIRA)]

Luca Rea created IGNITE-2738:


 Summary: Ignite-YARN custom queue name
 Key: IGNITE-2738
 URL: https://issues.apache.org/jira/browse/IGNITE-2738
 Project: Ignite
  Issue Type: Bug
Reporter: Luca Rea


Hi,
Actually is not possible to pass a custom queue name when launching Ignite 
YARN, so all Ignite YARN containers always run into the "default" queue (that 
usually is configured to have limited resources available).



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

[jira] [Created] (IGNITE-2737) Ignite-Spark documentation is missing some useful informations

[Luca Rea (JIRA)]

Luca Rea created IGNITE-2737:


 Summary: Ignite-Spark documentation is missing some useful 
informations
 Key: IGNITE-2737
 URL: https://issues.apache.org/jira/browse/IGNITE-2737
 Project: Ignite
  Issue Type: Bug
Reporter: Luca Rea


Hi,

in my tests I have experienced some configuration issue running spark in local 
and yarn-client mode, so I want to share them.
In order to let Ignite work correctly I had to customize spark-defaults.conf 
adding to "spark.driver.extraClassPath" and "spark.executor.extraClassPath" the 
string
{code}
"/opt/ignite/libs/*:/opt/ignite/libs/optional/ignite-spark/*:/opt/ignite/libs/optional/ignite-log4j/*:/opt/ignite/libs/optional/ignite-yarn/*:/opt/ignite/libs/ignite-spring/*"
{code}
(opt/ignite is my IGNITE_HOME) and other IGNITE_ useful variables like 
"spark.executorEnv.IGNITE_WORK_DIR" in order to let them be loaded by executors.



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

[jira] [Created] (IGNITE-2736) custom Ignite Configuration (not xml file) is not used by spark executors

[Luca Rea (JIRA)]

Luca Rea created IGNITE-2736:


 Summary: custom Ignite Configuration (not xml file) is not used by 
spark executors
 Key: IGNITE-2736
 URL: https://issues.apache.org/jira/browse/IGNITE-2736
 Project: Ignite
  Issue Type: Bug
Reporter: Luca Rea


Hi,
I have launched an Ignite Cluster inside YARN and I use spark-shell from a 
client to attach to existing cluster cluster in client mode, connection between 
client and cluster doesn't support multicast so I've tried to use a custom 
config like below:

{code}
import org.apache.ignite.spark._
import org.apache.ignite.configuration._
import org.apache.ignite._
import org.apache.ignite.spi.discovery.tcp._
val spi = new TcpDiscoverySpi();
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm._
val ipFinder = new TcpDiscoveryVmIpFinder();
import java.util.Arrays
ipFinder.setAddresses(Arrays.asList("172.16.24.48:47500", "172.16.24.49:47500", 
"172.16.24.50:47500", "172.16.24.51:47500", "172.16.24.52:47500", 
"172.16.24.53:47500"));
spi.setIpFinder(ipFinder);
val cfg = new IgniteConfiguration() with Serializable;
cfg.setGridName("ignite-cluster");
cfg.setDiscoverySpi(spi);
val cacheCfg = new CacheConfiguration("myCache");
import org.apache.ignite.cache._
cacheCfg.setCacheMode(CacheMode.PARTITIONED);
cacheCfg.setBackups(1);
cfg.setCacheConfiguration(cacheCfg);
class cfg extends Serializable;

val ic = new IgniteContext[Integer, Integer](sc, () => cfg )

val sharedRdd = ic.fromCache("example")
val x = sqlContext.sparkContext.parallelize(1 to 1, 10).map(i => (new 
Integer(i), new Integer(i)))
sharedRdd.savePairs(x)
{code}

when I run the last command it freeze waiting to connect to the cluster, in 
fact it seems that in this way the spark execurors don't use the above 
configuration nor load the file default-config.xml but use some hardocoded 
configuration with only multicast enabled.

The workaround is to use a acustom xml configuration file and copy it into the 
config ignite path of all all spark nodes the run:

{code}
import org.apache.ignite.spark._
val ic = new IgniteContext[Integer, Integer](sc, "config/custom-config.xml")
{code}

custom-config.xml:
{code}
http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="
   http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd;>



  
  

  

  

  172.16.24.48:47500
  172.16.24.49:47500
  172.16.24.50:47500
  172.16.24.51:47500
  172.16.24.52:47500
  172.16.24.53:47500

  

  

  



{code}



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