Re: Cassandra store issues

[Valentin Kulichenko]

Igor,

Thanks for clarifications!

-Val

On Thu, Mar 30, 2017 at 9:09 PM, Igor Rudyak  wrote:

> Hi Val,
>
> Thanks for the info. I replied to both questions.
>
> Regarding the first question - we just don't support mapping from
> java.sql.Timestamp to Cassandra's Datatype.Name.TIMESTAMP type, cause there
> are no direct mapping for it http://docs.datastax.com/en/
> developer/java-driver/3.1/manual/#cql-to-java-type-mapping.  We can
> easily add support for this mapping, but there actually plenty of other
> Timestamp types in core java (java.sql.Timestamp, java.security.Timestamp,
> java.sun.jmx.snmp.Timestamp and etc.) and even more in different third
> party libraries. Thus it's just technically not possible to add support for
> all variety of Timestamps.
>
> Regarding second question - in current implementation, complex data types
> (collections, custom types) could only be mapped to BLOB type in Cassandra.
>
> Igor
>
> On Thu, Mar 30, 2017 at 5:39 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Hi Igor,
>>
>> There are two recent questions on the user forum regarding
>> ignite-cassandra module, and they seem to be very similar to each other:
>>
>>- http://apache-ignite-users.70518.x6.nabble.com/Timestamp-is-
>>not-stored-correctly-with-Cassandra-td11590.html
>>
>> 
>>- http://apache-ignite-users.70518.x6.nabble.com/Mapping-java-
>>util-Map-in-CassandraPersistentStore-td11574.html
>>
>> 
>>
>> Can you please take a look?
>>
>> Do we support all Cassandra data types properly? If not, why?
>>
>> -Val
>>
>
>

Cassandra store issues

[Valentin Kulichenko]

Hi Igor,

There are two recent questions on the user forum regarding ignite-cassandra
module, and they seem to be very similar to each other:

   -
   
http://apache-ignite-users.70518.x6.nabble.com/Timestamp-is-not-stored-correctly-with-Cassandra-td11590.html
   -
   
http://apache-ignite-users.70518.x6.nabble.com/Mapping-java-util-Map-in-CassandraPersistentStore-td11574.html

Can you please take a look?

Do we support all Cassandra data types properly? If not, why?

-Val

Re: Apache Ignite 2.0 Release

[Denis Magda]

Vovan, 

I expect to finalize and merge Spring Data Integration by the code freeze time 
(April 14th):
 IGNITE-1192Provide integration with Spring Data 


—
Denis

> On Mar 30, 2017, at 3:10 PM, Vladimir Ozerov  wrote:
> 
> Igniters,
> 
> We are getting closer to proposed code freeze date. Could you please go
> through the list of required [1] tickets and provide brief update on where
> we are?
> 
> As per myself, I am curerntly working on CREATE/DROP index feature
> stabilization and expect it to be ready for review on the next week.
> 
> Vladimir.
> 
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0
> 
> On Tue, Mar 28, 2017 at 9:11 PM, nivanov  wrote:
> 
>> I think we can make it on time to add IgniteML (a.k.a. distributed math) to
>> 2.0 release pipeline.
>> 
>> 
>> 
>> --
>> View this message in context: http://apache-ignite-
>> developers.2346864.n4.nabble.com/Apache-Ignite-2-0-Release-
>> tp15690p15857.html
>> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>> 

Re: jdbc vs jdbc2 packages

[Denis Magda]

Folks,

I had a chance to validate usability of both Ignite JDBC drivers at PGConf USA 
today trying to connect to the cluster from the new JetBrains DataGrip SQL tool 
[1]. Together with JetBrains folks we agreed on the following or spotted the 
issues listed below.

1) Default JDBC driver, that connects via a client node using a Spring XML 
config, is so counterintuitive and twisted that JetBrains folks couldn’t set it 
up w/o my assistance. We force SQL tools users, that accustomed to connect to 
DBs by hostname, to pass some weird Spring XML and add up to 15 (!) jars to the 
classpath of a tool rather than one. This is huge +1 for the thin client based 
driver that requires a hostname only. So, along with the thin client protocol 
optimizations DML has to be supported for it as well [2]. 

2) Regardless of JDBC driver version if you execute a query like “SELECT * FROM 
PersonCache” you’ll get a deserialization exception for _val that is implicitly 
added to the result set. Luckily, this will be no longer the issue after this 
[3] improvement is released in 2.0.

3) It would be more user-friendly if the JDBC drivers are packaged under single 
“ignite-jdbc.jar” and located in special directory of a release bundle. All the 
dependencies have to be in this jar. The ticket is ready [4].

So I would encourage us to wrap up this discussion creating additional tickets 
in order to renew the thin client based driver and promote it for tools and non 
transactional use cases.

[1] https://www.jetbrains.com/datagrip/ 
[2] https://issues.apache.org/jira/browse/IGNITE-4892 

[3] https://issues.apache.org/jira/browse/IGNITE-3487 

[4] https://issues.apache.org/jira/browse/IGNITE-4893 


—
Denis

> On Mar 30, 2017, at 1:09 AM, Denis Magda  wrote:
> 
> Val, Igniters,
> 
> I still believe the thin client has a right for living. It’s ideal for use 
> cases when someone attempts to connect to Ignite from a tool or some sort of 
> interface and query the data or update it in non transactional fashion. A 
> TCP/IP address as a connection string to the cluster is ideal for this 
> scenario.
> 
> If someone decides to use JDBC programmatically and leverage from 
> transactions then he will switch to the JDBC versions that starts a client 
> node with a passed Ignite configuration.
> 
> How do you like this?
> 
> In general, it sounds like a right movement to replace REST with more 
> flexible and, probably, unified protocol for thin client based JDBC 
> implementation. But what if we extend REST a bit (supporting pagination for 
> SELECTs and DML) at the first phase so that the thin client driver can be 
> used right away in the scenarios I listed above? The rest of optimizations 
> can be done after that.
> 
> —
> Denis
> 
>> On Mar 23, 2017, at 7:24 PM, Valentin Kulichenko 
>>  wrote:
>> 
>> I'm against keeping legacy thin client because:
>> 
>> - Having two ways to configure driver is unnecessary complication and very
>> bad from usability standpoint.
>> - It is much slower than client node, performance was the main driver
>> behind its deprecation.
>> 
>> What we should do, is improve usability of the client node, this will be
>> good improvement not only for JDBC driver. The list of required changes was
>> covered earlier in the thread, I will check if we have tickets for all of
>> them and provide a list.
>> 
>> -Val
>> 
>> On Thu, Mar 16, 2017 at 1:02 AM, Dmitriy Setrakyan 
>> wrote:
>> 
>>> Denis, I completely agree that we should have a thin JDBC client. Can you
>>> file a ticket?
>>> 
>>> On Wed, Mar 15, 2017 at 4:58 PM, Denis Magda  wrote:
>>> 
 Frankly, during these two a couple of day I had a chance to play with Web
 Console and Ignite JDBC driver.
 
 As many other users I referred to JDBC documentation in order to setup
>>> the
 driver properly. However, then due to the recently reported issue I fell
 back to JDBC v 1 (thin client based):
 https://issues.apache.org/jira/browse/IGNITE-4829 <
 https://issues.apache.org/jira/browse/IGNITE-4829>
 
 I was amazed how swift JDBC v 1 and sluggish JDBC v 2 which is default.
 Unfortunately, JDBC v 1 doesn’t support DML this is why I had hard time
 finding out a workaround for IGNITE-4829. But, in any case I fully
>>> support
 reincarnation of JDBC v 1.
 
 *Val*, as one of the most experienced folks who participated in this
 discussion, would you mind wrapping the discussion up in a form of a
>>> ticket
 listing the design proposal?
 
 —
 Denis
 
> On Feb 10, 2017, at 4:47 PM, Dmitriy Setrakyan 
 wrote:
> 
> I generally like the idea of supporting thin JDBC clients. Often it 

[jira] [Created] (IGNITE-4893) Release Ignite JDBC driver(s) under a single JAR

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4893:
---

 Summary: Release Ignite JDBC driver(s) under a single JAR
 Key: IGNITE-4893
 URL: https://issues.apache.org/jira/browse/IGNITE-4893
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda


Presently, if someone uses the client node based driver (with Spring XML 
config) from an SQL tool we demand to add to the classpath all the jars from 
"libs" and "ignite-spring", "ignite-indexing" subdirectories (up to 15! jars in 
total).

As for the thin client based driver, the things are easier but the driver is in 
"ignite-core.jar".

It would be more user-friendly if the JDBC drivers are packaged under single 
“ignite-jdbc.jar” and located in special directory of a release bundle. All the 
dependencies have to be in this jar.



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

[jira] [Created] (IGNITE-4892) Support DML for thin client based JDBC driver

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4892:
---

 Summary: Support DML for thin client based JDBC driver
 Key: IGNITE-4892
 URL: https://issues.apache.org/jira/browse/IGNITE-4892
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
 Fix For: 2.1


Support all DML operations for the thin client based JDBC driver:
https://apacheignite.readme.io/docs/jdbc-driver#hostname-based-jdbc-connection



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

[jira] [Created] (IGNITE-4891) Key is deserialized during transactional get() even if withKeepBinary is set

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-4891:
---

 Summary: Key is deserialized during transactional get() even if 
withKeepBinary is set
 Key: IGNITE-4891
 URL: https://issues.apache.org/jira/browse/IGNITE-4891
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.9
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 2.0


This test reproduces the issue: https://github.com/olegskoblya/tx-binary-bug



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

[jira] [Created] (IGNITE-4890) Unable to create tables automatically because 'unconfigured columnfamily' error is not handled for older Cassandra versions

[Venky (JIRA)]

Venky created IGNITE-4890:
-

 Summary: Unable to create tables automatically because 
'unconfigured columnfamily' error is not handled for older Cassandra versions
 Key: IGNITE-4890
 URL: https://issues.apache.org/jira/browse/IGNITE-4890
 Project: Ignite
  Issue Type: Bug
  Components: compatibility
Affects Versions: 1.9
Reporter: Venky
 Fix For: 2.0


PROBLEM:
When running Ignite with older Cassandra versions (i.e DSE 4.8.10, Cassandra 
2.1.6 or older), we noticed that only the first tabel in an Ignite config is 
created and the others fail with 'unconfigured columnfamily' exception.

SUGGESTED FIX:
It appears that the error from Cassandra is changed in newer versions to 
'unconfigured table ...' and this is handled.  The conditions checked in 
org.apache.ignite.cache.store.cassandra.common.CassandraHelper needs to be 
modified to handle the older Cassandra errors. 

We are submitting a patch to do that. 

13:44:28,753 ERROR com.walmartlabs.qarth.ignite.tests.utils.CacheStoreHelper 
[main] - Failed to execute Cassandra CQL statement: insert into 
"test1"."blob_test2" ("key", "value") values (?,?);
class org.apache.ignite.IgniteException: Failed to execute Cassandra CQL 
statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
at 
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:163)
at 
org.apache.ignite.cache.store.cassandra.CassandraCacheStore.write(CassandraCacheStore.java:276)
at 
com.walmartlabs.qarth.ignite.tests.cassandra.CassandraDirectPersistenceTest.blobStrategyTest(CassandraDirectPersistenceTest.java:233)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: class org.apache.ignite.IgniteException: Failed to prepare Cassandra 
CQL statement: insert into "test1"."blob_test2" ("key", "value") values (?,?);
at 
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:615)
at 
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.execute(CassandraSessionImpl.java:133)
... 27 more
Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: 
unconfigured columnfamily blob_test2
at 
com.datastax.driver.core.exceptions.InvalidQueryException.copy(InvalidQueryException.java:50)
at 
com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
at 
com.datastax.driver.core.AbstractSession.prepare(AbstractSession.java:98)
at 
org.apache.ignite.cache.store.cassandra.session.CassandraSessionImpl.prepareStatement(CassandraSessionImpl.java:597)
... 28 more
Caused by: com.datastax.driver.core.exceptions.InvalidQueryException: 

Re: Real size of a stored data in IgniteCache

[Александр Меньшиков]

Vyacheslav,
Objects have different size in different runtime (x86 or Power, compress
pointer on or off and so on). So only one possible way to see real size is
do it in runtime. You can see how many bytes was allocated in one thread by
using

import *com.sun.management*.ThreadMXBean;

ThreadMXBean bean = (ThreadMXBean) ManagementFactory.getThreadMXBean();
//it return java.*lang*.management.ThreadMXBean
System.out.println(bean.
*getThreadAllocatedBytes(Thread.currentThread().getId())*);

Or you can use JMH with args
*-prof gc.*
But please note it shows all the allocated bytes including temp objects,
not only the remaining.

