[GitHub] ignite pull request #1731: IGNITE-4534, up-to-date with ignite-3477-master

[glukos]

GitHub user glukos opened a pull request:

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

IGNITE-4534, up-to-date with ignite-3477-master

All changes from IGNITE-4534 applied over ignite-3477-master.

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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-4534-from-3477-master

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

https://github.com/apache/ignite/pull/1731.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 #1731


commit b127153b2d2733aab1881b056d2dd2bd7f374d81
Author: Sergey Chugunov 
Date:   2017-04-03T15:29:52Z

Merge mistake was corrected, obsolete tests were removed

commit 281efd4b9f0577d55260c7ea53c450e6182085c6
Author: Ilya Lantukh 
Date:   2017-04-03T16:19:30Z

Fixed GridCacheRebalancingUnmarshallingFailedSelfTest.

commit dce205fe288e048707596bb0b467fe562e93e845
Author: Ilya Lantukh 
Date:   2017-04-03T16:20:41Z

Merge branch 'ignite-3477-master' of 
https://github.com/gridgain/apache-ignite into ignite-3477-master

commit 98d92d89d69497172a6d33d88c17c1b05396ae04
Author: Ivan Rakov 
Date:   2017-04-04T18:53:35Z

IGNITE-4534: Implement offheap eviction policies based on page memory




---
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: IGNITE-4535 : Add option to store deserialized values on-heap

[Dmitriy Setrakyan]

Ilya, I looked at the Semyon's comments in the ticket, and I think I agree
with him on all counts.

1. Setting an eviction policy should not be a mechanism to enable the
on-heap cache. We already have eviction policies off-heap as well, and they
don't enable anything. On top of that, the eviction policy should not be a
requirement for the on-heap cache. User should still be able to enable the
on-heap cache, even if it grows indefinitely without evictions. We should
have a more intuitive flag here.

2. As far as the tests go, they should examine all the tests and adapt them
to the new behavior. I think we should have a replica of all off-heap tests
to test the scenario with on-heap caches.

D.

On Tue, Apr 4, 2017 at 8:12 AM, Ilya Lantukh  wrote:

> Hi Igniters,
>
> Since review of IGNITE-4535
>  implementation caused
> some misunderstandings, I'd like to open a discussion here and see if
> everyone agrees with the chosen approach or can suggest a better one.
>
> We are going to re-use existing EvictionPolicy mechanics to decide when
> entry is going to be evicted from on-heap cache. If evictionPolicy == null,
> we assume that there is no on-heap cache. One of suggested alternatives was
> to have a separate boolean parameter that will enable on-heap cache.
>
> Another questionable decision was to remove tests for memory mode
> variations. For example, we had GridCacheContinuousQueryAtomicSelfTest,
> GridCacheContinuousQueryAtomicOffheapTieredSelfTest and
> GridCacheContinuousQueryAtomicOffheapValuesSelfTest that were testing the
> same functionallity for ONHEAP_TIERED, OFFHEAP_TIERED and OFFHEAP_VALUES
> modes, respectively. Since those memory modes were removed, only
> GridCacheContinuousQueryAtomicSelfTest was left and it now runs in
> off-heap
> mode without on-heap cache. One of suggestions was to add a new subclass to
> this test (and all other tests) that will run the same test case with
> on-heap cache enabled. In my opinion, functionallity that is specific for
> on-heap cache should be tested in completely separate tests (which we
> already have), and there is no need to run generic tests with every
> possible configuration.
>
> What do you think?
>
> --
> Best regards,
> Ilya
>

[GitHub] ignite pull request #1730: IGNITE-1267: JobStealingCollisionSpi never sends ...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-1267: JobStealingCollisionSpi never sends jobs to a node that joined 
after task was executed

(cherry picked from commit 7059d8e)

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

$ git pull https://github.com/gridgain/apache-ignite ignite-1267

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

https://github.com/apache/ignite/pull/1730.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 #1730


commit 6eae8dd0bc3e696878cf66e0fa2be607846fbe64
Author: Andrey V. Mashenkov 
Date:   2017-04-04T15:10:20Z

Fixed.

(cherry picked from commit 7059d8e)




---
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 #1729: IGNTIE-1267: JobStealingCollisionSpi never sends ...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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 #1729: IGNTIE-1267: JobStealingCollisionSpi never sends ...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNTIE-1267: JobStealingCollisionSpi never sends jobs to a node that joined 
after task was executed

Fixed

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

$ git pull https://github.com/gridgain/apache-ignite ignite-1267

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

https://github.com/apache/ignite/pull/1729.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 #1729


commit 6eae8dd0bc3e696878cf66e0fa2be607846fbe64
Author: Andrey V. Mashenkov 
Date:   2017-04-04T15:10:20Z

Fixed.

(cherry picked from commit 7059d8e)




---
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.
---

