[jira] [Created] (IGNITE-2502) GridNearAtomicUpdateRequest allocates to much Object[]

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-2502:
---

 Summary: GridNearAtomicUpdateRequest allocates to much Object[]
 Key: IGNITE-2502
 URL: https://issues.apache.org/jira/browse/IGNITE-2502
 Project: Ignite
  Issue Type: Sub-task
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 1.6


*Problem*
GridNearAtomicUpdateRequest might create up to 4 ArrayList's. Initially they 
are empty. When the very first element is added, ArrayList is extended to hold 
10 objects (new Object[]). Put in ATOMIC cache almost all operations are 
performed on a single key. 
As a result 90% of array is not used.

*Proposed solution*
We know in advance how many keys participate in operation. Let's use min(10, 
keyCount) as initial array list size. This will make allocation more accurate.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2506) A damon node with binary marshaller hangs on unmarshalling of a user class

[Artem Shutak (JIRA)]

Artem Shutak created IGNITE-2506:


 Summary: A damon node with binary marshaller hangs on 
unmarshalling of a user class
 Key: IGNITE-2506
 URL: https://issues.apache.org/jira/browse/IGNITE-2506
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Artem Shutak


A damon node with binary marshaller hangs on unmarshalling of a user class.

As a POC, {{IgniteDaemonNodeMarshallerCacheTest}} test hangs if 
{{GridTestProperties.setProperty(GridTestProperties.MARSH_CLASS_NAME, 
BinaryMarshaller.class.getName());}}.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2507) GridBinaryMarshaller#pushContext() uses ThreadLocal inefficiently.

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-2507:


 Summary: GridBinaryMarshaller#pushContext() uses ThreadLocal 
inefficiently.
 Key: IGNITE-2507
 URL: https://issues.apache.org/jira/browse/IGNITE-2507
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 1.5.0.final
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


{noformat}
java.lang.ThreadLocal$ThreadLocalMap.set(ThreadLocal, Object)
java.lang.ThreadLocal$ThreadLocalMap.access$100(ThreadLocal$ThreadLocalMap, 
ThreadLocal, Object)
java.lang.ThreadLocal.setInitialValue()
java.lang.ThreadLocal.get()
org.apache.ignite.internal.binary.GridBinaryMarshaller.pushContext(BinaryContext)
org.apache.ignite.internal.binary.GridBinaryMarshaller.unmarshal(byte[], 
ClassLoader)
{noformat}
It creates hundreds of ThreadLocalMap$Entry instances. Need to find out whether 
BinaryContext can be stored more efficiently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2504) Multiple From

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2504:
--

 Summary: Multiple From
 Key: IGNITE-2504
 URL: https://issues.apache.org/jira/browse/IGNITE-2504
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Tupitsyn






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2503) Unions

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2503:
--

 Summary: Unions
 Key: IGNITE-2503
 URL: https://issues.apache.org/jira/browse/IGNITE-2503
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Tupitsyn






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Created] (IGNITE-2493) Get rid fo sun.misc.Cleaner in PlatformMemoryPool.

[Andrey Gura]

Vova,

could you please add some details to ticket description?

Thanks.

On Thu, Jan 28, 2016 at 3:33 PM, Vladimir Ozerov (JIRA) 
wrote:

> Vladimir Ozerov created IGNITE-2493:
> ---
>
>  Summary: Get rid fo sun.misc.Cleaner in PlatformMemoryPool.
>  Key: IGNITE-2493
>  URL: https://issues.apache.org/jira/browse/IGNITE-2493
>  Project: Ignite
>   Issue Type: Task
>   Components: interop
> Affects Versions: 1.5.0.final
> Reporter: Vladimir Ozerov
> Assignee: Vladimir Ozerov
>  Fix For: 1.6
>
>
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

[jira] [Created] (IGNITE-2505) IgniteTxImplicitSingleStateImpl#allEntries() and #writes() instantiate new collection on every call

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-2505:


 Summary: IgniteTxImplicitSingleStateImpl#allEntries() and 
