Igniters,
I am starting migration of C++/.Net integration modules donated by GridGain
to Ignite. I am going to put all that stuff, including Java classes, .Net
classes and .cpp/.h files in a new module.
In GridGain we first named this stuff clients and later interop. But
there are several
), but
could we call the module Ignite4net or IgniteNetModule ?
The only thing to consider is that the interfaces in .NET are always named
with the letter I to the first position ( IService for example ).
Regards,
Gianfranco
2015-08-21 15:50 GMT+02:00 Vladimir Ozerov voze...@gridgain.com:
Igniters
*
Apache Camel PMC Member Committer | Enterprise Architect, Open Source
Integration specialist
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
On Fri, Aug 21, 2015 at 2:50 PM, Vladimir Ozerov voze...@gridgain.com
wrote
Alexey,
I do not think it makes sense to dig into this at all.
On Tue, Aug 18, 2015 at 1:21 PM, Alexey Kuznetsov akuznet...@gridgain.com
wrote:
Just curious: it is possible to use http://www.ikvm.net/ to run Ignite
under .Net
Does anyone investigate IKVM + Ignite?
On Tue, Aug 18, 2015 at
+1
On Tue, Aug 18, 2015 at 2:36 PM, Sergi Vladykin sergi.vlady...@gmail.com
wrote:
Agree, the whole concept of grid name looks weird if nodes with different
names still work as a single topology.
Though we will need to refactor our tests if we are going to remove it..
Sergi
2015-08-18
We already have a method GridCacheProcessor.checkCache() which accepts two
cache configurations - local and remote - and decides whether they are
compatible.
Looks like we just need to refactor it a bit so that it can be used for
getOrCreateCache scenario.
However, whatever checks we perform,
isCreated() property on cache itself.
On Fri, Aug 14, 2015 at 12:03 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
May be we can return not only cache instance, but also a boolean defining
whether a cache was created by this call or not?
E.g.:
IgniteCache getOrCreateCache
+1
It is hard to understand why do we have so much different annotations for
injections while requierd resource type could be clearly derived from field
or method types. Looks like a single annotation will be enough. And it
should not be hard to abstract out injection logic into SPI.
On Thu, Aug
May be we can return not only cache instance, but also a boolean defining
whether a cache was created by this call or not?
E.g.:
IgniteCache getOrCreateCache(...);
IgniteCache getOrCreateCache(..., CacheCreateResult);
class CacheCreateResult {
boolean isCreated();
}
On Fri, Aug 14, 2015 at
On 8/10/2015 11:55 AM, Vladimir Ozerov wrote:
Denis,
It seems that org.apache.ignite.tools.classgen.ClassesGenerator is what
you
need.
On Mon, Aug 10, 2015 at 11:36 AM, Denis Magda dma...@gridgain.com
wrote:
Igniters,
As a part of ignite-core module we have 'classnames.properties' file
Denis,
It seems that org.apache.ignite.tools.classgen.ClassesGenerator is what you
need.
On Mon, Aug 10, 2015 at 11:36 AM, Denis Magda dma...@gridgain.com wrote:
Igniters,
As a part of ignite-core module we have 'classnames.properties' file
located in ignite-core/META-INF folder. The file
We already worked on the problem a bit. Now IO pool is not an enum, but a
byte. We have 0..31 bytes reserved for Ignite pools (and some of them are
already used for existing pools), and the rest values are for plugins which
can register their own pools and send messages to them.
It seems to me
+1 for keeping things as is. I honestly do not believe that writting
JavaDocs consume statistically significant percentage of
commiter/contributor time.
Moreover different people tend to differently evaluate complexity of
code. Mature igniter will have much more obvious things than a newcomer.
It
Igniters,
Let's discuss how to mention contributor name when pushing contributed
patches. There are at least two ways of doing this:
1) Impersonate commit on behalf of real author. In this case commit will
appear in history as if it was performed by contributor:
git commit --author=John Doe
+1 for RTC. For now rules to become a committer are pretty soft, CI and
JIRA processes are still changing, etc. I believe without additional
control quality of our product will deteriorate in such environment.
Let's graduate first, establish development processes, define requirements
to become a
+1
On Thu, Jul 9, 2015 at 11:39 AM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
I would like to start a vote on graduating Apache Ignite to TLP.
Status page: http://incubator.apache.org/projects/ignite.html
Incubator graduation discussion:
http://s.apache.org/thoughts-on-graduation
:00 Vladimir Ozerov voze...@gridgain.com:
Igniters,
Ignite allows external parties to add plugins. Currently plugins are
started at the very end of start process, and they are stopped before
all
other components.
This is a problem because sometimes we need to stop plugin AFTER
Vladimir Ozerov created IGNITE-1108:
---
Summary: Additional lifecycle callbacks in PluginProvider
interface.
Key: IGNITE-1108
URL: https://issues.apache.org/jira/browse/IGNITE-1108
Project: Ignite
of this. I suspect
original exception may be in the cause of the one thrown outside.
--
Yakov Zhdanov, Director RD
*GridGain Systems*
www.gridgain.com
2015-07-06 18:05 GMT+03:00 Vladimir Ozerov voze...@gridgain.com:
Igniters,
I noticed that IgniteFuture.chain() could loose exceptions. I
Igniters,
Ignite allows external parties to add plugins. Currently plugins are
started at the very end of start process, and they are stopped before all
other components.
This is a problem because sometimes we need to stop plugin AFTER all other
components. not BEFORE. E.g. consider a plugin
Vladimir Ozerov created IGNITE-1097:
---
Summary: IgniteFuture.chain() unwraps exceptions incorrectly.
Key: IGNITE-1097
URL: https://issues.apache.org/jira/browse/IGNITE-1097
Project: Ignite
Igniters,
I noted strange behavior of IgniteCache.invoke() in async mode. If
exception is thrown from entry processor, sometimes it lands in future as
expected, but sometimes it is thrown right-away as if it was a synchronous
call. Behavior depends on topology and may be key affinity. Test case
, Jul 6, 2015 at 8:43 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Igniters,
I noted strange behavior of IgniteCache.invoke() in async mode. If
exception is thrown from entry processor, sometimes it lands in future as
expected, but sometimes it is thrown right-away
Igniters,
I noticed that IgniteFuture.chain() could loose exceptions. I created the
ticket https://issues.apache.org/jira/browse/IGNITE-1097 with example of
lost EntryProcessorException.
It appears that the problem is caused by some very sophisticated magic we
do with exceptions when calling
Igniters,
Can someone explain me how write-behind store should behave in case of node
stop when some changes has not been flushed to the underlying store yet?
Are we guarantee that all pending changes will be flushed to the underlying
store?
Vladimir.
is a cache delegate needed? Just trying to
understand context here please.
On Wed, Jul 1, 2015 at 1:50 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Atri,
Currently if user start data streaming on a client for already started
cache it doesn't yield in internal cache delegate creation
(mitigating this concern to a
point).
On Wed, Jul 1, 2015 at 2:02 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
For client node it is necessary to perform regular cache operations.
However, data streamer uses completely different logic to perform cache
updates and does not require
Yes.
On Wed, Jul 1, 2015 at 11:46 AM, Atri Sharma atri.j...@gmail.com wrote:
Hrm, got that.
So conclusion is to not go ahead with this feature?
On Wed, Jul 1, 2015 at 2:14 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Atri,
If user require first create cache and the start
is fine with this (low number of caches) but may
need functionality to automate cache creation when streaming.
I feel that we should implement this and document memory implications of
this so it can be used for needed use cases.
Thoughts?
On Wed, Jul 1, 2015 at 12:27 PM, Vladimir Ozerov
Atri,
These are old tickets migrated from our internal JIRA during open-sourcing
process. I do not know the context well.
Yakov,
Can you advise whether these tickets are still relevant?
On Wed, Jul 1, 2015 at 11:54 AM, Atri Sharma atri.j...@gmail.com wrote:
Vladimir, I believe you created the
:
Hi,
I have uploaded patch for this.
I am not sure about internal flow hence might be missing some part.
Please
advice if same.
Please see and let me know your comments and feedback.
Regards,
Atri
On Tue, Jun 30, 2015 at 3:18 PM, Vladimir Ozerov voze...@gridgain.com
identify performance issues
later on.
If you are fine I can make ticket and assign it to myself.
On Tue, Jun 30, 2015 at 12:01 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Igniters,
Consider the following use case.
1) User configured cache template, but has never accessed
Igniters,
Consider the following use case.
1) User configured cache template, but has never accessed it explicitly yet;
2) User calls Ignite.dataStreamer([cacheName]) - exception is thrown
because cache is not started.
I have a feeling that data streamer must have getOrCreateCache semantics
so
U.convertException(e).
Vladimir.
On Tue, Jun 30, 2015 at 12:29 PM, Atri Sharma atri.j...@gmail.com wrote:
Vladimir,
Is this problem specific to all checks of isAsync() calls?
On Mon, Jun 29, 2015 at 6:29 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Atri,
Currently allmost all exceptions
solutino is required here.
Vladimir.
On Mon, Jun 29, 2015 at 3:45 PM, Atri Sharma atri.j...@gmail.com wrote:
I have taken the patch.
Please advice on how to implement this. I will get the patch out today
since its critical.
On Mon, Jun 29, 2015 at 6:05 PM, Vladimir Ozerov voze
Vladimir Ozerov created IGNITE-1059:
---
Summary: putAll() throws IgniteException instead of
CachePartialUpdateException in ascyn mode when partial update occurs.
Key: IGNITE-1059
URL: https://issues.apache.org
Igniters,
I noted that in async mode we throw IgniteException in case of partial
update, while CachePartialUpdateException is expected here accoring to our
contract.
This appears to be pretty critical as user cannot get failed keys when
working in async mode. I created a ticket for that:
+1 for Semen point.
Is it really popular scenario when user does not have classes on server?
Looks like a corner case for me.
On Fri, Jun 26, 2015 at 11:40 AM, Semyon Boikov sboi...@gridgain.com
wrote:
Ok, in this case we need to design this wrapper API, also this should be
somehow
Vladimir Ozerov created IGNITE-1058:
---
Summary: GridIoPolicy: Switch from enum to collection of byte
constants.
Key: IGNITE-1058
URL: https://issues.apache.org/jira/browse/IGNITE-1058
Project
I created a ticket: IGNITE-1058.
On Fri, Jun 26, 2015 at 3:50 PM, Yakov Zhdanov yzhda...@apache.org wrote:
+1 You definitely should file a ticket.
--Yakov
2015-06-26 13:05 GMT+03:00 Vladimir Ozerov voze...@gridgain.com:
Igniters,
Currently we have enum GridIoPolicy which defines
Vladimir Ozerov created IGNITE-1012:
---
Summary: Not all entries are returned by scan query in case of
concurrent partition exchange.
Key: IGNITE-1012
URL: https://issues.apache.org/jira/browse/IGNITE-1012
,
is that it doesn't support sustaining releases in a transparent way,
where's
the one above (or similarly offered by Artiom) does.
Cos
On Wed, Jun 03, 2015 at 01:51PM, Vladimir Ozerov wrote:
This approach doesn't work well when there are several development
branches. E.g. someone
? IMO it's not easy to build robust
applications with JNI but not sure that's a concern for us given that this
is all in user space. ..
On 4 Jun 2015 19:16, Vladimir Ozerov voze...@gridgain.com wrote:
Igniters,
Lots of our features rely on callbacks from Ignite to user code
Igniters,
Lots of our features rely on callbacks from Ignite to user code. This is
essential for task execution, cache invokes, cache store, continuous
queries, messaging, etc..
Ideally from user perspective target class should look somewhat like this:
class MyListener : public IListenerMyKey*,
This approach doesn't work well when there are several development
branches. E.g. someone is working on tickets for current release, someone
else is working on features for the next release. Current approach with
sprint branches handles this situation.
Another problem is that version is subject to
, Vladimir Ozerov wrote:
Igniters,
In Java our API extensively use exceptions to signal faulty
conditions. The
same technique must be applied somehow to C++ API as well.
The most obvious solution for our Java minds is to simply throw
exceptions
in C++ as well. But this solution doesn't
Vladimir Ozerov created IGNITE-978:
--
Summary: Create timeout of IgniteCache.get()
Key: IGNITE-978
URL: https://issues.apache.org/jira/browse/IGNITE-978
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-979:
--
Summary: Revisit timeout logic in Ignite.
Key: IGNITE-979
URL: https://issues.apache.org/jira/browse/IGNITE-979
Project: Ignite
Issue Type: Task
Igniters,
In Java our API extensively use exceptions to signal faulty conditions. The
same technique must be applied somehow to C++ API as well.
The most obvious solution for our Java minds is to simply throw exceptions
in C++ as well. But this solution doesn't seem to be valid for C++ world:
1)
can think of a more portable library (Boost?)
On Mon, Jun 1, 2015 at 1:28 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
Igniters,
There is widespread opinion that STL types should not be used in public
(exported) APIs to maximize portability. It means that even such simple
types like
Igniters,
There is widespread opinion that STL types should not be used in public
(exported) APIs to maximize portability. It means that even such simple
types like std::string or std:vector shouldn't appear in any public
definitions.
Pros:
Better portability = less problems when Ignite library
It denotes a store which is local to node. I.e. there is no single point of
through and different nodes can have different values of the same key saved
on store.
In this case to maintain data integrity Ignite will store not only values,
but versions as well. Later on these versions are compared to
Code generation in any from (either compiile-time or runtime) is nice idea
and we certainly should pay attention to it. But it appears to be too
complicated for initial release.
I would stick to explicit serializers for now.
On Wed, May 27, 2015 at 9:28 AM, Denis Magda dma...@gridgain.com wrote:
Igniters,
C++ doesn't have reflection/introspection. For this reason we have to map
user structs/classes to their marshal/unmarshal handlers (functions)
somehow.
Various approaches for this are available:
1) Predefined map [type ID - marshal/unmarshal functions] which is
configured at runtime
NVIDIA:
http://on-demand.gputechconf.com/gtc/2012/presentations/S0377-C++-Data-Marshalling-Best-Practices.pdf
The slides are quite high level but probably they will expose a solution
to p.2.
--
Denis
On 5/26/2015 12:09 PM, Vladimir Ozerov wrote:
Igniters,
C++ doesn't have reflection
On 26.05.2015 22:12, Vladimir Ozerov wrote:
SFINAE could be a way to perform compile-time introspection:
http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error
On Tue, May 26, 2015 at 5:40 PM, Denis Magda dma...@gridgain.com
wrote:
Yeap, it's not so easy to marshall/unmarshall
Koert,
IGFS stores data in-memory. When using IGFS in pure in-memory mode, no
failover exists and data can be lost in case one of data nodes leaves the
grid.
When secondary file system is used (e.g. HDFS), then Ignite is able to
transparently re-read lost data chunks from the underlying file
+1.
On Mon, May 25, 2015 at 6:20 PM, Yakov Zhdanov yzhda...@apache.org wrote:
Guys,
We are currently finishing working on IGNITE-709 - which will bring client
discovery to Ignite. This mode will allow clients to connect and use the
cluster without taking place in nodes ring and therefore
cache. However, this makes
sense in the most common use case - IGFS as a caching layer over some
perstent file system.
On Mon, May 25, 2015 at 7:07 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On Mon, May 25, 2015 at 7:18 AM, Vladimir Ozerov voze...@gridgain.com
wrote:
Koert,
IGFS
vozerov
On Thu, May 21, 2015 at 10:08 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
vkulichenko
On Thu, May 21, 2015 at 12:07 PM, Artiom Shutak ashu...@gridgain.com
wrote:
Hi, Igniters,
Respond to this email with your jira username.
I will add your username to
Igniters,
In upcoming interop efforts we will need concurrent collections and
primitives in C++ layer. Obvious candidate is Boost, but it appears to be
too heavy. Another library I found is Intel's TBB (
https://www.threadingbuildingblocks.org/) - it is open-source and pretty
light.
Does anyone
Igniters,
We need to decide which C++ version to use in interop. Currently wide
developer community is in progress of adopting C++11. But if we choose it,
users might have problems if their CPP projects using older C++ revisions
which are still very common.
I think we should stick to C++03
:27 PM, Branko Čibej br...@apache.org wrote:
On 20.05.2015 09:40, Vladimir Ozerov wrote:
This is not about resulting size of our lib. Moreover, we will not
statically link it to Ignite because in this case users will have
troubles
when using both Boost and Ignite simultaneously
Brane,
Thanks for clarifications, I mistakenly thought that smart pointers were
introduced only in C++11. If they are already in C++03 of course we should
take advantage of them.
On Wed, May 20, 2015 at 12:08 PM, Branko Čibej br...@apache.org wrote:
On 20.05.2015 09:47, Vladimir Ozerov wrote
:
On Wed, May 20, 2015 at 12:01 AM, Vladimir Ozerov voze...@gridgain.com
wrote:
C++11 users can use C++03 projects, but not vice-versa.
Are we sacrificing any features? (sorry, my C++ knowledge is limited).
On Wed, May 20, 2015 at 9:52 AM, Dmitriy Setrakyan
dsetrak...@apache.org
wrote
Vladimir Ozerov created IGNITE-904:
--
Summary: Define entry point for interop startup.
Key: IGNITE-904
URL: https://issues.apache.org/jira/browse/IGNITE-904
Project: Ignite
Issue Type: Task
Hi,
Note that I'll created new component in JIRA - interop. Please make sure
to set it for any interop-related tickets.
Vladimir.
Vladimir Ozerov created IGNITE-908:
--
Summary: Introduce interop handle.
Key: IGNITE-908
URL: https://issues.apache.org/jira/browse/IGNITE-908
Project: Ignite
Issue Type: Task
Vladimir Ozerov created IGNITE-905:
--
Summary: Implement interop processor for early initialization.
Key: IGNITE-905
URL: https://issues.apache.org/jira/browse/IGNITE-905
Project: Ignite
Vladimir Ozerov created IGNITE-906:
--
Summary: Implement memory manager for interop communication.
Key: IGNITE-906
URL: https://issues.apache.org/jira/browse/IGNITE-906
Project: Ignite
Issue
:
Prashant, we are trying to achieve API parity. Of course, some limitations
will take place, but cache operations + queries will be supported.
Vladimir Ozerov, can you please reply to this thread with issue number, so
everyone can get updates on the progress?
--Yakov
2015-05-08 12:01 GMT
+1, looks good to me.
On Fri, May 8, 2015 at 5:26 PM, Yakov Zhdanov yzhda...@apache.org wrote:
Guys,
We have uploaded release candidate to
https://dist.apache.org/repos/dist/dev/incubator/ignite/1.1.0-rc3/
Tag name is
ignite-1.1.0-incubating-rc3
We fixed rat issues and added -incubating
Hi,
If the same message listener is registered twice for the same topic, it
will be notified twice when message arrives.
For events things are different. If user register listener twice, it will
be invoked only once when event occurrs.
Looks inconsistent and counterintuitive. Looks like we have
...@gridgain.com
wrote:
I also think that messaging is correct and events is not.
If you subscribe n times, you should unsubscribe n times.
On Thu, May 7, 2015 at 4:12 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On Thu, May 7, 2015 at 4:18 AM, Vladimir Ozerov voze
should have a PythonTask which will have
enough information to execute an appropriate Python program out of process.
D.
On Tue, May 5, 2015 at 1:23 AM, Vladimir Ozerov voze...@gridgain.com
wrote:
Dima,
The most complex part of task execution is master-node side. We assume
that
user
Alexey,
By default data streamer use optimized path and does not perform ordinary
puts and removes. I believe you will see metrics updates if you set
IgniteDataStreamer.allowOverwrite() to true.
On Wed, Apr 29, 2015 at 1:24 PM, Alexey Kuznetsov akuznet...@gridgain.com
wrote:
Just found that if
Vladimir Ozerov created IGNITE-834:
--
Summary: IgniteCache.clearAll() throws NPE.
Key: IGNITE-834
URL: https://issues.apache.org/jira/browse/IGNITE-834
Project: Ignite
Issue Type: Bug
Vladimir Ozerov created IGNITE-835:
--
Summary: IgniteCache.lock is broken for PARTITIONED cache without
near cache.
Key: IGNITE-835
URL: https://issues.apache.org/jira/browse/IGNITE-835
Project
Vladimir Ozerov created IGNITE-744:
--
Summary: removeAll() doesn't remove swapped entries for LOCAL
cache.
Key: IGNITE-744
URL: https://issues.apache.org/jira/browse/IGNITE-744
Project: Ignite
Vladimir Ozerov created IGNITE-700:
--
Summary: Do not write metrics for system transactions.
Key: IGNITE-700
URL: https://issues.apache.org/jira/browse/IGNITE-700
Project: Ignite
Issue Type
I worked on Hadoop docs, and accidently missed this.
Will add relevant docs on Monday after some consulting with Ivan.
04 апр. 2015 г. 10:54 пользователь Dmitriy Setrakyan
dsetrak...@apache.org написал:
Just noticed that this documentation is missing:
Hi,
We removed Grid prefix from all public API in Ignite. However, we still
have odd namings in internal classes which can be used by plugin
developers. E.g.:
DR:
GridCacheDrManager - DR manager interaface;
GridOsCacheDrManager - Ignite implementation of DR manager;
Cache objects:
-1 for automatic plugin detection. My concerns:
a) Different plugins might provide overlapping features and it is necessary
to decide which service will be provided by which provider.
b) Plugins participate in node lifecycle and relative start/stop order
might be important as well. E.g. when there
implementation wins.
We can have a kind of map from feature to plugin, i.e. I can set
explicitly that DR is to be taken from plugin B.
On Fri, Apr 3, 2015 at 8:18 PM, Vladimir Ozerov voze...@gridgain.com
wrote:
-1 for automatic plugin detection. My concerns:
a) Different plugins might provide overlapping
Alex,
Could you please look at the following ticket:
http://atlassian.gridgain.com/jira/browse/GG-10035
I see a hang when DR receiver tries to start a cache dynamically. All
instructions and results of my debug are inside the ticket.
Vladimir.
Vladimir Ozerov created IGNITE-672:
--
Summary: Add Hadoop edition build instructions to DEVNOTES.
Key: IGNITE-672
URL: https://issues.apache.org/jira/browse/IGNITE-672
Project: Ignite
Issue
Vladimir Ozerov created IGNITE-665:
--
Summary: Integrate Ignite with BigTop.
Key: IGNITE-665
URL: https://issues.apache.org/jira/browse/IGNITE-665
Project: Ignite
Issue Type: Task
+1, appears to be fine.
On Mon, Mar 30, 2015 at 9:41 AM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Looks good.
+1 from me
On Sat, Mar 28, 2015 at 6:40 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
(restarting a new vote for 1.0.0 after fixing the default build not
Vladimir Ozerov created IGNITE-625:
--
Summary: Race condition in IgfsFileWorker.
Key: IGNITE-625
URL: https://issues.apache.org/jira/browse/IGNITE-625
Project: Ignite
Issue Type: Bug
Vladimir Ozerov created IGNITE-576:
--
Summary: Merge ignite-core and ignite-hadoop in Hadoop Edition
build.
Key: IGNITE-576
URL: https://issues.apache.org/jira/browse/IGNITE-576
Project: Ignite
Vladimir Ozerov created IGNITE-521:
--
Summary: Exception is not thrown on bear node when TX is failed on
primary node.
Key: IGNITE-521
URL: https://issues.apache.org/jira/browse/IGNITE-521
Project
+ 1 for following future contract.
If we have own contract, then why do we extends Future? This only confiuses
users. If he cast our future to Future, then he will expect checked
exceptions and will use try-catch blocks, which will never fire because we
breakes Future semantics.
Furthermore,
Vladimir Ozerov created IGNITE-523:
--
Summary: Cache operation is stuck when an exception is thrown from
continuous query filter.
Key: IGNITE-523
URL: https://issues.apache.org/jira/browse/IGNITE-523
Vladimir Ozerov created IGNITE-512:
--
Summary: IgniteCache.randomEntry() is implemented incorrectly.
Key: IGNITE-512
URL: https://issues.apache.org/jira/browse/IGNITE-512
Project: Ignite
HI,
I'm looking at our continuous queries API and looks pretty weird for me.
Earlier we operated on stateful ContinuousQuery object with clear
lifecycle: we can start it and we can close it.
Now we operate on cursor which is either empty or contains results from
initial query. And when we close
Hi,
Consider the following use case. There are two plugins. One with features
(A1, B1, C1), and another with features (B2, C2, D2). If user want to use
both these plugins and pick features (A1, B1, C2, D2), he will not be able
to do so. The only valid feature sets will be either (A1, B1, C1, D2)
[
https://issues.apache.org/jira/browse/IGNITE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-465:
--
Assignee: Vladimir Ozerov
Abstract out IGFS endpoint configuration to a separate
[
https://issues.apache.org/jira/browse/IGNITE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-465:
---
Fix Version/s: (was: sprint-3)
sprint-2
Abstract out IGFS endpoint
[
https://issues.apache.org/jira/browse/IGNITE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-465.
--
Abstract out IGFS endpoint configuration to a separate class
[
https://issues.apache.org/jira/browse/IGNITE-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-465.
Resolution: Fixed
Abstract out IGFS endpoint configuration to a separate class
1 - 100 of 271 matches
Mail list logo
