RE: OSGi migration may require a special marshaller

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

RE: Custom ThreadFactory

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

RE: OSGi migration may require a special marshaller

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

Custom ThreadFactory

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

RE: Custom ThreadFactory

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

RE: OSGi migration may require a special marshaller

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

RE: OSGi migration may require a special marshaller

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

RE: OSGi migration may require a special marshaller

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

RE: OSGi migration may require a special marshaller

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

RE: OSGi migration may require a special marshaller

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

RE: OSGi migration may require a special marshaller

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

LOCAL cache serializes the entries?

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

RE: LOCAL cache serializes the entries?

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

RE: Cluster group affinity

()? 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

RE: Cluster group affinity

{ > 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>: > > >

Re: Cluster group affinity

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

Re: Which thread is used to run IgniteFuture continuations?

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:

Services collocation

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

Cluster group affinity

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

RE: Azul Zing

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

Azul Zing

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

RE: EntryProcessor invoked twice

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

EntryProcessor execution semantics

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

RE: EntryProcessor execution semantics

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

RE: [VOTE] Apache Ignite 1.5.0-EA

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

RE: EntryProcessor execution semantics

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 >

RE: API for asynchronous execution.

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

IgniteBinary, POJOs and indexing

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

RE: IgniteBinary, POJOs and indexing

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

Semaphore action

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

RE: Semaphore action

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>

RE: Semaphore action

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

RE: Semaphore action

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

LOCAL cache

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,

Re: Transformers in SCAN queries

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

RE: Binary object inside Externalizable

, 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: > > > &

CacheEntryEventFilter with Replicated caches

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

RE: CacheEntryEventFilter with Replicated caches

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

RE: CacheEntryEventFilter with Replicated caches

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

RE: CacheEntryEventFilter with Replicated caches

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

RE: 1.5.0.final is breaking packaging: osgi dependency is non-existent

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

RE: 1.5.0.final is breaking packaging: osgi dependency is non-existent

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

Re: Data compression in Ignite 2.0

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

Re: Data compression in Ignite 2.0

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...

Re: Rework "withAsync" in Apache 2.0

+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

Re: Rework "withAsync" in Apache 2.0

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

Re: Global off-heap memory limit

+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

Re: Create separate thread pool for query execution

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

Re: Create separate thread pool for query execution

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

Re: Indexing fields of non-POJO cache values

. 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

Re: Indexing fields of non-POJO cache values

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

Re: IgniteJdbcDriver's usage of JavaLogger

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

Re: Thin Client Protocol documentation

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

Re: Thin Client Protocol documentation

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

Re: Facility to detect long STW pauses and other system response degradations

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 (!)

Re: Deserialization of BinaryObject's byte arrays

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

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 execution to a closure passed in as a parameter. The closure may or may not actually execute the query. In some (all?) cases, the

Re: Deserialization of BinaryObject's byte arrays

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

Misleading query duration metrics

: 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

Deserialization of BinaryObject's byte arrays

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

Re: Deserialization of BinaryObject's byte arrays

.@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, >> >>

Re: Thin Client Protocol documentation

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

Re: Thin Client Protocol documentation

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

Re: Thin Client Protocol documentation

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 >

Sorted index includes the cache key and the affinity key columns. Why?

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

IgniteJdbcDriver's usage of JavaLogger

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

Re: DiscoverySpi based on Apache ZooKeeper

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

Re: DiscoverySpi based on Apache ZooKeeper

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

Re: TcpCommunicationSpi in dockerized environment

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

Re: IEP-14: Ignite failures handling (Discussion)

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

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

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

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

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

[jira] [Created] (IGNITE-3306) Extend IgniteCluster interface with the methods to send and receive custom discovery events

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

[jira] [Created] (IGNITE-7156) Disabling readFromBackup for a cache effectively disables near cache on non-affinity nodes

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

[jira] [Created] (IGNITE-7368) IgniteCache.getAll() throws high volume of GridDhtInvalidPartitionException if on-heap is enabled

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