, 2018 6:22 PM
To: dev@ignite.apache.org
Subject: Re: IEP-14: Ignite failures handling (Discussion)
On Wed, Mar 14, 2018 at 3:36 PM, Andrey Kornev
wrote:
> If I were the one responsible for running Ignite-based applications (be it
> embedded or standalone Ignite) in my company's datacen
If I were the one responsible for running Ignite-based applications (be it
embedded or standalone Ignite) in my company's datacenter, I'd prefer the
application nodes simply make their current state readily available to external
tools (via JMX, health checks, etc.) and leave the decision of when
I believe the only reasonable way to handle a critical system failure (as it is
defined in the IEP) is a JVM halt (not a graceful exit/shutdown!). The sooner -
the better, lesser impact. There’s simply no way to reason about the state of
the system in a situation like that, all bets are off. Any
Sergey,
The way I "solved" this problem was to modify both
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi#getNodeAddresses(TcpDiscoveryNode,
boolean)
and
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#nodeAddresses(ClusterNode)
to make sure the external IP addresses (the one
en to be correct and
reliable coordinator service by many users and Jepsen tests, as opposed to
various in-house implementations (e.g. Zen of Elasticsearch).
вт, 9 янв. 2018 г. в 21:53, Andrey Kornev :
> Semyon,
>
> Not to discourage you or anything, just a interesting fact from recent
>
Andrey Kornev created IGNITE-7368:
-
Summary: IgniteCache.getAll() throws high volume of
GridDhtInvalidPartitionException if on-heap is enabled
Key: IGNITE-7368
URL: https://issues.apache.org/jira/browse/IGNITE
Semyon,
Not to discourage you or anything, just a interesting fact from recent history.
I vaguely remember already trying to implement DiscoverySpi on top of Zookeeper
back in 2012. After a few failed attempts and a lot of help from Zookeeper's
original developers (Flavio Junqueira and Ben Reed
take weeks :)
But, of course, you are welcome to take the initiative.
Thanks,
Pavel
On Tue, Dec 5, 2017 at 10:20 PM, Andrey Kornev
wrote:
> Pavel,
>
> I have absolutely no doubts that support for all those features will be
> added eventually. And if so, wouldn't it be th
Andrey Kornev created IGNITE-7156:
-
Summary: Disabling readFromBackup for a cache effectively disables
near cache on non-affinity nodes
Key: IGNITE-7156
URL: https://issues.apache.org/jira/browse/IGNITE-7156
sense to do that. Another problem is that it will
take weeks :)
But, of course, you are welcome to take the initiative.
Thanks,
Pavel
On Tue, Dec 5, 2017 at 10:20 PM, Andrey Kornev
wrote:
> Pavel,
>
> I have absolutely no doubts that support for all those features will be
> added
.run(
> GridWorker.java:110)
> at org.apache.ignite.internal.util.worker.GridWorkerPool$1.
> run(GridWorkerPool.java:70)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> Threa
Pavel,
Thanks! While we're at it, are there any plans to add cluster-related
operations? For example, I think it'd be nice to allow the thin clients to
obtain a current topology snapshot. This would make it possible the clients to
send requests directly to the affinity host for colocated comput
Pavel,
Great job on the Thin Client protocol design!
I'm a bit late to the party, but I'm wondering why none of the compute features
are supported? Such omission is unfortunate. Is it intentional? If so, what are
the reasons?
I think it would be useful for the clients to be able to invoke alre
My 2 cents. Don’t do it. JVM provides sufficient means of detecting a
struggling process out of the box. SRE/Operations teams usually know how to
monitor JVMs and can handle killing of such processes themselves.
The feature adds no value, just complexity (and more configuration parameters
(!) —
: Andrey Kornev
Sent: Sunday, November 5, 2017 12:17 PM
To: dev@ignite.apache.org
Subject: Query duration metrics
Hi,
It appears as if the query duration metric is a bit misleading.
GridQueryProcessor.executeQuery() doesn't actually "run" the query. It simply
delegates query
0:16 AM, Vladimir Ozerov
wrote:
> ByteBuffer is not fundamental data type. It is a thin wrapper over array.
> Protocol should contain only fundamental types.
>
> вт, 7 нояб. 2017 г. в 10:05, Andrey Kornev :
>
>> Vladimir,
>>
>> Could you please elaborate as to why addin
.g.:
BinaryWriter.writeByteArray();
BinaryReader.readByteArray();
Vladimir.
On Mon, Nov 6, 2017 at 9:25 PM, Andrey Kornev
mailto:andrewkor...@hotmail.com>>
wrote:
> Will do! Thanks!
>
> From: Valentin Kulichenko
> mailto:valentin.kuliche...@g
what others in the community think?
>
> D.
>
> On Fri, Nov 3, 2017 at 1:07 PM, Andrey Kornev
> wrote:
>
> > Hello,
> >
> > We store lots of byte arrays (serialized graph-like data structures) as
> > fields of BinaryObject. Later on, while reading such field,
Hi,
It appears as if the query duration metric is a bit misleading.
GridQueryProcessor.executeQuery() doesn't actually "run" the query. It simply
delegates query execution to a closure passed in as a parameter. The closure
may or may not actually execute the query. In some (all?) cases, the clo
Hello,
We store lots of byte arrays (serialized graph-like data structures) as fields
of BinaryObject. Later on, while reading such field, BinaryInputStream
implementation creates an on-heap array and copies the bytes from the
BinaryObject's internal backing array to the new array.
While in ge
Hello,
Ignite adds the cache key and optionally the affinity key (if defined) as two
last columns of all user-defined indexes (line 301 in H2TableDescriptor). For
example, given a user index salary_idx including a single field "salary", the
actual index is going to look like this:
CREATE INDEX
Logger
Hi Andrey,
What kind of fix do you suggest?
On Mon, Oct 23, 2017 at 6:58 PM, Andrey Kornev
wrote:
> Hello,
>
> Just curious if anyone knows why IgniteJdbcDriver class instantiates a
> JavaLogger() on line 410 rather than using the globally configured logger
> instance?
&
Hello,
Just curious if anyone knows why IgniteJdbcDriver class instantiates a
JavaLogger() on line 410 rather than using the globally configured logger
instance?
I have an slf4j logger configured and with ignite-indexing module in the
classpath, I get scary looking (albeit benign) message in m
ation.
Regards
Andrey
From: Dmitriy Setrakyan
Sent: Monday, October 16, 2017 6:14 PM
To: dev@ignite.apache.org
Subject: Re: Indexing fields of non-POJO cache values
On Mon, Oct 16, 2017 at 12:35 PM, Andrey Kornev
wrote:
> [Crossposting to the dev list]
>
> A
could (almost on the fly) declare getters and
setters that could be as aliases for my data.
On Fri, Oct 13, 2017 at 12:39 AM, Andrey Kornev
mailto:andrewkor...@hotmail.com>> wrote:
Hey Andrey,
Thanks for your reply!
We've been using a slightly different approach, where we extract t
could (almost on the fly) declare getters and
setters that could be as aliases for my data.
On Fri, Oct 13, 2017 at 12:39 AM, Andrey Kornev
mailto:andrewkor...@hotmail.com>> wrote:
Hey Andrey,
Thanks for your reply!
We've been using a slightly different approach, where we extract t
from closures and tasks.
Vladimir.
On Wed, Oct 26, 2016 at 8:37 AM, Andrey Kornev
wrote:
> Guys,
> I feel very uneasy about proliferation of thread pools in Ignite. I
> suggest we take step back.
> Most of the users (including yours truly) have no idea how to correctly
> configure
Guys,
I feel very uneasy about proliferation of thread pools in Ignite. I suggest we
take step back.
Most of the users (including yours truly) have no idea how to correctly
configure the existing thread pools, what those thread pools are for (like,
management thread pool, or marshaller cache thr
+1
I'm particularly interested in the use case where I have caches that are
created dynamically and in general I don't know in advance how many of them
will exist at any point in time. But I do know the total amount of memory I'm
willing to make available to the caches.
So it would be nice if th
issue, we could add a NOTE to
documentation about such possibility.
Andrey Kornev wrote:
>> ... in general I think compression is a great data. The cleanest way to
achieve that would be to just make it possible to chain the marshallers...
I think it is also good idea. And looks like it could be used
I'm guessing the suggestion here is to use the compressed form directly for
WHERE clause evaluation. If that's the case I think there are a couple of
issues:
1) the LIKE predicate.
2) predicates other than equality (for example, <, >, etc.)
But since Ignite isn't just about SQL queries (surpr
+1 "Async" suffix.
From: Vladimir Ozerov
Sent: Thursday, July 21, 2016 2:41 AM
To: dev@ignite.apache.org
Subject: Re: Rework "withAsync" in Apache 2.0
Moreover, have a look at *CompletableFuture *interface:
handle
handle*Async*
thenApply
thenApply*Async*
And
Totally agree with this particular suggestion. On more than just a few
occasions I've been greatly confused by Ignite's "asynchronous" operations
that in reality are blocking under some circumstances and non-blocking under
others... Go figure! The reason I was given for such design was performa
Hello,
It appears that a LOCAL cache gets created on all cluster nodes despite it
being LOCAL. In other words, a call to Ignite.getOrCreateCache(...) results in
the cache started on all nodes:
3871 [exchange-worker-#74%Node1%] INFO GridCacheProcessor - Started cache
[name=myCache, mode=LOCAL
Andrey Kornev created IGNITE-3306:
-
Summary: Extend IgniteCluster interface with the methods to send
and receive custom discovery events
Key: IGNITE-3306
URL: https://issues.apache.org/jira/browse/IGNITE-3306
Hello,
I'd like to suggest making the point about the callback execution ordering more
prominent in the Ignite documentation and/or the javadocs of
@IgniteAsyncCallback. I think the documentation should emphasize the fact that
the events for the same keys are guaranteed to be delivered in-orde
g jars or something similar. Hence, my this email
> thread.
>
> Were my assumptions incorrect.
> Thanks
> Cos
>
> On Thu, May 05, 2016 at 04:39AM, Andrey Kornev wrote:
> > Anton,
> >
> > My first impression after having taken a look at bigtop's JIRA ti
Anton,
My first impression after having taken a look at bigtop's JIRA ticket is that
the issue is not so much with OSGi per se, but rather it has something to do
with Ignite's HDFS accelerator yum packaging.
Regards
Andrey
> Date: Thu, 5 May 2016 13:55:26 +0300
> Subject: Re: 1.5.0.final is br
Vladimir, Igniters
Here are my 2 cents.
The current situation with threading when it comes to executing user callbacks
-- the CQ filters (either local or remote), the CQ listeners, the event
listeners, the messaging listeners, the entry processors (did I miss anything?)
-- is pretty sad. The
This is a nasty problem that is very difficult to track especially for
beginners. But I think it's easy to solve: since the BinaryObjects are built
exclusively using the BinaryObjectBuilder, you can simply implement a check in
the BinaryObjectBuilder.build() to see whether or not
BinaryObjectBu
This is a nasty problem that is very difficult to track especially for
beginners. But I think it's easy to solve: since the BinaryObjects are built
exclusively using the BinaryObjectBuilder, you can simply implement a check in
the BinaryObjectBuilder.build() to see whether or not
BinaryObjectBu
Alexey,
Thank you for the explanation!
But why any of that matters in this case? I'm talking about the REPLICATED
cache -- all data changes get applied to all nodes in the same order on all
nodes. And I'm talking about a cache event listener that is instantiated on one
of thise nodes. It can b
Alexey,
I'm talking about JCache's CacheEntry listener (which I think is implemented on
top of the continuous query feature).
Andrey
> Date: Wed, 9 Mar 2016 15:52:48 -0800
> Subject: Re: CacheEntryEventFilter with Replicated caches
> From: alexey.goncha...@gmail.com
> To: dev@ignite.apache.org
wrong). In that case, it will be impossible to
> deploy it only on the node that registered it.
>
> D.
>
> On Wed, Mar 9, 2016 at 1:44 PM, Andrey Kornev
> wrote:
>
> > Hello,
> >
> > It's come to my attention, when registering the cache event listene
Hello,
It's come to my attention, when registering the cache event listener, the
filters get deployed on all the nodes of the cache, despite the fact that the
cache is configured as REPLICATED. This seems redundant since it's sufficient
to have the filter deployed only on the node that has the
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
>
of the issues. In the long term, we should fix the
> > binary serialization to work the way you are describing.
> >
> > D.
> >
> > On Sat, Feb 20, 2016 at 9:26 AM, Andrey Kornev
> > wrote:
> >
> > > Val,
> > >
> > >
Val,
I think Ignite Serialization should follow the approach similar to what Java
serialization does: it can transparently and consistently handle both
Serializable and Externalizable classes. It can do it because it relies on a
single class - ObjectOutputStream - to do serialization (and a sin
50MB for an empty cache! That's a lot of emptiness!
The Ignite team's recommendation to have one key/value type per cache now seems
a little more dubious and difficult to follow in practice.
Just curious, what is the reason for such waste? Is it because by default the
initial cache size is set
Another perhaps bigger problem with running queries (including scan queries)
using closures was discussed at length on the @dev not so long ago. It has to
do with partitions migration due to cluster topology changes which may result
in the query returning incomplete result. And while it is possi
her Ignite operations. Andrey, what was the pool intended for?
>
> This T> IgniteFuture acquireAndExecuteAsyncAction(Callable>
> action); can be implemented with IgniteFuture
> acquireAndExecute(Callable action); where T is IgniteFuture for
> operations initiated and
Just to clarify, 7.4 below refers to GridGain 7.4, which is Ignite 1.4.
_
From: Andrey Kornev
Sent: Sunday, January 17, 2016 10:27 AM
Subject: RE: Semaphore action
To:
Vladisav,
It would be great if you could implement the
It does sounds like a useful addition,
> and I believe it could be implemented easily.
> I can do it if the community agrees on changing the API of the Semaphore.
>
> Best regards,
> VJ
>
> On Sun, Jan 17, 2016 at 5:53 AM, Andrey Kornev
> wrote:
>
> > Dmitriy,I don&#x
Andrey,
In general this seems like a good addition. However, I do not understand
how you can specify an executor, given that execution could happen
remotely. Can you please clarify?
D.
On Fri, Jan 15, 2016 at 1:00 PM, Andrey Kornev
wrote:
&g
Hi there,
The Semaphore feature was a great addition to Ignite's synchronization
primitive toolkit. I'd like to propose an enhancement to make Semaphore API
even more useful.
My biggest complaint about the current API is its blocking nature. For example,
the only way to acquire a permit is by
create
> > and update indexes dynamically. There is a ticket, IGNITE-735 [1], that
> > has been sitting around for a while. I think we should reprioritize it.
> >
> > Sergi, can you please comment on how hard this would be to implement?
> >
> > [1] https://iss
Hello, Ignite Community,
IgniteBinary javadocs mention the ability to dynamically change the structure
of the "classes" without restarting the cluster. The javadocs even say that the
new fields become automatically available to the SQL queries with no extra
effort. It's all fine and dandy, but
Dmitriy,
Alexey's point is just an explanation of the existing implementation and not
how it is supposed to be. And while nobody really knows what the correct
behavior should be, the one implemented by Ignite is incredibly
over-engineered. As I argued in a different thread, other vendors provi
s
> To: dev@ignite.apache.org
>
> On Mon, Nov 30, 2015 at 9:02 AM, Andrey Kornev
> wrote:
>
> >
> > Neither Coherence nor Hazelcast require the EP to be stateless and
> > side-effect free. Even better Hazelcast makes the choice explicit by
> > providing the back
Raul,
I'm not associated with GG and my opinion is that Yakov's naming is good enough.
And since you've asked for opinions, it's also my opinion that the discussion
about the naming was a non-consequential bikeshedding
(https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality) and potentiall
Thank you, Alexey!
By stating that "sending a serialized EntryProcessor should be cheaper" you
implicitly assume that the cache entry is big and the computation done by the
processor is cheap. But what if it's not the case? What if the computation
itself is quite expensive and depends on extern
iguration#getBackups amount
>2. just a remote nodes with some other keys
>
> Thanks!
>
> On Wed, Nov 25, 2015 at 8:43 PM, Andrey Kornev
> wrote:
>
> > Hello,
> >
> > I'd like to ask the community members to share their thoughts/opinions on
> >
Hello,
I'd like to ask the community members to share their thoughts/opinions on the
following subject.
JCache provides a way to atomically execute one or more actions against a cache
entry using the Entry Processor mechanism. The Cache interface exposes an
invoke() method that takes a key of
Raul, if you don't mind, for posterity, could you please collect all your ideas
spread all over this two-week long email thread and update the wiki page here
https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility? The
details of your de-/serialization implementation would be espec
u, 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
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
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
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 an
gt; > > > > > I'll implement a proof of concept of my proposed
> > > > > marshalling/unmarshalling
> > > > > > strategy and push it to Git so you can take it for a spin.
> > > > > >
> > > > > > Reg
a.org/wiki/Principle_of_least_astonishment).
Regards
Andrey
> From: dsetrak...@apache.org
> Date: Sat, 7 Nov 2015 00:32:37 -0800
> Subject: Re: LOCAL cache serializes the entries?
> To: dev@ignite.apache.org
>
> On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev
> wrote:
>
> >
> > Th
ache.org
> Date: Thu, 5 Nov 2015 17:34:28 -0800
> Subject: Re: LOCAL cache serializes the entries?
> To: dev@ignite.apache.org
>
> On Thu, Nov 5, 2015 at 6:44 AM, Andrey Kornev
> wrote:
>
> > Hello,
> >
> > It seems that even if the cache is configured as LO
Hello,
We've made an attempt to formalize the approach to Ignite's OSGi enablement:
https://cwiki.apache.org/confluence/display/IGNITE/OSGI+Compatibility. Please
have a look and feel free to provide your positive feedback :)))
Thanks
Andrey
> From: dsetrak...@apache.org
> Date: Wed, 4 Nov 2015
Hello,
It seems that even if the cache is configured as LOCAL, the entries are
nevertheless stored in serialized form. If that's the case, could someone
explain the reasons?
Regards
Andrey
; wrote:
>
> > Andrey, et al,
> >
> > Can you provide a way on how to get a required Bundle object based on, say,
> > bundle symbolic name and version?
> >
> > I have reached the end of the internet trying to find a way in OSGI to look
> > up a Bundle b
t; > bundle is refreshed, it will produce a new BundleRevision and therefore a
> > new classloader. And if you don't release the class from the previous
> > BundleRevision then you endup with memory leak. So maybe the Marshaller
> > interface or somewhere should provide a
t; complex.
> > > >
> > > > Using the TCCL should work when serialising, but it'll probably be of
> > no
> > > > use when deserialising on the other end.
> > > >
> > > > I need to enhance Ignite to:
> > > >
> > >
Gi manifest header or the like, as I explained before.
> Package version must be taken into account.
>
> What do you think?
>
> Raúl.
> On 2 Nov 2015 17:25, "Andrey Kornev" wrote:
>
> > Raul,
> >
> > The fundamental hurdle we need to jump over to ma
Raul,
The fundamental hurdle we need to jump over to make Ignite OSGi-enabled is the
marshalling. More specifically the issue is with deserialization of the classes
that are provided by the bundles other than the Ignite bundle itself.
When the Ignite transport layer receives a message it needs
Alexey,
PortableBuilder has an (un-documented) method hashCode(int hashCode) that
should be used to explicitly set the hashCode for the portable instance being
built. I'm not sure why this has been designed this way, but I'm guessing that
since the PortableBuilder is pretty dumb and it wouldn't
Hello,
Just a few questions.
1) It's not clear from the proposed API how to capture/retrieve a consistent
snapshot of multiple caches. If my query involves a join I'd like to ensure
consistency across all join participants.
2) Implementation wise, is the snapshot just a physical copy of all cac
Excellent idea! +10
PS. Got burnt by this a few times already
_
From: Vladimir Ozerov
Sent: Friday, October 9, 2015 4:22 PM
Subject: Which thread is used to run IgniteFuture continuations?
To:
Igniters,
We are missing an ability to sp
discoveryEvent() {
> return null;
> }
> });
>
> // Picking node.
> ClusterNode node = parts.get(aff.partition(key)).get(0);
>
>
> --Yakov
>
> 2015-10-07 11:39 GMT+03:00 Andrey Kornev :
>
> > Dmitriy,
> >
ined as
ClusterGroup.forCache()?
Thanks
Andrey
> From: dsetrak...@apache.org
> Date: Tue, 6 Oct 2015 12:07:39 -0700
> Subject: Re: Cluster group affinity
> To: dev@ignite.apache.org
>
> On Tue, Oct 6, 2015 at 8:46 AM, Andrey Kornev
> wrote:
>
> > Thanks, Andrey! This
On Tue, Oct 6, 2015 at 6:46 PM, Andrey Kornev
wrote:
> Thanks, Andrey! This definitely helps.
>
> It's just that implementing such a simple feature in the "user space"
> feels awkward and requires intimate knowledge of fairly lo
ent method and assignments for previous cluster
> group state from previousAssignment method.
>
> RendezvousAffinityFunction uses only currentTopologySnapshot() and
> backups() methods of AffinityFunctionContext interface.
>
>
> On Tue, Oct 6, 2015 at 5:07 PM, Andrey Kornev
&
can use existing
> affinity functions for you case just passing properly formed
> AffinityFunctionContext to assignPartitions method.
>
> On Tue, Oct 6, 2015 at 4:25 PM, Andrey Kornev
> wrote:
>
> > Dmitriy,
> >
> > The affinity function only maps a key to a partiti
5 Oct 2015 09:53:25 -0700
> Subject: Re: Cluster group affinity
> To: dev@ignite.apache.org
>
> On Mon, Oct 5, 2015 at 2:28 AM, Andrey Kornev
> wrote:
>
> > Hello,
> >
> > I have a user-defined cluster group and I'd like to be able to
> > consistent
Hello,
I have a user-defined cluster group and I'd like to be able to consistently
pick the same node in the group for a given key. Essentially, what I want is a
cluster group affinity that is not associated with any cache. How can I do it?
Thanks
Andrey
Hello,
I could not find any documentation that describes the behavior of data mutating
operations wrt transactions when executed against TRANSACTIONAL caches.
Specifically, I'd like to know whether or not the mutators start implicit
transactions and if so, how do I configure the properties of
Andrey Kornev created IGNITE-1533:
-
Summary: Add support for Azul Zing JVM
Key: IGNITE-1533
URL: https://issues.apache.org/jira/browse/IGNITE-1533
Project: Ignite
Issue Type: Task
some conversations that most of their sales are coming from the
> commercial support of OpenJDK. What I am saying that if the support effort of
> Azul is huge, may be there's no point of doing this... ;)?
>
> Cos
>
> On Tue, Sep 22, 2015 at 11:47AM, Dmitriy Setrakyan wrote
Hello,
Since it looks like there is an effort underway to certify Ignite on different
JVMs, I'm wondering if Azul Zing could also be considered as a potential
candidate?
Regards
Andrey
Andrey Kornev created IGNITE-1401:
-
Summary: Introduce special local node discovery events
Key: IGNITE-1401
URL: https://issues.apache.org/jira/browse/IGNITE-1401
Project: Ignite
Issue Type
as a group, all to the same new node.
Thanks
Andrey
> From: dsetrak...@apache.org
> Date: Mon, 7 Sep 2015 21:02:46 -0700
> Subject: Re: Services collocation
> To: dev@ignite.apache.org
>
> On Mon, Sep 7, 2015 at 6:05 PM, Andrey Kornev
> wrote:
>
> > Hello,
>
Hello,
I'd like to be able to deploy my cluster-wide singleton services all collocated
on the same cluster node. What is the best way to achieve that?
Ideally, I'd like to be able to define the "service groups" where all services
in a group would be deployed on the same node, whereas the differ
96 matches
Mail list logo
