Re: ignite-platform module

[Raul Kripalani]

On Thu, Nov 12, 2015 at 5:23 PM, Dmitriy Setrakyan 
wrote:

> Vladimir, I think it is unclear how one approach is better than the other
> apart from just being different. I would avoid undertaking this type of
> restructuring unless we have a really compelling reason.
>

I need three modules for OSGi:

* ignite-osgi-support => provides an IgniteOsgiHelper in a manner similar
to IgniteSpringHelper.
* ignite-osgi-karaf-features => a Maven module of POM packaging which
simply provides a features.xml for quick installation in Karaf.
* ignite-osgi-paxlogging-fragment => a fragment for Pax Logging that
exposes the extra packages from log4j that Ignite uses
(o.a.log4j.[varia/xml]).

It would clutter the modules folder to have them at that level. So I
suggest:

modules
 |-- osgi
  |- support
  |- karaf-features
  |- paxlogging-fragment

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Re: ignite-platform module

[Raul Kripalani]

On Thu, Nov 12, 2015 at 8:24 PM, Dmitriy Setrakyan 
wrote:

> Raul, following this logic, we should also group all streaming integration
> into one streaming folder and so on… My vote is to keep the structure
> consistent and flat for now, and if the community decides that grouping
> should serve us better, we will restructure the project modules in one
> step.
>

It's not the same situation. Conceptually there are no single-themed
streaming modules in Ignite. There are modules that integrate Ignite with a
given technology, where one of the elements of that integration – and
mostly the only one for now – is streaming. In other words, conceptually
speaking they are not limited to streaming even if streaming is their sole
functionality for the time being.

On the other hand, everything nested under osgi would be grouped under a
single theme: OSGi.

But anyway, I don't have strong feelings for this, so let's just keep the
structure linear for now.

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Re: NuGet icon hosting

[Dmitriy Setrakyan]

Here you go:
https://ignite.apache.org/images/logo_ignite_32_32.png

D.

On Thu, Nov 12, 2015 at 10:09 AM, Pavel Tupitsyn 
wrote:

> Hi Dmitry,
>
> Looks like you have misunderstood me. There is no icon, that is why I ask
> for it.
>
> We (Igniters) want to distribute Ignite.NET as a NuGet package (which is
> the most convenient way in .NET world).
> * To make our package look good we need an icon. It should be 32x32
> transparent png.
> * There is no way to embed an icon into a package. It can only be specified
> by an URL.
>
> Therefore we need two things:
> * Create an icon
> * Host it on ignite.apache.org
>
> I'm asking for help with these two. I'm not sure about the license here.
>
> Makes sense?
>
>
> On Thu, Nov 12, 2015 at 8:31 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Thu, Nov 12, 2015 at 6:50 AM, Pavel Tupitsyn 
> > wrote:
> >
> > > Igniters,
> > >
> > > I'm working on a NuGet package for Ignite.NET (
> > > https://issues.apache.org/jira/browse/IGNITE-1626)
> > > It requires a 32x32 transparent png icon hosted somewhere (
> > > https://docs.nuget.org/create/nuspec-reference).
> > >
> > > We have some icons on our site, like
> > > https://ignite.apache.org/images/logo3.png.
> > >
> > > Who is responsible for the site and icons there? Can we get a good
> > looking
> > > 32x32 icon there?
> > >
> >
> > Pavel, do you know the license under which this icon is distributed? Can
> we
> > see this icon?
> >
> >
> > >
> > > Thanks,
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

Re: Custom ThreadFactory

[Dmitriy Setrakyan]

On Thu, Nov 12, 2015 at 10:26 AM, Andrey Kornev 
wrote:

> Even better, Ignite might provide out-of-the-box access to the local
> instance via a
> thread local. It could be in a form of a static public
> method on the Ignition class.
>
> Ignite itself could benefit from
> this feature as it does get it wrong occasionally. A good example of
> this is the ClusterGroupAdapter class or any other class that serializes
>  the instance of IgniteKernal. Imagine the situation where you have a
> single JVM with multiple Ignite nodes started -- Ignite requires the
> grid names to be different. But since only the name of the grid is
> serialized, during deserialization an invalid (unexpected, to put it
> mildly) instance of IgniteKernal is looked up. I don't know how serious
> it is, but it is probably a bug.
>

Andrey, I think its best to summarize the design thoughts in a ticket. Then
someone from the community will pick it up.


>
> Regards
> Andrey
>
> > Date: Thu, 12 Nov 2015 21:11:38 +0300
> > Subject: Re: Custom ThreadFactory
> > From: voze...@gridgain.com
> > To: dev@ignite.apache.org
> >
> > I would avoid running any external payloads in public pool because it
> could
> > unpredictably affect Ignite internals. "Public" doesn't mean "opened for
> > everyone" here.
> >
> > On the other hand, I abosuletly agree that removing possibility to
> > configure custom pools was not very good idea. I do not see any problems
> > with returning it back while still keeping "thread count" property for
> the
> > most common use case when custom pool is not needed/
> >
> > On Thu, Nov 12, 2015 at 9:02 PM, Andrey Kornev  >
> > wrote:
> >
> > > Hello,
> > >
> > > If my memory doesn't fail me, in the pre-Ignite versions of GridGain,
> it
> > > was possible to configure custom executor services which would then be
> used
> > > to create the public, system, utility, etc. thread pools. In Ignite
> however
> > > it's only possible to configure the size of the thread pools and not
> their
> > > implementations.
> > >
> > > This is unfortunate as I'd like to be able to configure my own
> > > ThreadFactory. My implementation would for example ensure that newly
> > > created threads have their thread locals properly initialized (for
> example,
> > > by storing the local instance of Ignite in it). Specific use case is
> being
> > > able to get hold of the local Ignite instance during deserialization
> when
> > > the JVM instance has multiple Ignite nodes started. Some of my classes
> must
> > > be able to access resources that are local to the node on which they
> are
> > > being deserialized. At the moment there is absolutely no way of
> achieving
> > > something like that.
> > >
> > > I'm wondering if it would be possible to add this feature back to
> Ignite?
> > > It seems to be indispensable for unit testing.
> > >
> > > Alternatively, to reduce the impact on the public API, an environment
> > > variable that takes an FQN of the ThreadFactory to use would also
> work. It
> > > would be injectable with the Ignite resources in the manner similar to
> how
> > > it's done for the closures and factories...
> > >
> > > Regards
> > > Andrey
> > >
> > > PS. While we're at it, I also remember that in the pre-Ignite versions
> it
> > > was possible to inject an instance of the public executor service into
> the
> > > closures. Not anymore. It causes the inconvenience of starting another
> > > thread pool while there is already a public pool managed by Ignite with
> > > plenty of threads idling most of the time... It feels wasteful.
> > >
>
>

[jira] [Created] (IGNITE-1894) .Net: Delegate support in the API via extension methods

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1894:
---

 Summary: .Net: Delegate support in the API via extension methods
 Key: IGNITE-1894
 URL: https://issues.apache.org/jira/browse/IGNITE-1894
 Project: Ignite
  Issue Type: Improvement
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
 Fix For: 1.6


In many places we require a single-method interface implementation from the 
user:
{code:title=ICompute}
TRes Call(IComputeFunc clo);
{code}

All of these can be extended to accept a delegate:
{code:title=ICompute}
TRes Call(Func clo);
{code}

We can't replace interfaces with delegates completely (which is desirable), 
because it will take away serialization control from the user. So the interface 
approach has to stay as a primary.
Delegate support can be added via extension methods, which wrap provided 
delegates into a class that implements corresponding interface.



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

[jira] [Created] (IGNITE-1898) Make it possible to obtain the local Ignite instance statically

[Andrey Kornev (JIRA)]

Andrey Kornev created IGNITE-1898:
-

 Summary: Make it possible to obtain the local Ignite instance 
statically
 Key: IGNITE-1898
 URL: https://issues.apache.org/jira/browse/IGNITE-1898
 Project: Ignite
  Issue Type: Improvement
  Components: general
Reporter: Andrey Kornev
Priority: Minor


Currently the ways to obtain the local instance of Ignite make use of the grid 
name or the node UUID with the corresponding {{Ignition.ignite()}} methods. 
However, during deserialization if would sometime be desirable to be able to 
obtain the local instance of Ignite (the one on which the given class is being 
deserialized) without relying on the grid name. Such instance can then be used 
to look up the node-local resources and any other context. The grid name is not 
reliable way to serialize/deserialize {{IgniteKernal}} in a situation when a 
single JVM has multiple Ignite nodes started (as is often the case in unit 
tests).

The proposed solution is to
# implement a custom ThreadFactory to be used with the public, system, utility 
and so on thread pools. For all newly created thread, the factory will create a 
thread local and initialize it with the current instance of Ignite.
# modify the classes that create their own threads, to do the same.
# provide a public static method on the Ignition class
{{public static Ignite getLocalNode();}}
that returns the value of the thread local. It throws {{IllegalStateException}} 
if the method is invoked from a non-Ignite thread.

This will guarantee that all threads started by a particular Ignite instance 
will have the instance reference available in their thread locals.




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

RE: Custom ThreadFactory

[Andrey Kornev]

There you go: 
https://issues.apache.org/jira/browse/IGNITE-1898
and
https://issues.apache.org/jira/browse/IGNITE-1899

Cheers
Andrey

> From: dsetrak...@apache.org
> Date: Thu, 12 Nov 2015 12:53:52 -0800
> Subject: Re: Custom ThreadFactory
> To: dev@ignite.apache.org
> 
> On Thu, Nov 12, 2015 at 10:26 AM, Andrey Kornev 
> wrote:
> 
> > Even better, Ignite might provide out-of-the-box access to the local
> > instance via a
> > thread local. It could be in a form of a static public
> > method on the Ignition class.
> >
> > Ignite itself could benefit from
> > this feature as it does get it wrong occasionally. A good example of
> > this is the ClusterGroupAdapter class or any other class that serializes
> >  the instance of IgniteKernal. Imagine the situation where you have a
> > single JVM with multiple Ignite nodes started -- Ignite requires the
> > grid names to be different. But since only the name of the grid is
> > serialized, during deserialization an invalid (unexpected, to put it
> > mildly) instance of IgniteKernal is looked up. I don't know how serious
> > it is, but it is probably a bug.
> >
> 
> Andrey, I think its best to summarize the design thoughts in a ticket. Then
> someone from the community will pick it up.
> 
> 
> >
> > Regards
> > Andrey
> >
> > > Date: Thu, 12 Nov 2015 21:11:38 +0300
> > > Subject: Re: Custom ThreadFactory
> > > From: voze...@gridgain.com
> > > To: dev@ignite.apache.org
> > >
> > > I would avoid running any external payloads in public pool because it
> > could
> > > unpredictably affect Ignite internals. "Public" doesn't mean "opened for
> > > everyone" here.
> > >
> > > On the other hand, I abosuletly agree that removing possibility to
> > > configure custom pools was not very good idea. I do not see any problems
> > > with returning it back while still keeping "thread count" property for
> > the
> > > most common use case when custom pool is not needed/
> > >
> > > On Thu, Nov 12, 2015 at 9:02 PM, Andrey Kornev  > >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > If my memory doesn't fail me, in the pre-Ignite versions of GridGain,
> > it
> > > > was possible to configure custom executor services which would then be
> > used
> > > > to create the public, system, utility, etc. thread pools. In Ignite
> > however
> > > > it's only possible to configure the size of the thread pools and not
> > their
> > > > implementations.
> > > >
> > > > This is unfortunate as I'd like to be able to configure my own
> > > > ThreadFactory. My implementation would for example ensure that newly
> > > > created threads have their thread locals properly initialized (for
> > example,
> > > > by storing the local instance of Ignite in it). Specific use case is
> > being
> > > > able to get hold of the local Ignite instance during deserialization
> > when
> > > > the JVM instance has multiple Ignite nodes started. Some of my classes
> > must
> > > > be able to access resources that are local to the node on which they
> > are
> > > > being deserialized. At the moment there is absolutely no way of
> > achieving
> > > > something like that.
> > > >
> > > > I'm wondering if it would be possible to add this feature back to
> > Ignite?
> > > > It seems to be indispensable for unit testing.
> > > >
> > > > Alternatively, to reduce the impact on the public API, an environment
> > > > variable that takes an FQN of the ThreadFactory to use would also
> > work. It
> > > > would be injectable with the Ignite resources in the manner similar to
> > how
> > > > it's done for the closures and factories...
> > > >
> > > > Regards
> > > > Andrey
> > > >
> > > > PS. While we're at it, I also remember that in the pre-Ignite versions
> > it
> > > > was possible to inject an instance of the public executor service into
> > the
> > > > closures. Not anymore. It causes the inconvenience of starting another
> > > > thread pool while there is already a public pool managed by Ignite with
> > > > plenty of threads idling most of the time... It feels wasteful.
> > > >
> >
> >
  

[jira] [Created] (IGNITE-1899) Incorrect Ignite (IgniteKernal) instance deserialized when multiple Ignite nodes started in the same JVM

[Andrey Kornev (JIRA)]

Andrey Kornev created IGNITE-1899:
-

 Summary: Incorrect Ignite (IgniteKernal) instance deserialized 
when multiple Ignite nodes started in the same JVM
 Key: IGNITE-1899
 URL: https://issues.apache.org/jira/browse/IGNITE-1899
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Andrey Kornev


The current approach to serialization/deserialization of {{IgniteKernal}} is 
flawed as it relies on the grid name. However, in a situation when a single JVM 
instance has multiple Ignite instances started (as is often the case in unit 
tests) this approach doesn't work. Ignite requires that each Ignite instance 
started within the same JVM be assigned different names. Thus, during 
deserialization on another node a wrong instance of {{IgniteKernal}} gets 
looked up.

Say, the JVM instance has 2 nodes started: node A and node B. Then, when the 
node A serializes {{IgniteKernal}} it'll write the grid name "A" to the wire. 
Then, during deserialization of the {{IgniteKernal}} instance on the node B, 
the name "A" will be read from the wire and used to look up the Ignite instance 
uisng {{Ignition.ignite("A");}}. Clearly the class (holding a reference to 
{{IgniteKernal}}) ends up with a wrong instance of Ignite. If the class also 
retrieves the node-local resources by doing 
{{Ignition.ignite(deserializedGridName).cluster().nodeLocalMap()}} then it may 
end up with incorrect data.

As of Ignite 1.4, {{ClusterGroupAdapter}} class or any other class that 
serialize the instance of {{IgniteKernal}} suffer from this issue. The fix 
would be to simply stop serializing the grid name altogether and during 
deserialization rely on the thread local instead, as per IGNITE-1898.



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

Re: IGFS URI authority: simplify handling of IGFS and Grid names.

[Ivan V.]

Hi, Dmitriy,
null Grid name and null Igfs name mean the default Grid and Igfs
respectively.
In case of in-process connection, URI without specified grid and/or igfs
name means to connect to the default (null-named) Grid and/or Igfs.
If this contract makes sense, we should not prohibit nulls.

On Wed, Nov 11, 2015 at 9:11 PM, Dmitriy Setrakyan 
wrote:

> I also agree (I think). Would prohibiting nulls also make sense?
>
> On Wed, Nov 11, 2015 at 4:04 AM, Vladimir Ozerov 
> wrote:
>
> > +1
> >
> > User should have minimal chance to do a mistake in common scenarios.
> >
> > On Wed, Nov 11, 2015 at 1:47 PM, Ivan V. 
> > wrote:
> >
> > > Hi, dev,
> > > currently IGFS URI has form
> > > igfs://[igfs-name[:grid-name]]@[host[:port]]/[path] .
> > > This connection can be established with "in-process" routine (used
> mostly
> > > in tests), or with SHMEM, or with TCP protocol.
> > > Current logic of "igfs-name" and "grid-name" handling is as follows.
> > > In case of in-proc routine the Ignite process is asked for named Grid
> and
> > > its IGFS, null names mean default instances.
> > > In case of external process connection (to "host:port" specified in the
> > > URI) there is a restriction that the name of connected IGFS and Grid
> must
> > > exactly match "igfs-name" and "grid-name" specified in the URI. But
> that
> > > rule leads to the following (may be unexpected) behavior: if URI is
> > > "igfs://localhost:10500/", the IGFS name and Grid names are null-s, and
> > the
> > > name match rule requires the connected IGFS and Grid to be default. And
> > if
> > > that is not the case, an exception is thrown. This situation has
> happened
> > > with a user, and described in
> > > https://issues.apache.org/jira/browse/IGNITE-1566 .
> > > In order to fix the problem and improve the usability, I would suggest
> to
> > > relax the name handling logic in the following way: in case of external
> > > connection treat unspecified Igfs and Grid names as a direction to
> > connect
> > > to the Grid/Igfs that owns the connection port (not more than one such
> > pair
> > > exists).
> > > Any objections, corrections, thoughts?
> > > Thanks in advance.
> > >
> >
>

Blog topics wiki page

[Yakov Zhdanov]

Guys,

I have created wiki page to put and discuss ideas for blog topics -
https://cwiki.apache.org/confluence/display/IGNITE/Blog+Topics

--Yakov

Latest state of new Binary format

[Raul Kripalani]

Hello,

I need to know in which branch the latest state of the Binary format is, in
order to introduce changes.

It is my understanding that it hasn't been merged to 1.5 yet, right?

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

IGNITE-1355 Potential NPE in CacheAffinityProxy

[Artem Shutak]

Igniters,

I'm working on https://issues.apache.org/jira/browse/IGNITE-1355.

I want to hear a community opinion what should do Ignite in case when user
uses Affinity for nonexistent cache? Current implementation returns
AffinityProxy on a call of Ignite.affinity("nonexistent_cache") and
AffinityProxy throws NPE on a call of any method if cache has not been
created yet.

I see next possible decisions:
- Ignite.affinity("nonexistent_cache") can return 'null' instead of
AffinityProxy like Ignite does it for Ignite.cache("nonexistent_cache").
But it breaks backward compatibility.
- AffinityProxy methods can return a special value like 0 for
'partitions()' method  and empty array for 'primaryPartitions(ClusterNode)'
method.
- AffinityProxy methods can throw Exception that cache does not exist.

I vote for the second one.

Thoughts?

Thanks,
-- Artem --

ignite-platform module

[Raul Kripalani]

Hello,

Currently we have a single ignite-platform module aggregating all sources
for .NET and CPP integration.

For the OSGi integration I'm working on, I need to add two modules to the
Ignite codebase to facilitate deploying Ignite on top of Apache Karaf (OSGi
container).

One can regard Apache Karaf as another platform, so semantically it feels
natural is to nest these modules under platform/karaf.

However, this would require some refactoring so that platform can contain
modules:

platform
   |-dotnet
   |-java
   |-cpp
   |-pom.xml

What do you think?

Regards,

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Re: Latest state of new Binary format

[Raul Kripalani]

I think it's ignite-1282, right? I need a confirmation to start working
from the right place.

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

On Thu, Nov 12, 2015 at 12:46 PM, Raul Kripalani  wrote:

> Hello,
>
> I need to know in which branch the latest state of the Binary format is,
> in order to introduce changes.
>
> It is my understanding that it hasn't been merged to 1.5 yet, right?
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[jira] [Created] (IGNITE-1900) Ignite JMX problem with Spring Boot

[wmz7year (JIRA)]

wmz7year created IGNITE-1900:


 Summary: Ignite JMX problem with Spring Boot
 Key: IGNITE-1900
 URL: https://issues.apache.org/jira/browse/IGNITE-1900
 Project: Ignite
  Issue Type: Bug
  Components: 1.4
Affects Versions: ignite-1.4
Reporter: wmz7year


I use Ignite with Spring Boot.
When start application,Spring Boot will register JMX info.

In IgniteMXBean interface,There is two method getUserAttributesFormatted and 
getLifecycleBeansFormatted return Collection
But In JMX DefaultMXBeanMappingFactory.makeParameterizedTypeMapping method will 
get method return type.

 final Type rawType = objType.getRawType();
if (rawType instanceof Class) {
Class c = (Class) rawType;
if (c == List.class || c == Set.class || c == SortedSet.class) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 1);
if (c == SortedSet.class)
mustBeComparable(c, actuals[0]);
return makeArrayOrCollectionMapping(objType, actuals[0], 
factory);
} else {
boolean sortedMap = (c == SortedMap.class);
if (c == Map.class || sortedMap) {
Type[] actuals = objType.getActualTypeArguments();
assert(actuals.length == 2);
if (sortedMap)
mustBeComparable(c, actuals[0]);
return makeTabularMapping(objType, sortedMap,
actuals[0], actuals[1], factory);
}
}
}