If you know exactly which object contains your data, you can use *Java
Object Layout *( http://openjdk.java.net/projects/code-tools/jol/ ) which
show you everything even alignment. In this video (in Russian, but i know
it's not problem for you) you can see how to use it:
https://www.youtube.com/watch?v=r_bnfv-nlcs




2017-03-30 19:45 GMT+03:00 Dmitriy Setrakyan :

> On Thu, Mar 30, 2017 at 9:30 AM, Vyacheslav Daradur 
> wrote:
>
> > Dmitry, as I understand Ignite doesn't provide a possibility to show real
> > total size of objects in a IgniteCache.
> >
>
> Currently no, but the 2.0 release, which is fully off-heap, will provide a
> precise cache size.
>

Re: Apache Ignite 2.0 Release

[Vladimir Ozerov]

Igniters,

We are getting closer to proposed code freeze date. Could you please go
through the list of required [1] tickets and provide brief update on where
we are?

As per myself, I am curerntly working on CREATE/DROP index feature
stabilization and expect it to be ready for review on the next week.

Vladimir.

[1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0

On Tue, Mar 28, 2017 at 9:11 PM, nivanov  wrote:

> I think we can make it on time to add IgniteML (a.k.a. distributed math) to
> 2.0 release pipeline.
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Apache-Ignite-2-0-Release-
> tp15690p15857.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

[GitHub] ignite pull request #1706: Ignite 4862

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

Ignite 4862



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

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

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

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


commit bfb00b6e61f9709718c30971997aeb0ac79e86b4
Author: Alexandr Kuramshin 
Date:   2016-11-18T20:12:28Z

IgniteTcpCommunicationBigClusterTest added

commit 02dd92e605b9b53f5a16c7ec5f8e7b5698b15ba4
Author: Alexandr Kuramshin 
Date:   2016-11-18T21:55:37Z

IgniteTcpCommunicationBigClusterTest update

commit 6acf193a3d356d1bad4c02a53ac76833ed1008d0
Author: Alexandr Kuramshin 
Date:   2016-11-19T09:55:45Z

Have got TcpCommunicationSpi error

commit 4fd39653d24f62f19f70b4dffba8497185cc46fb
Author: Alexandr Kuramshin 
Date:   2016-11-19T16:39:10Z

Some discovery have been done

commit c2c181922c7c24ea457577e32d2af897c8bec87f
Author: Alexandr Kuramshin 
Date:   2016-11-19T20:11:28Z

Prove that problem is not in the onFirstMessage hang

commit f8076edba097f6077229b2090ee3ff1a3369878c
Author: Alexandr Kuramshin 
Date:   2016-11-19T20:26:37Z

Revert: Prove that problem is not in the onFirstMessage hang

commit 6e1f2dfc2acb3dbb8f24aa51ed67b2ee447b4585
Author: Alexandr Kuramshin 
Date:   2016-11-21T08:55:09Z

Revert: pushing unnecessary changes to the master

commit ed794ca815f6bb1471af15779279d287576b39cc
Author: Alexandr Kuramshin 
Date:   2016-11-21T09:08:00Z

Revert: pushing unnecessary changes to the master

commit 3a57d63668bed239e21eca588134272783472e97
Author: iveselovskiy 
Date:   2016-12-09T14:13:37Z

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

commit 166ad21d560c41c42a6de81cf5910537baa3ac92
Author: iveselovskiy 
Date:   2016-12-12T18:46:44Z

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

commit 1eaba3e91bfe54c2bf6f761ac3f238a3b181a8e0
Author: iveselovskiy 
Date:   2017-03-27T18:41:07Z

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

commit cef7775c9dcfc32b11a4cc4678b3a69a1e1b17da
Author: iveselovskiy 
Date:   2017-03-30T13:05:23Z

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

commit 26dc941d7176f31bd4cbaacb722e2903b4cd20cb
Author: iveselovskiy 
Date:   2017-03-30T16:45:49Z

4862

commit d7fc80a7cb58496b3cf385185328c84966988edb
Author: iveselovskiy 
Date:   2017-03-30T19:05:40Z

4862: introduced common lazy value utility class.




---
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: usimg of other JTA implementation

[Dmitriy Setrakyan]

On Thu, Mar 30, 2017 at 10:04 AM, ALEKSEY KUZNETSOV <
alkuznetsov...@gmail.com> wrote:

> Igniters! Why havent u made use of some open JTA implementation for
> distributed transactions instead of implementing own one
>

Because using standard JTA would be much slower. Instead we chose to
support JTA API on top of our own distributed transaction management.

usimg of other JTA implementation

[ALEKSEY KUZNETSOV]

Igniters! Why havent u made use of some open JTA implementation for
distributed transactions instead of implementing own one
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1705: Ignite 4879

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite 4879

for tests purpose

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

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

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

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






---
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 #1704: IGNITE-4879: System pool starvation while partiti...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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 #1704: IGNITE-4879: System pool starvation while partiti...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4879: System pool starvation while partition evicting.



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

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

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

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






---
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: Real size of a stored data in IgniteCache

[Dmitriy Setrakyan]

On Thu, Mar 30, 2017 at 9:30 AM, Vyacheslav Daradur 
wrote:

> Dmitry, as I understand Ignite doesn't provide a possibility to show real
> total size of objects in a IgniteCache.
>

Currently no, but the 2.0 release, which is fully off-heap, will provide a
precise cache size.

Re: Real size of a stored data in IgniteCache

[Vyacheslav Daradur]

Dmitry, as I understand Ignite doesn't provide a possibility to show real
total size of objects in a IgniteCache.


чт, 30 марта 2017 г. в 19:03, Dmitriy Setrakyan :

> Would it help if you had the total data size for a cache and a number of
> entries, which I believe Ignite provides? In this case, you can divide one
> by another and have your average object size.
>
> D.
>
> On Thu, Mar 30, 2017 at 7:42 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Hi Vyacheslav,
> >
> > No, Ignite doesn't provide such methods.
> > However, you can see how it is overcome in one of EvictionPolicy
> > implementations and make a proposal how it could be implemented.
> >
> > On Thu, Mar 30, 2017 at 5:20 PM, Vyacheslav Daradur  >
> > wrote:
> >
> > > Alexey,
> > >
> > > Yes, it works in my case.
> > >
> > > Does Ignite provide any methods for my case?
> > >
> > >
> > > 2017-03-30 17:04 GMT+03:00 Alexey Kuznetsov :
> > >
> > > > Vyacheslav,
> > > >
> > > > Will JVisualVM + heap dump + analyzing objects count and  sizes in
> heap
> > > > dump works in your case?
> > > >
> > > >
> > > >
> > > > On Thu, Mar 30, 2017 at 8:26 PM, Vyacheslav Daradur <
> > daradu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Hello everyone.
> > > > >
> > > > > How do I know real size of a stored data in the IgniteCache?
> > > > >
> > > > > For example: I created new cache and put one object, and I want to
> > know
> > > > > real size of one object in cache.
> > > > >
> > > > > try (Ignite ignite = Ignition.start("cache-config.xml")) {
> > > > >
> > > > > IgniteCache cache = ignite.getOrCreateCache("
> > > > > myCache");
> > > > >
> > > > > MyObject obj = new MyObject()
> > > > >
> > > > > cache.put(obj.getLongId(), obj);
> > > > > }
> > > > >
> > > > > I looked at ClusterMetrics and CacheMetrics, but I'am not sure wich
> > > > method
> > > > > is real needed to me.
> > > > >
> > > > > p.s. I haven't found the answer in search.
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrey V. Mashenkov
> >
>
-- 
Best Regards, Vyacheslav

Re: Making News page more visible

[Prachi Garg]

Sure, will implement it soon.

Thanks,
-P

On Wed, Mar 29, 2017 at 7:16 PM, Denis Magda  wrote:

> Prachi, as one of the site maintainers, would you mind contributing this?
>
> Denis
>
>
> On Wednesday, March 29, 2017, Tom Diederich 
> wrote:
>
>> Thanks, Denis! I agree that an anchor would make sense. Also really like
>> the
>> idea to add the social icons to make sharing fast and easy.
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-developer
>> s.2346864.n4.nabble.com/Making-News-page-more-visible-tp15763p15927.html
>> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>>
>

Re: Real size of a stored data in IgniteCache

[Dmitriy Setrakyan]

Would it help if you had the total data size for a cache and a number of
entries, which I believe Ignite provides? In this case, you can divide one
by another and have your average object size.

D.

On Thu, Mar 30, 2017 at 7:42 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Hi Vyacheslav,
>
> No, Ignite doesn't provide such methods.
> However, you can see how it is overcome in one of EvictionPolicy
> implementations and make a proposal how it could be implemented.
>
> On Thu, Mar 30, 2017 at 5:20 PM, Vyacheslav Daradur 
> wrote:
>
> > Alexey,
> >
> > Yes, it works in my case.
> >
> > Does Ignite provide any methods for my case?
> >
> >
> > 2017-03-30 17:04 GMT+03:00 Alexey Kuznetsov :
> >
> > > Vyacheslav,
> > >
> > > Will JVisualVM + heap dump + analyzing objects count and  sizes in heap
> > > dump works in your case?
> > >
> > >
> > >
> > > On Thu, Mar 30, 2017 at 8:26 PM, Vyacheslav Daradur <
> daradu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hello everyone.
> > > >
> > > > How do I know real size of a stored data in the IgniteCache?
> > > >
> > > > For example: I created new cache and put one object, and I want to
> know
> > > > real size of one object in cache.
> > > >
> > > > try (Ignite ignite = Ignition.start("cache-config.xml")) {
> > > >
> > > > IgniteCache cache = ignite.getOrCreateCache("
> > > > myCache");
> > > >
> > > > MyObject obj = new MyObject()
> > > >
> > > > cache.put(obj.getLongId(), obj);
> > > > }
> > > >
> > > > I looked at ClusterMetrics and CacheMetrics, but I'am not sure wich
> > > method
> > > > is real needed to me.
> > > >
> > > > p.s. I haven't found the answer in search.
> > > >
> > > > --
> > > > Best Regards, Vyacheslav
> > > >
> > >
> > >
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav
> >
>
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>

[GitHub] ignite pull request #1703: IGNITE-4888

[gvvinblade]

GitHub user gvvinblade opened a pull request:

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

IGNITE-4888



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

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

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

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


commit 6de3a8c695316f3b4d189a4b6db081b95b9396c2
Author: Igor Seliverstov 
Date:   2017-03-30T15:21:23Z

[IGNITE-4888]An assertion error in TcpDiscoverySelfTest




---
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: putting entity into cache while commiting.Why!?

[Alexander Fedotov]

Actually, there is no dirty value. The value is visible only in scope of
the transaction.
You call doInTransaction for ignite(1) thus initiating a pessimistic
transaction.
Inside doInTransaction cache.put is called, but cache belongs to the
ignite(0) and therefore
the put happens in an implicit transaction and succeeds immediately.
So, the value received by cache.get is not a dirty value.

On Thu, Mar 30, 2017 at 5:57 PM, ALEKSEY KUZNETSOV  wrote:

> I don't see point of commiting key1 only to zero node and thus creating
> drity value on zero node.
>
> чт, 30 мар. 2017 г. в 17:36, Alexey Goncharuk  >:
>
> > Note that you call doInTransaction() for ignite(1), but you have acquired
> > the cache reference for ignite(0), thus your cache.put() commits
> > immediately from another node, because transactional scope is node-local.
> >
> > If you change the test either to use ignite(0) for doInTransaction, or to
> > get the cache in the callable like ignite(1).cache("testCache"), the test
> > will not throw an exception. Note that it will hang because
> doInTrasaction
> > starts a pessimistic transaction which acquires a lock on key1, and then
> > you put it to infinite sleep. The lock prevents the transaction from
> > the main thread to commit.
> >
> > 2017-03-30 15:44 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > I've edited code and now DIRTY READ occures!
> > >
> > > Ignite ignite0 = ignite(0);
> > > IgniteTransactions transactions = ignite0.transactions();
> > > IgniteCache cache =
> > ignite0.getOrCreateCache("testCache");
> > > Object monitor = new Object();
> > >
> > > GridTestUtils.runAsync(new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > doInTransaction(ignite(1), new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > synchronized (monitor) {
> > > cache.put("key1", "val1!");
> > > monitor.wait();
> > > fail();
> > > return null;
> > > }
> > > }
> > > });
> > > return null;
> > > }
> > > });
> > > Thread.currentThread().sleep(1000);<-- dirty read occures only if
> > > we sleep some time !
> > > Transaction tx =
> > > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > > TransactionIsolation.READ_COMMITTED);
> > > String key1Value = cache.get("key1");
> > > if(key1Value.equals("val1!"))
> > > throw new RuntimeException("dirty read!");<-- exception does
> > > happen!
> > > cache.put("key1", "val1");
> > > cache.put("key2", "val2");
> > > cache.put("key3", "val3");
> > > tx.commit();
> > >
> > >
> > > чт, 30 мар. 2017 г. в 14:04, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Agree, the cache is transactional, however, the second transaction
> does
> > > not
> > > > see the dirty value:
> > > >
> > > > Ignite ignite0 = ignite(0);
> > > > IgniteTransactions transactions = ignite0.transactions();
> > > > final IgniteCache cache =
> > > > ignite0.getOrCreateCache("testCache");
> > > >
> > > > final Object monitor = new Object();
> > > >
> > > > GridTestUtils.runAsync(new Callable() {
> > > > @Override
> > > > public Object call() throws Exception {
> > > > synchronized (monitor){
> > > > doInTransaction(ignite(1), new Callable() {
> > > > @Override
> > > > public Object call() throws Exception {
> > > > cache.put("key1", "val1");
> > > > monitor.wait();
> > > > System.out.println("continue first transaction");
> > > > return null;
> > > > }
> > > > });
> > > > }
> > > > return null;
> > > > }
> > > > });
> > > >
> > > > Transaction tx =
> > > > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > > > TransactionIsolation.READ_COMMITTED);
> > > > assertNull(cache.get("key1")); // <- This check passes
> > > > tx.commit();
> > > >
> > > >
> > > > 2017-03-30 13:30 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > Well, i changed code , added :
> > > > >
> > > > > CacheConfiguration config = cache.getConfiguration(
> > > > > CacheConfiguration.class);
> > > > > System.out.println(config.getAtomicityMode());//TRANSACTIONAL
> > > > >
> > > > > So, atomicity is transactional
> > > > >
> > > > > чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > >:
> > > > >
> > > > > > Aleksey,
> > > > > >
> > > > > > It looks like in your test the result of method atomicityMode()
> is
> > > not
> > > > > used
> > > > > > because you do getOrCreateCache() without the configuration
> > argument,
> > > > > which
> > > > 

[jira] [Created] (IGNITE-4889) Replacement of Cache Key classes with fields not participating in equals operation

[Sergey Chugunov (JIRA)]

Sergey Chugunov created IGNITE-4889:
---

 Summary: Replacement of Cache Key classes with fields not 
participating in equals operation
 Key: IGNITE-4889
 URL: https://issues.apache.org/jira/browse/IGNITE-4889
 Project: Ignite
  Issue Type: Improvement