#writes() instantiate new collection on every call
 Key: IGNITE-2505
 URL: https://issues.apache.org/jira/browse/IGNITE-2505
 Project: Ignite
  Issue Type: Sub-task
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh


It can be optimized by creating and storing Collections.singletonList() on 
#addEntry() call.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: affinityRun() and affinityCall() (JIRA ticket)

[Dood]

Val,

Before I go on and submit pull requests etc. - would you comment on the 
path I am taking with this? As I said I am not a JAVA developer but I am 
trying to teach myself the language and contribute at the same time ;)


Here are my thoughts on implementing this for the queue 
(GridCacheQueueAdapter.java). I have also declared the following in 
IgniteQueue.java:


@IgniteAsyncSupported
public void affinityRun(IgniteRunnable job) throws IgniteException;

@IgniteAsyncSupported
public  R affinityCall(IgniteCallable job) throws IgniteException;

Here is what is in GridCacheQueueAdapter.java

/** {@inheritDoc} */
public void affinityRun(IgniteRunnable job) {
if (!collocated)
throw new IgniteException("Illegal operation requested on non-collocated 
queue:affinityRun().");


try {
compute.affinityRun(cache.name(),queueKey,job);
}
catch (IgniteException e) {
throw e;
}
}

/** {@inheritDoc} */
public  R affinityCall(IgniteCallable job) {
if (!collocated)
throw new IgniteException("Illegal operation requested on non-collocated 
queue:affinityCall().");


try {
return compute.affinityCall(cache.name(),queueKey,job);
}
catch (IgniteException e) {
throw e;
}
}

I have included the following at the top of the class 
GridCacheQueueAdapter:

private final IgniteCompute compute;

this.compute = cctx.kernalContext().grid().compute();

Let me know what you think!

On 1/27/2016 3:55 PM, Valentin Kulichenko wrote:

Hi,

Both GridCacheQueueAdapter and GridCacheSetImpl have a reference to
GridCacheContext which represents the underlying cache for the data
structure. GridCacheContext.name() will give you the correct cache name
that you can use when calling affinityRun method.

-Val

On Wed, Jan 27, 2016 at 9:13 AM, Dood@ODDO  wrote:


Hello,

I am playing with https://issues.apache.org/jira/browse/IGNITE-1144 as
introduction to hacking on Ignite. I am not a Java developer by day but
have experience writing code in various languages. This is my first
in-depth exposure to Ignite internals (have lightly used it as a user in a
POC project).

Looking at this ticket, I am guessing that what it needs to do is get the
cache name from the kernel context. After that it can just pass on the call
(such as affinityRun()) to the regular affinityRun() call with the cache
name filled in as the first parameter. This is because an internal
(un-exposed) cache is used to track the queue/set data structures. Is this
all correct?

My question is: how do I get the cache name from within the queue
implementation.

Thanks!

[GitHub] ignite pull request: Ignite-996 TestSuite

[ilantukh]

Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/315


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: IGNITE-1692 Changed test initialization logic...

[ilantukh]

Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/293


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: IGNITE-2495: ODBC: One-row queries can not be...

[isapego]

GitHub user isapego opened a pull request:

https://github.com/apache/ignite/pull/438

IGNITE-2495: ODBC: One-row queries can not be fetched.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/isapego/ignite ignite-2495

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/438.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #438


commit 8c0c675207c954a58abc9bb065dff055577aa9b8
Author: isapego 
Date:   2016-01-28T14:13:01Z

IGNITE-2495: Added tests for row.

commit ac0b59ff8cfd0ae0ec9fb82aa10972078952065a
Author: isapego 
Date:   2016-01-28T14:33:52Z

IGNITE-2495: Added cursor test.

commit 0b26795deed9ba0932e4f8ed85d0465540660137
Author: isapego 
Date:   2016-01-28T15:09:24Z

IGNITE-2495: Updated cursor tests to match cursor desired behaviour.

commit 27f438cf3802ac49f9e358e9de004f2235a2ef55
Author: isapego 
Date:   2016-01-28T15:37:01Z

IGNITE-2495: Changed Cursor behaviour to match test.

commit cc0c0799d45698edce3e86e7fae2f78598746427
Author: isapego 
Date:   2016-01-29T11:59:01Z

IGNITE-2495: Fixed DataQuery.




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: ignite-2288: Changed F.first(Iterable) to use...

[ilantukh]

Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/382


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: gg-10858 - BinaryMarshaller metadata propagat...

[ilantukh]

Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/314


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: gg-10897 fixed svuid for CacheObjectAdapter.

[ilantukh]

Github user ilantukh closed the pull request at:

https://github.com/apache/ignite/pull/349


---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Pool size limits

[Denis Magda]

Hi Vasiliy,

Thanks for catching this issue!

If to refer how the rest of the pools are initialized both initial and max
size of utility cache pool must be the  equal
(myCfg.getUtilityCacheThreadPoolSize()). The same is for marshalling pool.

Fixed the issue and merged into the master.

Regards,
Denis



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Pool-size-limits-tp6741p6932.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Docker image

[Nikolay Tikhonov]

Val,

Our docker repo contains not only the latest version or 1.0.0-incubating,
there all versions.  List of versions here [1]. I've updated "Dockerfile"
tab, now it shows dockerfile from "1.5.0.final" tag.

[1] https://hub.docker.com/r/apacheignite/ignite/tags

On Fri, Jan 29, 2016 at 9:34 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Nikolay,
>
> As far as I know you were creating Docker images for Ignite.
>
> I just opened it [1] and noticed that the version is 1.0.0 there. Is there
> a reason for this? Can we switch it to the latest?
>
> [1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
>
> -Val
>

[jira] [Created] (IGNITE-2499) exception on Save SWAP settings

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-2499:
--

 Summary: exception on Save SWAP settings
 Key: IGNITE-2499
 URL: https://issues.apache.org/jira/browse/IGNITE-2499
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


I've set File-based swap and click Save
{code}
16:17:18.477 Error: item.swapSpaceSpi[swapKind] is undefined
validate@https://staging-console.gridgain.com/all.js:1332:21
$scope.saveItem@https://staging-console.gridgain.com/all.js:1405:17
anonymous/fn@https://staging-console.gridgain.com/app.min.js line 93099 > 
Function:2:450
ngEventHandler/https://staging-console.gridgain.com/app.min.js:96847:21
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94711:22
$RootScopeProvider/this.$gethttps://staging-console.gridgain.com/app.min.js:94734:26
ngEventHandler/<@https://staging-console.gridgain.com/app.min.js:96852:21
jQuery.event.dispatch@https://staging-console.gridgain.com/app.min.js:126942:25
jQuery.event.add/elemData.handle@https://staging-console.gridgain.com/app.min.js:126813:91
1 app.min.js:92305:24
consoleLog/<() app.min.js:92305
$ExceptionHandlerProvider/this.$get

[jira] [Created] (IGNITE-2500) Ordering

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2500:
--

 Summary: Ordering
 Key: IGNITE-2500
 URL: https://issues.apache.org/jira/browse/IGNITE-2500
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2501) Subqueries

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-2501:
--

 Summary: Subqueries
 Key: IGNITE-2501
 URL: https://issues.apache.org/jira/browse/IGNITE-2501
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Affects Versions: 1.1.4
Reporter: Pavel Tupitsyn


Subqueries in joins, etc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-2508) org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#nodes(int, AffinityTopologyVersion) call are too costly

[Ilya Lantukh (JIRA)]

Ilya Lantukh created IGNITE-2508:


 Summary: 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl#nodes(int,
 AffinityTopologyVersion) call are too costly
 Key: IGNITE-2508
 URL: https://issues.apache.org/jira/browse/IGNITE-2508
 Project: Ignite
  Issue Type: Sub-task
