[jira] [Created] (IGNITE-5492) Local cache metrcis is broken

2017-06-14 Thread Alexey Kuznetsov (JIRA)
Alexey Kuznetsov created IGNITE-5492:


 Summary: Local cache metrcis is broken
 Key: IGNITE-5492
 URL: https://issues.apache.org/jira/browse/IGNITE-5492
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Alexey Kuznetsov
 Fix For: 2.1


Reproducer:
IgniteConfiguration cfg = new IgniteConfiguration();
Ignite ignite = Ignition.start(cfg);

CacheConfiguration locCacheCfg = new 
CacheConfiguration<>("local");
locCacheCfg.setCacheMode(CacheMode.LOCAL);
locCacheCfg.setStatisticsEnabled(true);

IgniteCache locCache = ignite.getOrCreateCache(locCacheCfg);

assert(locCache.get("ZZZ") == null)
assert(locCache.localMetrics().getCacheMisses == 1)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


Re: Apache Ignite Persistent Store Description

2017-06-14 Thread Denis Magda
That’s right and this is what I tried to convert in this segment "distributed 
transactional SQL database, both in memory and on disk”.

Overall, this is a fixed version (the previous one was copy-pasted from my 
drafts I prepared before the donation):

=
Persistent store is a distributed ACID and SQL-compliant disk store that 
transparently integrates with Ignite as an optional disk layer (SSD, Flash, 3D 
XPoint). Having the store enabled, you no longer need to keep all the data in 
memory or warm RAM up after the whole cluster restart. The persistent store 
will keep the superset of data and all the SQL indexes on disk making Ignite 
fully operational from disk.
 
Relying on this new feature and on advanced SQL capabilities which existed 
before, Ignite can serve as a distributed transactional SQL database, both in 
memory and on disk, while continuing to support all the existing use cases, 
including the in-memory data grid.
=

—
Denis

> On Jun 14, 2017, at 5:55 PM, Alexey Kuznetsov  wrote:
> 
> I think this feature gives a kind of durability out of the box.
> Your data will survive full cluster restart with this store and for that
> you will only need add some lines to node config - and that's all.
> 
> For example, I'm putting  into cache messages that should be send to remote
> system and that system not always available.
> And my cluster also could be down for some reasons.
> With store I simply starts timer and on every 5 seconds check my cache for
> messages and send them to remote system.
> If cluster restarted - all my messages will be in cache and will be
> processed somewhen.
> 
> On Thu, Jun 15, 2017 at 7:15 AM, Denis Magda  wrote:
> 
>> Igniters,
>> 
>> While we’re getting to know the store that has been donated recently let’s
>> discuss how we can position this feature and how Ignite can be used once
>> it’s enabled.
>> 
>> Here are my thoughts around this:
>> 
>> 
>> Persistent store is a distributed ACID and ANSI-99 SQL compliant disk
>> store that transparently integrates with GridGain as an optional disk layer
>> (SSD, Flash, 3D XPoint). Having the store enabled, you are no longer need
>> to keep all the data in memory or warm RAM up after the whole cluster
>> restart. The persistent store will keep the superset of data and all the
>> SQL indexes on disk making GridGain fully operational from disk.
>> 
>> Relying on this new feature and on advanced SQL capabilities existed
>> before, GridGain can server as a distributed transactional SQL database,
>> both in memory and on disk, while continuing to support all the existing
>> use cases, including the in-memory data grid.
>> ——
>> 
>> Any thoughts, suggestions?
>> 
>> —
>> Denis
> 
> 
> 
> 
> -- 
> Alexey Kuznetsov



Re: Apache Ignite Persistent Store Description

2017-06-14 Thread Alexey Kuznetsov
I think this feature gives a kind of durability out of the box.
Your data will survive full cluster restart with this store and for that
you will only need add some lines to node config - and that's all.

For example, I'm putting  into cache messages that should be send to remote
system and that system not always available.
And my cluster also could be down for some reasons.
With store I simply starts timer and on every 5 seconds check my cache for
messages and send them to remote system.
If cluster restarted - all my messages will be in cache and will be
processed somewhen.

On Thu, Jun 15, 2017 at 7:15 AM, Denis Magda  wrote:

> Igniters,
>
> While we’re getting to know the store that has been donated recently let’s
> discuss how we can position this feature and how Ignite can be used once
> it’s enabled.
>
> Here are my thoughts around this:
>
> 
> Persistent store is a distributed ACID and ANSI-99 SQL compliant disk
> store that transparently integrates with GridGain as an optional disk layer
> (SSD, Flash, 3D XPoint). Having the store enabled, you are no longer need
> to keep all the data in memory or warm RAM up after the whole cluster
> restart. The persistent store will keep the superset of data and all the
> SQL indexes on disk making GridGain fully operational from disk.
>
> Relying on this new feature and on advanced SQL capabilities existed
> before, GridGain can server as a distributed transactional SQL database,
> both in memory and on disk, while continuing to support all the existing
> use cases, including the in-memory data grid.
> ——
>
> Any thoughts, suggestions?
>
> —
> Denis




-- 
Alexey Kuznetsov


[GitHub] ignite pull request #2098: IGNITE-5229: Specify caches when using Redis prot...

2017-06-14 Thread asfgit
Github user asfgit closed the pull request at:

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


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


Apache Ignite Persistent Store Description

2017-06-14 Thread Denis Magda
Igniters,

While we’re getting to know the store that has been donated recently let’s 
discuss how we can position this feature and how Ignite can be used once it’s 
enabled.

Here are my thoughts around this:


Persistent store is a distributed ACID and ANSI-99 SQL compliant disk store 
that transparently integrates with GridGain as an optional disk layer (SSD, 
Flash, 3D XPoint). Having the store enabled, you are no longer need to keep all 
the data in memory or warm RAM up after the whole cluster restart. The 
persistent store will keep the superset of data and all the SQL indexes on disk 
making GridGain fully operational from disk.

Relying on this new feature and on advanced SQL capabilities existed before, 
GridGain can server as a distributed transactional SQL database, both in memory 
and on disk, while continuing to support all the existing use cases, including 
the in-memory data grid.
——

Any thoughts, suggestions?

—
Denis

[jira] [Created] (IGNITE-5491) .NET: PersistentMetrics

2017-06-14 Thread Pavel Tupitsyn (JIRA)
Pavel Tupitsyn created IGNITE-5491:
--

 Summary: .NET: PersistentMetrics
 Key: IGNITE-5491
 URL: https://issues.apache.org/jira/browse/IGNITE-5491
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.1
Reporter: Pavel Tupitsyn
 Fix For: 2.1


* Add {{PersistentStoreConfiguration.EnableMetrics}} property
* Add {{PersistenceMetrics}} class

Currently in Java there is only internal API to get them - 
{{IgniteCacheDatabaseSharedManager#persistentStoreMetrics()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (IGNITE-5490) Implement replacement for obsolete CacheMetrics#getOffHeapAllocatedSize

2017-06-14 Thread Ivan Rakov (JIRA)
Ivan Rakov created IGNITE-5490:
--

 Summary: Implement replacement for obsolete 
CacheMetrics#getOffHeapAllocatedSize
 Key: IGNITE-5490
 URL: https://issues.apache.org/jira/browse/IGNITE-5490
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.0
Reporter: Ivan Rakov


With 2.0 new architecture, many caches can share one memory policy. Memory 
metrics allows to measure memory usage (loaded pages) for the whole policy. 
However, there's also a need to measure how much memory (or pages) is used by 
each cache.
Before 2.0 such information was accessible with 
CacheMetrics#getOffHeapAllocatedSize, but current implemetation returns 0.
We should either implement it or provide alternative metrics (e. g. approximate 
number of loaded pages per cache). Please note that precise number of loaded 
pages per cache is not defined - one page can contain entries of differet 
caches.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] ignite pull request #2113: IGNITE-5458

2017-06-14 Thread devozerov
Github user devozerov closed the pull request at:

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


---
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 #2125: IGNITE-5458-2.1.1

2017-06-14 Thread devozerov
Github user devozerov closed the pull request at:

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


---
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-4636 .NET: Support local collection joins in LINQ ready for review

2017-06-14 Thread Pavel Tupitsyn
Changes have been reviewed and merged, thank you for another great
contribution!

Pavel

On Tue, Jun 13, 2017 at 1:30 PM, Pavel Tupitsyn 
wrote:

> Hi, I'll have a look and reply in JIRA.
>
> On Tue, Jun 13, 2017 at 10:34 AM, Guru Stron 
> wrote:
>
>> Hi guys,
>>
>> Can anyone please review?
>>
>> Pull request:
>> https://github.com/apache/ignite/pull/2118
>>
>> Also i've scheduled some build jobs:
>>
>> http://ci.ignite.apache.org/viewQueued.html?itemId=659286
>> b=queuedBuildOverviewTab
>> http://ci.ignite.apache.org/viewQueued.html?itemId=659287
>> b=queuedBuildOverviewTab
>>
>
>


[GitHub] ignite pull request #2118: IGNITE-4636 .NET Support local collection joins i...

2017-06-14 Thread asfgit
Github user asfgit closed the pull request at:

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


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


[jira] [Created] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

2017-06-14 Thread Nikolay Tikhonov (JIRA)
Nikolay Tikhonov created IGNITE-5489:


 Summary: Possible connection leaks when loadPreviousValue set to 
true
 Key: IGNITE-5489
 URL: https://issues.apache.org/jira/browse/IGNITE-5489
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Nikolay Tikhonov


When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
connections to DB.
See attached test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] ignite pull request #2130: IGNITE-5267 Ignite 2.1.1 - Partitions map exchang...