Reporter: Sergey Chugunov


h2. Notes

Having key classes with fields not participating in *equals* operation leads to 
errors when handling them in B+Tree data structures.

It is discussed here in more details: [dev-list 
discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html]

h2. Acceptance Criteria
# All classes known to have such flaw are replaced at run time to use them 
safely within B+Tree.
# All tests marked with this issue number are passing.

h2. Out-of-scope
*BinaryIdentityResolver* approach is deprecated when solution described above 
is implemented and proven to be working.





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

[jira] [Created] (IGNITE-4888) An assertion error in TcpDiscoverySelfTest

[Igor Seliverstov (JIRA)]

Igor Seliverstov created IGNITE-4888:


 Summary: An assertion error in TcpDiscoverySelfTest
 Key: IGNITE-4888
 URL: https://issues.apache.org/jira/browse/IGNITE-4888
 Project: Ignite
  Issue Type: Bug
Reporter: Igor Seliverstov
Assignee: Igor Seliverstov


The exception as shown below sometimes appears in output:

{noformat}
java.lang.AssertionError
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:735)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:503)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:1678)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{noformat}



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

Re: putting entity into cache while commiting.Why!?

[ALEKSEY KUZNETSOV]

I don't see point of commiting key1 only to zero node and thus creating
drity value on zero node.

чт, 30 мар. 2017 г. в 17:36, Alexey Goncharuk :

> Note that you call doInTransaction() for ignite(1), but you have acquired
> the cache reference for ignite(0), thus your cache.put() commits
> immediately from another node, because transactional scope is node-local.
>
> If you change the test either to use ignite(0) for doInTransaction, or to
> get the cache in the callable like ignite(1).cache("testCache"), the test
> will not throw an exception. Note that it will hang because doInTrasaction
> starts a pessimistic transaction which acquires a lock on key1, and then
> you put it to infinite sleep. The lock prevents the transaction from
> the main thread to commit.
>
> 2017-03-30 15:44 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > I've edited code and now DIRTY READ occures!
> >
> > Ignite ignite0 = ignite(0);
> > IgniteTransactions transactions = ignite0.transactions();
> > IgniteCache cache =
> ignite0.getOrCreateCache("testCache");
> > Object monitor = new Object();
> >
> > GridTestUtils.runAsync(new Callable() {
> > @Override
> > public Object call() throws Exception {
> > doInTransaction(ignite(1), new Callable() {
> > @Override
> > public Object call() throws Exception {
> > synchronized (monitor) {
> > cache.put("key1", "val1!");
> > monitor.wait();
> > fail();
> > return null;
> > }
> > }
> > });
> > return null;
> > }
> > });
> > Thread.currentThread().sleep(1000);<-- dirty read occures only if
> > we sleep some time !
> > Transaction tx =
> > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > TransactionIsolation.READ_COMMITTED);
> > String key1Value = cache.get("key1");
> > if(key1Value.equals("val1!"))
> > throw new RuntimeException("dirty read!");<-- exception does
> > happen!
> > cache.put("key1", "val1");
> > cache.put("key2", "val2");
> > cache.put("key3", "val3");
> > tx.commit();
> >
> >
> > чт, 30 мар. 2017 г. в 14:04, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Agree, the cache is transactional, however, the second transaction does
> > not
> > > see the dirty value:
> > >
> > > Ignite ignite0 = ignite(0);
> > > IgniteTransactions transactions = ignite0.transactions();
> > > final IgniteCache cache =
> > > ignite0.getOrCreateCache("testCache");
> > >
> > > final Object monitor = new Object();
> > >
> > > GridTestUtils.runAsync(new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > synchronized (monitor){
> > > doInTransaction(ignite(1), new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > cache.put("key1", "val1");
> > > monitor.wait();
> > > System.out.println("continue first transaction");
> > > return null;
> > > }
> > > });
> > > }
> > > return null;
> > > }
> > > });
> > >
> > > Transaction tx =
> > > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > > TransactionIsolation.READ_COMMITTED);
> > > assertNull(cache.get("key1")); // <- This check passes
> > > tx.commit();
> > >
> > >
> > > 2017-03-30 13:30 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > Well, i changed code , added :
> > > >
> > > > CacheConfiguration config = cache.getConfiguration(
> > > > CacheConfiguration.class);
> > > > System.out.println(config.getAtomicityMode());//TRANSACTIONAL
> > > >
> > > > So, atomicity is transactional
> > > >
> > > > чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > >
> > > > > Aleksey,
> > > > >
> > > > > It looks like in your test the result of method atomicityMode() is
> > not
> > > > used
> > > > > because you do getOrCreateCache() without the configuration
> argument,
> > > > which
> > > > > will create a cache with a default configuration, which is ATOMIC.
> > > > >
> > > > > 2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > public class FooTest extends GridCacheAbstractSelfTest {
> > > > > >
> > > > > > @Override
> > > > > > protected void afterTestsStopped() throws Exception {
> > > > > > super.afterTestsStopped();
> > > > > > stopAllGrids();
> > > > > > }
> > > > > >
> > > > > > @Override
> > > > > > protected int gridCount() {
> > > > > > return 3;
> > > > > > }
> > > > > >
> > > > > > @Override
> > > > > > protected CacheMode cacheMode() {
> > > > > > return CacheMode.PARTITIONED;
> 

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

Hi ! Thanks for help. I've created ticket :
https://issues.apache.org/jira/browse/IGNITE-4887
and a commit :
https://github.com/voipp/ignite/commit/aa3487bd9c203394f534c605f84e06436b638e5c
We really need this feature

чт, 30 мар. 2017 г. в 11:31, Alexey Goncharuk :

> Aleksey,
>
> I doubt your approach works as expected. Current transaction recovery
> protocol heavily relies on the originating node ID in its internal logic.
> For example, currently a transaction will be rolled back if you want to
> transfer a transaction ownership to another node and original tx owner
> fails. An attempt to commit such a transaction on another node may fail
> with all sorts of assertions. After transaction ownership changed, you need
> to notify all current transaction participants about this change, and it
> should also be done failover-safe, let alone that you did not add any tests
> for these cases.
>
> I back Denis here. Please create a ticket first and come up with clear
> use-cases, API and protocol changes design. It is hard to reason about the
> changes you've made when we do not even understand why you are making these
> changes and how they are supposed to work.
>
> --AG
>
> 2017-03-30 10:43 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > So, what do u think on my idea ?
> >
> > ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV  >:
> >
> > > Hi! No, i dont have ticket for this.
> > > In the ticket i have implemented methods that change transaction status
> > to
> > > STOP, thus letting it to commit transaction in another thread. In
> another
> > > thread you r going to restart transaction in order to commit it.
> > > The mechanism behind it is obvious : we change thread id to newer one
> in
> > > ThreadMap, and make use of serialization of txState, transactions
> itself
> > to
> > > transfer them into another thread.
> > >
> > >
> > > вт, 28 мар. 2017 г. в 20:15, Denis Magda :
> > >
> > > Aleksey,
> > >
> > > Do you have a ticket for this? Could you briefly list what exactly was
> > > done and how the things work.
> > >
> > > —
> > > Denis
> > >
> > > > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com>
> > > wrote:
> > > >
> > > > Hi, Igniters! I 've made implementation of transactions of non-single
> > > > coordinator. Here you can start transaction in one thread and commit
> it
> > > in
> > > > another thread.
> > > > Take a look on it. Give your thoughts on it.
> > > >
> > > >
> > > https://github.com/voipp/ignite/pull/10/commits/
> > 3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45
> > > >
> > > > пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >:
> > > >
> > > >> You know better, go ahead! :)
> > > >>
> > > >> Sergi
> > > >>
> > > >> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > >>
> > > >>> we've discovered several problems regarding your "accumulation"
> > > >>> approach.These are
> > > >>>
> > > >>>   1. perfomance issues when transfering data from temporary cache
> to
> > > >>>   permanent one. Keep in mind big deal of concurent transactions in
> > > >>> Service
> > > >>>   commiter
> > > >>>   2. extreme memory load when keeping temporary cache in memory
> > > >>>   3. As long as user is not acquainted with ignite, working with
> > cache
> > > >>>   must be transparent for him. Keep this in mind. User's node can
> > > >> evaluate
> > > >>>   logic with no transaction at all, so we should deal with both
> types
> > > of
> > > >>>   execution flow : transactional and non-transactional.Another one
> > > >>> problem is
> > > >>>   transaction id support at the user node. We would have handled
> all
> > > >> this
> > > >>>   issues and many more.
> > > >>>   4. we cannot pessimistically lock entity.
> > > >>>
> > > >>> As a result, we decided to move on building distributed
> transaction.
> > We
> > > >> put
> > > >>> aside your "accumulation" approach until we realize how to solve
> > > >>> difficulties above .
> > > >>>
> > > >>> чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >:
> > > >>>
> > >  The problem "How to run millions of entities, and millions of
> > > >> operations
> > > >>> on
> > >  a single Pentium3" is out of scope here. Do the math, plan
> capacity
> > >  reasonably.
> > > 
> > >  Sergi
> > > 
> > >  2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com
> > > >>> :
> > > 
> > > > hmm, If we have millions of entities, and millions of operations,
> > > >> would
> > >  not
> > > > this approache lead to memory overflow and perfomance degradation
> > > >
> > > > чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin <
> > > >> sergi.vlady...@gmail.com
> > >  :
> > > >
> > > >> 1. Actually you have to check versions on all the values you
> have
> > > >>> read
> > > >> during the tx.
> > > >>
> > > 

[jira] [Created] (IGNITE-4887) Support for starting transaction in another thread

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-4887:


 Summary: Support for starting transaction in another thread
 Key: IGNITE-4887
 URL: https://issues.apache.org/jira/browse/IGNITE-4887
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.9
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


Consider the following pseudo-code:
{code:xml}
IgniteTransactions transactions = ignite1.transactions();
Transaction tx = startTransaction(transactions);
cache.put("key1", 1);
tx.stop();
{code}
And in another thread:
{code:xml}
transactions.txStart(tx);
cache.put("key3", 3);
cache.remove("key2");
tx.commit();
{code}
The Api should be implemented , that let you continue transaction in another 
thread.
method stop() should mark the transaction as unavailable for further commit.
method txStart() should resume the transaction. 

reason behind the proposal :
Consider the next scenario:
we begin transaction, doing some changes and start async future that will be 
able to introduce futher changes into transaction and commit it in the end.





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

Re: Real size of a stored data in IgniteCache

[Andrey Mashenkov]

Hi Vyacheslav,

No, Ignite doesn't provide such methods.
However, you can see how it is overcome in one of EvictionPolicy
implementations and make a proposal how it could be implemented.

On Thu, Mar 30, 2017 at 5:20 PM, Vyacheslav Daradur 
wrote:

> Alexey,
>
> Yes, it works in my case.
>
> Does Ignite provide any methods for my case?
>
>
> 2017-03-30 17:04 GMT+03:00 Alexey Kuznetsov :
>
> > Vyacheslav,
> >
> > Will JVisualVM + heap dump + analyzing objects count and  sizes in heap
> > dump works in your case?
> >
> >
> >
> > On Thu, Mar 30, 2017 at 8:26 PM, Vyacheslav Daradur  >
> > wrote:
> >
> > > Hello everyone.
> > >
> > > How do I know real size of a stored data in the IgniteCache?
> > >
> > > For example: I created new cache and put one object, and I want to know
> > > real size of one object in cache.
> > >
> > > try (Ignite ignite = Ignition.start("cache-config.xml")) {
> > >
> > > IgniteCache cache = ignite.getOrCreateCache("
> > > myCache");
> > >
> > > MyObject obj = new MyObject()
> > >
> > > cache.put(obj.getLongId(), obj);
> > > }
> > >
> > > I looked at ClusterMetrics and CacheMetrics, but I'am not sure wich
> > method
> > > is real needed to me.
> > >
> > > p.s. I haven't found the answer in search.
> > >
> > > --
> > > Best Regards, Vyacheslav
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>
>
>
> --
> Best Regards, Vyacheslav
>



-- 
Best regards,
Andrey V. Mashenkov

Re: putting entity into cache while commiting.Why!?

[Alexey Goncharuk]

Note that you call doInTransaction() for ignite(1), but you have acquired
the cache reference for ignite(0), thus your cache.put() commits
immediately from another node, because transactional scope is node-local.

If you change the test either to use ignite(0) for doInTransaction, or to
get the cache in the callable like ignite(1).cache("testCache"), the test
will not throw an exception. Note that it will hang because doInTrasaction
starts a pessimistic transaction which acquires a lock on key1, and then
you put it to infinite sleep. The lock prevents the transaction from
the main thread to commit.

2017-03-30 15:44 GMT+03:00 ALEKSEY KUZNETSOV :

> I've edited code and now DIRTY READ occures!
>
> Ignite ignite0 = ignite(0);
> IgniteTransactions transactions = ignite0.transactions();
> IgniteCache cache = ignite0.getOrCreateCache("testCache");
> Object monitor = new Object();
>
> GridTestUtils.runAsync(new Callable() {
> @Override
> public Object call() throws Exception {
> doInTransaction(ignite(1), new Callable() {
> @Override
> public Object call() throws Exception {
> synchronized (monitor) {
> cache.put("key1", "val1!");
> monitor.wait();
> fail();
> return null;
> }
> }
> });
> return null;
> }
> });
> Thread.currentThread().sleep(1000);<-- dirty read occures only if
> we sleep some time !
> Transaction tx =
> transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> TransactionIsolation.READ_COMMITTED);
> String key1Value = cache.get("key1");
> if(key1Value.equals("val1!"))
> throw new RuntimeException("dirty read!");<-- exception does
> happen!
> cache.put("key1", "val1");
> cache.put("key2", "val2");
> cache.put("key3", "val3");
> tx.commit();
>
>
> чт, 30 мар. 2017 г. в 14:04, Alexey Goncharuk  >:
>
> > Agree, the cache is transactional, however, the second transaction does
> not
> > see the dirty value:
> >
> > Ignite ignite0 = ignite(0);
> > IgniteTransactions transactions = ignite0.transactions();
> > final IgniteCache cache =
> > ignite0.getOrCreateCache("testCache");
> >
> > final Object monitor = new Object();
> >
> > GridTestUtils.runAsync(new Callable() {
> > @Override
> > public Object call() throws Exception {
> > synchronized (monitor){
> > doInTransaction(ignite(1), new Callable() {
> > @Override
> > public Object call() throws Exception {
> > cache.put("key1", "val1");
> > monitor.wait();
> > System.out.println("continue first transaction");
> > return null;
> > }
> > });
> > }
> > return null;
> > }
> > });
> >
> > Transaction tx =
> > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > TransactionIsolation.READ_COMMITTED);
> > assertNull(cache.get("key1")); // <- This check passes
> > tx.commit();
> >
> >
> > 2017-03-30 13:30 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > Well, i changed code , added :
> > >
> > > CacheConfiguration config = cache.getConfiguration(
> > > CacheConfiguration.class);
> > > System.out.println(config.getAtomicityMode());//TRANSACTIONAL
> > >
> > > So, atomicity is transactional
> > >
> > > чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Aleksey,
> > > >
> > > > It looks like in your test the result of method atomicityMode() is
> not
> > > used
> > > > because you do getOrCreateCache() without the configuration argument,
> > > which
> > > > will create a cache with a default configuration, which is ATOMIC.
> > > >
> > > > 2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > public class FooTest extends GridCacheAbstractSelfTest {
> > > > >
> > > > > @Override
> > > > > protected void afterTestsStopped() throws Exception {
> > > > > super.afterTestsStopped();
> > > > > stopAllGrids();
> > > > > }
> > > > >
> > > > > @Override
> > > > > protected int gridCount() {
> > > > > return 3;
> > > > > }
> > > > >
> > > > > @Override
> > > > > protected CacheMode cacheMode() {
> > > > > return CacheMode.PARTITIONED;
> > > > > }
> > > > >
> > > > > @Override
> > > > > protected CacheAtomicityMode atomicityMode() {
> > > > > return CacheAtomicityMode.TRANSACTIONAL;
> > > > > }
> > > > >
> > > > > public void testLoggingTransactions() throws
> > InterruptedException {
> > > > > Ignite ignite0 = ignite(0);
> > > > > IgniteTransactions transactions = ignite0.transactions();
> > > > > IgniteCache 

Re: Real size of a stored data in IgniteCache

[Vyacheslav Daradur]

Alexey,

Yes, it works in my case.

Does Ignite provide any methods for my case?


2017-03-30 17:04 GMT+03:00 Alexey Kuznetsov :

> Vyacheslav,
>
> Will JVisualVM + heap dump + analyzing objects count and  sizes in heap
> dump works in your case?
>
>
>
> On Thu, Mar 30, 2017 at 8:26 PM, Vyacheslav Daradur 
> wrote:
>
> > Hello everyone.
> >
> > How do I know real size of a stored data in the IgniteCache?
> >
> > For example: I created new cache and put one object, and I want to know
> > real size of one object in cache.
> >
> > try (Ignite ignite = Ignition.start("cache-config.xml")) {
> >
> > IgniteCache cache = ignite.getOrCreateCache("
> > myCache");
> >
> > MyObject obj = new MyObject()
> >
> > cache.put(obj.getLongId(), obj);
> > }
> >
> > I looked at ClusterMetrics and CacheMetrics, but I'am not sure wich
> method
> > is real needed to me.
> >
> > p.s. I haven't found the answer in search.
> >
> > --
> > Best Regards, Vyacheslav
> >
>
>
>
> --
> Alexey Kuznetsov
>



-- 
Best Regards, Vyacheslav

[GitHub] ignite pull request #1702: Ignite 4587

[agura]

GitHub user agura opened a pull request:

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

Ignite 4587



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

$ git pull https://github.com/agura/incubator-ignite ignite-4587

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

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


commit f0dcbbdecd10ee9afee3cb0c5a96bb1540d0c06a
Author: Max Kozlov 
Date:   2017-02-13T09:20:51Z

Delete CLOCK mode in CacheAtomicWriteOrderMode.

commit a37ff76168613007d3ca09c06688bc6456e4c330
Author: Max Kozlov 
Date:   2017-02-13T09:27:28Z

Delete use CLOCK for ignite-core.

commit 25d4ea5003773b739baba2c2d5c3e7be2194ba7a
Author: Max Kozlov 
Date:   2017-02-13T09:43:59Z

Fix tests CLOCK change to PRIMARY and delete same test.

commit fcc4d8567b9ec39bb9632cf64da5f4b4390a5928
Author: Max Kozlov 
Date:   2017-02-13T13:14:25Z

Delete CLOCK, and remove check FULL_SYNC.

commit 062d631d6b6968963bcb6ef6431d622366b11706
Author: Max Kozlov 
Date:   2017-02-13T13:15:41Z

Change from CLOCK to PRIMARY in CacheConfigurationTest.cs.

commit 92e11e85cc3490b8544746e2b98336a29316c725
Author: Max Kozlov 
Date:   2017-02-13T17:00:29Z

Fix method fastMap.

commit bc7a9bd88b8d9fc18a291adbb7eb05dd1c2c0862
Author: Max Kozlov 
Date:   2017-02-27T11:33:08Z

Merge branch 'master' into ignite-4587

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicSingleUpdateFuture.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateFuture.java

commit a61e5661d182fec218f7a0ee6a3b8f484e9a7643
Author: Max Kozlov 
Date:   2017-02-27T11:40:22Z

Remove isFastMap method in GridDhtAtomicCache class because always returns 
false.

commit 8a96fdf199bf476bd417192d795fcf4d1135deb8
Author: Max Kozlov 
Date:   2017-02-27T13:25:13Z

Remove field updVer in GridNearAtomicAbstractUpdateFuture. Remove parametr 
updVer in GridNearAtomicSingleUpdateFuture.mapSingleUpdate, 
GridNearAtomicUpdateFuture.mapSingleUpdate and 
GridNearAtomicUpdateFuture.mapUpdate.

commit 72c15e5974fa253b919d001677e98a87ed219991
Author: Max Kozlov 
Date:   2017-03-01T13:01:35Z

Remove CacheAtomicWriteOrderMode.java and refactoring core module.

commit 97fdb0e03492047fe64191059a1725775e335b7b
Author: Max Kozlov 
Date:   2017-03-01T13:04:13Z

Refactoring yardstick module.

commit 82790a862f93378a09a8e8a7b52956bbe77f9085
Author: Max Kozlov 
Date:   2017-03-01T13:05:32Z

Refactoring idexing module.

commit 3d5c1345dc550b622569b0e63e019a4ae92539a8
Author: Max Kozlov 
Date:   2017-03-01T13:27:44Z

Refactoring visor-console module.

commit 5adaa1160190896b653ad4c5ea1035bc6c86048c
Author: Max Kozlov 
Date:   2017-03-01T20:41:21Z

Some loose change.

commit a60841220c1fe20c22e3122090bcfb98fa1f4b18
Author: Max Kozlov 
Date:   2017-03-01T20:41:46Z

Delete PRIMARY in test config.

commit ed3370f2fd750485a11d850b515092e4b26b6940
Author: Max Kozlov 
Date:   2017-03-01T20:42:42Z

Delete support write order mode in web-console.

commit 59af0367fe7b74ebb826c1cb57adc8cacf13ee49
Author: Max Kozlov 
Date:   2017-03-01T20:43:19Z

Delete write order mode in dotnet platform.

commit 32d2308647646027fa5792d05e532a041a974e73
Author: Max Kozlov 
Date:   2017-03-01T20:44:55Z

Delete atomicWriteOrderMode in config cpp platform.

commit 6265f33bf9401bf8c5449bb3da7daeadca086b3b
Author: Max Kozlov 
Date:   2017-03-01T22:21:35Z

Remove and rename tests.

commit 9b02f81f2e9d21ad2c2ad4e5fe4efd52545f59fb
Author: Max Kozlov 
Date:   2017-03-07T11:45:24Z

Remove GridClockSyncProcessor and related code removed.

commit decc8021f7ae5c0073f8cf15c7ca64a57305aa3b
Author: Max Kozlov 
Date:   2017-03-09T11:34:40Z

Remove GridClockSyncProcessor, GridTimeSyncProcessorSelfTest and related.

commit bdc8f2078fe914f4bd85ce0c7dc6ca8689e223e4
Author: Max Kozlov 
Date:   2017-03-09T14:20:44Z

Remove globalTime.

commit 20a87f832e4b3f46c8da511e85e08f1f6203b693
Author: Max Kozlov 
Date:   2017-03-09T15:29:23Z

Remove updateTime.

commit ea3d5de8437df5cafcf8315dde1ac6d113eef6ad
Author: Max Kozlov 
Date:   2017-03-09T15:35:52Z

wip

commit 

Re: Real size of a stored data in IgniteCache

[Alexey Kuznetsov]

Vyacheslav,

Will JVisualVM + heap dump + analyzing objects count and  sizes in heap
dump works in your case?



On Thu, Mar 30, 2017 at 8:26 PM, Vyacheslav Daradur 
wrote:

> Hello everyone.
>
> How do I know real size of a stored data in the IgniteCache?
>
> For example: I created new cache and put one object, and I want to know
> real size of one object in cache.
>
> try (Ignite ignite = Ignition.start("cache-config.xml")) {
>
> IgniteCache cache = ignite.getOrCreateCache("
> myCache");
>
> MyObject obj = new MyObject()
>
> cache.put(obj.getLongId(), obj);
> }
>
> I looked at ClusterMetrics and CacheMetrics, but I'am not sure wich method
> is real needed to me.
>
> p.s. I haven't found the answer in search.
>
> --
> Best Regards, Vyacheslav
>



-- 
Alexey Kuznetsov

[jira] [Created] (IGNITE-4886) VisorServiceTask should properly handle ClassNotFound exceptions.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-4886:


 Summary: VisorServiceTask should properly handle ClassNotFound 
exceptions.
 Key: IGNITE-4886
 URL: https://issues.apache.org/jira/browse/IGNITE-4886
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 1.9
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.0


{code}
org.apache.ignite.IgniteException: Failed to find service class: 
at 
org.apache.ignite.internal.processors.service.ServiceDescriptorImpl.serviceClass(ServiceDescriptorImpl.java:68)
at 
org.apache.ignite.internal.visor.service.VisorServiceDescriptor.(VisorServiceDescriptor.java:71)
at 
org.apache.ignite.internal.visor.service.VisorServiceTask$VisorServiceJob.run(VisorServiceTask.java:65)
at 
org.apache.ignite.internal.visor.service.VisorServiceTask$VisorServiceJob.run(VisorServiceTask.java:44)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:560)
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6564)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:554)
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:483)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1114)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: 
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1702)
at 
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1547)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at 
org.apache.ignite.internal.processors.service.ServiceDescriptorImpl.serviceClass(ServiceDescriptorImpl.java:65)
... 18 common frames omitted
{code}



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