The Collection will not match any type for this although IgniteKernal 
return type is Set.


I think IgniteMXBean interface should change Collection to Set and List



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

Re: IGNITE-1355 Potential NPE in CacheAffinityProxy

[Yakov Zhdanov]

Any cache can be destroyed after proxy is created, so any cache may become
unexistent at any moment. So, I would still allow proxy creation for
unexistent caches, but throw an exception if cache does not exist at the
moment of proxy method call.

--Yakov

2015-11-12 16:01 GMT+03:00 Artem Shutak :

> Igniters,
>
> I'm working on https://issues.apache.org/jira/browse/IGNITE-1355.
>
> I want to hear a community opinion what should do Ignite in case when user
> uses Affinity for nonexistent cache? Current implementation returns
> AffinityProxy on a call of Ignite.affinity("nonexistent_cache") and
> AffinityProxy throws NPE on a call of any method if cache has not been
> created yet.
>
> I see next possible decisions:
> - Ignite.affinity("nonexistent_cache") can return 'null' instead of
> AffinityProxy like Ignite does it for Ignite.cache("nonexistent_cache").
> But it breaks backward compatibility.
> - AffinityProxy methods can return a special value like 0 for
> 'partitions()' method  and empty array for 'primaryPartitions(ClusterNode)'
> method.
> - AffinityProxy methods can throw Exception that cache does not exist.
>
> I vote for the second one.
>
> Thoughts?
>
> Thanks,
> -- Artem --
>