2017-06-14 Thread Jokser
GitHub user Jokser opened a pull request:

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

IGNITE-5267 Ignite 2.1.1 - Partitions map exchange fix

Testing fixes for partitionsMapExchange

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

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

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

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


commit c540206e8350a5625c854a38791b0d094a996d55
Author: EdShangGG 
Date:   2017-04-06T12:43:26Z

Merge remote-tracking branch 'origin/ignite-gg-8.0.3.ea4' into GG-11860-2

commit f2c9d6cd0f22974aa4e1db99cd519a954b18dd4c
Author: Ilya Lantukh 
Date:   2017-04-10T16:00:02Z

Moved updatePartitionSingleMap(...) outside of synchronized block.

commit ead06b06f4b164998bfc5853dfa28cac4b618d8d
Author: Aleksei Scherbakov 
Date:   2017-04-10T16:46:18Z

IGNITE-4920 Fixed.

commit 9ad0883c66120940740bc1944bd1e17814f9d540
Author: Aleksei Scherbakov 
Date:   2017-04-10T16:58:09Z

IGNITE-4920 Fixed.

commit a3ad6e04c163718306044573be7b30fe636ad193
Author: Aleksei Scherbakov 
Date:   2017-04-12T13:07:33Z

IGNITE-4920 Uppercase system prop.

commit ea02f6a025994a7f0567ac1959ff03cf1cb9d982
Author: EdShangGG 
Date:   2017-04-13T14:59:56Z

GG-12064 Need to have an ability to cancel snapshot operations
-fixing issues with client nodes

commit 4b8dc799fcd0173576e7e3439d5c7e88531fd1b7
Author: EdShangGG 
Date:   2017-04-14T10:26:34Z

GG-12064 Need to have an ability to cancel snapshot operations
-fixing issues with multiple exchange future completion

commit 0db2c2037117cf377915768c9bcf97b9d33ee3dd
Author: Alexey Goncharuk 
Date:   2017-04-17T06:41:02Z

Merge branch 'ignite-gg-8.0.3.ea5' of 
https://github.com/gridgain/apache-ignite into ignite-gg-8.0.4.ea1

commit 9f2ff8f99daec2c313e086a734ab61af4bf2b994
Author: Alexey Goncharuk 
Date:   2017-04-17T11:31:29Z

Merge branch master  into ignite-gg-8.0.4.ea1

commit 0a3830ae004e0bcbd6512604fc1008602b78a034
Author: Alexey Goncharuk 
Date:   2017-04-17T11:31:59Z

Fixing compilation after merge

commit 346373a75387ea0e1c07bb7a5824c7910faf78e6
Author: EdShangGG 
Date:   2017-04-17T15:32:21Z

GG-12064 Need to have an ability to cancel snapshot operations
-cancel for RESTORE

commit 633db6f1b011450f5e926375c24d1ac2fa5e1dd7
Author: EdShangGG 
Date:   2017-04-18T14:30:59Z

GG-12064 Need to have an ability to cancel snapshot operations
-added handling start on broken restore

commit 7eccf755659b52e35755e5fc3e51736c72aaa0e7
Author: Ivan Rakov 
Date:   2017-04-18T15:20:56Z

Merge branch 'master' into ignite-gg-8.0.4.ea1

commit 51c18a27347239479117311ef9ec6f6ffaffdb92
Author: Alexey Goncharuk 
Date:   2017-04-18T15:29:47Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-gg-8.0.4.ea1

commit eff4201ab5ccfa4cfe874d300a975e6a53f94ba1
Author: Ivan Rakov 
Date:   2017-04-18T15:49:11Z

Fixing compilation after merge

commit 7808492b7dee12bdd0c3922e1760ffa364183bc2
Author: Alexey Kuznetsov 
Date:   2017-04-18T16:52:30Z

8.0.4.ea1 Fixed snapshot utility tests.

commit c812cc843e3fdfbc17a99920247320af997b3aa4
Author: Eduard Shangareev 
Date:   2017-04-19T10:30:15Z