Re: IGNITE-4052 ready for review

[Вадим Опольский]

Hello everyone!

Nikolay, method Protos.FrameworkInfo.Builder#setRoleBytes and
Protos.FrameworkInfo.Builder#setUserBytes were added into
IgniteFrameworkInfoTest.

Details please what do you want to me do with the methods. How correctly to
test methods work?

The code was changed with official "Coding Guidelines" and the lib was
deleted.

I didn't try to use new properties on real mesos cluster.

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

Vadim Opolski

*You used only Protos.FrameworkInfo.Builder#setRole method, but also exists
Protos.FrameworkInfo.Builder#setRoleBytes. Please, pay attention on it. You
did some code styles changes which conflict with official "Coding
Guidelines" (see *
*https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute*
*).
Also you use lib for testing with licence different from Apache Licence
2.0. Are you sure that for this test you need additional libs? I think this
can be implemented without them.*

*Also did you try to use new properties on real mesos cluster? Did work
properly?*

2017-03-24 15:54 GMT+03:00 Вадим Опольский :

> Nikolay, I will add properties for mesos role and unit test next week.
>
> -- Forwarded message --
> From: Вадим Опольский 
> Date: 2017-03-22 15:53 GMT+03:00
> Subject: Re: IGNITE-4052 ready for review
> To: dev@ignite.apache.org
>
>
> Nikolay, just changed status to "path available".
>
> 2017-03-22 15:44 GMT+03:00 Nikolai Tikhonov :
>
>> Hi Вадим!
>>
>> Thank you for your contribution!
>> Please change status of the ticket to "path available". I'll review your
>> changes.
>>
>> Thanks,
>> Nikolay
>>
>> On Wed, Mar 22, 2017 at 3:36 PM, Вадим Опольский 
>> wrote:
>>
>> > Hello everybody!
>> >
>> > Nikolay,
>> >  review please https://github.com/apache/ignite/pull/1662 .
>> >
>> > Added ability to configure current user parameters via system env
>> > properties - "MESOS_USER".
>> >
>> > Vadim Opolski
>> >
>> >
>> > -- Forwarded message --
>> > From: Вадим Опольский 
>> > Date: 2017-03-21 14:40 GMT+03:00
>> > Subject: Assignee IGNITE-4052
>> > To: dev@ignite.apache.org
>> >
>> >
>> > Dear sirs !
>> >
>> > I want to resolve issue IGNITE-4052.
>> >
>> > https://issues.apache.org/jira/browse/IGNITE-4052
>> >
>> > Is it actual ?
>> >
>> > Vadim Opolski
>> >
>> >
>>
>
>
>

Real size of a stored data in IgniteCache

[Vyacheslav Daradur]

Hello everyone.