IGNITE-4535 : Add option to store deserialized values on-heap

[Ilya Lantukh]

Hi Igniters,

Since review of IGNITE-4535
 implementation caused
some misunderstandings, I'd like to open a discussion here and see if
everyone agrees with the chosen approach or can suggest a better one.

We are going to re-use existing EvictionPolicy mechanics to decide when
entry is going to be evicted from on-heap cache. If evictionPolicy == null,
we assume that there is no on-heap cache. One of suggested alternatives was
to have a separate boolean parameter that will enable on-heap cache.

Another questionable decision was to remove tests for memory mode
variations. For example, we had GridCacheContinuousQueryAtomicSelfTest,
GridCacheContinuousQueryAtomicOffheapTieredSelfTest and
GridCacheContinuousQueryAtomicOffheapValuesSelfTest that were testing the
same functionallity for ONHEAP_TIERED, OFFHEAP_TIERED and OFFHEAP_VALUES
modes, respectively. Since those memory modes were removed, only
GridCacheContinuousQueryAtomicSelfTest was left and it now runs in off-heap
mode without on-heap cache. One of suggestions was to add a new subclass to
this test (and all other tests) that will run the same test case with
on-heap cache enabled. In my opinion, functionallity that is specific for
on-heap cache should be tested in completely separate tests (which we
already have), and there is no need to run generic tests with every
possible configuration.

What do you think?

-- 
Best regards,
Ilya

Re: Ignite-4795 - ready for review

[Дмитрий Рябов]

Andrey, I made fix, can you look it again?

2017-03-28 20:40 GMT+03:00 Andrey Gura :

> Dmitry, see JIRA ticket for review comments.
>
> On Mon, Mar 27, 2017 at 6:13 PM, Denis Magda  wrote:
> > Hello Dmitriy, thanks! Someone will have a look at your changes soon.
> Sorry for the delay.
> >
> > —
> > Denis
> >
> >> On Mar 27, 2017, at 3:24 AM, Дмитрий Рябов 
> wrote:
> >>
> >> Hello, can anyone review this issue?
> >>
> >> 2017-03-20 16:33 GMT+03:00 Дмитрий Рябов :
> >>
> >>> Done.
> >>>
> >>> 2017-03-20 16:30 GMT+03:00 Антон Чураев :
> >>>
>  Dmitry, thank you!
> 
>  Could you please also change issue status to "Patch available".
> 
>  2017-03-20 16:01 GMT+03:00 Дмитрий Рябов :
> 
> > Hello, community. Please, review and/or suggest something about
>  javadocs of
> > transactions.
> >
> > PR: https://github.com/apache/ignite/pull/1630/files
> >
> > JIRA: https://issues.apache.org/jira/browse/IGNITE-4795
> >
> 
> 
> 
>  --
>  С уважением,
>  Чураев Антон
> 
> >>>
> >>>
> >
>

readyNearLocks()! wat?

[ALEKSEY KUZNETSOV]

Igniters! What is the purpose of calling GridNearTxLocal#readyNearLocks()
After we received prepare response at primary node ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

IGNITE-4022 IgniteServices soesn't throw an exception if there are no server nodes

[Vladislav Pyatkov]

Please, check my PA:

https://issues.apache.org/jira/browse/IGNITE-4022
https://github.com/apache/ignite/pull/1728

I think, test is not need. Because the suggestion will not be affect o
logic.
But I want have listened someone's mind.

-- 
Vladislav Pyatkov

Re: IGNITE-2558 PR is ready to review (NearCacheConfiguration should not extend MutableConfiguration)

[Kozlov Maxim]

Create ticket https://issues.apache.org/jira/browse/IGNITE-4910 
 and fix PR.

> 4 апр. 2017 г., в 17:06, Kozlov Maxim  написал(а):
> 
> Valentin, of course. I'll let you know how I'll do it.
> 
>> 4 апр. 2017 г., в 16:38, Valentin Kulichenko > > написал(а):
>> 
>> Maxim,
>> 
>> It looks like you added copyOnRead property on configuration, but I'm
>> pretty sure that currently it will be ignored. Basically, it's a new
>> feature and I'm OK if we do this as a separate task sometime later (e.g. in
>> 2.1). Can you create a ticket and remove the property for now?
>> 
>> -Val
>> 
>> On Tue, Apr 4, 2017 at 3:04 AM, Kozlov Maxim > > wrote:
>> 
>>> Hi igniters,
>>> 
>>> Please review if someone has time.
>>> https://issues.apache.org/jira/browse/IGNITE-2558 
>>>  <
>>> https://issues.apache.org/jira/browse/IGNITE-2558 
>>> >
>>> https://github.com/apache/ignite/pull/1701 
>>>  >> 
>>> ignite/pull/1701>
>>> 
>>> --
>>> Best Regards,
>>> Max K.
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> --
> Best Regards,
> Max K.
> 
> 
> 
> 