Reporter: Ilya Lantukh
Assignee: Ilya Lantukh
 Fix For: 1.5.0.final


New HashSet and ArrayList are instantiated on every call. Check if it is 
possible to optimize subsequent calls of this method if affinity assignment 
hasn't changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Adding tracing component to Ignite

[Dmitriy Setrakyan]

How do you disable it? I mean, how do you make sure that it does not affect
performance when it is turned off?

D.

On Fri, Jan 29, 2016 at 12:31 PM, Vladimir Ozerov 
wrote:

> Folks,
>
> Quite often we face some concurrency or performance issues. And what is
> worse, sometimes they spread across several nodes making them hard to
> debug.
>
> We do various things to debug such problems. We add System.outs, measure
> latencies between algorithm steps, etc.. And once the problem is resolved,
> we throw away all debugging code.
>
> What if add a kind of tracing component to Ignite, so that convenient
> debugging infrastructure wiil always be ready for use?
>
> E.g., assume that we have performance issue in cache operation. Tracing
> framework could be used as follows:
>
> /** Register tracer. */
> Cache.onStart() {
> ...
> ctx.trace().createProfile("cache_problem");
> }
>
> /** Put trace inside problematic code. */
> Cache.get(...) {
> TraceEvent traceEvt = ctx.trace().start("cache_problem");
> ...
> traceEvt.checkpoint("LOCKED", [optional args and identifiers]);
> ...
> traceEvt.checkpoint("COMMITTED", ...);
> }
>
> /** In the end we dump problematic events. */
> Cache.onStop() {
> ...
> ctx.profile("cache_problem").dump(System.out, [FILTER PREDICATE]);
> }
>
> Result:
> 23:20:01.234 [LOCKED=20ms, COMMITTED=152ms, FINISHED=153ms]
> 23:20:03.211 [LOCKED= 1ms, COMMITTED=  1ms, FINISHED=  2ms]
>
> I believe lots of you already did something like this during debug. The
> idea is to have some reusable component, so that we do not need to reinvent
> the wheel over and over again.
>
> Thoughts?
>
> Vladimir.
>