GG-12118 Stabilize tests in 8.0.4.ea1 after master merge
-fixing NPE in exchange future

commit 553288b11d9d6ed2f8cd9c612399944533d64988
Author: Ivan Rakov 
Date:   2017-04-19T10:36:42Z

GG-12118: Page counter increment fix

commit 40bbc5d12b20c3ebf3e4c9dba0675c080a811d3c
Author: Alexey Goncharuk 
Date:   2017-04-19T15:15:36Z

Merge ignite-2.0 into ignite-gg-8.0.4.ea1

commit be8b260bd90e951c84ccbbb733e89fcd6c758279
Author: Ivan Rakov 
Date:   2017-04-19T16:00:17Z

IGNITE-4861: Export rebalance metrics and state as MBeans

commit 58995f668a172f3acdb2bd6386dc5390f0dca9a2
Author: Alexey Kuznetsov 
Date:   2017-04-19T16:27:27Z

8.0.4.ea1 Fixed compilation.

commit d8c6ffafa0923544dbb9814c2ea0cbbddde7a5d0
Author: EdShangGG 
Date:   2017-04-19T16:24:36Z

GG-12118 Stabilize tests in 8.0.4.ea1 after master merge
-fixing issued with message ids

commit 097b4f67e48e31b61ffa5c1220d7ada8b51f4516
Author: Ivan Rakov 

[jira] [Created] (IGNITE-5487) JettyRestProcessorAbstractSelfTest may hang up

2017-06-14 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-5487:
--

 Summary: JettyRestProcessorAbstractSelfTest may hang up
 Key: IGNITE-5487
 URL: https://issues.apache.org/jira/browse/IGNITE-5487
 Project: Ignite
  Issue Type: Task
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


3 tests in client test: 
org.apache.ignite.internal.processors.rest.JettyRestProcessorAbstractSelfTest
- testDecrement
- testIncrement
- testExe

may hang up without any response.
 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] ignite pull request #2129: IGNITE-5267 Fixed partitions map exchanges & test...

2017-06-14 Thread Jokser
GitHub user Jokser opened a pull request:

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

IGNITE-5267 Fixed partitions map exchanges & tests



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-5267-fix-tests-clean

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

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


commit 66557c8b6d6dbfa09bb559b6ab281ce84ee78d3c
Author: Alexey Goncharuk 
Date:   2017-02-03T09:22:24Z

GG-11940 - Do not evict non-user cache entries

commit e22d01abbe3c7275770b5447743f46ee30b25e28
Author: Alexey Goncharuk 
Date:   2017-02-03T10:58:05Z

Merge branch ignite-db-x into ignite-gg-8.0.3.ea1

commit 2280467e86bdba00f9bad438c6d7113bc3a37a12
Author: Alexey Goncharuk 
Date:   2017-02-03T10:59:22Z

Merge branch 'ignite-db-x' of https://github.com/gridgain/apache-ignite 
into ignite-gg-8.0.3.ea1

commit 5c33c292f1ed4c9c8298512a0f3e26daf2308d2e
Author: Alexey Goncharuk 
Date:   2017-02-03T11:03:57Z

Fixing compilation after merge.

commit 5967c6d08b4dc978c543df3295b08790440542a6
Author: Aleksei Scherbakov 
Date:   2017-02-06T15:00:47Z

GG-11946 Fixed.

commit b1fb8ff108c49ef5f809bad8dc7cd54c7e088be1
Author: EdShangGG 
Date:   2017-02-06T17:25:47Z

GG-11575 'bin' folder contains a service folders from 'database' system

commit 993f1f62695822bb4b71c5f86f42c5de866b21ce
Author: EdShangGG 
Date:   2017-02-06T17:39:28Z

GG-11947 Incorrect checkpoint lock usage

commit 159d5f4683a3e131f6d3599b4ecc3bba5639213d
Author: EdShangGG 
Date:   2017-02-06T18:07:21Z

GG-11948 All page updates should be done under checkpoint lock

commit 5544978df00a131bae5f52d6c5e335c43a9ffb74
Author: sboikov 
Date:   2017-02-07T11:19:16Z

ignite-4552 Use for rmvQueue ConcurrentLinkedDeque instead of 
GridCircularBuffer to reduce memory usage.
This closes #1465.

(cherry picked from commit e6ea938)

commit 754bd7b8a37f7afd3312fc9e9d4d4c7d726387c0
Author: Alexey Goncharuk 
Date:   2017-02-07T16:19:10Z

GG-11937 - Fixed checkpoint read lock release on exception