--
Best Regards,
Max K.

[jira] [Created] (IGNITE-4910) Add copyOnRead property for near cache.

[Maksim Kozlov (JIRA)]

Maksim Kozlov created IGNITE-4910:
-

 Summary: Add copyOnRead property for near cache.
 Key: IGNITE-4910
 URL: https://issues.apache.org/jira/browse/IGNITE-4910
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Maksim Kozlov
Assignee: Maksim Kozlov


Add {{setCopyOnRead}} to {{NearCacheConfiguration}} class.
Continuation of the task from the ticket 
[https://issues.apache.org/jira/browse/IGNITE-2558].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1728: IGNITE-4022

[vldpyatkov]

GitHub user vldpyatkov opened a pull request:

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

IGNITE-4022

IgniteServices soesn't throw an exception if there are no server nodes

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

$ git pull https://github.com/vldpyatkov/ignite ignite-4022

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

https://github.com/apache/ignite/pull/1728.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 #1728






---
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: IGNITE-2558 PR is ready to review (NearCacheConfiguration should not extend MutableConfiguration)

[Kozlov Maxim]

Valentin, of course. I'll let you know how I'll do it.

> 4 апр. 2017 г., в 16:38, Valentin Kulichenko  
> написал(а):
> 
> Maxim,
> 
> It looks like you added copyOnRead property on configuration, but I'm
> pretty sure that currently it will be ignored. Basically, it's a new
> feature and I'm OK if we do this as a separate task sometime later (e.g. in
> 2.1). Can you create a ticket and remove the property for now?
> 
> -Val
> 
> On Tue, Apr 4, 2017 at 3:04 AM, Kozlov Maxim  wrote:
> 
>> Hi igniters,
>> 
>> Please review if someone has time.
>> https://issues.apache.org/jira/browse/IGNITE-2558 <
>> https://issues.apache.org/jira/browse/IGNITE-2558>
>> https://github.com/apache/ignite/pull/1701 > ignite/pull/1701>
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 
>> 

--
Best Regards,
Max K.

Re: ScanQuery With BinaryObject

[Valentin Kulichenko]

Andrey,

To my knowledge, peer class loading is not supported for scan query
filters, but I'm not sure though. Can you please check?

Note that this actually doesn't matter if the class is available on
server's local classpath. In this case it will be always used regardless of
any changes done on a client (i.e. will never be dynamically loaded). This
is true for any functionality, including Compute Grid.

-Val

On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Crossposted to dev:
>
> Guys,
>
> ScanQuery filter code (see IgniteBiPredicate implementation below) can be
> cached on server side
> that can cause unexpected results.
> The main point here is server node never restarts while client does it with
> filter code changed.
>
> Is it ok?
>
> I try to add *serialVersionUID* and it was useless. The only class renaming
> was helpful.
>
>
> -- Forwarded message --
> From: David Li 
> Date: Mon, Apr 3, 2017 at 9:24 AM
> Subject: Re: ScanQuery With BinaryObject
> To: u...@ignite.apache.org
>
>
> Sorry, please ignore the previous email, it was sent by mistake.
>
> 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip it.
> 2. In terminal, I start an ignite instance by *bin/ignite.sh
> examples/config/example-ignite.xml*
> 3. I create a Java application, source code as below:
>
> public static void main(String[] args) {
> String ORG_CACHE = "org_cache_remote";
>* Ignition.setClientMode(true);*
> Ignite ignite = Ignition.start("example-ignite.xml");
> CacheConfiguration orgCacheCfg = new
> CacheConfiguration<>(ORG_CACHE);
> orgCacheCfg.setIndexedTypes(Long.class, Organization.class);
> ignite.destroyCache(ORG_CACHE);
> IgniteCache cache = ignite.createCache(
> orgCacheCfg);
> cache.put(1L, new Organization(1L, "org1", true, "jurong east",
> ""));
> cache.put(2L, new Organization(2L, "org2", false, "orchard", ""));
> cache.put(3L, new Organization(3L, "org3", true, "jurong west",
> ""));
> cache.put(4L, new Organization(4L, "org4", false, "woodlands",
> ""));
> cache.put(5L, new Organization(5L, "org5", false, "changi", ""));
> // cache.put(6L, new Organization(6L, "org6", true, "jurong island",
> ""));
>
> IgniteCache binaryCache = cache.withKeepBinary();
>
> List> result;
>
> System.out.println("Scan by address");
> ScanQuery scanAddress = new ScanQuery<>(
> new IgniteBiPredicate() {
> @Override
> public boolean apply(Long aLong, BinaryObject binaryObject) {
> *// first time filter by jurong, got two entries, org1 and
> org3*
> *// second time filter by changi, got two entries, org1 and
> org3*
> *// third time filter by changi as well, uncomment org6,
> got three entries, org1, org3 and org6*
> *return
> binaryObject.field("address").startsWith("jurong");*
> }
> }
> );
> result = binaryCache.query(scanAddress).getAll();
> System.out.println("result: " + result.size());
> for (Cache.Entry entry : result) {
> System.out.println(entry.getValue().deserialize().toString());
> }
>
> ignite.close();
> }
>
> Here what I want to do is start a client node, connect to the server node
> started in step 2. Then I create a cache, put some data inside,
> then try to run a scan query to find entries by its address.
> The problem is when I run this program first time, it will return two
> entries, their addresses are started with "jurong", which is correct.
> When I run the program again, with changed value, eg. "changi", it should
> return one entry, somehow, it still return two entries with address started
> with "jurong", rather than "changi".
> When I uncomment the line of "org6", and run the program again, it will
> return three entries, all of their addresses are started with "jurong".
>
> I have no idea what is going on.
>
>
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

