GitHub user wmz7year opened a pull request:
https://github.com/apache/ignite/pull/227
Fix Ignite-1900
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/wmz7year/ignite ignite-1900
Alternatively you can review and apply these c
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
Compon
Github user wmz7year closed the pull request at:
https://github.com/apache/ignite/pull/200
---
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 en
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
Al
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 1
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/IGN
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
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
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 ge
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 u
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.
Now,
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 OS
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
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 ClusterGr
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 pr
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.
* Ther
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 an
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-
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
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
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
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
Pavel Tupitsyn created IGNITE-1896:
---
Summary: .Net: Improve query API
Key: IGNITE-1896
URL: https://issues.apache.org/jira/browse/IGNITE-1896
Project: Ignite
Issue Type: Improvement
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 re
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
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/ji
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
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
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
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?
R
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 :
I need to add that in the next scenario AffinityImpl will be used (not
AffinityProxy) and the code throws NPE too.
ignite.getOrCreateCache(new CacheConfiguration("myCache"));
Affinity affinity = ignite.affinity("myCache");
affinity.mapPartitionToNode(0); // All ok.
ignite2.cache("myCache").dest
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
AffinityPr
Raul,
"platform" currently refers to some non-Java integration. OSGI/Karaf are
not "platforms" in this terminology.
On Thu, Nov 12, 2015 at 3:22 PM, Raul Kripalani wrote:
> Hello,
>
> Currently we have a single ignite-platform module aggregating all sources
> for .NET and CPP integration.
>
> F
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.ne
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 Engin
Guys,
I have created wiki page to put and discuss ideas for blog topics -
https://cwiki.apache.org/confluence/display/IGNITE/Blog+Topics
--Yakov
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 K
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 We
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
40 matches
Mail list logo