commit a65d4a70743685fcacb482ebffe0adb026332a75
Author: Alexey Goncharuk 
Date:   2017-02-08T09:36:39Z

IGNITE-3477 - Code formatting.

commit 9a8746e1ae9e599e6b7fa3d376d7f8fc1a4e8b92
Author: Alexey Goncharuk 
Date:   2017-02-02T16:54:30Z

GG-11878 - Snapshots ignore node filter

commit 7122256c87ce74e7942fa083138dd3a4d5e0f976
Author: Alexey Goncharuk 
Date:   2017-02-07T16:19:10Z

GG-11937 - Fixed checkpoint read lock release on exception

commit fe63e0ea349cdaab02e919d40f8f3df6a5e5cf00
Author: Alexey Goncharuk 
Date:   2017-02-08T15:15:17Z

GG-11954 - Fixing tests

commit f092fbf2a0b8d727827a080078f9892d24e2b4ae
Author: Dmitriy Govorukhin 
Date:   2017-02-08T15:51:53Z

ignite-gg-11952 fix issue.

commit fe0cff39445f1d8e3eea1241c51750c888114121
Author: Dmitriy Govorukhin 
Date:   2017-02-09T10:47:55Z

ignite-gg-8.0.2.ea4 licence header fix.

commit 839c598988ba7710c168d6c9e48378d912177010
Author: Alexey Kuznetsov 
Date:   2017-02-09T09:44:41Z

IGNITE-4676 Fixed hang if closure executed nested internal task with 
continuation. Added test.
(cherry picked from commit e7a5307)

commit 3889b2b798f680a81c8cca114798a7516c8e3ba1
Author: Alexey Kuznetsov 
Date:   2017-02-09T10:49:33Z

Merge remote-tracking branch 'community/ignite-gg-8.0.2.ea4' into 
ignite-gg-8.0.2.ea4

commit c286f9625287d99f107edbb0ad13e31c9f7de4f4
Author: Eduard Shangareev 
Date:   2017-02-12T15:36:54Z

Fixing deletion tests

commit 7c58bf5a4a83790f00344ccace3e2ee6b53f817b
Author: Alexey Goncharuk 
Date:   2017-02-13T10:35:03Z

IGNITE-3477 - Merge optimizations

commit adf223eb280d4ce5320d9e8923be5a8e5802a268
Author: Alexey Goncharuk 
Date:   2017-02-13T11:10:39Z

Use maskNull for stopAllCaches request

commit e4e58df698950c699170f1bd17c57e67026eda20
Author: Aleksei Scherbakov 
Date:   2017-02-13T11:19:27Z

IGNITE-4664 - Added lifecycle and injection support for TopologyValidator. 
Fixes #1514

commit d3601c41ea630e221fd6c1a29e3cb5a35bd0c472
Author: Alexey Goncharuk 
Date:   2017-02-13T11:21:47Z

Merge branch 

Re: Transaction Deadlock Detection exception is not wrapped by the timeout exception

2017-06-14 Thread Denis Magda
Andrey,

> On Jun 14, 2017, at 3:11 AM, Andrey Gura  wrote:
> 
> Guys,
> 
> first of all I should notice that thre is difference between eception
> handling in pessimistic and optimistic transaction, because in
> optimistic txs we can't throw CacheException on tx.commit() call.
> 

How do we use the detection with this transactions then? There is no special 
documentation section about this.

> The second, I'm surprised why TransactionTimeoutException is replaced
> by IgniteCheckedException? I still see converter for
> IgniteTxTimeoutCheckedException that eventually throws
> TransactionTimeoutException with TransactionDeadlockException as
> cause.
> 
See the provided example that shows this is no longer true:
https://github.com/dmagda/ignite_transactions/blob/master/src/main/java/org/apache/ignite/examples/DeadlockDetectionExample.java
 


In the example I have to use IgniteCheckedException instead on 
TransactionTimeoutException because otherwise the whole exception will be 
swallowed.
> 
> 
> On Wed, Jun 14, 2017 at 3:11 AM, Dmitriy Setrakyan
>  wrote:
>> On Tue, Jun 13, 2017 at 5:06 PM, Denis Magda  wrote:
>> 
>>> e.getCause() might return ‘null’ and you’ll get NullPointerException
>>> trying to execute e.getCause().getCause().
>>> 
>>> Ideally, we need to throw TransactionDeadlockException like it’s done in
>>> .NET.
>>> 
>> 
>> Agree, looks odd, but because of JSR107 we cannot throw any additional type
>> of exception.
>> 
>> Can we simplify by having one getCause() instead of double
>> getCause().getCause()?
>> 
>> 
>>> —
>>> Denis
>>> 
 On Jun 13, 2017, at 4:43 PM, Dmitriy Setrakyan 