Re: IGNITE-2558 PR is ready to review (NearCacheConfiguration should not extend MutableConfiguration)

[Valentin Kulichenko]

Maxim,

It looks like you added copyOnRead property on configuration, but I'm
pretty sure that currently it will be ignored. Basically, it's a new
feature and I'm OK if we do this as a separate task sometime later (e.g. in
2.1). Can you create a ticket and remove the property for now?

-Val

On Tue, Apr 4, 2017 at 3:04 AM, Kozlov Maxim  wrote:

> Hi igniters,
>
> Please review if someone has time.
> https://issues.apache.org/jira/browse/IGNITE-2558 <
> https://issues.apache.org/jira/browse/IGNITE-2558>
> https://github.com/apache/ignite/pull/1701  ignite/pull/1701>
>
> --
> Best Regards,
> Max K.
>
>
>
>
>

[GitHub] ignite pull request #1727: IGNITE-3487: _key and _val fields should be exclu...

[skalashnikov]

GitHub user skalashnikov opened a pull request:

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

IGNITE-3487: _key and _val fields should be excluded from 'select * from' 
queries



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

$ git pull https://github.com/gridgain/apache-ignite ignite-3487

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

https://github.com/apache/ignite/pull/1727.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 #1727


commit 3a10a319f54085b6f3b59a466ea9244b53eceac9
Author: Sergi Vladykin 
Date:   2017-03-09T13:16:27Z

ignite-1.9.1 - h2 version upgrade

commit 219e6285ac1ab761045df85b73296905cd07
Author: Sergi Vladykin 
Date:   2017-03-09T13:21:55Z

ignite-1.9.1 - h2 version upgrade - tests fix

commit 143a09461b352c82b02bdbb629d6aa8f90c0745a
Author: Sergi Vladykin 
Date:   2017-03-09T15:24:25Z

ignite-1.9.1 - sql index hints

commit 8946b312670b0721c3dc271c12933c80c41668ed
Author: skalashnikov 
Date:   2017-03-17T17:57:19Z

IGNITE-3487: Made _key and _val columns hidden

commit 10ba37183806712994ff193af886d9744da3edc1
Author: skalashnikov 
Date:   2017-03-20T09:25:39Z

IGNITE-3487: minor fixes

commit 603fe292b27ddc421d42eb9156f03b77dc1c5233
Author: skalashnikov 
Date:   2017-03-28T08:53:25Z

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

commit 7a42e62d7b013492a6b704bfb7bdd8440eb0d2da
Author: skalashnikov 
Date:   2017-03-28T10:10:59Z

Merge branch 'ignite-1.9.1-hints' of 
https://github.com/gridgain/apache-ignite into ignite-3487

commit ca16c40e6fcea231666ed22e27f20bc6b4aa4690
Author: skalashnikov 
Date:   2017-04-04T13:31:52Z

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




---
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 #1680: IGNITE-3487: Made _key and _val columns hidden

[skalashnikov]

Github user skalashnikov closed the pull request at:

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


---
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: Client got stucked on get operation

[Alper Tekinalp]

Hi.

Can someone point me a direction that why a thread can stuck on the trace
above? Where should I look for? How can I investicate the issue? Where
should I look?

On Mon, Mar 20, 2017 at 12:57 PM, Alper Tekinalp  wrote:

> Hi all.
>
>
> We have 3 ignite servers. Server 1 works as standalone. Server 2 and 3
> connects eachother as server but connects server 1 as client. In a point of
> the time server 3 got stucked at:
>
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.
> parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.
> doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
>   at java.util.concurrent.locks.AbstractQueuedSynchronizer.
> acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
>   at org.apache.ignite.internal.util.future.GridFutureAdapter.
> get0(GridFutureAdapter.java:161)
>   at org.apache.ignite.internal.util.future.GridFutureAdapter.
> get(GridFutureAdapter.java:119)
>   at org.apache.ignite.internal.processors.cache.distributed.
> dht.atomic.GridDhtAtomicCache.get0(GridDhtAtomicCache.java:488)
>   at org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(
> GridCacheAdapter.java:4665)
>   at org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(
> GridCacheAdapter.java:1388)
>   at org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(
> IgniteCacheProxy.java:1121)
>   at sun.reflect.GeneratedMethodAccessor634.invoke(Unknown Source)
>   at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at com.evam.cache.client.CachePassthroughInvocationHand
> ler.invokeInternal(CachePassthroughInvocationHandler.java:99)
>   at com.evam.cache.client.CachePassthroughInvocationHandler.invoke(
> CachePassthroughInvocationHandler.java:78)
>   at com.sun.proxy.$Proxy56.get(Unknown Source)
>
> when getting record from server 1. Long after that server 2 also got
> stucked at the same trace and also server 2 and server 3 disconnects from
> each other.
>
> We investigated gc logs and there is not an unusual behaviour. One things
> is server 1 logs errors as follows when server 2 and server 3 disconnects:
>
> [ERROR] 2017-03-18 22:01:21.881 [sys-stripe-82-#83%cache-server%] msg -
> Received message without registered handler (will ignore)
> [msg=GridNearSingleGetRequest [futId=1490866022968, key=BinaryObjectImpl
> [arr= true, ctx=false, start=0], partId=199, flags=1,
> topVer=AffinityTopologyVersion [topVer=33, minorTopVer=455],
> subjId=53293ebb-f01b-40b6-a060-bec4209e9c8a, taskNameHash=0, createTtl=0,
> accessTtl=-1], node=53293ebb-f01b-40b6-a060-bec4209e9c8a, 
> locTopVer=AffinityTopologyVersion
> [topVer=33, minorTopVer=2937], msgTopVer=AffinityTopologyVersion
> [topVer=33, minorTopVer=455], cacheDesc=null]
> Registered listeners:
>
>
> Where should we look for the main cause of the problem? What can cause
> such a behaviour? There seems nothing wrong on server 1 logs etc.
>
> We use ignite 1.8.3.
>
> --
> Alper Tekinalp
>
> Software Developer
> Evam Streaming Analytics
>
> Atatürk Mah. Turgut Özal Bulv.
> Gardenya 5 Plaza K:6 Ataşehir
> 34758 İSTANBUL
>
> Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
> www.evam.com.tr
> 
>



-- 
Alper Tekinalp

Software Developer
Evam Streaming Analytics

Atatürk Mah. Turgut Özal Bulv.
Gardenya 5 Plaza K:6 Ataşehir
34758 İSTANBUL

Tel:  +90 216 455 01 53 Fax: +90 216 455 01 54
www.evam.com.tr

[GitHub] ignite pull request #1726: IGNITE-3583: Replaced passing by value with passi...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-3583: Replaced passing by value with passing by reference



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

$ git pull https://github.com/gridgain/apache-ignite ignite-3583

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

https://github.com/apache/ignite/pull/1726.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 #1726


commit b6d1eecdb4aa6a4713e9e63dee0751e7b4515dbc
Author: Igor Sapego 
Date:   2017-04-04T12:18:49Z

IGNITE-3583: Replaced passing by value with passing by reference




---
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 #1725: Ignite 4667 Throw exception on starting client ca...

[dkarachentsev]

GitHub user dkarachentsev opened a pull request:

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

Ignite 4667 Throw exception on starting client cache when indexed types 
cannot be loaded



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

$ git pull https://github.com/gridgain/apache-ignite ignite-4667

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

https://github.com/apache/ignite/pull/1725.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 #1725


commit 9c6824b4f33fbdead64299d9e0c34365d5d4a570
Author: nikolay_tikhonov 
Date:   2016-11-24T13:27:05Z

IGNITE-3958 Fixed "Client node should not start rest processor".

commit 56998e704e9a67760c70481c10c56e72c0a866bb
Author: Konstantin Dudkov 
Date:   2016-10-28T13:27:34Z

ignite-4088 Added methods to create/destroy multiple caches. This closes 
#1174.

(cherry picked from commit f445e7b)

commit 3e2ccfd30427ba0552eea8667c0129ae5ace9c0b
Author: Igor Sapego 
Date:   2016-11-25T11:26:54Z

IGNITE-4299: Fixes for examples.

commit 6fbaef45af8f40062a95058df7ec0984c99035b9
Author: Konstantin Dudkov 
Date:   2016-11-25T10:58:58Z

IGNITE-4305 marshalling fix in GridNearAtomicSingleUpdateInvokeRequest

commit 1a2de51f5807a91ce0d5dff28f24ed5bf7abebbc
Author: Konstantin Dudkov 
Date:   2016-11-28T09:59:02Z

IGNITE-4305 marshalling fix

commit c06e4017771603df7118974758d3d6b9cadc41b5
Author: Eduard Shangareev 
Date:   2016-11-30T11:34:47Z

ignite-4332 Usage of cache.getEntry inside GridCacheQueryManager.runQuery 
causes to remote operations

commit 066691098797be8c01daa0e8dc2ba94d4ad73561
Author: sboikov 
Date:   2016-12-01T14:16:28Z

ignite-4344 Do not create offheap map on client nodes.

commit e9ace7730773a6d4a1d30b271854f1fe8a7ba632
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:06:41Z

Improved exception handling.

commit 12bdd6a031a33eda004a66e73cee9628f073ed68
Author: Alexey Kuznetsov 
Date:   2016-12-02T09:09:29Z

Updated classnames.properties for running nodes in IDE.

commit 33dda46061aae73e5c138851cfdd5f49a1c254cb
Author: sboikov 
Date:   2016-12-02T09:13:38Z

ignite-4285 For serializable txs allow multiple threads to get read lock 
for the same key

commit cc13d9d155f70e22e08ef203ac64e5cc0aa0a50f
Author: dkarachentsev 
Date:   2016-11-28T08:30:14Z

IGNITE-4026: Fixed BinaryObjectBuilder.build() can fail if one of the 
fields is Externalizable, enum from binary object. This closes #1281. This 
closes #1289.

(cherry picked from commit 0b7c62d)

commit b4aedfd5350b4a318f1608596a171789513835a4
Author: Igor Sapego 
Date:   2016-12-02T17:10:09Z

IGNITE-4347: Fixed NPE.

commit acf20b32d8fb68e42b904b091fb2b943f4558cef
Author: sboikov 
Date:   2016-12-05T11:01:28Z

ignite-4296 Optimize GridDhtPartitionsSingleMessage processing
- optimized processing of GridDhtPartitionsSingleMessage
- minor optimizations for RendezvousAffinityFunction
 - fixed heartbeats sending in tcp discovery

commit 6ba1711a1fa10d8276974227491136070c3ed43a
Author: Anton Vinogradov 
Date:   2016-12-06T09:55:41Z

IGNITE-4242 ExchangeManager should wait for cache rebalancing in async way

commit 3df412e7f25aac8227b68cffe1577593a05d1431
Author: sboikov 
Date:   2016-12-07T09:25:32Z

ignite-2545 Optimization for GridCompoundFuture's futures iteration

commit f3db74f782c68c7f73ef3ef4390e010976493634
Author: Anton Vinogradov 
Date:   2016-12-07T10:15:37Z

IGNITE-4238: Added geospatial queries example (nolgpl examples hotfix)

commit 0d4a1b7381fece47ee480f3a06bff7c51a7fead4
Author: Alexey Kuznetsov 
Date:   2016-12-07T11:02:49Z

Improved exception handling for failed queries.

commit 56efb10c40fd4481d6a9dc00928e7beee1f164c5
Author: Anton Vinogradov 
Date:   2016-12-07T11:25:53Z

IGNITE-4353 Parent Cassandra module deployed on maven repository (hotfix: 
deploy to custom maven repository)

commit ac8602dbdf2bbf5b16a611eaf6d520a0a7b0010b
Author: Sergi Vladykin 
Date:   2016-08-15T13:46:54Z

ignite-3685 - fixed

commit bbaa79af8ef526b5d2684db0e3d71d60a8f1ebe7
Author: agura 
Date:   2016-12-07T16:36:11Z

IGNITE-3770 GridLogThrottle.warn ignores the exception

commit 18598574bb2992aa193eed1d72ca333a1e21ad72
Author: Andrey V. Mashenkov 
Date:   2016-12-08T09:36:07Z

GG-11746: Backport of IGNITE-4379:  Fixed broken local SqlFieldsQuery.

commit 671a77a2d81cac401765dddf25f30fba4e4ab17f
Author: sboikov 

Re: TC should fail on AssertionError in logs

[Anton Vinogradov]

Additional task created (https://issues.apache.org/jira/browse/IGNITE-4909)

On Mon, Apr 3, 2017 at 7:47 PM, Yakov Zhdanov  wrote:

> Change this to RuntimeException. I think it would be fine. Assertion in
> logs should mean something terrible from now and on.
>
> --Yakov
>

[jira] [Created] (IGNITE-4909) Get Rid of AssertionError as a positive warnings

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-4909:


 Summary: Get Rid of AssertionError as a positive warnings
 Key: IGNITE-4909
 URL: https://issues.apache.org/jira/browse/IGNITE-4909
 Project: Ignite
  Issue Type: Task
Reporter: Anton Vinogradov


I found that some tests can cause AssertionError even in case everything is ok.

Examples:
1) [INFO ]test-runner-#4966%future.GridEmbeddedFutureSelfTest%[root] Failed 
with unhandled error (normal behaviour): java.lang.AssertionError: Test 
assertion (should be ignored).
2) [INFO ]test-runner-#4883%lang.GridByteArrayListSelfTest%[root] Caught 
expected error: java.lang.AssertionError



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: one point optimisation