How do I know real size of a stored data in the IgniteCache?

For example: I created new cache and put one object, and I want to know
real size of one object in cache.

try (Ignite ignite = Ignition.start("cache-config.xml")) {

IgniteCache cache = ignite.getOrCreateCache("myCache");

MyObject obj = new MyObject()

cache.put(obj.getLongId(), obj);
}

I looked at ClusterMetrics and CacheMetrics, but I'am not sure wich method
is real needed to me.

p.s. I haven't found the answer in search.

-- 
Best Regards, Vyacheslav

[GitHub] ignite pull request #1701: IGNITE-2558: Remove extends MutableConfiguration,...

[dream-x]

GitHub user dream-x opened a pull request:

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

IGNITE-2558: Remove extends MutableConfiguration, add setCopyOnRead method.

[Jira](https://issues.apache.org/jira/browse/IGNITE-2558)

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

$ git pull https://github.com/dream-x/ignite ignite-2558

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

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


commit 3ecd24102e87650ea944642a1002fbcedc51a626
Author: Max Kozlov 
Date:   2017-03-30T12:19:17Z

Remove extends MutableConfiguration, add setCopyOnRead method.




---
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: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Andrey Gura]

Den,

Mentioned enum is removed in PR for IGNITE-4587 issue. This PR isn't
merged into master branch yet.

On Thu, Mar 30, 2017 at 1:40 PM, Denis Magda  wrote:
> Do we need to merge anything else to the master branch or you mean the enum 
> was removed with the rest of the changes before and merged by Andrey G?
>
> —
> Denis
>
>> On Mar 30, 2017, at 5:16 AM, Kozlov Maxim  wrote:
>>
>> + Denis
>>
>>> 30 марта 2017 г., в 12:14, Kozlov Maxim >> > написал(а):
>>>
>>> Denis,
>>>
>>> CacheAtomicWriteOrderMode enum already removed.
>>>
 30 марта 2017 г., в 7:38, Denis Magda > написал(а):

 Maxim, Andrey G., Igniters,

 What if go further and remove CacheAtomicWriteOrderMode enum from the 
 public API at all? I see no sense to keep it for the only one option left 
 - PRIMARY.

 Any objections?

 —
 Denis

> On Feb 27, 2017, at 8:09 AM, Kozlov Maxim  > wrote:
>
> Hi Igniters,
>
> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only 
> one value PRIMARY. Andrey Gura, proposition remove 
> CacheAtomicWriteOrderMode enum. Will there be something special for this 
> purpose is enum?
>
> jira: https://issues.apache.org/jira/browse/IGNITE-4587 
>  
>  >
>
> --
> Best Regards,
> Max K.
>
>
>
>

>>>
>>> --
>>> Best Regards,
>>> Max K.
>>>
>>>
>>>
>>>
>>
>> --
>> Best Regards,
>> Max K.
>>
>>
>>
>>
>

[jira] [Created] (IGNITE-4885) .NET: Meaningless exception on generic type in BinaryConfiguration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4885:
--

 Summary: .NET: Meaningless exception on generic type in 
BinaryConfiguration
 Key: IGNITE-4885
 URL: https://issues.apache.org/jira/browse/IGNITE-4885
 Project: Ignite
  Issue Type: Bug
  Components: platforms
Affects Versions: 1.6
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.0


{{BinaryTypeConfiguration}} does not support open generic types (when 
parameters are not specified, like {{typeof(List<>)}} instead of 
{{typeof(List}}). But the exception is not helpful, and stack trace is 
very short (because of native transition).

We should try to provide meaningful exception message and a proper stack trace.



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

Re: putting entity into cache while commiting.Why!?

[ALEKSEY KUZNETSOV]

I've edited code and now DIRTY READ occures!

Ignite ignite0 = ignite(0);
IgniteTransactions transactions = ignite0.transactions();
IgniteCache cache = ignite0.getOrCreateCache("testCache");
Object monitor = new Object();

GridTestUtils.runAsync(new Callable() {
@Override
public Object call() throws Exception {
doInTransaction(ignite(1), new Callable() {
@Override
public Object call() throws Exception {
synchronized (monitor) {
cache.put("key1", "val1!");
monitor.wait();
fail();
return null;
}
}
});
return null;
}
});
Thread.currentThread().sleep(1000);<-- dirty read occures only if
we sleep some time !
Transaction tx =
transactions.txStart(TransactionConcurrency.OPTIMISTIC,
TransactionIsolation.READ_COMMITTED);
String key1Value = cache.get("key1");
if(key1Value.equals("val1!"))
throw new RuntimeException("dirty read!");<-- exception does happen!
cache.put("key1", "val1");
cache.put("key2", "val2");
cache.put("key3", "val3");
tx.commit();


чт, 30 мар. 2017 г. в 14:04, Alexey Goncharuk :

> Agree, the cache is transactional, however, the second transaction does not
> see the dirty value:
>
> Ignite ignite0 = ignite(0);
> IgniteTransactions transactions = ignite0.transactions();
> final IgniteCache cache =
> ignite0.getOrCreateCache("testCache");
>
> final Object monitor = new Object();
>
> GridTestUtils.runAsync(new Callable() {
> @Override
> public Object call() throws Exception {
> synchronized (monitor){
> doInTransaction(ignite(1), new Callable() {
> @Override
> public Object call() throws Exception {
> cache.put("key1", "val1");
> monitor.wait();
> System.out.println("continue first transaction");
> return null;
> }
> });
> }
> return null;
> }
> });
>
> Transaction tx =
> transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> TransactionIsolation.READ_COMMITTED);
> assertNull(cache.get("key1")); // <- This check passes
> tx.commit();
>
>
> 2017-03-30 13:30 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Well, i changed code , added :
> >
> > CacheConfiguration config = cache.getConfiguration(
> > CacheConfiguration.class);
> > System.out.println(config.getAtomicityMode());//TRANSACTIONAL
> >
> > So, atomicity is transactional
> >
> > чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Aleksey,
> > >
> > > It looks like in your test the result of method atomicityMode() is not
> > used
> > > because you do getOrCreateCache() without the configuration argument,
> > which
> > > will create a cache with a default configuration, which is ATOMIC.
> > >
> > > 2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > public class FooTest extends GridCacheAbstractSelfTest {
> > > >
> > > > @Override
> > > > protected void afterTestsStopped() throws Exception {
> > > > super.afterTestsStopped();
> > > > stopAllGrids();
> > > > }
> > > >
> > > > @Override
> > > > protected int gridCount() {
> > > > return 3;
> > > > }
> > > >
> > > > @Override
> > > > protected CacheMode cacheMode() {
> > > > return CacheMode.PARTITIONED;
> > > > }
> > > >
> > > > @Override
> > > > protected CacheAtomicityMode atomicityMode() {
> > > > return CacheAtomicityMode.TRANSACTIONAL;
> > > > }
> > > >
> > > > public void testLoggingTransactions() throws
> InterruptedException {
> > > > Ignite ignite0 = ignite(0);
> > > > IgniteTransactions transactions = ignite0.transactions();
> > > > IgniteCache cache =
> > > > ignite0.getOrCreateCache("testCache");
> > > > Object monitor = new Object();
> > > >
> > > > GridTestUtils.runAsync(new Callable() {
> > > > @Override
> > > > public Object call() throws Exception {
> > > > synchronized (monitor){
> > > > doInTransaction(ignite(1), new
> Callable() {
> > > > @Override
> > > > public Object call() throws Exception {
> > > > cache.put("key1", "val1");
> > > > monitor.wait();
> > > > System.out.println("continue first
> > > > transaction");
> > > > return null;
> > > > }
> > > > });
> > > > }
> > > > return null;
> > > > }
> > > > });
> > > >
> > > > 

Re: Question: local cache on client nodes

[Denis Magda]

It's abdolutely fine to have local caches on client nodes if an application
needs to cache data locally in hashtable like data structure and talk to it
using Ignite APIs.

The upshot is that this kind of cache can be started on any node and we
should keep supporting this capability in 2.0.

--
Denis

On Thursday, March 30, 2017, Sergey Chugunov 
wrote:

> Hello Igniters,
>
> Participating in big effort of reworking cache storage structures
> (IGNITE-3477 [1]) I came across a test that looks strange to me:
> *CacheStopAndDestroySelfTest::testLocalClose*.
>
> It is very simple: it starts two server nodes and one client node (with
> forceServerMode flag set to true), then creates local cache on one node,
> then adds some values to it on ALL nodes including client.
>
> It looks very confusing for me as I thought that client nodes aren't
> supposed to consume a lot of resources as they may be started on small
> machines, offheap PageMemory structures aren't allocated on clients at all.
> Which leads to test failure, obviously.
>
> Could you please clarify what the local cache is, how it is supposed to be
> used?
> Should it be started on client nodes as well as on server ones or it is
> something wrong with the test itself?
>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3477
>
>
> Thanks,
> Sergey Chugunov
>

Re: ignite-4884 - ready for review (Visorcmd - minor text mistake)

[Alexey Kuznetsov]

I will do it tomorrow.

On Thu, Mar 30, 2017 at 6:29 PM, Vyacheslav Daradur 
wrote:

> Hello everyone.
>
> Looks like minor mistake.
>
> Please review if someone has time.
>
> --
> Best Regards, Vyacheslav
>



-- 
Alexey Kuznetsov

[GitHub] ignite pull request #1700: Ignite 4760

[vadopolski]

Github user vadopolski closed the pull request at:

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


---
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 #1700: Ignite 4760

[vadopolski]

GitHub user vadopolski opened a pull request:

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

Ignite 4760



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

$ git pull https://github.com/vadopolski/ignite ignite-4760

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

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


commit 5c048d214585842c2dc88a4207a7069779d301f9
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T09:06:12Z

ignite -4760
Added Map ThreadLocal.

commit ee483f664776d8d17470bb2eec463952851ac0a0
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T09:11:40Z

ignite -4760
Added Map for different regions.

commit d10e937123dcd1e5d0a2ffa324ea21bfe8575105
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T11:20:29Z

ignite -4760
Changed threadLocalForCache to use per-cache thread local for 
HibernateNonStrictAccessStrategy.

commit b7b47b3eca9df47e3572166eb584cc96153ced0b
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T11:39:03Z

ignite -4760
Changed threadLocalForCache to use per-cache thread local for 
HibernateNonStrictAccessStrategy.




---
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 #1699: Ignite 4760

[vadopolski]

Github user vadopolski closed the pull request at:

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


---
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 #1699: Ignite 4760

[vadopolski]

GitHub user vadopolski opened a pull request:

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

Ignite 4760



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

$ git pull https://github.com/vadopolski/ignite ignite-4760

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

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


commit 5c048d214585842c2dc88a4207a7069779d301f9
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T09:06:12Z

ignite -4760
Added Map ThreadLocal.

commit ee483f664776d8d17470bb2eec463952851ac0a0
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T09:11:40Z

ignite -4760
Added Map for different regions.

commit d10e937123dcd1e5d0a2ffa324ea21bfe8575105
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T11:20:29Z

ignite -4760
Changed threadLocalForCache to use per-cache thread local for 
HibernateNonStrictAccessStrategy.

commit b7b47b3eca9df47e3572166eb584cc96153ced0b
Author: vopolski <2w3e4r5t>
Date:   2017-03-30T11:39:03Z

ignite -4760
Changed threadLocalForCache to use per-cache thread local for 
HibernateNonStrictAccessStrategy.




---
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-4884 - ready for review (Visorcmd - minor text mistake)

[Vyacheslav Daradur]

Hello everyone.

Looks like minor mistake.

Please review if someone has time.

-- 
Best Regards, Vyacheslav

[GitHub] ignite pull request #1698: IGNITE-4884

[daradurvs]

GitHub user daradurvs opened a pull request:

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

IGNITE-4884



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

$ git pull https://github.com/daradurvs/ignite ignite-4884

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

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


commit 379866e69c3d3bde9099436ce6644d9c8287cdba
Author: Vyacheslav Daradur 
Date:   2017-03-30T11:20:46Z

ignite-4884: fixed




---
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-4884) Visorcmd - minor text mistake

[Vyacheslav Daradur (JIRA)]

Vyacheslav Daradur created IGNITE-4884:
--

 Summary: Visorcmd - minor text mistake
 Key: IGNITE-4884
 URL: https://issues.apache.org/jira/browse/IGNITE-4884
 Project: Ignite
  Issue Type: Task
Reporter: Vyacheslav Daradur
Assignee: Vyacheslav Daradur
Priority: Trivial
 Fix For: 2.0


{noformat}
'Hi' - Number of cache hits.
'Mi' - Number of cache misses.
'Rd' - number of cache reads.
'Wr' - Number of cache writes.
{noformat}

Looks like "number of cache reads" should begin with the capital "N"



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

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Yakov Zhdanov]

Alex, I am finishing this up.

--Yakov

2017-03-30 14:03 GMT+03:00 Александр Меньшиков :

> Yakov, can I take this ticket or you have already started to implement it?
> Ask because you are an assignee in JIRA.
>
> 2017-03-07 22:21 GMT+03:00 Denis Magda :
>
>> Good, the ticket is ready:
>> https://issues.apache.org/jira/browse/IGNITE-4799 <
>> https://issues.apache.org/jira/browse/IGNITE-4799>
>>
>> —
>> Denis
>>
>> > On Mar 7, 2017, at 1:47 AM, Yakov Zhdanov  wrote:
>> >
>> >>> What’s about compute engine load balancers then? They rely on the
>> > metrics received from remote nodes.
>> >
>> > First of all, that was poor design decision - to make different
>> components
>> > dependant, possibly, through user-defined implementation of Discovery
>> Spi.
>> >
>> > What you say makes sense to me. Let's remove HB frequency from Discovery
>> > SPI API and adjust it accordingly to
>> > IgniteConfiguraion.getMetricsUpdateFrequency.
>> > You should also consider completely removing heartbeats from failure
>> > detection process - it should rely only on internal ping packets.
>> >
>> > --Yakov
>>
>>
>

Re: putting entity into cache while commiting.Why!?

[Alexey Goncharuk]

Agree, the cache is transactional, however, the second transaction does not
see the dirty value:

Ignite ignite0 = ignite(0);
IgniteTransactions transactions = ignite0.transactions();
final IgniteCache cache =
ignite0.getOrCreateCache("testCache");

final Object monitor = new Object();

GridTestUtils.runAsync(new Callable() {
@Override
public Object call() throws Exception {
synchronized (monitor){
doInTransaction(ignite(1), new Callable() {
@Override
public Object call() throws Exception {
cache.put("key1", "val1");
monitor.wait();
System.out.println("continue first transaction");
return null;
}
});
}
return null;
}
});

Transaction tx =
transactions.txStart(TransactionConcurrency.OPTIMISTIC,
TransactionIsolation.READ_COMMITTED);
assertNull(cache.get("key1")); // <- This check passes
tx.commit();


2017-03-30 13:30 GMT+03:00 ALEKSEY KUZNETSOV :

> Well, i changed code , added :
>
> CacheConfiguration config = cache.getConfiguration(
> CacheConfiguration.class);
> System.out.println(config.getAtomicityMode());//TRANSACTIONAL
>
> So, atomicity is transactional
>
> чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk  >:
>
> > Aleksey,
> >
> > It looks like in your test the result of method atomicityMode() is not
> used
> > because you do getOrCreateCache() without the configuration argument,
> which
> > will create a cache with a default configuration, which is ATOMIC.
> >
> > 2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > public class FooTest extends GridCacheAbstractSelfTest {
> > >
> > > @Override
> > > protected void afterTestsStopped() throws Exception {
> > > super.afterTestsStopped();
> > > stopAllGrids();
> > > }
> > >
> > > @Override
> > > protected int gridCount() {
> > > return 3;
> > > }
> > >
> > > @Override
> > > protected CacheMode cacheMode() {
> > > return CacheMode.PARTITIONED;
> > > }
> > >
> > > @Override
> > > protected CacheAtomicityMode atomicityMode() {
> > > return CacheAtomicityMode.TRANSACTIONAL;
> > > }
> > >
> > > public void testLoggingTransactions() throws InterruptedException {
> > > Ignite ignite0 = ignite(0);
> > > IgniteTransactions transactions = ignite0.transactions();
> > > IgniteCache cache =
> > > ignite0.getOrCreateCache("testCache");
> > > Object monitor = new Object();
> > >
> > > GridTestUtils.runAsync(new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > synchronized (monitor){
> > > doInTransaction(ignite(1), new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > cache.put("key1", "val1");
> > > monitor.wait();
> > > System.out.println("continue first
> > > transaction");
> > > return null;
> > > }
> > > });
> > > }
> > > return null;
> > > }
> > > });
> > >
> > > Transaction tx =
> > > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > > TransactionIsolation.READ_COMMITTED);
> > > cache.put("key1", "val1");
> > > cache.put("key2", "val2");
> > > cache.put("key3", "val3");
> > > tx.commit();
> > >
> > > }
> > > }
> > >
> > >
> > > чт, 30 мар. 2017 г. в 11:55, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Can you please paste the full example?
> > > >
> > > > 2017-03-30 11:50 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > But i managed to read dirty. That is my example :
> > > > >
> > > > > Ignite ignite0 = ignite(0);
> > > > > IgniteTransactions transactions = ignite0.transactions();
> > > > > IgniteCache cache =
> > > > ignite0.getOrCreateCache("testCache");
> > > > > Object monitor = new Object();
> > > > >
> > > > > GridTestUtils.runAsync(new Callable() {
> > > > > @Override
> > > > > public Object call() throws Exception {
> > > > > synchronized (monitor){
> > > > > doInTransaction(ignite(1), new Callable() {
> > > > > @Override
> > > > > public Object call() throws Exception {
> > > > > cache.put("key1", "val1");
> > > > > monitor.wait();
> > > > > return null;
> > > > > }
> > > > > });
> > > > > }
> > > > > return null;
> > > > > }
> > > > > });
> > 

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[Александр Меньшиков]