Re: The Changelog podcast

[Dmitriy Setrakyan]

Raul,

How do I give it a +1 on github? Should I just reply to your original
comment?

D.

On Fri, Jan 29, 2016 at 11:13 AM, Raul Kripalani  wrote:

> Hey Igniters,
>
> In case you haven't come across it, The Changelog [1] is a weekly podcast
> that features new cool stuff in the Open Source space.
>
> They have featured Spark, Storm, Kubernetes, Docker, Kong, InfluxDB,
> ZeroDB, React, Prometheus, Mesos, etc.
>
> I have submitted a proposal to feature Apache Ignite:
> https://github.com/thechangelog/ping/issues/379.
>
> Feel free to support it with a +1 if you'd like us to appear there.
>
> I've nominated Dmitriy since he's the PMC Chair and knows the project
> pretty well, but anyone can do it. In fact, if we have several interested
> people, we could start a VOTE.
>
> [1] https://changelog.com/
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io | twitter: @raulvk 
>

Re: The Changelog podcast

[Raul Kripalani]

Yep. Github way of voting tends to be a "+1" comment.
On 30 Jan 2016 00:16, "Dmitriy Setrakyan"  wrote:

> Raul,
>
> How do I give it a +1 on github? Should I just reply to your original
> comment?
>
> D.
>
> On Fri, Jan 29, 2016 at 11:13 AM, Raul Kripalani  wrote:
>
> > Hey Igniters,
> >
> > In case you haven't come across it, The Changelog [1] is a weekly podcast
> > that features new cool stuff in the Open Source space.
> >
> > They have featured Spark, Storm, Kubernetes, Docker, Kong, InfluxDB,
> > ZeroDB, React, Prometheus, Mesos, etc.
> >
> > I have submitted a proposal to feature Apache Ignite:
> > https://github.com/thechangelog/ping/issues/379.
> >
> > Feel free to support it with a +1 if you'd like us to appear there.
> >
> > I've nominated Dmitriy since he's the PMC Chair and knows the project
> > pretty well, but anyone can do it. In fact, if we have several interested
> > people, we could start a VOTE.
> >
> > [1] https://changelog.com/
> >
> > *Raúl Kripalani*
> > PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> > Messaging Engineer
> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> > Blog: raul.io | twitter: @raulvk 
> >
>