[ALEKSEY KUZNETSOV]

any thoughts on one phase commit realization ?

пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV :

> I've attached test that prints messages exchange . Which shows us that
> there are more messages then you declared in article. Perhaps,
> implementation has changed.
> I created it on base of IgniteOnePhaseCommitNearSelfTest
>
> пн, 3 апр. 2017 г. в 19:03, Dmitriy Setrakyan :
>
> Aleksey,
>
> The blog describes the 1-phase commit at a high level, but I am still
> curious about the differences you found. Can you share them here?
>
> D.
>
> On Mon, Apr 3, 2017 at 2:11 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> wrote:
>
> > Regarding IgniteOnePhaseCommitNearSelfTest test , ignite's one phase
> > optimisation works not as you said.
> > I attached picture of message exchange. There are partial prepare phase
> > exists, along with finish phase.
> >
> >
> >
> > пн, 3 апр. 2017 г. в 10:55, Christos Erotocritou  >:
> >
> >> As far as I know a partition is always allocated to a specific node and
> >> does not span nodes. Ignite has default 1024 partitions on start that
> are
> >> split equally across nodes.
> >>
> >> > On 3 Apr 2017, at 08:10, ALEKSEY KUZNETSOV 
> >> wrote:
> >> >
> >> > in ur blog u texted belonging to the same partition is nessesary for 1
> >> > phase commit. But its not guarantee belonging to the same node.
> >> Partition
> >> > may span many nodes
> >> >
> >> > вс, 2 Апр 2017 г., 13:46 ALEKSEY KUZNETSOV  >:
> >> >
> >> >> thank u !
> >> >>
> >> >> пт, 31 Мар 2017 г., 21:06 Denis Magda :
> >> >>
> >> >> Here is a good blog post about 1phase commit impl in Ignite and its
> >> >> advantages:
> >> >>
> >> >> http://gridgain.blogspot.com/2014/09/one-phase-commit-fast-
> >> transactions-for.html
> >> >> <
> >> >> http://gridgain.blogspot.com/2014/09/one-phase-commit-fast-
> >> transactions-for.html
> >> >>>
> >> >>
> >> >> Took a reference to it from there:
> >> >>
> >> >> https://apacheignite.readme.io/docs/transactions#section-
> >> two-phase-commit-2pc
> >> >> <
> >> >> https://apacheignite.readme.io/docs/transactions#section-
> >> two-phase-commit-2pc
> >> >>>
> >> >>
> >> >> —
> >> >> Denis
> >> >>
> >> >>> On Mar 31, 2017, at 12:27 PM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >> >> wrote:
> >> >>>
> >> >>> On Fri, Mar 31, 2017 at 9:25 AM, ALEKSEY KUZNETSOV <
> >> >> alkuznetsov...@gmail.com
> >>  wrote:
> >> >>>
> >>  Igniters! What is the point of one phase optimisation?
> >> 
> >> >>>
> >> >>> Performance
> >> >>
> >> >> --
> >> >>
> >> >> *Best Regards,*
> >> >>
> >> >> *Kuznetsov Aleksey*
> >> >>
> >> > --
> >> >
> >> > *Best Regards,*
> >> >
> >> > *Kuznetsov Aleksey*
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: IgniteSemaphore and failoverSafe flag