Yakov, can I take this ticket or you have already started to implement it?
Ask because you are an assignee in JIRA.

2017-03-07 22:21 GMT+03:00 Denis Magda :

> Good, the ticket is ready:
> https://issues.apache.org/jira/browse/IGNITE-4799 <
> https://issues.apache.org/jira/browse/IGNITE-4799>
>
> —
> Denis
>
> > On Mar 7, 2017, at 1:47 AM, Yakov Zhdanov  wrote:
> >
> >>> What’s about compute engine load balancers then? They rely on the
> > metrics received from remote nodes.
> >
> > First of all, that was poor design decision - to make different
> components
> > dependant, possibly, through user-defined implementation of Discovery
> Spi.
> >
> > What you say makes sense to me. Let's remove HB frequency from Discovery
> > SPI API and adjust it accordingly to
> > IgniteConfiguraion.getMetricsUpdateFrequency.
> > You should also consider completely removing heartbeats from failure
> > detection process - it should rely only on internal ping packets.
> >
> > --Yakov
>
>

Question: local cache on client nodes

[Sergey Chugunov]

Hello Igniters,

Participating in big effort of reworking cache storage structures
(IGNITE-3477 [1]) I came across a test that looks strange to me:
*CacheStopAndDestroySelfTest::testLocalClose*.

It is very simple: it starts two server nodes and one client node (with
forceServerMode flag set to true), then creates local cache on one node,
then adds some values to it on ALL nodes including client.

It looks very confusing for me as I thought that client nodes aren't
supposed to consume a lot of resources as they may be started on small
machines, offheap PageMemory structures aren't allocated on clients at all.
Which leads to test failure, obviously.

Could you please clarify what the local cache is, how it is supposed to be
used?
Should it be started on client nodes as well as on server ones or it is
something wrong with the test itself?


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


Thanks,
Sergey Chugunov

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Denis Magda]

Do we need to merge anything else to the master branch or you mean the enum was 
removed with the rest of the changes before and merged by Andrey G?

—
Denis

> On Mar 30, 2017, at 5:16 AM, Kozlov Maxim  wrote:
> 
> + Denis
> 
>> 30 марта 2017 г., в 12:14, Kozlov Maxim > > написал(а):
>> 
>> Denis, 
>> 
>> CacheAtomicWriteOrderMode enum already removed.
>> 
>>> 30 марта 2017 г., в 7:38, Denis Magda >> > написал(а):
>>> 
>>> Maxim, Andrey G., Igniters,
>>> 
>>> What if go further and remove CacheAtomicWriteOrderMode enum from the 
>>> public API at all? I see no sense to keep it for the only one option left - 
>>> PRIMARY.
>>> 
>>> Any objections?
>>> 
>>> —
>>> Denis
>>> 
 On Feb 27, 2017, at 8:09 AM, Kozlov Maxim > wrote:
 
 Hi Igniters,
 
 After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only 
 one value PRIMARY. Andrey Gura, proposition remove 
 CacheAtomicWriteOrderMode enum. Will there be something special for this 
 purpose is enum?
 
 jira: https://issues.apache.org/jira/browse/IGNITE-4587 
  
 >
 
 --
 Best Regards,
 Max K.
 
 
 
 
>>> 
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 
> 
> --
> Best Regards,
> Max K.
> 
> 
> 
> 

Re: putting entity into cache while commiting.Why!?

[ALEKSEY KUZNETSOV]

Well, i changed code , added :

CacheConfiguration config = cache.getConfiguration(CacheConfiguration.class);
System.out.println(config.getAtomicityMode());//TRANSACTIONAL

So, atomicity is transactional

чт, 30 мар. 2017 г. в 12:43, Alexey Goncharuk :

> Aleksey,
>
> It looks like in your test the result of method atomicityMode() is not used
> because you do getOrCreateCache() without the configuration argument, which
> will create a cache with a default configuration, which is ATOMIC.
>
> 2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > public class FooTest extends GridCacheAbstractSelfTest {
> >
> > @Override
> > protected void afterTestsStopped() throws Exception {
> > super.afterTestsStopped();
> > stopAllGrids();
> > }
> >
> > @Override
> > protected int gridCount() {
> > return 3;
> > }
> >
> > @Override
> > protected CacheMode cacheMode() {
> > return CacheMode.PARTITIONED;
> > }
> >
> > @Override
> > protected CacheAtomicityMode atomicityMode() {
> > return CacheAtomicityMode.TRANSACTIONAL;
> > }
> >
> > public void testLoggingTransactions() throws InterruptedException {
> > Ignite ignite0 = ignite(0);
> > IgniteTransactions transactions = ignite0.transactions();
> > IgniteCache cache =
> > ignite0.getOrCreateCache("testCache");
> > Object monitor = new Object();
> >
> > GridTestUtils.runAsync(new Callable() {
> > @Override
> > public Object call() throws Exception {
> > synchronized (monitor){
> > doInTransaction(ignite(1), new Callable() {
> > @Override
> > public Object call() throws Exception {
> > cache.put("key1", "val1");
> > monitor.wait();
> > System.out.println("continue first
> > transaction");
> > return null;
> > }
> > });
> > }
> > return null;
> > }
> > });
> >
> > Transaction tx =
> > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > TransactionIsolation.READ_COMMITTED);
> > cache.put("key1", "val1");
> > cache.put("key2", "val2");
> > cache.put("key3", "val3");
> > tx.commit();
> >
> > }
> > }
> >
> >
> > чт, 30 мар. 2017 г. в 11:55, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Can you please paste the full example?
> > >
> > > 2017-03-30 11:50 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > But i managed to read dirty. That is my example :
> > > >
> > > > Ignite ignite0 = ignite(0);
> > > > IgniteTransactions transactions = ignite0.transactions();
> > > > IgniteCache cache =
> > > ignite0.getOrCreateCache("testCache");
> > > > Object monitor = new Object();
> > > >
> > > > GridTestUtils.runAsync(new Callable() {
> > > > @Override
> > > > public Object call() throws Exception {
> > > > synchronized (monitor){
> > > > doInTransaction(ignite(1), new Callable() {
> > > > @Override
> > > > public Object call() throws Exception {
> > > > cache.put("key1", "val1");
> > > > monitor.wait();
> > > > return null;
> > > > }
> > > > });
> > > > }
> > > > return null;
> > > > }
> > > > });
> > > >
> > > > Transaction tx =
> > > > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > > > TransactionIsolation.READ_COMMITTED);
> > > > cache.put("key1", "val1");
> > > >
> > > > And through debugging cache.put() method i can see in method
> > > > *org.apache.ignite.internal.processors.cache.distributed.
> > > > near.GridNearTxLocal#enlistWriteEntry*
> > > > that "key1" already *EXISTS *in internal cache :
> > > cacheCtx.cache().entryEx()
> > > > returns not null.
> > > >
> > > > ср, 29 мар. 2017 г. в 20:11, Alexander Fedotov <
> > > > alexander.fedot...@gmail.com
> > > > >:
> > > >
> > > > Hello Aleksey,
> > > >
> > > > No, the enlisted entry won't be visible for other transactions. Dirty
> > > reads
> > > > are not allowed in Ignite.
> > > >
> > > > Kind regards,
> > > > Alex
> > > >
> > > > 29 марта 2017 г. 7:36 PM пользователь "ALEKSEY KUZNETSOV" <
> > > > alkuznetsov...@gmail.com> написал:
> > > >
> > > > Hello, Igniters! I have one more question to you. Will appreciate any
> > > help.
> > > > Consider cache with near , dht configured not null.
> > > > When we start commit transaction , in method
> > > > *org.apache.ignite.internal.processors.cache.distributed.
> > > > near.GridNearTxLocal#enlistWriteEntry*
> > > > we put newly created entry into cache by executing entryEx().
> > > > I wonder if 

[GitHub] ignite pull request #1697: IGNITE-4849 Review and refactoring the versioned ...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4849  Review and refactoring the versioned classes



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

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

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

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


commit 225f9c70dc25aebceaa324ad18c240734c8b504f
Author: tledkov-gridgain 
Date:   2017-03-15T15:47:43Z

IGNITE-4827: remove LATE_AFF_ASSIGN_SINCE

commit f05710883a4fb020a099ca6722355e2468f043eb
Author: tledkov-gridgain 
Date:   2017-03-16T09:48:47Z

IGNITE-4827: LOAD_CACHE_JOB_SINCE and refactoring the class 
GridCacheAdapter.LoadKeysCallable and v2

commit 34414c1c5ddf26853822595f8bf0c18c0f5911a1
Author: tledkov-gridgain 
Date:   2017-03-16T09:52:37Z

IGNITE-4827: remove PartitionSizeLongTask.SINCE_VER

commit 152324f33037e896df59ae2ede0746b551f4e808
Author: tledkov-gridgain 
Date:   2017-03-16T13:00:57Z

IGNITE-4827: VisorCacheConfiguration remove compatibility with older 
versions

commit eb815762fe2003fc69bbbd7938e34cef71cbc851
Author: tledkov-gridgain 
Date:   2017-03-16T13:22:17Z

IGNITE-4827: remove GridDhtPartitionMap and rename GridDhtPartitionMap2

commit bdb63a2ed7cc64d598cbc0cf27124a3574c2599a
Author: tledkov-gridgain 
Date:   2017-03-16T13:26:35Z

IGNITE-4827: remove NEAR_JOB_SINCE

commit cde7ba7de4f60e3bb955f5c071b29582bcc1db28
Author: tledkov-gridgain 
Date:   2017-03-16T13:28:13Z

IGNITE-4827: minors

commit 039c1d334ae7def3fc00d905db2a0b5388199964
Author: tledkov-gridgain 
Date:   2017-03-16T13:33:19Z

IGNITE-4827: remove CUSTOM_MSG_ALLOW_JOINING_FOR_VERIFIED_SINCE