>>> wrote:
 
 This looks a bit confusing. Why is it not enough to have this check:
 
 e.getCause().getCause() instanceof TransactionDeadlockException
 
 ?
 
 On Tue, Jun 13, 2017 at 4:40 PM, Denis Magda  wrote:
 
> Pardon me, copy pasted the catch block twice. This how the block looked
> like in Ignite 1.x
> 
> catch (CacheException e) {
>   if (e.getCause() instanceof TransactionTimeoutException &&
>   e.getCause().getCause() instanceof TransactionDeadlockException)
> 
>   System.out.println(e.getCause().getCause().getMessage());
> }
> 
> and this is how it must be coded in 2.0:
> 
>> catch (CacheException e) {
>>  if (e.getCause() instanceof IgniteCheckedException &&
>>  e.getCause().getCause() instanceof TransactionDeadlockException)
>> 
>>  System.out.println(e.getCause().getCause().getMessage());
>> }
> 
> 
> 
> —
> Denis
> 
>> On Jun 13, 2017, at 4:24 PM, Denis Magda  wrote:
>> 
>> Andrey Gura, Igniters,
>> 
>> If to refer to our documentation [1], this is how we need to catch the
> deadlock detection exception:
>> 
>> catch (CacheException e) {
>>  if (e.getCause() instanceof IgniteCheckedException &&
>>  e.getCause().getCause() instanceof TransactionDeadlockException)
>> 
>>  System.out.println(e.getCause().getCause().getMessage());
>> }
>> 
>> However, this is no longer works in Ignite 2.0 because
> IgniteCheckedException has to be used instead of
> TransactionTimeoutException:
>> 
>> catch (CacheException e) {
>>  if (e.getCause() instanceof IgniteCheckedException &&
>>  e.getCause().getCause() instanceof TransactionDeadlockException)
>> 
>>  System.out.println(e.getCause().getCause().getMessage());
>> }
>> 
>> See the example with the workaround:
>> https://github.com/dmagda/ignite_transactions/blob/
> master/src/main/java/org/apache/ignite/examples/
> DeadlockDetectionExample.java
>> 
>> 
>> Could we do on of the following:
>> 
>> 1) Recover the previous behavior or
>> 2) Throw TransactionDeadlockDetection right away as it’s done in .NET
>>> [3]
>> 
>> [1] https://apacheignite.readme.io/docs/transactions#section-
> deadlock-detection
>> [3] https://github.com/apache/ignite/blob/master/modules/
> platforms/dotnet/examples/Apache.Ignite.Examples/Datagrid/
> TransactionDeadlockDetectionExample.cs#L110
>> 
> 
> 
>>> 
>>> 



[jira] [Created] (IGNITE-5486) ExampleNodeStartup fails with NPe

2017-06-14 Thread Sergey Kozlov (JIRA)
Sergey Kozlov created IGNITE-5486:
-

 Summary: ExampleNodeStartup fails with NPe
 Key: IGNITE-5486
 URL: https://issues.apache.org/jira/browse/IGNITE-5486
 Project: Ignite
  Issue Type: Bug
  Components: examples
Affects Versions: 2.1
Reporter: Sergey Kozlov
 Fix For: 2.1


1. Start 3 or more nodes in IDEA and sporadically one prints out NPE:
{noformat}
[2017-06-14 15:34:52,510][ERROR][sys-#35%null%][GridCacheIoManager] Failed 
processing message [senderId=d6187078-9af2-464f-a86b-9a8f3f4e53ee, 
msg=GridDhtPartitionsFullMessage [parts={-2100569601=GridDhtPartitionFullMap 
[nodeId=d6187078-9af2-464f-a86b-9a8f3f4e53ee, nodeOrder=1, updateSeq=12, 
size=2], 689859866=GridDhtPartitionFullMap 
[nodeId=d6187078-9af2-464f-a86b-9a8f3f4e53ee, nodeOrder=1, updateSeq=12, 
size=2]}, 
partCntrs=o.a.i.i.processors.cache.distributed.dht.preloader.IgniteDhtPartitionCountersMap@4494aed2,
 partHistSuppliers=null, partsToReload=null, topVer=AffinityTopologyVersion 
[topVer=-1, minorTopVer=0], exs={}, compress=false, partCnt=2, 
super=GridDhtPartitionsAbstractMessage [exchId=null, lastVer=null, flags=1, 
super=GridCacheMessage [msgId=8, depInfo=null, err=null, skipPrepare=false
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignment.getIds(GridAffinityAssignment.java:170)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.update(GridDhtPartitionTopologyImpl.java:1147)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1272)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1400(GridCachePartitionExchangeManager.java:124)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:329)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2195)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2177)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:926)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:445)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:364)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:300)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:103)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:290)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:124)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1095)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[GitHub] ignite pull request #2128: IGNITE-5412: delete strange and incomplete test J...

