Valentin Kulichenko created IGNITE-1262:
---
Summary: CacheJdbcPojoStoreFactory issues
Key: IGNITE-1262
URL: https://issues.apache.org/jira/browse/IGNITE-1262
Project: Ignite
Issue Type
is in the factory so user can fully configure it.
3. really strange thing with h2 dialect. can you make it serializable?
Thanks!
--Yakov
2015-08-15 3:40 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com
:
Igniters,
I'm looking at CacheJdbcPojoStoreFactory and have a couple of questions
Valentin Kulichenko created IGNITE-1267:
---
Summary: JobStealingCollisionSpi never sends jobs to a node that
joined after task was executed
Key: IGNITE-1267
URL: https://issues.apache.org/jira/browse/IGNITE
is flushed messages will be
correctly ordered and thread-per-partition mode is not needed.
Do you see any problems with this approach, does it worth to try this?
Thanks
On Thu, Jul 23, 2015 at 8:53 AM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Igniters
I think we should just throw an exception in this case. Providing two
configurations for one cache looks like incorrect usage for me.
-Val
On Thu, Aug 13, 2015 at 11:43 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On Thu, Aug 13, 2015 at 5:56 PM, Alexey Goncharuk
Artem,
Why do we need a requirement about one commit per pull request? I
understand that we should should avoid garbage in history and properly deal
with merges from master. But I don't see anything wrong with 2-3 commits in
a PR if they are meaningful. E.g., implemented initial version - fixed
And a minor question.
On TC in branches dropdown I see 'pull/xx/head' and 'pull/xx/merge'. What
is the difference?
-Val
On Fri, Aug 14, 2015 at 3:23 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Artem,
Why do we need a requirement about one commit per pull request? I
Guys,
I updated the section about pull requests on Wiki. Please take a look and
provide your comments if you have any.
-Val
On Fri, Aug 14, 2015 at 3:46 PM, Raul Kripalani r...@evosent.com wrote:
On 14 Aug 2015 23:41, Valentin Kulichenko valentin.kuliche...@gmail.com
wrote:
Agree
Agree. Actually, it's up to a committer, I think. I just don't see a reason
to have one-commit-per-pull-request requirement. From my understanding,
this is not how pull requests work.
BTW, I just tested the process and it works like a charm. I like it! And
I'm about to merge your contributions,
Valentin Kulichenko created IGNITE-1248:
---
Summary: Add a method to retrieve Spring application context
Key: IGNITE-1248
URL: https://issues.apache.org/jira/browse/IGNITE-1248
Project: Ignite
Valentin Kulichenko created IGNITE-1244:
---
Summary: Need to expose offheap memory size allocated for indexes
to cache metrics
Key: IGNITE-1244
URL: https://issues.apache.org/jira/browse/IGNITE-1244
Igniters,
Today I fixed couple of tickets and attached patches to them, but TC
doesn't seem to trigger builds. Does it work for someone else?
Artem, since you were working on this, can you take a look at my tickets
and check if I'm doing everything correctly?
Here are the tickets:
:)
On August 11, 2015 11:32:04 PM PDT, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Igniters,
Today I fixed couple of tickets and attached patches to them, but TC
doesn't seem to trigger builds. Does it work for someone else?
Artem, since you were working on this, can you take a look
Valentin Kulichenko created IGNITE-1238:
---
Summary: Joining node should be discarded in case discovery
exchange data can't be deserialized
Key: IGNITE-1238
URL: https://issues.apache.org/jira/browse/IGNITE
Valentin Kulichenko created IGNITE-1226:
---
Summary: Need to add method that returns names of all available
caches
Key: IGNITE-1226
URL: https://issues.apache.org/jira/browse/IGNITE-1226
Project
Valentin Kulichenko created IGNITE-1227:
---
Summary: Need to implement Ignite-based Spring transaction manager
Key: IGNITE-1227
URL: https://issues.apache.org/jira/browse/IGNITE-1227
Project
Igniters,
Current version of JDBC driver is still based on legacy thin client and I
think it's wrong. First of all, the thin client as deprecated long time ago
and is not really supported. Second of all, it's much slower than native
query API, which makes the driver useless in most cases.
I
Mike,
You can just sign up with your email.
-Val
On Wed, Aug 5, 2015 at 10:45 AM, Mike Dickson mikedick...@yahoo.com.invalid
wrote:
What is our login? How do we get one?
On Wednesday, August 5, 2015 10:35 AM, Dmitriy Setrakyan
dsetrak...@apache.org wrote:
On Wed, Aug 5, 2015
on factories. This will also ensure that all the notifications are provided
by a listener instead of some initial query, as users have been asking.
I have updated the IGNITE-1186 ticket.
--Yakov
2015-07-31 22:29 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com:
Igniters
Valentin Kulichenko created IGNITE-1192:
---
Summary: Provide integration with Spring Data
Key: IGNITE-1192
URL: https://issues.apache.org/jira/browse/IGNITE-1192
Project: Ignite
Issue
Igniters,
It was brought to my attention that we always send the filter instance when
creating a continuous query. This is not correct if JCache entry listener
API is used, because it works with factories and assumes that filter is not
even Serializable, but we require it.
I think this can be
Valentin Kulichenko created IGNITE-1186:
---
Summary: Filter is sent instead of factory when continuous query
is created
Key: IGNITE-1186
URL: https://issues.apache.org/jira/browse/IGNITE-1186
On Fri, Jul 31, 2015 at 12:30 AM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On Fri, Jul 31, 2015 at 12:06 AM, Sergi Vladykin sergi.vlady...@gmail.com
wrote:
Guys,
We had a problem with thread starvation in PUBLIC pool because of queries
as described in
On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda dma...@gridgain.com wrote:
Igniters,
I've been working on the task that will let the user to retrieve version
related information for a particular Cache.Entry
I tend to agree on points brought by Brane and Cos. Having a formality that
review is always required regardless of what the change actually implies
looks like an overkill.
At the same time, I usually feel uncomfortable without a review. Ignite is
not just a complicated project. It has a lot of
, 2015 at 5:43 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
On Mon, Jul 27, 2015 at 12:32 PM, Alexey Goncharuk
alexey.goncha...@gmail.com wrote:
I like the idea, however I do not like the API.
Why do we need to limit deployment process to a list of files or GIT
+1 for the feature. Looks like really good usability enhancement.
-Val
On Sun, Jul 26, 2015 at 10:31 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
Igniters,
So far Ignite deployment process left it up to a user to deploy all the
libraries on all the nodes manually, before a node can
acked message and that's the way how backups can safely
evict
from the queue.
Let me know if you have questions.
--Yakov
2015-07-23 8:53 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com
:
Igniters,
Based on discussions
if you have questions.
--Yakov
2015-07-23 8:53 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com
:
Igniters,
Based on discussions with our users I came to conclusion that
our
continuous query implementation is not good
safely
evict
from the queue.
Let me know if you have questions.
--Yakov
2015-07-23 8:53 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com
:
Igniters
invocations made on that particular Ignite instance.
I think ability to redeploy (and therefore undeploy) is a must here.
Otherwise you will need to restart the cluster each time you have changes.
This makes the feature useless.
--AG
2015-07-27 11:49 GMT-07:00 Valentin Kulichenko
questions.
--Yakov
2015-07-23 8:53 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com
:
Igniters,
Based on discussions with our users I came to conclusion that our
continuous query implementation is not good enough for use cases with
strong consistency
Folks,
It looks like we have a bug in exception handling logic in cache. I didn't
have a chance to make testing myself yet, but I heard several complaints
from users about ClusterTopologyException thrown directly from cache
operations.
Here is the ticket:
Valentin Kulichenko created IGNITE-1151:
---
Summary: Cache operations can throw ClusterTopologyException
without wrapping it into CacheException
Key: IGNITE-1151
URL: https://issues.apache.org/jira/browse
Valentin Kulichenko created IGNITE-1144:
---
Summary: Need to have a capability to run a closure collocated
with a queue/set
Key: IGNITE-1144
URL: https://issues.apache.org/jira/browse/IGNITE-1144
Igniters,
Based on discussions with our users I came to conclusion that our
continuous query implementation is not good enough for use cases with
strong consistency requirements, because there is a possibility to lose
updates in case of topology change.
So I started working on
, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Igniters,
Today I noticed that we don't have any documentation for our
implementation
of Spring Cache Abstraction, so I added this page:
http://apacheignite.gridgain.org/v1.2/docs/spring-caching
Feel free to comment!
-Val
Done.
On Wed, Jul 15, 2015 at 11:26 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
On Wed, Jul 15, 2015 at 11:23 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Yes, we need to. Is there a way to do this automatically? I can't find
anything like this..
Unfortunately
:
What do you mean by proper format?
--Yakov
2015-07-16 6:03 GMT+03:00 Valentin Kulichenko
valentin.kuliche...@gmail.com
:
Guys,
It seems to me that code samples in our JavaDoc is not formatted
properly.
See this page for example:
https
Igniters,
Today I noticed that we don't have any documentation for our implementation
of Spring Cache Abstraction, so I added this page:
http://apacheignite.gridgain.org/v1.2/docs/spring-caching
Feel free to comment!
-Val
+1
On Jul 9, 2015 4:40 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
Since joining
Valentin Kulichenko created IGNITE-1071:
---
Summary: IgniteCache.metrics() method returns local metrics
Key: IGNITE-1071
URL: https://issues.apache.org/jira/browse/IGNITE-1071
Project: Ignite
Valentin Kulichenko created IGNITE-1074:
---
Summary: SQL query requires to have all participating client caches
Key: IGNITE-1074
URL: https://issues.apache.org/jira/browse/IGNITE-1074
Project
Valentin Kulichenko created IGNITE-1075:
---
Summary: IgniteDataStreamer doesn't throw an exception if there
are no data nodes
Key: IGNITE-1075
URL: https://issues.apache.org/jira/browse/IGNITE-1075
Valentin Kulichenko created IGNITE-1072:
---
Summary: Need to automatically support LocalDateTime class in
indexing
Key: IGNITE-1072
URL: https://issues.apache.org/jira/browse/IGNITE-1072
Project
Valentin Kulichenko created IGNITE-1073:
---
Summary: Need to add skipOldValue flag to continuous queries
Key: IGNITE-1073
URL: https://issues.apache.org/jira/browse/IGNITE-1073
Project: Ignite
Valentin Kulichenko created IGNITE-1076:
---
Summary: classnames-jdk.properties missing java.sql classes
Key: IGNITE-1076
URL: https://issues.apache.org/jira/browse/IGNITE-1076
Project: Ignite
Valentin Kulichenko created IGNITE-1039:
---
Summary: Need to inspect nested objects for indexing automatically
Key: IGNITE-1039
URL: https://issues.apache.org/jira/browse/IGNITE-1039
Project
Valentin Kulichenko created IGNITE-1040:
---
Summary: NPE if indexing fails with exception
Key: IGNITE-1040
URL: https://issues.apache.org/jira/browse/IGNITE-1040
Project: Ignite
Issue
+1
On Thu, Jun 18, 2015 at 10:50 AM, Alexey Goncharuk
alexey.goncha...@gmail.com wrote:
+1
2015-06-18 7:20 GMT-07:00 Branko Čibej br...@apache.org:
On 17.06.2015 00:02, Yakov Zhdanov wrote:
Guys,
We have uploaded release candidate to
Valentin Kulichenko created IGNITE-1025:
---
Summary: Need to print out warning if IP finder has a lot of
addresses on Windows
Key: IGNITE-1025
URL: https://issues.apache.org/jira/browse/IGNITE-1025
Valentin Kulichenko created IGNITE-1017:
---
Summary: ClusterGroup.forAttribute() accepts only String value
Key: IGNITE-1017
URL: https://issues.apache.org/jira/browse/IGNITE-1017
Project: Ignite
Valentin Kulichenko created IGNITE-1016:
---
Summary: Add excludeNeighbors and backupFilter to
FairAffinityFunction
Key: IGNITE-1016
URL: https://issues.apache.org/jira/browse/IGNITE-1016
Project
Valentin Kulichenko created IGNITE-1018:
---
Summary: Node local map is not available when
LifecycleEventType.BEFORE_NODE_START is processed in lifecycle bean
Key: IGNITE-1018
URL: https://issues.apache.org
rules to it) can be one of them - when the vote is
closed, decision is made. Are there other options?
-Val
On Jun 11, 2015 12:03 AM, Branko Čibej br...@apache.org wrote:
On 11.06.2015 01:47, Valentin Kulichenko wrote:
Hmm. I'm not sure I understand. As far as I understand, any vote here
Hmm. I'm not sure I understand. As far as I understand, any vote here
is unanimous, but not majority. I.e., if anyone in community has
objections, vote is declined (already not a democracy, right? :) ). If so,
I really don't see any difference between consensus is recorded by no
objections
being
Valentin Kulichenko created IGNITE-1003:
---
Summary: Communication issues when running client node in separate
subnetwork
Key: IGNITE-1003
URL: https://issues.apache.org/jira/browse/IGNITE-1003
Valentin Kulichenko created IGNITE-995:
--
Summary: Nodes on one host doesn't discover each other if IP
finder doesn't explicitly provide port
Key: IGNITE-995
URL: https://issues.apache.org/jira/browse/IGNITE
Valentin Kulichenko created IGNITE-953:
--
Summary: GridCacheContext.readResolve() fails with NPE if client
cache on receiver does not exist yet
Key: IGNITE-953
URL: https://issues.apache.org/jira/browse
Valentin Kulichenko created IGNITE-954:
--
Summary: Continuous queries are deployed on client nodes
Key: IGNITE-954
URL: https://issues.apache.org/jira/browse/IGNITE-954
Project: Ignite
Valentin Kulichenko created IGNITE-955:
--
Summary: Local listener in continuous queries should not be
mandatory
Key: IGNITE-955
URL: https://issues.apache.org/jira/browse/IGNITE-955
Project
Valentin Kulichenko created IGNITE-946:
--
Summary: Need to expose versioned cache entry to public API
Key: IGNITE-946
URL: https://issues.apache.org/jira/browse/IGNITE-946
Project: Ignite
Guys,
I was communicating with one of our users and he faced this issue. I think
we should fix it, so I created a ticket:
https://issues.apache.org/jira/browse/IGNITE-941
Feel free to comment on design.
--
Val
On Wed, May 20, 2015 at 10:40 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com
Valentin Kulichenko created IGNITE-941:
--
Summary: Need to read-only mode in transactional cache
Key: IGNITE-941
URL: https://issues.apache.org/jira/browse/IGNITE-941
Project: Ignite
Valentin Kulichenko created IGNITE-940:
--
Summary: Need to expose SQL metadata to public API
Key: IGNITE-940
URL: https://issues.apache.org/jira/browse/IGNITE-940
Project: Ignite
Issue
Igniters (especially Sergi),
What happens if I use Java primitives like Doubles as values? Are they
indexed? I just created a simple example which loads some data and executes
this query: 'select max(_val) from Double'. Indexes are not created and the
speed of the query is the same as the speed
Igniters,
Current implementation of clear() method doesn't clear entries if there are
near readers for them. This makes this method ultimately unusable if near
cache is configured (behavior is unpredictable and counterintuitive).
At the same time, the purpose of the method is to invalidate the
Igniters,
As we all know, transactional cache updates persistence store from a client
node, while loads are still done on primary node. But it's not always
possible to have a database connection on client. There is a workaround -
send a closure to server node and start a transaction there. You
+1, looks good
On Tue, May 12, 2015 at 10:55 AM, 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-rc5/
Tag name is
ignite-1.1.0-incubating-rc5
We fixed Ignite startup when built from
User list works for me.
Ognen, I received your message as well.
--
Val
On Tue, May 12, 2015 at 10:31 AM, Yakov Zhdanov yzhda...@apache.org wrote:
I believe I have subscribed successfully as well. At least I have received
confirmations.
--Yakov
2015-05-12 16:26 GMT+03:00 Dmitriy Setrakyan
Valentin Kulichenko created IGNITE-896:
--
Summary: Configuration inconsistency
Key: IGNITE-896
URL: https://issues.apache.org/jira/browse/IGNITE-896
Project: Ignite
Issue Type: Bug
I already created a ticket anyway (can cloase it if we decide not to fix):
https://issues.apache.org/jira/browse/IGNITE-896
There is one more issue here: we require cache configuration to be
serializable for dynamic cache support. So if eviction policy, for example,
depends on some
, there is a usability issue there. It would be great if
you could file a ticket and propose a design for it.
D
On Thu, May 7, 2015 at 8:36 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Igniters,
I was playing with the cache store in a Spring project and found a couple
of usability
Guys,
I noticed that some entities on cache configuration are configured via
factories, while others are set directly. For example, we use factory for
ExpiryPolicy, but not for EvictionPolicy, which looks inconsistent. Since
factory-based approach comes from JCache, I think we should use it
+1
./ignite.sh successfully started the node. Cos, you probably have incorrect
IGNITE_HOME in environment.
Git error is OK, build procedure tries to get values from Git, fails to do
that, but doesn't stop and use default values (at least this is how it
works for me).
On Fri, May 8, 2015 at 5:51
Hmm. How they can be different if they use the same mechanisms of
continuous processor, simply delegating to it? :)
Anyway, my opinion is the same - several subscriptions should mean several
notifications.
--
Val
On Thu, May 7, 2015 at 6:53 AM, Pavel Tupitsyn ptupit...@gridgain.com
wrote:
I
listeners, but this
definitely affects local listeners.
On Thu, May 7, 2015 at 10:42 PM, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
Hmm. How they can be different if they use the same mechanisms of
continuous processor, simply delegating to it? :)
Anyway, my opinion
Alexey,
Do you have only one server node? In this case query is considered to be
local and pagination is disabled. Really looks like redundant iteration.
I also noticed that IgniteCacheProxy.query(Query filter, @Nullable
ClusterGroup grp) method on line 347 ignores page size parameter (added a
Igniters,
I was playing with the cache store in a Spring project and found a couple
of usability issues:
1. Setting cache store factory in configuration is not enough to enable
read/write-through, we also require to explicitly enable them via
setReadThrough and setWriteThrough
Guys,
Ticket says only about top-level pom, but how about all our modules (e.g.,
ignite-spring, ignite-logj4, ...)? Should they have -incubating label as
well?
On Fri, May 1, 2015 at 4:55 PM, Konstantin Boudnik c...@apache.org wrote:
Yup, good catch. The tag is missed.
Created
Ognen,
For Ignite node to be functional you need two ports to be opened - one for
discovery and another for communication.
Both TcpDiscoverySpi and TcpCommunicationSpi have two configuration
properties: setLocalPort() and setLocalPortRange(). In both cases Ignite
will use the first available
Valentin Kulichenko created IGNITE-779:
--
Summary: Allow to load configurations from abstract input stream
Key: IGNITE-779
URL: https://issues.apache.org/jira/browse/IGNITE-779
Project: Ignite
Ognen,
You can use continuous queries for that:
https://ignite.incubator.apache.org/releases/1.0.0/javadoc/org/apache/ignite/cache/query/ContinuousQuery.html
On Mon, Apr 20, 2015 at 10:02 AM, Ognen Duzlevski ognen.duzlev...@gmail.com
wrote:
Hello,
I am looking at the
Valentin Kulichenko created IGNITE-766:
--
Summary: Class loader hash should be always appended to MBean name
Key: IGNITE-766
URL: https://issues.apache.org/jira/browse/IGNITE-766
Project: Ignite
Guys,
I created ticket https://issues.apache.org/jira/browse/IGNITE-766 based on
this forum post:
http://apacheignite.readme.io/v1.0/discuss/551db8b0a7e98017009e3e97
Currently we append class loader hash and JVM ID only in pair,
if IGNITE_MBEAN_APPEND_JVM_ID system property is set. But I believe
Valentin Kulichenko created IGNITE-691:
--
Summary: CacheObjectContext always contains default affinity mapper
Key: IGNITE-691
URL: https://issues.apache.org/jira/browse/IGNITE-691
Project: Ignite
Valentin Kulichenko created IGNITE-661:
--
Summary: Need to remove edtFTPj dependency from project
Key: IGNITE-661
URL: https://issues.apache.org/jira/browse/IGNITE-661
Project: Ignite
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 to
include LGPL libs)
I have uploaded the new 1.0.0 release candidate to:
Valentin Kulichenko created IGNITE-651:
--
Summary: Marshaller cache should persist updates to disk
Key: IGNITE-651
URL: https://issues.apache.org/jira/browse/IGNITE-651
Project: Ignite
Igniters,
Note that due to licensing issues all modules that depend on LGPL libraries
were excluded from Maven build by default. Two new profiles were introduced:
- lgpl - enables ignite-hibernate, ignite-geospatial and
ignite-scheduler modules
- examples - enables ignite-examples
I pushed the fix - now LGPL dependencies are excluded by default. I added
commands for both build options to DEVNOTES (Dima, please review the text
and fix if you think it's needed).
--
Val
On Sat, Mar 28, 2015 at 2:31 PM, Dmitriy Setrakyan dsetrak...@apache.org
wrote:
Understood. Valentin,
I think we should modify the build procedure of source package so that
ignite.properties is augmented there as well. This way user will be able to
build binary package from downloaded source zip.
Actually it seems incorrect to ship source package with DEV version of
ignite.properties, because it
, Valentin Kulichenko
valentin.kuliche...@gmail.com wrote:
I made a fix in sprint-2 - binary package can be built without Git now
(revision will be 'n/a').
--
Val
On Thu, Mar 26, 2015 at 2:42 PM, Branko Čibej br...@apache.org wrote:
If the user cannot build a complete release from source
I made a fix in sprint-2 - binary package can be built without Git now
(revision will be 'n/a').
--
Val
On Thu, Mar 26, 2015 at 2:42 PM, Branko Čibej br...@apache.org wrote:
If the user cannot build a complete release from source, then the source
release is not functional. It's as simple as
...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/IGNITE-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Shutak updated IGNITE-585:
Assignee: Yakov Zhdanov (was: Valentin Kulichenko)
[Test] Need to test and fix
Valentin Kulichenko created IGNITE-575:
--
Summary: Renamings: CacheAffinityXXX - AffinityXXX,
CacheEvictionXXX - EvictionXXX
Key: IGNITE-575
URL: https://issues.apache.org/jira/browse/IGNITE-575
Guys,
I think this solution is not very good from usability standpoint. It's a
common practice to have several cache configurations in one file and I
don't like that user will have to create a file per cache.
After offline discussion I implemented different way of doing the same
thing - added
I probably would agree with the point about commit/rollback methods, but
others look useful for me. You're starting a DB transaction and may need to
know details about ongoing cache transaction. E.g., what if you want to
start DB transaction with the same isolation? Meta can also contain some
Valentin Kulichenko created IGNITE-548:
--
Summary: Exceptions when running ServiceExample
Key: IGNITE-548
URL: https://issues.apache.org/jira/browse/IGNITE-548
Project: Ignite
Issue Type
Guys,
I'm running new version of ServiceExample and get several exceptions due to
dynamically started caches.
I created a ticket: https://issues.apache.org/jira/browse/IGNITE-548
Alex G., can you please take a look?
--
Val
1 - 100 of 150 matches
Mail list logo
