Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/570
---
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 enab
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/581
---
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 enab
Roman Shtykh created IGNITE-2904:
Summary: IgniteStream API Implementation
Key: IGNITE-2904
URL: https://issues.apache.org/jira/browse/IGNITE-2904
Project: Ignite
Issue Type: New Feature
Roman Shtykh created IGNITE-2905:
Summary: Window processing support for IgniteStream
Key: IGNITE-2905
URL: https://issues.apache.org/jira/browse/IGNITE-2905
Project: Ignite
Issue Type: Sub-t
Igniters,
In some cases there is necessity to control a type of object that is
being inserted into a cache.
Presently this kind of check is accomplished at compile time only
relying on Java Generics. However it doesn't prevent us from connecting
to a cluster using a non-generic instance of a c
GitHub user avinogradovgg opened a pull request:
https://github.com/apache/ignite/pull/585
Professional 7.5.11
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite gridgain-7.5.11
Alternatively you can review a
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/582
---
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 enab
Krome Plasma created IGNITE-2906:
Summary: Embedded / child element types indexing/queryfields
(non-flat)
Key: IGNITE-2906
URL: https://issues.apache.org/jira/browse/IGNITE-2906
Project: Ignite
Hello Igniters,
Lately I'm working on a ticket
https://issues.apache.org/jira/browse/IGNITE-2004. As part of the ticket
need to add API which will provide an ability to execute operation
asynchronously. The ability might be useful not only for continuous query
filter but also for cache and discove
We already had discussion about it several months ago. Normal practice is
to allow user specify thread pool where he would like to execute the
callback. This is how things work in JDK CompletableFutures and Hazelcast
futures, and this is the most flexible approach.
On Tue, Mar 29, 2016 at 2:23 PM,
This approach works for cases when callback will be invoked on local node
(cache future, local listener and etc), but how user set a thread pool when
callback executed on remote nodes (remote filter, entry processor and etc)?
On Tue, Mar 29, 2016 at 2:57 PM, Vladimir Ozerov
wrote:
> We already h
Pavel Tupitsyn created IGNITE-2907:
--
Summary: GridServiceNotFoundException is not descriptive
Key: IGNITE-2907
URL: https://issues.apache.org/jira/browse/IGNITE-2907
Project: Ignite
Issue Ty
Nick,
I hardly can image why user would like to have async entry processor
provided that we already have IgniteCache.withAsync(). Moreover, usually
this method is invoked while holding lock on entry, so it doesn't seem to
be a valid use case (plus remember about unwrap() method). Though, may be I
Pavel Tupitsyn created IGNITE-2908:
--
Summary: .NET: Missing IgniteConfiguration properties
Key: IGNITE-2908
URL: https://issues.apache.org/jira/browse/IGNITE-2908
Project: Ignite
Issue Type:
Vova,
1) As far as I remember, we enforce ordering of updates for the same key,
> right? If yes, then stalled filter invoke for update #1 will stall all
> further updates.
>
Invocation of filter will be implemented in thread-partition style for
supporting ordering of updates.
> 2) Listener noti
We will switch the Ignite JAR to the 1.0-alpha-1 version from Geronimo, but
I am still very confused.
I do not understand why we need to check any TCK compliance when creating a
JAR for the JSR107 spec. The TCK compliance should be checked against an
implementation, not a spec.
Is there any place
On Tue, Mar 29, 2016 at 3:04 PM Dmitriy Setrakyan
wrote:
> We will switch the Ignite JAR to the 1.0-alpha-1 version from Geronimo,
> but I am still very confused.
>
> I do not understand why we need to check any TCK compliance when creating
> a JAR for the JSR107 spec. The TCK compliance should b
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
ok, let me try to make it clearer (and don't hesitate to shout if still not ;)):
TCK are not only @Test but also some bianary validations (aka sigtest
or signature tests) the spec jars need to pass. It basically checks
you respect the spec signature for the supported java version of the
spec. Not
How about adding setTypeNames() configuration property that will be similar
to setTypes(), but for binary objects?
-Val
On Tue, Mar 29, 2016 at 1:56 AM, Denis Magda wrote:
> Igniters,
>
> In some cases there is necessity to control a type of object that is being
> inserted into a cache.
> Prese
On Tue, Mar 29, 2016 at 3:49 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> How about adding setTypeNames() configuration property that will be similar
> to setTypes(), but for binary objects?
>
Agree. Sounds like it will solve the problem, no?
>
> -Val
>
> On Tue, Mar 29, 20
I just mention to mention that Apache Ignite passes JCache TCK with flying
colors :)
We have it integrated into our build routine and verify it using our CI
tests. In addition, it was verified by one of the JCache spec leads, Greg
Luck, who confirmed that Ignite complies with the spec.
Given the
Denis Magda created IGNITE-2909:
---
Summary: Checking cache object type in runtime
Key: IGNITE-2909
URL: https://issues.apache.org/jira/browse/IGNITE-2909
Project: Ignite
Issue Type: Improvement
Sounds good. Created the ticket
https://issues.apache.org/jira/browse/IGNITE-2909
On 3/30/2016 2:40 AM, Dmitriy Setrakyan wrote:
On Tue, Mar 29, 2016 at 3:49 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
How about adding setTypeNames() configuration property that will be simi
Le 30 mars 2016 01:45, "Dmitriy Setrakyan" a écrit :
>
> I just mention to mention that Apache Ignite passes JCache TCK with
flying colors :)
>
True! Totally forgot tck were open! Didn't check sigtest, is it there too?
If so nothing blocking a 1.0.
> We have it integrated into our build routine
Hi Konstantin,
Do you have any progress on this ticket? When do you plan to finish it?
-Val
On Wed, Mar 2, 2016 at 2:54 AM, Yakov Zhdanov wrote:
> Hi Konstantin!
>
> I have added a comment to the ticket.
>
> --Yakov
>
> 2016-03-01 16:13 GMT+03:00 Konstantin Margorin :
>
> > Hello Igniters.
> >
Alexey Kuznetsov created IGNITE-2910:
Summary: VisorNodeDataCollectorTask should collect info about
offheap and swap keys per partitions
Key: IGNITE-2910
URL: https://issues.apache.org/jira/browse/IGNITE-2910
27 matches
Mail list logo