commit 021a22280257fd36392379fe4619ef109c9c7412
Author: tledkov-gridgain 
Date:   2017-03-16T13:52:50Z

IGNITE-4827: remove VisorCache compat

commit dbd2cb88e447261b0618f47f085f4ba0a594bd0d
Author: tledkov-gridgain 
Date:   2017-03-16T13:55:32Z

IGNITE-4827: remove MULTIPLE_CONN_SINCE_VER

commit 2dd6e75901b790c5d8bbd8a740bc94ebe0268483
Author: tledkov-gridgain 
Date:   2017-03-16T14:10:30Z

IGNITE-4827: remove PART_MAP_COMPRESS_SINCE

commit 0f7c4fb1d5a1b4d73d54be6cbbbef2a167df93e5
Author: tledkov-gridgain 
Date:   2017-03-16T14:24:28Z

IGNITE-4827: remove old rebalance API

commit aba09393f552b472434a86ccc6dbe05355a63f09
Author: tledkov-gridgain 
Date:   2017-03-16T14:39:47Z

IGNITE-4827: remove CacheContinuousQueryBatchAck.SINCE_VER

commit e3aeadf2d0bf1d039ea6e081945df9091d13427e
Author: tledkov-gridgain 
Date:   2017-03-16T15:32:24Z

IGNITE-4827: remove services compatibility with older version

commit 20422f1ed74abb6655ac7862e7d11409cd9b1464
Author: tledkov-gridgain 
Date:   2017-03-16T15:41:12Z

IGNITE-4827: remove BINARY_CFG_CHECK_SINCE

commit 663a07cbb9865d342fc3bf5612be1228f537358a
Author: tledkov-gridgain 
Date:   2017-03-16T16:08:11Z

IGNITE-4827: remove services compatibility with older version

commit 572ad53a7adca25b0a6a97712a1aae9e40271836
Author: tledkov-gridgain 
Date:   2017-03-17T07:23:16Z

IGNITE-4827: remove GridQueryRequest

commit 6e0aa1483bce6a0f869a9217f5e077b6913f5a08
Author: Alexey Kuznetsov 
Date:   2017-03-17T07:46:23Z

IGNITE-4827 Cleanup deprecated code.

commit 021068904901254f843553c6f7a2a181e2f29e93
Author: tledkov-gridgain 
Date:   2017-03-17T09:04:06Z

IGNITE-4827: remove SINGLE_GET_MSG_SINCE

commit 8e71cc803e10f25967465d80a5086cba19bf86aa
Author: tledkov-gridgain 
Date:   2017-03-17T09:30:05Z

IGNITE-4827: remove unused

commit 178d520d02022cdb8832f6a69b3c4a9fc4178f58
Author: tledkov-gridgain 
Date:   2017-03-17T09:30:14Z

Merge branch 'ignite-2.0' into ignite-4827

commit 1e3fc2d92bd484d051d27654a2785369a5859593
Author: tledkov-gridgain 
Date:   2017-03-17T09:36:03Z

IGNITE-4827: minors

commit f9d193abbb221f525c4fb3b657c76c583fb95210
Author: tledkov-gridgain 
Date:   2017-03-17T09:38:47Z

IGNITE-4827: remove LOCAL_STORE_KEEPS_PRIMARY_AND_BACKUPS_SINCE

commit 8118fa1be3fca9a3317dd8d9b6e44107bb68dd09
Author: tledkov-gridgain 
Date:   2017-03-17T11:51:35Z

IGNITE-4827: remove compatibility at compute closures

commit ace6e1875e8d1bc5918fffc05ff2afd69104f355
Author: tledkov-gridgain 

[jira] [Created] (IGNITE-4883) Web Console: Improve the tables on Admin Panel Screen

[Vica Abramova (JIRA)]

Vica Abramova created IGNITE-4883:
-

 Summary: Web Console: Improve the tables on Admin Panel Screen
 Key: IGNITE-4883
 URL: https://issues.apache.org/jira/browse/IGNITE-4883
 Project: Ignite
  Issue Type: Task
  Components: UI, wizards
Reporter: Vica Abramova


Tab Coutries:
- don't show number on Country column
- by default, do sorting by number of users (descendingly), not by alphabet
- show only number on User column (delete the title 'total rows')




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

Re: putting entity into cache while commiting.Why!?

[Alexey Goncharuk]

Aleksey,

It looks like in your test the result of method atomicityMode() is not used
because you do getOrCreateCache() without the configuration argument, which
will create a cache with a default configuration, which is ATOMIC.

2017-03-30 12:06 GMT+03:00 ALEKSEY KUZNETSOV :

> public class FooTest extends GridCacheAbstractSelfTest {
>
> @Override
> protected void afterTestsStopped() throws Exception {
> super.afterTestsStopped();
> stopAllGrids();
> }
>
> @Override
> protected int gridCount() {
> return 3;
> }
>
> @Override
> protected CacheMode cacheMode() {
> return CacheMode.PARTITIONED;
> }
>
> @Override
> protected CacheAtomicityMode atomicityMode() {
> return CacheAtomicityMode.TRANSACTIONAL;
> }
>
> public void testLoggingTransactions() throws InterruptedException {
> Ignite ignite0 = ignite(0);
> IgniteTransactions transactions = ignite0.transactions();
> IgniteCache cache =
> ignite0.getOrCreateCache("testCache");
> Object monitor = new Object();
>
> GridTestUtils.runAsync(new Callable() {
> @Override
> public Object call() throws Exception {
> synchronized (monitor){
> doInTransaction(ignite(1), new Callable() {
> @Override
> public Object call() throws Exception {
> cache.put("key1", "val1");
> monitor.wait();
> System.out.println("continue first
> transaction");
> return null;
> }
> });
> }
> return null;
> }
> });
>
> Transaction tx =
> transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> TransactionIsolation.READ_COMMITTED);
> cache.put("key1", "val1");
> cache.put("key2", "val2");
> cache.put("key3", "val3");
> tx.commit();
>
> }
> }
>
>
> чт, 30 мар. 2017 г. в 11:55, Alexey Goncharuk  >:
>
> > Can you please paste the full example?
> >
> > 2017-03-30 11:50 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > But i managed to read dirty. That is my example :
> > >
> > > Ignite ignite0 = ignite(0);
> > > IgniteTransactions transactions = ignite0.transactions();
> > > IgniteCache cache =
> > ignite0.getOrCreateCache("testCache");
> > > Object monitor = new Object();
> > >
> > > GridTestUtils.runAsync(new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > synchronized (monitor){
> > > doInTransaction(ignite(1), new Callable() {
> > > @Override
> > > public Object call() throws Exception {
> > > cache.put("key1", "val1");
> > > monitor.wait();
> > > return null;
> > > }
> > > });
> > > }
> > > return null;
> > > }
> > > });
> > >
> > > Transaction tx =
> > > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > > TransactionIsolation.READ_COMMITTED);
> > > cache.put("key1", "val1");
> > >
> > > And through debugging cache.put() method i can see in method
> > > *org.apache.ignite.internal.processors.cache.distributed.
> > > near.GridNearTxLocal#enlistWriteEntry*
> > > that "key1" already *EXISTS *in internal cache :
> > cacheCtx.cache().entryEx()
> > > returns not null.
> > >
> > > ср, 29 мар. 2017 г. в 20:11, Alexander Fedotov <
> > > alexander.fedot...@gmail.com
> > > >:
> > >
> > > Hello Aleksey,
> > >
> > > No, the enlisted entry won't be visible for other transactions. Dirty
> > reads
> > > are not allowed in Ignite.
> > >
> > > Kind regards,
> > > Alex
> > >
> > > 29 марта 2017 г. 7:36 PM пользователь "ALEKSEY KUZNETSOV" <
> > > alkuznetsov...@gmail.com> написал:
> > >
> > > Hello, Igniters! I have one more question to you. Will appreciate any
> > help.
> > > Consider cache with near , dht configured not null.
> > > When we start commit transaction , in method
> > > *org.apache.ignite.internal.processors.cache.distributed.
> > > near.GridNearTxLocal#enlistWriteEntry*
> > > we put newly created entry into cache by executing entryEx().
> > > I wonder if this entry will became visible for other transactions!?
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> > > --
> > >
> > > *Best Regards,*
> > >
> > > *Kuznetsov Aleksey*
> > >
> >
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

[GitHub] ignite pull request #1695: IGNITE-3506 .NET: Fix ContinuousQuery, QueryBase,...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-3506 .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class 
constants



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

$ git pull https://github.com/ptupitsyn/ignite ignite-3506

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

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


commit 8631157416527d67e307a3a94cb76c9b73223b13
Author: Pavel Tupitsyn 
Date:   2017-03-30T07:34:15Z

IGNITE-3506 .NET: Fix ContinuousQuery, QueryBase, and SqlFieldsQuery class 
constants

commit 1ef4ba2a7af15f7387945dc3f7434472a6921fe5
Author: Pavel Tupitsyn 
Date:   2017-03-30T07:38:01Z

Add defaults test

commit 6e55d1dfc179e73cb77cd8d245a15958a4ced06c
Author: Pavel Tupitsyn 
Date:   2017-03-30T07:41:46Z

Fix QueryBase

commit 099d056bac19bb4f2f3b1f2151315e0cb31512e4
Author: Pavel Tupitsyn 
Date:   2017-03-30T07:42:39Z

Fix SqlFieldsQuery




---
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: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Kozlov Maxim]

+ Denis

> 30 марта 2017 г., в 12:14, Kozlov Maxim  написал(а):
> 
> Denis, 
> 
> CacheAtomicWriteOrderMode enum already removed.
> 
>> 30 марта 2017 г., в 7:38, Denis Magda  написал(а):
>> 
>> Maxim, Andrey G., Igniters,
>> 
>> What if go further and remove CacheAtomicWriteOrderMode enum from the public 
>> API at all? I see no sense to keep it for the only one option left - PRIMARY.
>> 
>> Any objections?
>> 
>> —
>> Denis
>> 
>>> On Feb 27, 2017, at 8:09 AM, Kozlov Maxim  wrote:
>>> 
>>> Hi Igniters,
>>> 
>>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only 
>>> one value PRIMARY. Andrey Gura, proposition remove 
>>> CacheAtomicWriteOrderMode enum. Will there be something special for this 
>>> purpose is enum?
>>> 
>>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 
>>> 
>>> 
>>> --
>>> Best Regards,
>>> Max K.
>>> 
>>> 
>>> 
>>> 
>> 
> 
> --
> Best Regards,
> Max K.
> 
> 
> 
> 

--
Best Regards,
Max K.

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

[Kozlov Maxim]

Denis, 

CacheAtomicWriteOrderMode enum already removed.

> 30 марта 2017 г., в 7:38, Denis Magda  написал(а):
> 
> Maxim, Andrey G., Igniters,
> 
> What if go further and remove CacheAtomicWriteOrderMode enum from the public 
> API at all? I see no sense to keep it for the only one option left - PRIMARY.
> 
> Any objections?
> 
> —
> Denis
> 
>> On Feb 27, 2017, at 8:09 AM, Kozlov Maxim  wrote:
>> 
>> Hi Igniters,
>> 
>> After remove CLOCK mode, CacheAtomicWriteOrderMode enum contains now only 
>> one value PRIMARY. Andrey Gura, proposition remove CacheAtomicWriteOrderMode 
>> enum. Will there be something special for this purpose is enum?
>> 
>> jira: https://issues.apache.org/jira/browse/IGNITE-4587 
>> 
>> 
>> --
>> Best Regards,
>> Max K.
>> 
>> 
>> 
>> 
> 

--
Best Regards,
Max K.

Re: putting entity into cache while commiting.Why!?

[ALEKSEY KUZNETSOV]

public class FooTest extends GridCacheAbstractSelfTest {

@Override
protected void afterTestsStopped() throws Exception {
super.afterTestsStopped();
stopAllGrids();
}

@Override
protected int gridCount() {
return 3;
}

@Override
protected CacheMode cacheMode() {
return CacheMode.PARTITIONED;
}

@Override
protected CacheAtomicityMode atomicityMode() {
return CacheAtomicityMode.TRANSACTIONAL;
}

public void testLoggingTransactions() throws InterruptedException {
Ignite ignite0 = ignite(0);
IgniteTransactions transactions = ignite0.transactions();
IgniteCache cache =
ignite0.getOrCreateCache("testCache");
Object monitor = new Object();

GridTestUtils.runAsync(new Callable() {
@Override
public Object call() throws Exception {
synchronized (monitor){
doInTransaction(ignite(1), new Callable() {
@Override
public Object call() throws Exception {
cache.put("key1", "val1");
monitor.wait();
System.out.println("continue first transaction");
return null;
}
});
}
return null;
}
});

Transaction tx =
transactions.txStart(TransactionConcurrency.OPTIMISTIC,
TransactionIsolation.READ_COMMITTED);
cache.put("key1", "val1");
cache.put("key2", "val2");
cache.put("key3", "val3");
tx.commit();

}
}


чт, 30 мар. 2017 г. в 11:55, Alexey Goncharuk :

