se have a look and let me know what you think?
> > > > > >
> > > > > > I'll implement a proof of concept of my proposed
> > > > > marshalling/unmarshalling
> > > > > > strategy and push it to Git so you can take it for
Thu, Nov 12, 2015 at 10:26 AM, Andrey Kornev <andrewkor...@hotmail.com>
> 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 Ig
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
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
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 <andrewkor...@hotmail.com&g
:
>
> > 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
fact if a
> > 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
exist in the same container. So it becomes more
> > > > complex.
> > > >
> > > > Using the TCCL should work when serialising, but it'll probably be of
> > no
> > > > use when deserialising on the other end.
> > > >
> > > > I
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
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" <andrewkor...@hotmail.com> wrote:
>
> > Raul,
> >
> > The fundamental hurdle we need to jump over to
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
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
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 <andrewkor...@hotmail.com>
> wrote:
>
> > Hello,
> >
> > It seems that even
()?
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 <andrewkor...@hotmail.com>
> wrote:
>
> > Thanks, Andrey! This
{
> return null;
> }
> });
>
> // Picking node.
> ClusterNode node = parts.get(aff.partition(key)).get(0);
>
>
> --Yakov
>
> 2015-10-07 11:39 GMT+03:00 Andrey Kornev <andrewkor...@hotmail.com>:
>
> >
are of changes in this collection.
On Tue, Oct 6, 2015 at 6:46 PM, Andrey Kornev <andrewkor...@hotmail.com>
wrote:
> Thanks, Andrey! This definitely helps.
>
> It's just that implementing such a simple feature in the "user space"
> feels
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:
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
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
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
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
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
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
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
e.apache.org
>
> On Mon, Nov 30, 2015 at 9:02 AM, Andrey Kornev <andrewkor...@hotmail.com>
> wrote:
>
> >
> > Neither Coherence nor Hazelcast require the EP to be stateless and
> > side-effect free. Even better Hazelcast makes the choice explicit by
>
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
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
able to 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://is
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
Just to clarify, 7.4 below refers to GridGain 7.4, which is Ignite 1.4.
_
From: Andrey Kornev <andrewkor...@hotmail.com>
Sent: Sunday, January 17, 2016 10:27 AM
Subject: RE: Semaphore action
To: <dev@ignite.apache.org>
ddition,
> 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 <andrewkor...@hotmail.com>
> wrote:
>
> > Dmitriy,I don't
urned by callable. Makes sense?
>
>
> --Yakov
>
> 2016-01-18 0:39 GMT+03:00 Andrey Kornev <andrewkor...@hotmail.com>:
>
> > Just to clarify, 7.4 below refers to GridGain 7.4, which is Ignite 1.4.
> > _
> > From: Andr
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,
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
, would fix most 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 <andrewkor...@hotmail.com>
> > wrote:
> >
> &
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
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
e if I am 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 <andrewkor...@hotmail.com>
> wrote:
>
> > Hello,
> >
> > It's come to my attention, when register
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
ar. 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 ticket is
> > that th
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
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
now without
compression, I think it is not an 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...
+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
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
+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
run queries from closures and tasks.
Vladimir.
On Wed, Oct 26, 2016 at 8:37 AM, Andrey Kornev <andrewkor...@hotmail.com>
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 trul
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
.
Regards
Andrey
From: Dmitriy Setrakyan <dsetrak...@apache.org>
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 <andrewkor...@hotmail.c
ample in JavaScript I 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
<andrewkor...@hotmail.com<mailto:andrewkor...@hotmail.com>> wrote:
Hey Andrey,
Thanks for your reply!
We've been using
iver's usage of JavaLogger
Hi Andrey,
What kind of fix do you suggest?
On Mon, Oct 23, 2017 at 6:58 PM, Andrey Kornev <andrewkor...@hotmail.com>
wrote:
> Hello,
>
> Just curious if anyone knows why IgniteJdbcDriver class instantiates a
> JavaLogger() on line 410 rather than using
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
nother 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 <andrewkor...@hotmail.com>
wrote:
> Pavel,
>
> I have absolutely no doubts that support for all those features will
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
(!)
me. Sounds like a useful feature.
>
> Would be nice to hear what others in the community think?
>
> D.
>
> On Fri, Nov 3, 2017 at 1:07 PM, Andrey Kornev <andrewkor...@hotmail.com>
> wrote:
>
> > Hello,
> >
> > We store lots of byte arrays (serialized g
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
For example, we can add new methods to reader/writer/builder,
which will handle this. E.g.:
BinaryWriter.writeByteArray();
BinaryReader.readByteArray();
Vladimir.
On Mon, Nov 6, 2017 at 9:25 PM, Andrey Kornev
<andrewkor...@hotmail.com<mailto:andrewkor...@hotmail.com>>
wrote:
> Will do
: Andrey Kornev <andrewkor...@hotmail.com>
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 s
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
.@gridgain.com>
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 <andrewkor...@hotmail.com>:
>
>> Vladimir,
>>
>>
adPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> What am I missing here? Can you provide an example of how to send a
> 'String' type request?
>
> -Prachi
>
> On Mon, Dec 4, 2017 at 1:06 PM, Andrey Kornev <andr
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
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 <andrewkor...@hotmail.com>
wrote:
> Pavel,
>
> I have absolutely no doubts that support for all those features will be
>
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
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
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
keeper is proven 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 <andrewkor...@hotmail.com>:
> Semyon,
>
> Not to discourage you or an
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
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 <andrewkor...@hotmail.com>
wrote:
> If I were the one responsible for running Ignite-based applications (be it
> embedded or standalone Ignite
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
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-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
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
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
75 matches
Mail list logo