2017-06-14 Thread tledkov-gridgain
GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-5412: delete strange and incomplete test JdbcMetadataSelfTest.…

…testMetadataResultSetClose

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

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

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

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


commit f11dde99a14c1005f501a809e58c713cdd58b54f
Author: tledkov-gridgain 
Date:   2017-06-14T11:46:31Z

IGNITE-5412: delete strange and incomplete test 
JdbcMetadataSelfTest.testMetadataResultSetClose




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


[jira] [Created] (IGNITE-5485) CacheHibernateStoreExample failsd with NPE

2017-06-14 Thread Sergey Kozlov (JIRA)
Sergey Kozlov created IGNITE-5485:
-

 Summary: CacheHibernateStoreExample failsd with NPE
 Key: IGNITE-5485
 URL: https://issues.apache.org/jira/browse/IGNITE-5485
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Sergey Kozlov
Priority: Critical
 Fix For: 2.1


1. Start {{DbH2ServerStartup}}
2. Start {{ExampleNodeStartup}}
3. Start {{CacheHibernateStoreExample}}. It fails with NPE:
{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.hasMovingPartitions(GridDhtPartitionTopologyImpl.java:2040)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.processFullPartitionUpdate(GridCachePartitionExchangeManager.java:1281)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager.access$1400(GridCachePartitionExchangeManager.java:124)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:329)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$3.onMessage(GridCachePartitionExchangeManager.java:327)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2195)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$MessageHandler.apply(GridCachePartitionExchangeManager.java:2177)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:926)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:445)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:364)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:300)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:103)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:290)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1554)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1182)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:124)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1095)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

{noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


Re: Transaction Deadlock Detection exception is not wrapped by the timeout exception

2017-06-14 Thread Andrey Gura
Guys,

first of all I should notice that thre is difference between eception
handling in pessimistic and optimistic transaction, because in
optimistic txs we can't throw CacheException on tx.commit() call.

The second, I'm surprised why TransactionTimeoutException is replaced
by IgniteCheckedException? I still see converter for
IgniteTxTimeoutCheckedException that eventually throws
TransactionTimeoutException with TransactionDeadlockException as
cause.



On Wed, Jun 14, 2017 at 3:11 AM, Dmitriy Setrakyan
 wrote:
> On Tue, Jun 13, 2017 at 5:06 PM, Denis Magda  wrote:
>
>> e.getCause() might return ‘null’ and you’ll get NullPointerException
>> trying to execute e.getCause().getCause().
>>
>> Ideally, we need to throw TransactionDeadlockException like it’s done in
>> .NET.
>>
>
> Agree, looks odd, but because of JSR107 we cannot throw any additional type
> of exception.
>
> Can we simplify by having one getCause() instead of double
> getCause().getCause()?
>
>
>> —
>> Denis
>>
>> > On Jun 13, 2017, at 4:43 PM, Dmitriy Setrakyan 
>> wrote:
>> >
>> > This looks a bit confusing. Why is it not enough to have this check:
>> >
>> > e.getCause().getCause() instanceof TransactionDeadlockException
>> >
>> > ?
>> >
>> > On Tue, Jun 13, 2017 at 4:40 PM, Denis Magda  wrote:
>> >
>> >> Pardon me, copy pasted the catch block twice. This how the block looked
>> >> like in Ignite 1.x
>> >>
>> >> catch (CacheException e) {
>> >>if (e.getCause() instanceof TransactionTimeoutException &&
>> >>e.getCause().getCause() instanceof TransactionDeadlockException)
>> >>
>> >>System.out.println(e.getCause().getCause().getMessage());
>> >> }
>> >>
>> >> and this is how it must be coded in 2.0:
>> >>
>> >>> catch (CacheException e) {
>> >>>   if (e.getCause() instanceof IgniteCheckedException &&
>> >>>   e.getCause().getCause() instanceof TransactionDeadlockException)
>> >>>
>> >>>   System.out.println(e.getCause().getCause().getMessage());
>> >>> }
>> >>
>> >>
>> >>
>> >> —
>> >> Denis
>> >>
>> >>> On Jun 13, 2017, at 4:24 PM, Denis Magda  wrote:
>> >>>
>> >>> Andrey Gura, Igniters,
>> >>>
>> >>> If to refer to our documentation [1], this is how we need to catch the
>> >> deadlock detection exception:
>> >>>
>> >>> catch (CacheException e) {
>> >>>   if (e.getCause() instanceof IgniteCheckedException &&
>> >>>   e.getCause().getCause() instanceof TransactionDeadlockException)
>> >>>
>> >>>   System.out.println(e.getCause().getCause().getMessage());
>> >>> }
>> >>>
>> >>> However, this is no longer works in Ignite 2.0 because
>> >> IgniteCheckedException has to be used instead of
>> >> TransactionTimeoutException:
>> >>>
>> >>> catch (CacheException e) {
>> >>>   if (e.getCause() instanceof IgniteCheckedException &&
>> >>>   e.getCause().getCause() instanceof TransactionDeadlockException)
>> >>>
>> >>>   System.out.println(e.getCause().getCause().getMessage());
>> >>> }
>> >>>
>> >>> See the example with the workaround:
>> >>> https://github.com/dmagda/ignite_transactions/blob/
>> >> master/src/main/java/org/apache/ignite/examples/
>> >> DeadlockDetectionExample.java
>> >>>
>> >>>
>> >>> Could we do on of the following:
>> >>>
>> >>> 1) Recover the previous behavior or
>> >>> 2) Throw TransactionDeadlockDetection right away as it’s done in .NET
>> [3]
>> >>>
>> >>> [1] https://apacheignite.readme.io/docs/transactions#section-
>> >> deadlock-detection
>> >>> [3] https://github.com/apache/ignite/blob/master/modules/
>> >> platforms/dotnet/examples/Apache.Ignite.Examples/Datagrid/
>> >> TransactionDeadlockDetectionExample.cs#L110
>> >>>
>> >>
>> >>
>>
>>