> Can you please paste the full example?
>
> 2017-03-30 11:50 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > But i managed to read dirty. That is my example :
> >
> > Ignite ignite0 = ignite(0);
> > IgniteTransactions transactions = ignite0.transactions();
> > IgniteCache cache =
> ignite0.getOrCreateCache("testCache");
> > Object monitor = new Object();
> >
> > GridTestUtils.runAsync(new Callable() {
> > @Override
> > public Object call() throws Exception {
> > synchronized (monitor){
> > doInTransaction(ignite(1), new Callable() {
> > @Override
> > public Object call() throws Exception {
> > cache.put("key1", "val1");
> > monitor.wait();
> > return null;
> > }
> > });
> > }
> > return null;
> > }
> > });
> >
> > Transaction tx =
> > transactions.txStart(TransactionConcurrency.OPTIMISTIC,
> > TransactionIsolation.READ_COMMITTED);
> > cache.put("key1", "val1");
> >
> > And through debugging cache.put() method i can see in method
> > *org.apache.ignite.internal.processors.cache.distributed.
> > near.GridNearTxLocal#enlistWriteEntry*
> > that "key1" already *EXISTS *in internal cache :
> cacheCtx.cache().entryEx()
> > returns not null.
> >
> > ср, 29 мар. 2017 г. в 20:11, Alexander Fedotov <
> > alexander.fedot...@gmail.com
> > >:
> >
> > Hello Aleksey,
> >
> > No, the enlisted entry won't be visible for other transactions. Dirty
> reads
> > are not allowed in Ignite.
> >
> > Kind regards,
> > Alex
> >
> > 29 марта 2017 г. 7:36 PM пользователь "ALEKSEY KUZNETSOV" <
> > alkuznetsov...@gmail.com> написал:
> >
> > Hello, Igniters! I have one more question to you. Will appreciate any
> help.
> > Consider cache with near , dht configured not null.
> > When we start commit transaction , in method
> > *org.apache.ignite.internal.processors.cache.distributed.
> > near.GridNearTxLocal#enlistWriteEntry*
> > we put newly created entry into cache by executing entryEx().
> > I wonder if this entry will became visible for other transactions!?
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1655: IGNITE-4302 BinaryMetadata exchange protocol refa...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: putting entity into cache while commiting.Why!?

[ALEKSEY KUZNETSOV]

But i managed to read dirty. That is my example :

Ignite ignite0 = ignite(0);
IgniteTransactions transactions = ignite0.transactions();
IgniteCache cache = ignite0.getOrCreateCache("testCache");
Object monitor = new Object();

GridTestUtils.runAsync(new Callable() {
@Override
public Object call() throws Exception {
synchronized (monitor){
doInTransaction(ignite(1), new Callable() {
@Override
public Object call() throws Exception {
cache.put("key1", "val1");
monitor.wait();
return null;
}
});
}
return null;
}
});

Transaction tx =
transactions.txStart(TransactionConcurrency.OPTIMISTIC,
TransactionIsolation.READ_COMMITTED);
cache.put("key1", "val1");

And through debugging cache.put() method i can see in method
*org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal#enlistWriteEntry*
that "key1" already *EXISTS *in internal cache : cacheCtx.cache().entryEx()
returns not null.

ср, 29 мар. 2017 г. в 20:11, Alexander Fedotov :

Hello Aleksey,

No, the enlisted entry won't be visible for other transactions. Dirty reads
are not allowed in Ignite.

Kind regards,
Alex

29 марта 2017 г. 7:36 PM пользователь "ALEKSEY KUZNETSOV" <
alkuznetsov...@gmail.com> написал:

Hello, Igniters! I have one more question to you. Will appreciate any help.
Consider cache with near , dht configured not null.
When we start commit transaction , in method
*org.apache.ignite.internal.processors.cache.distributed.
near.GridNearTxLocal#enlistWriteEntry*
we put newly created entry into cache by executing entryEx().
I wonder if this entry will became visible for other transactions!?
--

*Best Regards,*

*Kuznetsov Aleksey*

-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

[Alexey Goncharuk]

Aleksey,

I doubt your approach works as expected. Current transaction recovery
protocol heavily relies on the originating node ID in its internal logic.
For example, currently a transaction will be rolled back if you want to
transfer a transaction ownership to another node and original tx owner
fails. An attempt to commit such a transaction on another node may fail
with all sorts of assertions. After transaction ownership changed, you need
to notify all current transaction participants about this change, and it
should also be done failover-safe, let alone that you did not add any tests
for these cases.

I back Denis here. Please create a ticket first and come up with clear
use-cases, API and protocol changes design. It is hard to reason about the
changes you've made when we do not even understand why you are making these
changes and how they are supposed to work.

--AG

2017-03-30 10:43 GMT+03:00 ALEKSEY KUZNETSOV :

> So, what do u think on my idea ?
>
> ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV :
>
> > Hi! No, i dont have ticket for this.
> > In the ticket i have implemented methods that change transaction status
> to
> > STOP, thus letting it to commit transaction in another thread. In another
> > thread you r going to restart transaction in order to commit it.
> > The mechanism behind it is obvious : we change thread id to newer one in
> > ThreadMap, and make use of serialization of txState, transactions itself
> to
> > transfer them into another thread.
> >
> >
> > вт, 28 мар. 2017 г. в 20:15, Denis Magda :
> >
> > Aleksey,
> >
> > Do you have a ticket for this? Could you briefly list what exactly was
> > done and how the things work.
> >
> > —
> > Denis
> >
> > > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> > wrote:
> > >
> > > Hi, Igniters! I 've made implementation of transactions of non-single
> > > coordinator. Here you can start transaction in one thread and commit it
> > in
> > > another thread.
> > > Take a look on it. Give your thoughts on it.
> > >
> > >
> > https://github.com/voipp/ignite/pull/10/commits/
> 3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45
> > >
> > > пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin  >:
> > >
> > >> You know better, go ahead! :)
> > >>
> > >> Sergi
> > >>
> > >> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > >>
> > >>> we've discovered several problems regarding your "accumulation"
> > >>> approach.These are
> > >>>
> > >>>   1. perfomance issues when transfering data from temporary cache to
> > >>>   permanent one. Keep in mind big deal of concurent transactions in
> > >>> Service
> > >>>   commiter
> > >>>   2. extreme memory load when keeping temporary cache in memory
> > >>>   3. As long as user is not acquainted with ignite, working with
> cache
> > >>>   must be transparent for him. Keep this in mind. User's node can
> > >> evaluate
> > >>>   logic with no transaction at all, so we should deal with both types
> > of
> > >>>   execution flow : transactional and non-transactional.Another one
> > >>> problem is
> > >>>   transaction id support at the user node. We would have handled all
> > >> this
> > >>>   issues and many more.
> > >>>   4. we cannot pessimistically lock entity.
> > >>>
> > >>> As a result, we decided to move on building distributed transaction.
> We
> > >> put
> > >>> aside your "accumulation" approach until we realize how to solve
> > >>> difficulties above .
> > >>>
> > >>> чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >:
> > >>>
> >  The problem "How to run millions of entities, and millions of
> > >> operations
> > >>> on
> >  a single Pentium3" is out of scope here. Do the math, plan capacity
> >  reasonably.
> > 
> >  Sergi
> > 
> >  2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > >>> :
> > 
> > > hmm, If we have millions of entities, and millions of operations,
> > >> would
> >  not
> > > this approache lead to memory overflow and perfomance degradation
> > >
> > > чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin <
> > >> sergi.vlady...@gmail.com
> >  :
> > >
> > >> 1. Actually you have to check versions on all the values you have
> > >>> read
> > >> during the tx.
> > >>
> > >> For example if we have [k1 => v1, k2 => v2] and do:
> > >>
> > >> put(k1, get(k2) + 5)
> > >>
> > >> We have to remember the version for k2. This logic can be
> > >> relatively
> > > easily
> > >> encapsulated in a framework atop of Ignite. You need to implement
> > >> one
> >  to
> > >> make all this stuff usable.
> > >>
> > >> 2. I suggest to avoid any locking here, because you easily will
> end
> > >>> up
> > > with
> > >> deadlocks. If you do not have too frequent updates for your keys,
> > >> optimistic 

[jira] [Created] (IGNITE-4882) Sometime network request will be produce when cache entry is locked

[Vladislav Pyatkov (JIRA)]

Vladislav Pyatkov created IGNITE-4882:
-

 Summary: Sometime network request will be produce when cache entry 
is locked
 Key: IGNITE-4882
 URL: https://issues.apache.org/jira/browse/IGNITE-4882
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.7
Reporter: Vladislav Pyatkov


Look at the trace:

{noformat}
"utility-#10740%null%" #10774 prio=5 os_prio=0 tid=0x7f06c8026000 nid=0x556 
waiting on condition [0x7f06c33f]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0x00074e9e65f8> (a 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$ConnectFuture)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2094)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:1989)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:1955)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1148)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessage(GridIoManager.java:1384)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1335)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1306)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendWithRetries(GridContinuousProcessor.java:1288)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.sendNotification(GridContinuousProcessor.java:949)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.addNotification(GridContinuousProcessor.java:892)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:803)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$700(CacheContinuousQueryHandler.java:91)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:412)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerSet(GridCacheMapEntry.java:1291)
- locked <0x000683f62f38> (a 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCacheEntry)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.userCommit(IgniteTxLocalAdapter.java:784)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.finish(GridNearTxLocal.java:747)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:418)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$4.apply(GridNearTxLocal.java:868)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$4.apply(GridNearTxLocal.java:860)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:263)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListeners(GridFutureAdapter.java:251)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:381)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:347)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onComplete(GridNearOptimisticTxPrepareFuture.java:287)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearOptimisticTxPrepareFuture.onDone(GridNearOptimisticTxPrepareFuture.java:264)
at 

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

So, what do u think on my idea ?

ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV :

> Hi! No, i dont have ticket for this.
> In the ticket i have implemented methods that change transaction status to
> STOP, thus letting it to commit transaction in another thread. In another
> thread you r going to restart transaction in order to commit it.
> The mechanism behind it is obvious : we change thread id to newer one in
> ThreadMap, and make use of serialization of txState, transactions itself to
> transfer them into another thread.
>
>
> вт, 28 мар. 2017 г. в 20:15, Denis Magda :
>
> Aleksey,
>
> Do you have a ticket for this? Could you briefly list what exactly was
> done and how the things work.
>
> —
> Denis
>
> > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV 
> wrote:
> >
> > Hi, Igniters! I 've made implementation of transactions of non-single
> > coordinator. Here you can start transaction in one thread and commit it
> in
> > another thread.
> > Take a look on it. Give your thoughts on it.
> >
> >
> https://github.com/voipp/ignite/pull/10/commits/3a3d90aa6ac84f125e4c3ce4ced4f269a695ef45
> >
> > пт, 17 мар. 2017 г. в 19:26, Sergi Vladykin :
> >
> >> You know better, go ahead! :)
> >>
> >> Sergi
> >>
> >> 2017-03-17 16:16 GMT+03:00 ALEKSEY KUZNETSOV  >:
> >>
> >>> we've discovered several problems regarding your "accumulation"
> >>> approach.These are
> >>>
> >>>   1. perfomance issues when transfering data from temporary cache to
> >>>   permanent one. Keep in mind big deal of concurent transactions in
> >>> Service
> >>>   commiter
> >>>   2. extreme memory load when keeping temporary cache in memory
> >>>   3. As long as user is not acquainted with ignite, working with cache
> >>>   must be transparent for him. Keep this in mind. User's node can
> >> evaluate
> >>>   logic with no transaction at all, so we should deal with both types
> of
> >>>   execution flow : transactional and non-transactional.Another one
> >>> problem is
> >>>   transaction id support at the user node. We would have handled all
> >> this
> >>>   issues and many more.
> >>>   4. we cannot pessimistically lock entity.
> >>>
> >>> As a result, we decided to move on building distributed transaction. We
> >> put
> >>> aside your "accumulation" approach until we realize how to solve
> >>> difficulties above .
> >>>
> >>> чт, 16 мар. 2017 г. в 16:56, Sergi Vladykin  >:
> >>>
>  The problem "How to run millions of entities, and millions of
> >> operations
> >>> on
>  a single Pentium3" is out of scope here. Do the math, plan capacity
>  reasonably.
> 
>  Sergi
> 
>  2017-03-16 15:54 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> >>> :
> 
> > hmm, If we have millions of entities, and millions of operations,
> >> would
>  not
> > this approache lead to memory overflow and perfomance degradation
> >
> > чт, 16 мар. 2017 г. в 15:42, Sergi Vladykin <
> >> sergi.vlady...@gmail.com
>  :
> >
> >> 1. Actually you have to check versions on all the values you have
> >>> read
> >> during the tx.
> >>
> >> For example if we have [k1 => v1, k2 => v2] and do:
> >>
> >> put(k1, get(k2) + 5)
> >>
> >> We have to remember the version for k2. This logic can be
> >> relatively
> > easily
> >> encapsulated in a framework atop of Ignite. You need to implement
> >> one
>  to
> >> make all this stuff usable.
> >>
> >> 2. I suggest to avoid any locking here, because you easily will end
> >>> up
> > with
> >> deadlocks. If you do not have too frequent updates for your keys,
> >> optimistic approach will work just fine.
> >>
> >> Theoretically in the Committer Service you can start a thread for
> >> the
> >> lifetime of the whole distributed transaction, take a lock on the
> >> key
> > using
> >> IgniteCache.lock(K key) before executing any Services, wait for all
> >>> the
> >> services to complete, execute optimistic commit in the same thread
>  while
> >> keeping this lock and then release it. Notice that all the Ignite
> >> transactions inside of all Services must be optimistic here to be
> >>> able
>  to
> >> read this locked key.
> >>
> >> But again I do not recommend you using this approach until you
> >> have a
> >> reliable deadlock avoidance scheme.
> >>
> >> Sergi
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2017-03-16 12:53 GMT+03:00 ALEKSEY KUZNETSOV <
> >>> alkuznetsov...@gmail.com
> > :
> >>
> >>> Yeah, now i got it.
> >>> There are some doubts on this approach
> >>> 1) During optimistic commit phase, when you assure no one altered
> >>> the
> >>> original values, you must check versions of other dependent keys.
> >>> How
> >> could
> >>> we 

[GitHub] ignite pull request #1694: IGNITE-3548 .NET: Rename ILifecycleBean

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-3548 .NET: Rename ILifecycleBean



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

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

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

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


commit 9947616230576233b8308351cdd8b4796a813ae6
Author: Pavel Tupitsyn 
Date:   2017-03-30T07:19:58Z

IGNITE-3548 .NET: Rename ILifecycleBean




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