Re: affinityRun() and affinityCall() (JIRA ticket)

[Valentin Kulichenko]

Responded in the ticket.

-Val

On Fri, Jan 29, 2016 at 7:05 AM, Dood@ODDO  wrote:

> Val,
>
> Before I go on and submit pull requests etc. - would you comment on the
> path I am taking with this? As I said I am not a JAVA developer but I am
> trying to teach myself the language and contribute at the same time ;)
>
> Here are my thoughts on implementing this for the queue
> (GridCacheQueueAdapter.java). I have also declared the following in
> IgniteQueue.java:
>
> @IgniteAsyncSupported
> public void affinityRun(IgniteRunnable job) throws IgniteException;
>
> @IgniteAsyncSupported
> public  R affinityCall(IgniteCallable job) throws IgniteException;
>
> Here is what is in GridCacheQueueAdapter.java
>
> /** {@inheritDoc} */
> public void affinityRun(IgniteRunnable job) {
> if (!collocated)
> throw new IgniteException("Illegal operation requested on non-collocated
> queue:affinityRun().");
>
> try {
> compute.affinityRun(cache.name(),queueKey,job);
> }
> catch (IgniteException e) {
> throw e;
> }
> }
>
> /** {@inheritDoc} */
> public  R affinityCall(IgniteCallable job) {
> if (!collocated)
> throw new IgniteException("Illegal operation requested on non-collocated
> queue:affinityCall().");
>
> try {
> return compute.affinityCall(cache.name(),queueKey,job);
> }
> catch (IgniteException e) {
> throw e;
> }
> }
>
> I have included the following at the top of the class
> GridCacheQueueAdapter:
> private final IgniteCompute compute;
>
> this.compute = cctx.kernalContext().grid().compute();
>
> Let me know what you think!
>
>
> On 1/27/2016 3:55 PM, Valentin Kulichenko wrote:
>
>> Hi,
>>
>> Both GridCacheQueueAdapter and GridCacheSetImpl have a reference to
>> GridCacheContext which represents the underlying cache for the data
>> structure. GridCacheContext.name() will give you the correct cache name
>> that you can use when calling affinityRun method.
>>
>> -Val
>>
>> On Wed, Jan 27, 2016 at 9:13 AM, Dood@ODDO  wrote:
>>
>> Hello,
>>>
>>> I am playing with https://issues.apache.org/jira/browse/IGNITE-1144 as
>>> introduction to hacking on Ignite. I am not a Java developer by day but
>>> have experience writing code in various languages. This is my first
>>> in-depth exposure to Ignite internals (have lightly used it as a user in
>>> a
>>> POC project).
>>>
>>> Looking at this ticket, I am guessing that what it needs to do is get the
>>> cache name from the kernel context. After that it can just pass on the
>>> call
>>> (such as affinityRun()) to the regular affinityRun() call with the cache
>>> name filled in as the first parameter. This is because an internal
>>> (un-exposed) cache is used to track the queue/set data structures. Is
>>> this
>>> all correct?
>>>
>>> My question is: how do I get the cache name from within the queue
>>> implementation.
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>>
>

Re: Docker image

[Valentin Kulichenko]

Thanks, Nikolay!

On Fri, Jan 29, 2016 at 12:43 AM, Nikolay Tikhonov 
wrote:

> Val,
>
> Our docker repo contains not only the latest version or 1.0.0-incubating,
> there all versions.  List of versions here [1]. I've updated "Dockerfile"
> tab, now it shows dockerfile from "1.5.0.final" tag.
>
> [1] https://hub.docker.com/r/apacheignite/ignite/tags
>
> On Fri, Jan 29, 2016 at 9:34 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Nikolay,
> >
> > As far as I know you were creating Docker images for Ignite.
> >
> > I just opened it [1] and noticed that the version is 1.0.0 there. Is
> there
> > a reason for this? Can we switch it to the latest?
> >
> > [1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
> >
> > -Val
> >
>

[jira] [Created] (IGNITE-2509) Broken eviction for OFFHEAP_VALUES cache mode

[Denis Magda (JIRA)]

Denis Magda created IGNITE-2509:
---

 Summary: Broken eviction for OFFHEAP_VALUES cache mode
 Key: IGNITE-2509
 URL: https://issues.apache.org/jira/browse/IGNITE-2509
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Assignee: Vladimir Ershov


In case when {{OFFHEAP_VALUES}} mode is used {{EvictionPolicy}} calculates 
values size wrongly which leads to the fact that data is evicted only when 
either the limit on number of entries is reached or size of keys is bigger than 
max allowed size.

To reproduce set the following cache configuration

{noformat}
FifoEvictionPolicy plc = new FifoEvictionPolicy();
plc.setMaxMemorySize(2 * 1024 * 1024);

cacheCfg.setEvictionPolicy(plc);

cacheCfg.setMemoryMode(CacheMemoryMode.OFFHEAP_VALUES);
cacheCfg.setSwapEnabled(true);
{noformat}

Test that reproduces the issue is attached.

Also attached a patch that fixes the issue. However we should validate that the 
fix is full and add additional tests to the test suites.

Finally, {{cache.metrics().getOffHeapAllocatedSize()}} always returns 0 for 
this cache mode. Has to be fixed as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] ignite pull request: Ignite 1069

[kcheng-mvp]

GitHub user kcheng-mvp opened a pull request:

https://github.com/apache/ignite/pull/440

Ignite 1069

Fix issue 
https://issues.apache.org/jira/browse/IGNITE-1069

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/kcheng-mvp/ignite ignite-1069

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/440.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #440


commit a9d82908fb288fe7236ae9af662589779fb3e463
Author: kcheng-mvp 
Date:   2015-11-06T02:58:28Z

Merge branch 'ignite-1.5' of github.com:apache/ignite

commit cc55115c9851d47072c2adfd31db788d0de05c4d
Author: kcheng-mvp 
Date:   2015-11-09T07:18:34Z

Merge branch 'master' of github.com:apache/ignite

commit 9f8fb9339bf627d994e012a3ecaf734876455d55
Author: kcheng-mvp 
Date:   2015-11-12T07:01:54Z

Merge branch 'master' of github.com:apache/ignite

commit 6a7e233a31f322db2943031ab65f05bb0e5ca1e8
Author: kcheng-mvp 
Date:   2015-11-18T02:23:13Z

Merge branch 'master' of github.com:apache/ignite

commit 6013e52d95e9956db38dbe048cb7d6029c71c5af
Author: U-PYCREDIT\chengxw 
Date:   2015-12-02T10:12:39Z

Merge branch 'master' of https://github.com/apache/ignite

commit 6c9b2497e6f0ddf1258fd0894a7d2c6c69b28e18
Author: U-PYCREDIT\chengxw 
Date:   2015-12-03T01:21:33Z

Merge branch 'master' of https://github.com/apache/ignite

commit ea871f3eef80e0bff9997002d57f603cde299a0f
Author: kcheng-mvp 
Date:   2015-12-08T01:51:51Z

Merge branch 'master' of github.com:apache/ignite

commit 02d6ad01764b702b1aacc5d7a1cb01c56d985662
Author: kcheng 
Date:   2015-12-09T09:28:51Z

Merge branch 'master' of https://github.com/apache/ignite

commit 1160eb98280cc794a6467d2c3aa91b7db05a706d
Author: kcheng 
Date:   2016-01-11T09:21:37Z

Merge branch 'master' of https://github.com/apache/ignite

commit a876f9df590f1a5cc8cc07e5a8bad2aa2d841752
Author: kcheng 
Date:   2016-01-12T06:30:44Z

Merge branch 'master' of https://github.com/apache/ignite

commit d32ddceab6e2e6bf88aab3fd494658093ad44d50
Author: kcheng 
Date:   2016-01-14T00:37:36Z

Merge branch 'master' of https://github.com/apache/ignite

commit e92b187d73c5010501a799bfbd3e27b9cffbc749
Author: kcheng 
Date:   2016-01-18T00:39:10Z

Merge branch 'master' of https://github.com/apache/ignite

commit 12f5d3499b21498856327bb1d626ab5e4f1d9365
Author: kcheng 
Date:   2016-01-21T09:40:57Z

Merge branch 'master' of https://github.com/apache/ignite

commit d49feedad52ca922bf003e95ef3da9e34ee443bd
Author: kcheng 
Date:   2016-01-22T09:00:49Z

Merge branch 'master' of https://github.com/apache/ignite

commit b9caff3c7cebd5d984064a7d092d0101d4b5fb15
Author: kcheng 
Date:   2016-01-25T00:45:02Z

Merge branch 'master' of https://github.com/apache/ignite

commit bdc8f4eadfb5d54d345337885a6bacba28436eb7
Author: kcheng 
Date:   2016-01-28T05:41:59Z

Merge branch 'master' of https://github.com/apache/ignite

commit 7e8a75be7a4ed141a945f04ae039460aa92699b6
Author: kcheng 
Date:   2016-01-29T03:00:09Z

Merge branch 'master' of https://github.com/apache/ignite

commit 616f4df1ed0e9ccf4644db5133484e5cb92bd4d2
Author: kcheng 
Date:   2016-01-29T09:53:15Z

Merge branch 'master' of https://github.com/apache/ignite

commit b667f6580d8c1640f1efb3a22152eec82b8021e4
Author: kcheng 
Date:   2016-01-30T01:00:35Z

Merge branch 'master' of https://github.com/apache/ignite

commit 132f0aed20b1f914753416cec793a580bd8a14a0
Author: kcheng 
Date:   2016-01-30T01:33:24Z

work on #1069

commit 7a0e6cdce6210688ad7e76cd101751847b8fe069
Author: kcheng 
Date:   2016-01-30T03:42:09Z

add Node Type

commit 37866e81861441f71eb0c8bca4e1ccbf55ae4a3e
Author: kcheng 
Date:   2016-01-30T03:43:43Z

delete temporary file




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Adding tracing component to Ignite

[Vladimir Ozerov]

Folks,

Quite often we face some concurrency or performance issues. And what is
worse, sometimes they spread across several nodes making them hard to debug.

We do various things to debug such problems. We add System.outs, measure
latencies between algorithm steps, etc.. And once the problem is resolved,
we throw away all debugging code.

What if add a kind of tracing component to Ignite, so that convenient
debugging infrastructure wiil always be ready for use?

E.g., assume that we have performance issue in cache operation. Tracing
framework could be used as follows:

/** Register tracer. */
Cache.onStart() {
...
ctx.trace().createProfile("cache_problem");
}

/** Put trace inside problematic code. */
Cache.get(...) {
TraceEvent traceEvt = ctx.trace().start("cache_problem");
...
traceEvt.checkpoint("LOCKED", [optional args and identifiers]);
...
traceEvt.checkpoint("COMMITTED", ...);
}

/** In the end we dump problematic events. */
Cache.onStop() {
...
ctx.profile("cache_problem").dump(System.out, [FILTER PREDICATE]);
}

Result:
23:20:01.234 [LOCKED=20ms, COMMITTED=152ms, FINISHED=153ms]
23:20:03.211 [LOCKED= 1ms, COMMITTED=  1ms, FINISHED=  2ms]

I believe lots of you already did something like this during debug. The
idea is to have some reusable component, so that we do not need to reinvent
the wheel over and over again.

Thoughts?

Vladimir.