[GitHub] ignite pull request #2126: IGNITE-1094 recovery resolved

2017-06-14 Thread voipp
GitHub user voipp opened a pull request:

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

IGNITE-1094 recovery resolved



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

$ git pull https://github.com/voipp/ignite IGNITE-1094

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

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


commit f289a42c1a1afec46473e20a225d2c1a9319781b
Author: voipp 
Date:   2017-06-09T08:47:55Z

IGNITE-1094 recovery resolved




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


[jira] [Created] (IGNITE-5484) DataStructuresCacheKey and DataStructureInfoKey should have GridCacheInternal marker

2017-06-14 Thread Mikhail Cherkasov (JIRA)
Mikhail Cherkasov created IGNITE-5484:
-

 Summary: DataStructuresCacheKey and DataStructureInfoKey should 
have GridCacheInternal marker
 Key: IGNITE-5484
 URL: https://issues.apache.org/jira/browse/IGNITE-5484
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov


DataStructuresCacheKey and DataStructureInfoKey should have GridCacheInternal 
marker



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Created] (IGNITE-5483) SqlQuery fails with WHERE clause on LocalDateTime field

2017-06-14 Thread Benjamin Garaude (JIRA)
Benjamin Garaude created IGNITE-5483:


 Summary: SqlQuery fails with WHERE clause on LocalDateTime field
 Key: IGNITE-5483
 URL: https://issues.apache.org/jira/browse/IGNITE-5483
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Ignite 2.0.0
Oracle JDK 1.8.0_121

Reporter: Benjamin Garaude


When performing a SqlQuery with a WHERE clause containing an {{=}} predicate on 
a field of type LocalDateTime, the query fails with  
{{org.apache.ignite.IgniteCheckedException:Failed to execute SQL query.}} 

This bug occurred in 2.0, the same SqlQuery was working fine on 1.9.

If we dig into the details,the original exception is a {{ClassCastException}} 
on {{IgniteH2Indexing:3663}}.

When doing the same kind of query with a WHERE clause on a String type, it 
works.
You can find a test case showing that here: 
https://github.com/bgaraude/IgniteTest


I think this is related to IGNITE-4172, but this ticket says that the patch has 
to be updated once H2 has been updated.
It seems that ignite 2.0 uses an updated version of H2: 1.4.195. This H2 
version supports LocalDateTime. At least 
{{org.h2.value.DataType.getTypeFromClass}} returns TimeStamp for the 
LocalDateTime class. But {{IgniteH2Indexing$RowDescriptor.wrap()}} has not been 
updated accordingly. Hence, the ClassCastException.

Do you know a workaround i can use while this issue is fixed?





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)