NuGet icon hosting

[Pavel Tupitsyn]

Igniters,

I'm working on a NuGet package for Ignite.NET (
https://issues.apache.org/jira/browse/IGNITE-1626)
It requires a 32x32 transparent png icon hosted somewhere (
https://docs.nuget.org/create/nuspec-reference).

We have some icons on our site, like
https://ignite.apache.org/images/logo3.png.

Who is responsible for the site and icons there? Can we get a good looking
32x32 icon there?

Thanks,

-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

Re: ignite-platform module

[Vladimir Ozerov]

I do not keep track on OSGI integration efforts, so I am afraid I cannot
advise anything here.

Normally each folder inside "modules" corresponds to a single Java project
with some isolated feature. E.g. we have several logging modules: log4j,
log4j2, slf4j. They are very similar to each other, but located as:
-- modules/log4j
-- modules/log4j2
-- modules/slf4j

not as
-- modules/logging/log4j
-- modules/logging/log4j2
-- modules/logging/slf4j

If you follow this rule, you will place each module directly unders
"modules". But may be it makes sense to rethink this approach and group
realted modules under a single subdirectory: modules/[feature_name].

Vladimir.

On Thu, Nov 12, 2015 at 4:37 PM, Raul Kripalani  wrote:

> On Thu, Nov 12, 2015 at 12:58 PM, Vladimir Ozerov 
> wrote:
>
> >
> > "platform" currently refers to some non-Java integration. OSGI/Karaf are
> > not "platforms" in this terminology.
>
>
> Yep, I suspected so. So you recommend creating an "osgi-karaf" directory
> under modules/ with all Karaf-related modules?
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

[jira] [Created] (IGNITE-1895) Entries aren't evicted for LRU policy

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1895:
-

 Summary: Entries aren't evicted for LRU policy
 Key: IGNITE-1895
 URL: https://issues.apache.org/jira/browse/IGNITE-1895
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.5
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
 Fix For: 1.5


1. :
{code:title=CacheLruExample.java|borderStyle=solid}
package org.apache.ignite.examples.datagrid;

import java.util.HashMap;
import java.util.Map;
import org.apache.ignite.Ignite;
import org.apache.ignite.IgniteCache;
import org.apache.ignite.IgniteException;
import org.apache.ignite.Ignition;
import org.apache.ignite.examples.ExampleNodeStartup;

public class CachePutGetExample {
/** Cache name. */
private static final String CACHE_NAME = "cache_0001";

public static void main(String[] args) throws IgniteException, 
InterruptedException {
try (Ignite ignite = 
Ignition.start("examples/config/example-ignite-lru-client.xml")) {
try (IgniteCache cache = 
ignite.getOrCreateCache(CACHE_NAME)) {
System.out.println();
System.out.println(">>> Test started.");

int counter = 0;
for (int i = 1; i <= 100; i++) {
if (cache.get(i) != null)
counter++;
}
System.out.println(">>> Get: found not-null keys " + 
Integer.toString(counter));
Thread.sleep(1000);

for (int i = 1; i <= 100; i++) {
cache.remove(i);
}
System.out.println(">>> Remove: 1..100");
Thread.sleep(1000);


counter = 0;
for (int i = 1; i <= 100; i++) {
cache.put(i, Integer.toString(i));
counter++;
}
System.out.println(">>> Put: 1..100");
Thread.sleep(1000);


counter = 0;
for (int i = 50; i <= 100; i++) {
if (cache.get(i) != null)
counter++;
}
System.out.println(">>> Get 50..100");
Thread.sleep(1000);


for (int i = 30; i <= 49; i++) {
cache.put(i, Integer.toString(i));
}
System.out.println(">>> Put: 30..49");
Thread.sleep(1000);


counter = 0;
for (int i = 1; i <= 100; i++) {
if (cache.get(i) != null)
counter++;
}
System.out.println(">>> Get: found not-null keys (must be 50): 
" + Integer.toString(counter));
}
}
}

}
{code}

2. Copy attached configurations in examples/config directory
3. Start two nodes with example-ignite-lru.xml
3. Compile and run example
4. The output of example shows that cache has more entries than defined by max 
size in eviction policy:

{noformat}
...
[16:34:47,088][INFO ][main][GridDiscoveryManager] Topology snapshot [ver=3, 
servers=2, clients=1, CPUs=8, heap=3.8GB]

>>> Test started.
>>> Get: found not-null keys 0
>>> Remove: 1..100
>>> Put: 1..100
>>> Get 50..100
>>> Put: 30..49
>>> Get: found not-null keys (must be 50): 70
...
{noformat}



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

[GitHub] ignite pull request: Reusing message reader per NIO session

[vkulichenko]

GitHub user vkulichenko opened a pull request:

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

Reusing message reader per NIO session



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

$ git pull https://github.com/vkulichenko/incubator-ignite 
ignite-direct-marsh

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

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


commit 7123a73d1e80d568588a3cf44ea3e513f484093c
Author: Valentin Kulichenko 
Date:   2015-11-13T05:34:35Z

Reusing message reader per NIO session




---
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: OptimizedClassDescriptor verifyChecksum object set as optional

[姜 为]

Hi Denis,

This is not what I want ,but it works for my service.
Thank you!

Jiang

> 在 2015年11月11日，下午9:00，Denis Magda  写道：
> 
> Hi Jiang,
> 
> I'm a bit confused why you can't give different names to the services located 
> in different modules. If each service has a different name then my approach 
> will work for you, doesn't it?
> 
>   But if my service is by ModuleA.ExampleServiceImpl call 
> ModuleB.ExampleServiceImpl,
>   and ModuleB.ExampleServiceImpl call other complicated service.
> 
> 
> Could you provide me with the code showing what you're trying to achieve.
> 
> BTW, you use service notion in the thread. Probably you can implement 
> everything using Ignite Services module:
> https://apacheignite.readme.io/docs/service-grid 
> 
> What do you think?
> 
> 
> Regards,
> Denis
> 
> On 11/11/2015 5:54 AM, 姜 为 wrote:
>> Hi Denis:
>> 
>>  I tried compute.call(new ExampleServiceImplA());
>> 
>>  But if my service is by ModuleA.ExampleServiceImpl call 
>> ModuleB.ExampleServiceImpl,
>>  and ModuleB.ExampleServiceImpl call other complicated service.
>>  
>>  The ModuleA only has ExampleServiceImpl there is none ModuleB.other 
>> service.
>>  It does not work.
>> 
>> 
>>> 在 2015年11月10日，下午9:55，Denis Magda >>  >> >> 写道：
>>> 
>>> It should fail because you send your service impl inside of Callable
>>> compute.call(new Callable(new ExampleServiceImplA()));
>>> 
>>> Callable is loaded by application class loader and presents on both the 
>>> sender and receiver. This leads to the situation when the receiver tries to 
>>> loads ExampleServiceImplA using the app class loader as well.
>>> 
>>> To avoid this try to implement IgniteCallable by ExampleServiceImplA and 
>>> send the task this way:
>>> 
>>> compute.call(new ExampleServiceImplA());
>>> 
>>> 
 I think. If I have lots of type servers. It will be ExampleServiceImpl1 2 
 3 4 5….,will look very bloated.
>>> You can use java 8 closures sending a particular one depending on a server 
>>> type. Will it work for you?
>>> https://apacheignite.readme.io/docs/distributed-closures 
>>>  
>>> >> >
>>> 
>>> 
>>> Regards,
>>> Denis
>>> On 11/10/2015 4:31 PM, 姜 为 wrote:
 Hi Denis,
 
I tried your suggested,  here is the code : 
 >https://github.com/wmz7year/ignite-test/commit/4eaa4231e165eaa4de00dab94cd394f629e68497
  
 
  
 >

But I still got ClassNotFoundException.
 
<邮件附件.png>
 
 
I think. If I have lots of type servers. It will be ExampleServiceImpl1 
 2 3 4 5….,will look very bloated.

 
> 在 2015年11月10日，下午8:02，Denis Magda <  >dma...@gridgain.com 
>  >> 写道：
> 
> Jiang,
> 
> This exception happens exactly because you have two implementations with 
> the same name. If the names were different you wouldn't get to the point 
> of checksum validation.
> Here I fully share Val's opinion that checksum's verification shouldn't 
> be optional and it's a responsibility of an application to take care of 
> such situations.
> 
> I see the following approaches you can use in your code to get required 
> behavior:
> 
> 1) As suggested below use the approach with Serializable + 
> serialVersionUID. It will work;
> 
> 2) More preferable is to have different implementations with different 
> names (ExampleServiceImpl1, ExampleServiceImpl2, etc...). Is there any 
> reasons you can't use this straightforward approach?
> When the implementations are ready you can put their classes onto every 
> machine in order to have them in the classpath or you can leverage 
> IgniteConfiguration.peerClassLoadingEnabled feature.
> The feature allows to load missing classes from a machine that sends 
> compute based tasks onto a machine that will execute a task and you don't 
> need to copy implementations' classes manually at all.
> You can read more on this here: 
> 

