On Wed, Jan 13, 2016 at 10:07AM, Dmitriy Setrakyan wrote:
> I have released 1.5 in Jira. Agree, we should be disciplined to do this
> right after release. Is the post-release check list on the Wiki?
Yup, should be documented as a part of the release process.
>
> On Wed, Jan 13, 2016 at 8:05 AM,
On Wed, Jan 13, 2016 at 07:14AM, Dmitriy Setrakyan wrote:
> On Wed, Jan 13, 2016 at 2:46 AM, Yakov Zhdanov wrote:
>
> > Cos and all,
> >
> > I changed column title to "Maintainer". This fits better.
> >
> > Now we need to agree on release manager for 1.6. I think I can do it for
> > 1.6, then we
One other thing to keep in mind, that JSON data is often not-flattened ie
coming with hierarchical structures. In which case, querying it from Ignite
would be a non-trivial if at all possible.
Cos
On Thu, Jan 14, 2016 at 09:09AM, Dmitriy Setrakyan wrote:
> I would consider a case for generating h
Thanks Andrey.
I think option one is a bad UX, cause creating an interpreter isn't
a) a simple button click (might be improved later on by Z. folks)
b) what if I have 25 different caches and the equal number of interpreters
and need to make a change to all of them?
The second option sound
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
I also hardly believe that such change can give us such big immediate
performance benefit. Profiling shows that in our standard benchmarks
futures doesn't generate so much garbage to get ~5% from field removal. I
would rather re-check if benchmark is valid.
On the other hand, lots of our utility c
GitHub user VladimirErshov opened a pull request:
https://github.com/apache/ignite/pull/407
IGNITE-1605 implementation of data loss
IGNITE-1605 implementation of data loss
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/VladimirEr
If it really can give as 5% of performance we have to do it.
If anyone uses this methods we can support it by user request (if user
explicitly asked about) and it will work slower in that case. For example,
we can add *IgniteCache.withAsync(boolean useFutureWithTimer)* that will
give to user an as
Artem Shutak created IGNITE-2395:
Summary: Binary marshaller: id mapper must be resolved according
to configuration.
Key: IGNITE-2395
URL: https://issues.apache.org/jira/browse/IGNITE-2395
Project: Ig
Denis Magda created IGNITE-2394:
---
Summary: Cache loading from storage is called on client nodes
Key: IGNITE-2394
URL: https://issues.apache.org/jira/browse/IGNITE-2394
Project: Ignite
Issue Typ
All of optimizations applied to futures so far were extremely effective.
Ignite can create different number of futures per operation depending on
context. Multiple this by ops/sec.. This is probably one of the most
intensively instantiated (and therefore GCed) object. Internal futures is
very sensi
Dima,
because notebook doesn't have any settings for it.
On Thu, Jan 14, 2016 at 11:30 PM, Dmitriy Setrakyan
wrote:
> Andrey, I am still a bit unclear. Why not have ability to specify a default
> cache per notebook, not per-interpreter?
>
> On Thu, Jan 14, 2016 at 8:42 AM, Andrey Gura wrote:
>
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/406
IGNITE-2379 .NET: ASP.NET Output Cache provider
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-2379
Alternatively yo
Pavel Konstantinov created IGNITE-2393:
--
Summary: Set appropriate DB dialect for caches created during
importing metadata from DB
Key: IGNITE-2393
URL: https://issues.apache.org/jira/browse/IGNITE-2393
All Binary-related classes start from Binary. So, it's not consistent.
We should chose between *BinarySimpleNameIdMapper* and
*BinarySimpleClassNameIdMapper*.
Also, I'd like to move default *BinaryInternalIdMapper* to public package
(that uses full class name) and rename him accordingly. Any obje
Pavel Konstantinov created IGNITE-2392:
--
Summary: Do not generate 'cacheConfiguration' for client in case
if cluster has no caches but has IGFS
Key: IGNITE-2392
URL: https://issues.apache.org/jira/browse/IGNI
Denis Magda created IGNITE-2391:
---
Summary: IGFS + Ignite MR works slower than Hadoop (Hortonswork) MR
Key: IGNITE-2391
URL: https://issues.apache.org/jira/browse/IGNITE-2391
Project: Ignite
Iss
Still not sure how they are similar:
TopologyValidator is invoked on every topology change and provides a
boolean result whether topology is ready to be used. Currently there is no
way to mark a 'failed' topology as valid without another topology change.
This new method that Vladimir suggests res
I think persistence through snapshots (Raul proposed the other day) is an
option too.
Since all data structures in Ignite are basically key-value, it should be quite
universal. Ordering can be preserved too.
#This will also require taking care of data updated between snapshots to avoid
data l
Alexey,
All I am saying is that the difference between topology validator and this
new method becomes very subtle. One just looks like a subset of another. Am
I wrong?
D.
On Thu, Jan 14, 2016 at 2:38 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> Dmitriy,
>
> Are you suggesting tha
20 matches
Mail list logo