[Dmitry Karachentsev]

Hi Vladislav,

I see you're developing [1] for a while, did you have any chance to fix 
it? If no, is there any estimate?


[1] https://issues.apache.org/jira/browse/IGNITE-1977

Thanks!

-Dmitry.



20.03.2017 10:28, Alexey Goncharuk пишет:

I think re-creation should be handled by a user who will make sure that
nobody else is currently executing the guarded logic before the
re-creation. This is exactly the same semantics as with
BrokenBarrierException for j.u.c.CyclicBarrier.

2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic :


Hi everyone,

I agree with Val, he's got a point; recreating the lock doesn't seem
possible
(at least not the with the transactional cache lock/semaphore we have).
Is this re-create behavior really needed?

Best regards,
Vladisav



On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:


Guys,

How does recreation of the lock helps? My understanding is that scenario

is

the following:

1. Client A creates and acquires a lock, and then starts to execute

guarded

logic.
2. Client B tries to acquire the same lock and parks to wait.
3. Before client A unlocks, all affinity nodes for the lock fail, lock
disappears from the cache.
4. Client B fails with exception, recreates the lock, acquires it, and
starts to execute guarded logic concurrently with client A.

In my view this is wrong anyway, regardless of whether this happens
silently or with an exception handled in user's code. Because this code
doesn't have any way to know if client A still holds the lock or not.

Am I missing something?