Re: NuGet icon hosting

[Pavel Tupitsyn]

Also I'd like some help on wording (summary and description).
Here is how package manager looks in Visual Studio:
http://i.imgur.com/TcGoXB7.png



On Thu, Nov 12, 2015 at 5:50 PM, Pavel Tupitsyn 
wrote:

> Igniters,
>
> I'm working on a NuGet package for Ignite.NET (
> https://issues.apache.org/jira/browse/IGNITE-1626)
> It requires a 32x32 transparent png icon hosted somewhere (
> https://docs.nuget.org/create/nuspec-reference).
>
> We have some icons on our site, like
> https://ignite.apache.org/images/logo3.png.
>
> Who is responsible for the site and icons there? Can we get a good looking
> 32x32 icon there?
>
> Thanks,
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

Re: Custom ThreadFactory

[Vladimir Ozerov]

I would avoid running any external payloads in public pool because it could
unpredictably affect Ignite internals. "Public" doesn't mean "opened for
everyone" here.

On the other hand, I abosuletly agree that removing possibility to
configure custom pools was not very good idea. I do not see any problems
with returning it back while still keeping "thread count" property for the
most common use case when custom pool is not needed/

On Thu, Nov 12, 2015 at 9:02 PM, Andrey Kornev 
wrote:

> Hello,
>
> If my memory doesn't fail me, in the pre-Ignite versions of GridGain, it
> was possible to configure custom executor services which would then be used
> to create the public, system, utility, etc. thread pools. In Ignite however
> it's only possible to configure the size of the thread pools and not their
> implementations.
>
> This is unfortunate as I'd like to be able to configure my own
> ThreadFactory. My implementation would for example ensure that newly
> created threads have their thread locals properly initialized (for example,
> by storing the local instance of Ignite in it). Specific use case is being
> able to get hold of the local Ignite instance during deserialization when
> the JVM instance has multiple Ignite nodes started. Some of my classes must
> be able to access resources that are local to the node on which they are
> being deserialized. At the moment there is absolutely no way of achieving
> something like that.
>
> I'm wondering if it would be possible to add this feature back to Ignite?
> It seems to be indispensable for unit testing.
>
> Alternatively, to reduce the impact on the public API, an environment
> variable that takes an FQN of the ThreadFactory to use would also work. It
> would be injectable with the Ignite resources in the manner similar to how
> it's done for the closures and factories...
>
> Regards
> Andrey
>
> PS. While we're at it, I also remember that in the pre-Ignite versions it
> was possible to inject an instance of the public executor service into the
> closures. Not anymore. It causes the inconvenience of starting another
> thread pool while there is already a public pool managed by Ignite with
> plenty of threads idling most of the time... It feels wasteful.
>

Custom ThreadFactory

[Andrey Kornev]

Hello,

If my memory doesn't fail me, in the pre-Ignite versions of GridGain, it was 
possible to configure custom executor services which would then be used to 
create the public, system, utility, etc. thread pools. In Ignite however it's 
only possible to configure the size of the thread pools and not their 
implementations. 

This is unfortunate as I'd like to be able to configure my own ThreadFactory. 
My implementation would for example ensure that newly created threads have 
their thread locals properly initialized (for example, by storing the local 
instance of Ignite in it). Specific use case is being able to get hold of the 
local Ignite instance during deserialization when the JVM instance has multiple 
Ignite nodes started. Some of my classes must be able to access resources that 
are local to the node on which they are being deserialized. At the moment there 
is absolutely no way of achieving something like that.

I'm wondering if it would be possible to add this feature back to Ignite? It 
seems to be indispensable for unit testing. 

Alternatively, to reduce the impact on the public API, an environment variable 
that takes an FQN of the ThreadFactory to use would also work. It would be 
injectable with the Ignite resources in the manner similar to how it's done for 
the closures and factories...

Regards
Andrey

PS. While we're at it, I also remember that in the pre-Ignite versions it was 
possible to inject an instance of the public executor service into the 
closures. Not anymore. It causes the inconvenience of starting another thread 
pool while there is already a public pool managed by Ignite with plenty of 
threads idling most of the time... It feels wasteful.
  

Re: NuGet icon hosting

[Pavel Tupitsyn]

Hi Dmitry,

Looks like you have misunderstood me. There is no icon, that is why I ask
for it.

We (Igniters) want to distribute Ignite.NET as a NuGet package (which is
the most convenient way in .NET world).
* To make our package look good we need an icon. It should be 32x32
transparent png.
* There is no way to embed an icon into a package. It can only be specified
by an URL.

Therefore we need two things:
* Create an icon
* Host it on ignite.apache.org

I'm asking for help with these two. I'm not sure about the license here.

Makes sense?


On Thu, Nov 12, 2015 at 8:31 PM, Dmitriy Setrakyan 
wrote:

> On Thu, Nov 12, 2015 at 6:50 AM, Pavel Tupitsyn 
> wrote:
>
> > Igniters,
> >
> > I'm working on a NuGet package for Ignite.NET (
> > https://issues.apache.org/jira/browse/IGNITE-1626)
> > It requires a 32x32 transparent png icon hosted somewhere (
> > https://docs.nuget.org/create/nuspec-reference).
> >
> > We have some icons on our site, like
> > https://ignite.apache.org/images/logo3.png.
> >
> > Who is responsible for the site and icons there? Can we get a good
> looking
> > 32x32 icon there?
> >
>
> Pavel, do you know the license under which this icon is distributed? Can we
> see this icon?
>
>
> >
> > Thanks,
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>



-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

RE: Custom ThreadFactory

[Andrey Kornev]

Even better, Ignite might provide out-of-the-box access to the local instance 
via a 
thread local. It could be in a form of a static public 
method on the Ignition class. 

Ignite itself could benefit from 
this feature as it does get it wrong occasionally. A good example of 
this is the ClusterGroupAdapter class or any other class that serializes
 the instance of IgniteKernal. Imagine the situation where you have a 
single JVM with multiple Ignite nodes started -- Ignite requires the 
grid names to be different. But since only the name of the grid is 
serialized, during deserialization an invalid (unexpected, to put it 
mildly) instance of IgniteKernal is looked up. I don't know how serious 
it is, but it is probably a bug.

Regards
Andrey

> Date: Thu, 12 Nov 2015 21:11:38 +0300
> Subject: Re: Custom ThreadFactory
> From: voze...@gridgain.com
> To: dev@ignite.apache.org
> 
> I would avoid running any external payloads in public pool because it could
> unpredictably affect Ignite internals. "Public" doesn't mean "opened for
> everyone" here.
> 
> On the other hand, I abosuletly agree that removing possibility to
> configure custom pools was not very good idea. I do not see any problems
> with returning it back while still keeping "thread count" property for the
> most common use case when custom pool is not needed/
> 
> On Thu, Nov 12, 2015 at 9:02 PM, Andrey Kornev 
> wrote:
> 
> > Hello,
> >
> > If my memory doesn't fail me, in the pre-Ignite versions of GridGain, it
> > was possible to configure custom executor services which would then be used
> > to create the public, system, utility, etc. thread pools. In Ignite however
> > it's only possible to configure the size of the thread pools and not their
> > implementations.
> >
> > This is unfortunate as I'd like to be able to configure my own
> > ThreadFactory. My implementation would for example ensure that newly
> > created threads have their thread locals properly initialized (for example,
> > by storing the local instance of Ignite in it). Specific use case is being
> > able to get hold of the local Ignite instance during deserialization when
> > the JVM instance has multiple Ignite nodes started. Some of my classes must
> > be able to access resources that are local to the node on which they are
> > being deserialized. At the moment there is absolutely no way of achieving
> > something like that.
> >
> > I'm wondering if it would be possible to add this feature back to Ignite?
> > It seems to be indispensable for unit testing.
> >
> > Alternatively, to reduce the impact on the public API, an environment
> > variable that takes an FQN of the ThreadFactory to use would also work. It
> > would be injectable with the Ignite resources in the manner similar to how
> > it's done for the closures and factories...
> >
> > Regards
> > Andrey
> >
> > PS. While we're at it, I also remember that in the pre-Ignite versions it
> > was possible to inject an instance of the public executor service into the
> > closures. Not anymore. It causes the inconvenience of starting another
> > thread pool while there is already a public pool managed by Ignite with
> > plenty of threads idling most of the time... It feels wasteful.
> >
  

Re: Latest state of new Binary format

[Alexey Goncharuk]

Raul,

You are right, ignite-1282 is the integration branch for the Binary format.
There are a couple outstanding issues need to be fixed, but in general the
branch is stable enough to work with.

2015-11-12 15:51 GMT+03:00 Raul Kripalani :

> I think it's ignite-1282, right? I need a confirmation to start working
> from the right place.
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>
> On Thu, Nov 12, 2015 at 12:46 PM, Raul Kripalani  wrote:
>
> > Hello,
> >
> > I need to know in which branch the latest state of the Binary format is,
> > in order to introduce changes.
> >
> > It is my understanding that it hasn't been merged to 1.5 yet, right?
> >
> > Regards,
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > http://blog.raulkr.net | twitter: @raulvk
> >
>

[GitHub] ignite pull request: ignite-183: IgfsImpl and IgfsMetaManager use ...

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

ignite-183: IgfsImpl and IgfsMetaManager use the same busyLock.



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

$ git pull https://github.com/iveselovskiy/ignite ignite-183

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

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


commit 130433369010060e4567020eb10cf7712a5a0804
Author: iveselovskiy 
Date:   2015-11-12T17:34:25Z

ignite-183: IgfsImpl and IgfsMetaManager use the same busyLock.




---
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: ignite-platform module

[Dmitriy Setrakyan]

On Thu, Nov 12, 2015 at 5:37 AM, Raul Kripalani  wrote:

> On Thu, Nov 12, 2015 at 12:58 PM, Vladimir Ozerov 
> wrote:
>
> >
> > "platform" currently refers to some non-Java integration. OSGI/Karaf are
> > not "platforms" in this terminology.
>
>
> Yep, I suspected so. So you recommend creating an "osgi-karaf" directory
> under modules/ with all Karaf-related modules?
>

Raul, if we need to have a dependency on Karaf, then you are right, we
should have ignite-karaf module. However, I would prefer to have one
integration for all OSGI containers, not just Karaf, in which case the
module would be called “ignite-osgi” and put into “osgi" folder.


>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> http://blog.raulkr.net | twitter: @raulvk
>

Re: ignite-platform module

[Dmitriy Setrakyan]

On Thu, Nov 12, 2015 at 5:51 AM, Vladimir Ozerov 
wrote:

>
> If you follow this rule, you will place each module directly unders
> "modules". But may be it makes sense to rethink this approach and group
> realted modules under a single subdirectory: modules/[feature_name].
>

Vladimir, I think it is unclear how one approach is better than the other
apart from just being different. I would avoid undertaking this type of
restructuring unless we have a really compelling reason.


>
> Vladimir.
>
>

Re: NuGet icon hosting

[Dmitriy Setrakyan]

On Thu, Nov 12, 2015 at 6:50 AM, Pavel Tupitsyn 
wrote:

> Igniters,
>
> I'm working on a NuGet package for Ignite.NET (
> https://issues.apache.org/jira/browse/IGNITE-1626)
> It requires a 32x32 transparent png icon hosted somewhere (
> https://docs.nuget.org/create/nuspec-reference).
>
> We have some icons on our site, like
> https://ignite.apache.org/images/logo3.png.
>
> Who is responsible for the site and icons there? Can we get a good looking
> 32x32 icon there?
>

Pavel, do you know the license under which this icon is distributed? Can we
see this icon?


>
> Thanks,
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

[GitHub] ignite pull request: IGNITE-1626 .Net: Create NuGet package.

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1626 .Net: Create NuGet package.



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

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

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

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


commit f6786765ea52540ff18227c798eb0c9ae47715c4
Author: Pavel Tupitsyn 
Date:   2015-11-12T11:58:43Z

IGNITE-1626 .Net: Create NuGet package.

commit 9df5a1e2ab5ac73e3064a014c26c024db7a72e37
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:08:49Z

wip

commit 300124b846c4b7a40738e4d1e0417ee1658cd1b4
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:12:12Z

wip

commit fe651ecd8696622417365f3d207d1056f0b9fb6e
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:25:50Z

wip

commit 2a13da32b11275e663bbc18bd1fb2bf3dedab3d1
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:27:26Z

wip

commit 5d2a7c5fd8a162add23f156206d0369763c56cd1
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:34:03Z

wip

commit c3bac9ca07a57ac67dde42bafdc006fe168586fc
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:37:18Z

wip

commit b7b1fb667f6200bd06f04cfb80fb3af15a32b802
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:45:43Z

wip

commit 846a9b6577e9466ad606a19c9bd7bfc851668135
Author: Pavel Tupitsyn 
Date:   2015-11-12T13:57:09Z

wip

commit 608f92c8534e91cbae2e597da08f152152e54145
Author: Pavel Tupitsyn 
Date:   2015-11-12T14:07:43Z

Install.ps1 done

commit 7421d89cdf0822c93b932692e86aa86569aa2f99
Author: Pavel Tupitsyn 
Date:   2015-11-12T14:11:28Z

wip

commit cdeb2fed1503bc0e309cdd331023b9443317a68b
Author: Pavel Tupitsyn 
Date:   2015-11-12T14:19:37Z

Fix IgniteHome resolution

commit 1f410bb53ab62e095c6b5f3a8518fdd45adf
Author: Pavel Tupitsyn 
Date:   2015-11-12T15:22:04Z

Move nuget files to project folder

commit 628465c272ea82eeb9c303da7b245d108f611da1
Author: Pavel Tupitsyn 
Date:   2015-11-12T16:07:48Z

Merge remote-tracking branch 'remotes/upstream/ignite-1282' into ignite-1626




---
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-1897) Add failover to write-behind cache store

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-1897:
---

 Summary: Add failover to write-behind cache store
 Key: IGNITE-1897
 URL: https://issues.apache.org/jira/browse/IGNITE-1897
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
 Fix For: 1.6


Currently there is a possibility of losing database updates if primary node 
fails. We should maintain updates queue on backup node as well and flush it if 
needed.

The implementation should be similar to what is done with continuous queries in 
scope of this ticket: https://issues.apache.org/jira/browse/IGNITE-426



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