-Val

On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <

dsetrak...@apache.org

wrote:


On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:


Which user operation would result in exception? To my knowledge,

user

may

already be holding the lock and not invoking any Ignite APIs, no?


Yes, this is exactly my point.

Imagine that a node already holds a lock and another node is waiting

for

the lock. If all partition nodes leave the grid and the lock is

re-created,

this second node will immediately acquire the lock and we will have

two

lock owners. I think in this case this second node (blocked on

lock())

should get an exception saying that the lock was lost (which is, by

the

way, the current behavior), and the first node should get an

exception

on

unlock.


Makes sense.

[GitHub] ignite pull request #1710: Ignite 4477 Fix IgniteFuture.listen() and IgniteF...

[dkarachentsev]

Github user dkarachentsev closed the pull request at:

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


---
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 #1716: IGNITE-4625 .NET: MixedClusterTest leaves Java-on...

[ptupitsyn]

Github user ptupitsyn closed the pull request at:

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


---
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: ignite-3592 is ready fo review (Provide some kind of pluggable compression SPI support)

[Vyacheslav Daradur]

Guys, any thoughts?

I'm ready to improve quickly the solution according to yours notes to
include this in the Ignite-2.0.

2017-03-31 12:30 GMT+03:00 Vyacheslav Daradur :

> Hello everyone.
>
> I have prepared the raw evaluation (marshaller layer) of compression.
> (GZIP implementation)
> https://github.com/daradurvs/ignite-compression/tree/
> master/src/main/resources/result
>
> In plans for evaluation:
> 1. Deflater compressor implementation;
> 2. Snappy compressor implementation;
> 3. CPU load estimation with JMH;
> 4. Tests with different data.
>
>
>
>
> 2017-03-30 7:13 GMT+03:00 Denis Magda :
>
>> Sergi, Vovan,
>>
>> As SQL and binary marshaller maintainers could you plan to review the
>> contribution?
>>
>> —
>> Denis
>>
>> > On Mar 29, 2017, at 4:44 PM, Vyacheslav Daradur 
>> wrote:
>> >
>> >> At which point does this step take place? Do we deserialize right when
>> we
>> >> receive the object over the wire?
>> > When put it in cache, after marshalling.
>> > Covered by properly configured existing tests. [1][2][3]
>> >
>> >
>> >> Forgive me if I don't know the internals, but does this happen when SQL
>> >> queries are executed?
>> > Yes. Covered by tests[4]
>> >
>> > [1]
>> > https://github.com/apache/ignite/pull/1650/files#diff-af9e29
>> 60a6c9f73fa56a5b3824b6b397
>> > [2]
>> > https://github.com/apache/ignite/pull/1650/files#diff-ed2aa7
>> d56ed004ae9bc975edc9b8a9c2
>> > ]3]
>> > https://github.com/apache/ignite/pull/1650/files#diff-a4b76c
>> 24a5f9bc9e78d7cff0a7645328
>> > [4]
>> > https://github.com/apache/ignite/pull/1650/files#diff-c19a9d
>> f4058141d059bb577e75244764
>> >
>> > 2017-03-29 23:16 GMT+03:00 Dmitriy Setrakyan :
>> >
>> >> On Wed, Mar 29, 2017 at 11:57 AM, Vyacheslav Daradur <
>> daradu...@gmail.com>
>> >> wrote:
>> >>
>> >>> Queries works with BinaryObjectImpl.
>> >>>
>> >>> 1. In the full compression mode - compressed bytes sequence - will be
>> >>> decompressed at initialization of BinaryObjectImpl.
>> >>>
>> >>
>> >> At which point does this step take place? Do we deserialize right when
>> we
>> >> receive the object over the wire?
>> >>
>> >>
>> >>> 2. With annotated fields compression - value of compressed fields
>> will be
>> >>> decompress at deserializing on demand, for example when calls methods
>> >>> BinaryObjectImpl#field and BinaryObjectImpl#fieldByOrder
>> >>>
>> >>
>> >> Forgive me if I don't know the internals, but does this happen when SQL
>> >> queries are executed?
>> >>
>> >>
>> >>>
>> >>> 2017-03-29 21:47 GMT+03:00 Dmitriy Setrakyan :
>> >>>
>>  On Wed, Mar 29, 2017 at 11:44 AM, Vyacheslav Daradur <
>> >>> daradu...@gmail.com>
>>  wrote:
>> 
>> > Solution implemented in core-level and works with binary-marshaller.
>> >
>> > If you about the cache queries - it works with compressed data.
>> >
>> 
>>  Vyacheslav, can you please explain how the cache queries work with
>> the
>>  compressed data?
>> 
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Best Regards, Vyacheslav
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Best Regards, Vyacheslav
>>
>>
>
>
> --
> Best Regards, Vyacheslav
>



-- 
Best Regards, Vyacheslav