Re: Stable binary key representation

[Alexey Goncharuk]

Denis,

Can you suggest a use-case where identity resolver is needed (given that we
agree that a key must contain only valuable fields)?

2017-04-05 22:08 GMT+03:00 Denis Magda :

> Where do you want to remove the identity resolvers from? If it’s related
> to the internals of Hibernate module then it’s fine but if you suggest
> removing identity resolvers public interfaces then it might be a haste
> decision.
>
> —
> Denis
>
> > On Apr 5, 2017, at 7:42 AM, Alexey Goncharuk 
> wrote:
> >
> > +1, I see no other reasons to keep it.
> >
> > 2017-04-05 13:59 GMT+03:00 Sergi Vladykin :
> >
> >> +1
> >>
> >> Lets drop them.
> >>
> >> Sergi
> >>
> >> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> >> dmitriy.govoruk...@gmail.com>
> >> :
> >>
> >>> Hi guys, i implemented proxy for IgniteCache in hibernate integration,
> >> this
> >>> proxy transformate cacheKey to our key wrapper, leaves only required
> >>> field. I think we can remove identity resolve, it should not broke
> >>> integration with hibernate. Any objections?
> >>>
> >>> On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
> >>> valentin.kuliche...@gmail.com> wrote:
> >>>
>  I'm not saying there is no alternative solution. But let's implement
> it
> >>> and
>  prove that it works first, and remove resolvers only after that.
> 
>  -Val
> 
>  On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin <
> >>> sergi.vlady...@gmail.com
> >
>  wrote:
> 
> > Guys, nothing is impossible if you know a bit about reflection in
> >> Java
> >>> :)
> >
> > We had a look at the CacheKey class and it is easily replaceable.
> >
> > Sergi
> >
> >
> >
> > 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan  >>> :
> >
> >> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >>
> >>> "Hibernate key" is the CacheKey class I was referring to. It's
>  provided
> >> by
> >>> Hibernate, not by user and not by us. So I'm not sure it's
> >> possible
>  to
> >>> replace it.
> >>>
> >>
> >> If it is impossible to replace or get rid of the Hibernate key, is
> >>> this
> >> discussion valid at all?
> >>
> >
> 
> >>>
> >>
>
>

[GitHub] ignite pull request #1733: IGNITE-4885 .NET: Disallow abstract and open gene...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1738: IGNITE-4899 .NET: Review Dictionary usage in APIs

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Apache Ignite 2.0 Release

[Denis Magda]

Yes, I think they have to be released as well. Igniters, who can take over 
these tasks and make them done by the code freeze?

—
Denis

> On Apr 5, 2017, at 9:39 PM, Dmitriy Setrakyan  wrote:
> 
> *Denis*, we still have 5 issues that are *unassigned*. Are they supposed to
> be getting into release?
> 
> IGNITE-3488  > - Prohibit
> null as name in all the components (cache name first of all).
> IGNITE-3596  > - Hadoop
> edition can't be compiled against spark 2.0.0
> IGNITE-4794  > - Reconsider
> CachePeekMode.ONHEAP
> IGNITE-2202  > - Local
> server query result doesn't include versions in entries
> IGNITE-2398  > - .NET:
> Change default mapper behavior

Re: Apache Ignite 2.0 Release

[Denis Magda]

> *Denis Magda:*
> IGNITE-1192  - Provide
> integration with Spring Data

Will be finished and merged by the code freeze date. I’m on a business trip now 
and don’t have extra time to complete the feature.

Plus, following your template these are additional tickets:

*Alexey Kuznetsov*
IGNITE-4349  - Discontinue 
the schema-import utility

*Sergey Chugunov*
IGNITE-4536  - Update 
metrics for new offheap storage

*Nikita Ivanov*
IGNITE-4572  - Machine 
Learning: Develop distributed algebra support for dense and sparse data sets.

*Roman Shtykh*
IGNITE-4539  - RocketMQ Data 
Streamer

*Vadim Opolski*
IGNITE-1794  - Hibernate 5 
Support

—
Denis

> On Apr 5, 2017, at 9:39 PM, Dmitriy Setrakyan  wrote:
> 
> Guys,
> 
> Please provide a status underneath every ticket listed below, so we can get
> a full picture in one email thread:
> 
> *Alexey Goncharuk:*
> IGNITE-3477  - Rework
> offheap storage
> IGNITE-4337  - Introduce
> persistence interface to allow build reliable persistence plugins
> 
> *Alexander Menshikov:*
> IGNITE-4699  - Introduce
> custom configurable executors.
> 
> *Denis Magda:*
> IGNITE-1192  - Provide
> integration with Spring Data
> 
> *Dmitriy Karachentsev:*
> IGNITE-4477  - Fix
> IgniteFuture.listen() and IgniteFuture.chain() semantics
> 
> *Ilya Lantukh:*
> IGNITE-4535 
> - Add option to store
> deserialized values on-heap
> 
> *Ivan Rakov:*
> IGNITE-4534  - Implement
> offheap eviction policies based on page memory
> 
> *Sergey Kalashnikov:*
> IGNITE-3595  - Improve
> Enum fields handling in SQL.
> 
> *Sergi Vladykin:*
> IGNITE-3869  - Reduce
> number of temporary objects produced by H2
> 
> *Taras Ledkov:*
> IGNITE-3469  - Get rid
> of deprecated APIs and entities
> 
> *Vladimir Ozerov:*
> IGNITE-4565  - Support
> CREATE INDEX DDL statements
> 
> *Yakov Zdanov:*
> IGNITE-4799  - Remove
> TcpDiscoverySpi.heartbeatsFrequency parameter
> 
> 
> *Denis*, we still have 5 issues that are *unassigned*. Are they supposed to
> be getting into release?
> 
> IGNITE-3488  - Prohibit
> null as name in all the components (cache name first of all).
> IGNITE-3596  - Hadoop
> edition can't be compiled against spark 2.0.0
> IGNITE-4794  - Reconsider
> CachePeekMode.ONHEAP
> IGNITE-2202  - Local
> server query result doesn't include versions in entries
> IGNITE-2398  - .NET:
> Change default mapper behavior
> 
> 
> D.
> 
> On Wed, Apr 5, 2017 at 6:07 PM, Denis Magda  wrote:
> 
>> Dmitriy,
>> 
>> You can find all the required tickets with contributors assigned here:
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#
>> ApacheIgnite2.0-Requiredtickets > confluence/display/IGNITE/Apache+Ignite+2.0#ApacheIgnite2.0-
>> Requiredtickets>
>> 
>> In short, Alex G., Sergi, Vovan, Taras, Yakov, Sam, etc. (almost all the
>> community) please share your readiness with the rest of the community.
>> 
>> —
>> Denis
>> 
>>> On Apr 5, 2017, at 9:03 PM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Denis,
>>> 
>>> I think it will be worth while to list all the tickets by status together
>>> with a name of the engineer assigned to it. This way most folks involved
>>> would provide a response sooner.
>>> 
>>> What do you think?
>>> 
>>> D.
>>> 
>>> On Wed, Apr 5, 2017 at 1:27 PM, Denis Magda  wrote:
>>> 
 Igniters,
 
 What’s the overall status of 2.0 release? I see that many tickets
>> related
 to the page memory [1] are still in the open state and, looks like, this
 new memory architecture has not been fully merged yet. In addition, a
>> new
 version of H2 has to be released prior to 2.0.
 
 All this threatens the release schedule we agreed on. According to the
 plan the next week is a week of code freeze:
 https://cwiki.apache.org/confluence/di

Re: jdbc vs jdbc2 packages

[Denis Magda]

Ticket:
https://issues.apache.org/jira/browse/IGNITE-4922 


—
Denis

> On Mar 30, 2017, at 7:06 PM, Denis Magda  wrote:
> 
> 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
>>>

Re: Apache Ignite 2.0 Release

[Dmitriy Setrakyan]

Guys,

Please provide a status underneath every ticket listed below, so we can get
a full picture in one email thread:

*Alexey Goncharuk:*
IGNITE-3477  - Rework
offheap storage
IGNITE-4337  - Introduce
persistence interface to allow build reliable persistence plugins

*Alexander Menshikov:*
IGNITE-4699  - Introduce
custom configurable executors.

*Denis Magda:*
IGNITE-1192  - Provide
integration with Spring Data

*Dmitriy Karachentsev:*
IGNITE-4477  - Fix
IgniteFuture.listen() and IgniteFuture.chain() semantics

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

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

*Sergey Kalashnikov:*
IGNITE-3595  - Improve
Enum fields handling in SQL.

*Sergi Vladykin:*
IGNITE-3869  - Reduce
number of temporary objects produced by H2

*Taras Ledkov:*
IGNITE-3469  - Get rid
of deprecated APIs and entities

*Vladimir Ozerov:*
IGNITE-4565  - Support
CREATE INDEX DDL statements

*Yakov Zdanov:*
IGNITE-4799  - Remove
TcpDiscoverySpi.heartbeatsFrequency parameter


*Denis*, we still have 5 issues that are *unassigned*. Are they supposed to
be getting into release?

IGNITE-3488  - Prohibit
null as name in all the components (cache name first of all).
IGNITE-3596  - Hadoop
edition can't be compiled against spark 2.0.0
IGNITE-4794  - Reconsider
CachePeekMode.ONHEAP
IGNITE-2202  - Local
server query result doesn't include versions in entries
IGNITE-2398  - .NET:
Change default mapper behavior


D.

On Wed, Apr 5, 2017 at 6:07 PM, Denis Magda  wrote:

> Dmitriy,
>
> You can find all the required tickets with contributors assigned here:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#
> ApacheIgnite2.0-Requiredtickets  confluence/display/IGNITE/Apache+Ignite+2.0#ApacheIgnite2.0-
> Requiredtickets>
>
> In short, Alex G., Sergi, Vovan, Taras, Yakov, Sam, etc. (almost all the
> community) please share your readiness with the rest of the community.
>
> —
> Denis
>
> > On Apr 5, 2017, at 9:03 PM, Dmitriy Setrakyan 
> wrote:
> >
> > Denis,
> >
> > I think it will be worth while to list all the tickets by status together
> > with a name of the engineer assigned to it. This way most folks involved
> > would provide a response sooner.
> >
> > What do you think?
> >
> > D.
> >
> > On Wed, Apr 5, 2017 at 1:27 PM, Denis Magda  wrote:
> >
> >> Igniters,
> >>
> >> What’s the overall status of 2.0 release? I see that many tickets
> related
> >> to the page memory [1] are still in the open state and, looks like, this
> >> new memory architecture has not been fully merged yet. In addition, a
> new
> >> version of H2 has to be released prior to 2.0.
> >>
> >> All this threatens the release schedule we agreed on. According to the
> >> plan the next week is a week of code freeze:
> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#
> >> ApacheIgnite2.0-Releasephases  >> confluence/display/IGNITE/Apache+Ignite+2.0#
> ApacheIgnite2.0-Releasephases>
> >>
> >> [1] https://issues.apache.org/jira/browse/IGNITE-3477 <
> >> https://issues.apache.org/jira/browse/IGNITE-3477>
> >>
> >> —
> >> Denis
> >>
> >>> On Mar 31, 2017, at 4:02 AM, Vladimir Ozerov 
> >> wrote:
> >>>
> >>> Another big merge - now almost all our setters on public configuration
> >>> return "this" instance to allow for convenient chaining [1]. Big
> >>> thanks to *Andrew
> >>> Mashenkov* for making this happen.
> >>> Ideally I would also try to replace "set(Collection)" with "
> >>> set(Something...)". This should make configuration even more easier.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/IGNITE-4564
> >>>
> >>> On Fri, Mar 31, 2017 at 2:18 AM, Denis Magda 
> wrote:
> >>>
>  Vovan,
> 
>  I expect to finalize and merge Spring Data Integration by the code
> >> freeze
>  time (April 14th):
>  IGNITE-1192Provide integration with Spring Data <
>  https://issues.apache.org/jira/browse/IGNITE-1192>
> 
>  —
>  Denis
> 
> > On Mar 

[jira] [Created] (IGNITE-4922) JDBC Driver: renew thin client based solution

[Denis Magda (JIRA)]

Denis Magda created IGNITE-4922:
---

 Summary: JDBC Driver: renew thin client based solution
 Key: IGNITE-4922
 URL: https://issues.apache.org/jira/browse/IGNITE-4922
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Priority: Blocker
 Fix For: 2.1


This is a parent ticket for all the activities that are intended to improve the 
thin client based implementation of the JDBC driver making it default one.
 
Refer to the corresponding discussion on the dev list:
http://apache-ignite-developers.2346864.n4.nabble.com/jdbc-vs-jdbc2-packages-td14309.html

In a nutshell, depending on a type of a protocol to be used for the next-gen 
version the options are the following:
- This type of driver might be a default driver for tools and applications that 
don't need transactional support. Existing REST based protocol can be used for 
this scenario.
- If we want to support transactions (which is optional at the beginning) then 
Yakov solution (see discussion) can be applied. However, it makes sense to 
implement it only after MVCC is ready.



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

Re: Apache Ignite 2.0 Release

[Denis Magda]

Dmitriy,

You can find all the required tickets with contributors assigned here:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#ApacheIgnite2.0-Requiredtickets
 


In short, Alex G., Sergi, Vovan, Taras, Yakov, Sam, etc. (almost all the 
community) please share your readiness with the rest of the community.

—
Denis

> On Apr 5, 2017, at 9:03 PM, Dmitriy Setrakyan  wrote:
> 
> Denis,
> 
> I think it will be worth while to list all the tickets by status together
> with a name of the engineer assigned to it. This way most folks involved
> would provide a response sooner.
> 
> What do you think?
> 
> D.
> 
> On Wed, Apr 5, 2017 at 1:27 PM, Denis Magda  wrote:
> 
>> Igniters,
>> 
>> What’s the overall status of 2.0 release? I see that many tickets related
>> to the page memory [1] are still in the open state and, looks like, this
>> new memory architecture has not been fully merged yet. In addition, a new
>> version of H2 has to be released prior to 2.0.
>> 
>> All this threatens the release schedule we agreed on. According to the
>> plan the next week is a week of code freeze:
>> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#
>> ApacheIgnite2.0-Releasephases > confluence/display/IGNITE/Apache+Ignite+2.0#ApacheIgnite2.0-Releasephases>
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-3477 <
>> https://issues.apache.org/jira/browse/IGNITE-3477>
>> 
>> —
>> Denis
>> 
>>> On Mar 31, 2017, at 4:02 AM, Vladimir Ozerov 
>> wrote:
>>> 
>>> Another big merge - now almost all our setters on public configuration
>>> return "this" instance to allow for convenient chaining [1]. Big
>>> thanks to *Andrew
>>> Mashenkov* for making this happen.
>>> Ideally I would also try to replace "set(Collection)" with "
>>> set(Something...)". This should make configuration even more easier.
>>> 
>>> [1] https://issues.apache.org/jira/browse/IGNITE-4564
>>> 
>>> On Fri, Mar 31, 2017 at 2:18 AM, Denis Magda  wrote:
>>> 
 Vovan,
 
 I expect to finalize and merge Spring Data Integration by the code
>> freeze
 time (April 14th):
 IGNITE-1192Provide integration with Spring Data <
 https://issues.apache.org/jira/browse/IGNITE-1192>
 
 —
 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: Apache Ignite 2.0 Release

[Dmitriy Setrakyan]

Denis,

I think it will be worth while to list all the tickets by status together
with a name of the engineer assigned to it. This way most folks involved
would provide a response sooner.

What do you think?

D.

On Wed, Apr 5, 2017 at 1:27 PM, Denis Magda  wrote:

> Igniters,
>
> What’s the overall status of 2.0 release? I see that many tickets related
> to the page memory [1] are still in the open state and, looks like, this
> new memory architecture has not been fully merged yet. In addition, a new
> version of H2 has to be released prior to 2.0.
>
> All this threatens the release schedule we agreed on. According to the
> plan the next week is a week of code freeze:
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#
> ApacheIgnite2.0-Releasephases  confluence/display/IGNITE/Apache+Ignite+2.0#ApacheIgnite2.0-Releasephases>
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3477 <
> https://issues.apache.org/jira/browse/IGNITE-3477>
>
> —
> Denis
>
> > On Mar 31, 2017, at 4:02 AM, Vladimir Ozerov 
> wrote:
> >
> > Another big merge - now almost all our setters on public configuration
> > return "this" instance to allow for convenient chaining [1]. Big
> > thanks to *Andrew
> > Mashenkov* for making this happen.
> > Ideally I would also try to replace "set(Collection)" with "
> > set(Something...)". This should make configuration even more easier.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-4564
> >
> > On Fri, Mar 31, 2017 at 2:18 AM, Denis Magda  wrote:
> >
> >> Vovan,
> >>
> >> I expect to finalize and merge Spring Data Integration by the code
> freeze
> >> time (April 14th):
> >> IGNITE-1192Provide integration with Spring Data <
> >> https://issues.apache.org/jira/browse/IGNITE-1192>
> >>
> >> —
> >> 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: Adding ML to Ignite, IGNITE-4572

[Denis Magda]

Sorry for the late reply. Sure, you're always welcomed to join our
community and participate in the development of modules of interest.

As for ML, please keep an eye on this discussion where will break down ML
activities a bit later.

Denis

On Wednesday, April 5, 2017, anantbietec  wrote:

> I am very enthusiatic about this project but sir i have not submitted
> PROPOSAL FOR THIS IN gsoc 2017  can i still be allowed to do this project
>
> As the reply comes very late i didnt know what are the tasks to do in this
> project . So i didnt prepare the proposal .
>
> Can we still have the discussion and assign tasks to me so that i can
> contribute to the project and also tell me upto now what has been done so
> that i am also on the same page.
>
> Thanks
> Anant
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-
> IGNITE-4572-tp13936p16190.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>

Re: Adding ML to Ignite, IGNITE-4572

[anantbietec]

I am very enthusiatic about this project but sir i have not submitted
PROPOSAL FOR THIS IN gsoc 2017  can i still be allowed to do this project 

As the reply comes very late i didnt know what are the tasks to do in this
project . So i didnt prepare the proposal .

Can we still have the discussion and assign tasks to me so that i can
contribute to the project and also tell me upto now what has been done so
that i am also on the same page.

Thanks 
Anant



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p16190.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Bug fix to IGNITE-4817

[Guru Stron]

Hi guys,

I've finished implementing bug fix to IGNITE-4817 .NET: Contains fails in
LINQ when subquery comes from a variable

Also I've queued 'Ignite Platform .NET' & 'Ignite Platform .NET Inspection'
jobs on Team City:
http://ci.ignite.apache.org/viewQueued.html?itemId=532228&;
tab=queuedBuildOverviewTab
http://ci.ignite.apache.org/viewQueued.html?itemId=532229&;
tab=queuedBuildOverviewTab

Can somebody please take a look?

Re: Apache Ignite 2.0 Release

[Denis Magda]

Igniters, 

What’s the overall status of 2.0 release? I see that many tickets related to 
the page memory [1] are still in the open state and, looks like, this new 
memory architecture has not been fully merged yet. In addition, a new version 
of H2 has to be released prior to 2.0.

All this threatens the release schedule we agreed on. According to the plan the 
next week is a week of code freeze:
https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0#ApacheIgnite2.0-Releasephases
 


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


—
Denis

> On Mar 31, 2017, at 4:02 AM, Vladimir Ozerov  wrote:
> 
> Another big merge - now almost all our setters on public configuration
> return "this" instance to allow for convenient chaining [1]. Big
> thanks to *Andrew
> Mashenkov* for making this happen.
> Ideally I would also try to replace "set(Collection)" with "
> set(Something...)". This should make configuration even more easier.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-4564
> 
> On Fri, Mar 31, 2017 at 2:18 AM, Denis Magda  wrote:
> 
>> Vovan,
>> 
>> I expect to finalize and merge Spring Data Integration by the code freeze
>> time (April 14th):
>> IGNITE-1192Provide integration with Spring Data <
>> https://issues.apache.org/jira/browse/IGNITE-1192>
>> 
>> —
>> 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.
 
>> 
>> 

[GitHub] ignite pull request #1745: IGNITE-4817

[gurustron]

GitHub user gurustron opened a pull request:

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

IGNITE-4817

QueryParser switched to use CompoundExpressionTreeProcessor.

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

$ git pull https://github.com/gurustron/ignite IGNITE-4817

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

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


commit 488e67e7be7970e1373f3e23f34563e3a8a46bd3
Author: gurustron 
Date:   2017-04-05T20:11:48Z

IGNITE-4817: Query Parser uses CompoundExpressionTreeProcessor, small 
fixes, tests




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: IGNITE-4188, savepoints with atomic cache?

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

IGNITE-2313 done, can you review it?

PR: https://github.com/apache/ignite/pull/1709/files
JIRA: https://issues.apache.org/jira/browse/IGNITE-2313
CI: http://ci.ignite.apache.org/viewType.html?buildTypeId=
IgniteTests_RatJavadoc&branch_IgniteTests=pull%2F1709%
2Fhead&tab=buildTypeStatusDiv

2017-03-29 20:58 GMT+03:00 Denis Magda :

> Sorry, I get lost in tickets.
>
> Yes, IGNITE-2313 has to be completed in 2.0 if we want to makes this
> change.
>
> —
> Denis
>
> > On Mar 29, 2017, at 2:12 AM, Дмитрий Рябов 
> wrote:
> >
> > Savepoints marked for 2.1, exceptions for 2.0. Do you want me to make
> > exceptions first?
> >
> > 2017-03-29 11:24 GMT+03:00 Дмитрий Рябов :
> >
> >> Finish savepoints or flag&exceptions for atomic operations?
> >> Not sure about savepoints. Exceptions - yes. https://issues.apache.
> >> org/jira/browse/IGNITE-2313 isn't it?
> >>
> >> 2017-03-29 2:12 GMT+03:00 Denis Magda :
> >>
> >>> If we want to make the exception based approach the default one then
> the
> >>> task has to be released in 2.0.
> >>>
> >>> Dmitriy Ryabov, do you think you can finish it (dev, review, QA) by the
> >>> code freeze data (April 14)?
> >>>
> >>> —
> >>> Denis
> >>>
>  On Mar 28, 2017, at 11:57 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> >>> wrote:
> 
>  On Tue, Mar 28, 2017 at 11:54 AM, Sergi Vladykin <
> >>> sergi.vlady...@gmail.com>
>  wrote:
> 
> > I think updating an Atomic cache from within a transaction perfectly
> >>> makes
> > sense. For example for some kind of operations logging and so forth.
> >>> Still
> > I agree that this can be error prone and forbidden by default. I
> agree
> >>> with
> > Yakov that by default we should throw an exception and have some kind
> >>> of
> > flag (on cache or on TX?) to be able to explicitly enable this
> >>> behavior.
> >
> 
> 
>  Agree, this sounds like a good idea.
> >>>
> >>>
> >>
>
>

Re: IGNITE-2313 - ready for review

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

Em... sorry, always forgot about meaningful title(

Discussion? Yeah, I'll do it.

2017-04-05 22:15 GMT+03:00 Denis Magda :

> Dmitriy R., may I ask you to make a title and description of review
> request more meaningful? Looking at email's subject and body neither me nor
> anyone else have an idea what you ask to review. As a result most of
> community members will simply ignore your review request skipping the
> message. Don’t force people to go to JIRA ;)
>
> Igniters,
>
> This is the ticket to be reviewed: "Need to add a mode to fail atomic
> operations within a transaction”. Please review it.
>
> Dmitriy R., there was a relevant discussion around the ticket. Would you
> paste a link to it there?
>
> —
> Denis
>
>
> > On Apr 5, 2017, at 4:12 AM, Дмитрий Рябов  wrote:
> >
> > Hello, please review.
> >
> > PR: https://github.com/apache/ignite/pull/1709/files
> > JIRA: https://issues.apache.org/jira/browse/IGNITE-2313
> > CI:
> > http://ci.ignite.apache.org/viewType.html?buildTypeId=
> IgniteTests_RatJavadoc&branch_IgniteTests=pull%2F1709%
> 2Fhead&tab=buildTypeStatusDiv
>
>

Re: IGNITE-2313 - ready for review

[Denis Magda]

Dmitriy R., may I ask you to make a title and description of review request 
more meaningful? Looking at email's subject and body neither me nor anyone else 
have an idea what you ask to review. As a result most of community members will 
simply ignore your review request skipping the message. Don’t force people to 
go to JIRA ;)

Igniters,

This is the ticket to be reviewed: "Need to add a mode to fail atomic 
operations within a transaction”. Please review it.

Dmitriy R., there was a relevant discussion around the ticket. Would you paste 
a link to it there?

—
Denis


> On Apr 5, 2017, at 4:12 AM, Дмитрий Рябов  wrote:
> 
> Hello, please review.
> 
> PR: https://github.com/apache/ignite/pull/1709/files
> JIRA: https://issues.apache.org/jira/browse/IGNITE-2313
> CI:
> http://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests_RatJavadoc&branch_IgniteTests=pull%2F1709%2Fhead&tab=buildTypeStatusDiv

Re: Stable binary key representation

[Denis Magda]

Where do you want to remove the identity resolvers from? If it’s related to the 
internals of Hibernate module then it’s fine but if you suggest removing 
identity resolvers public interfaces then it might be a haste decision.

—
Denis

> On Apr 5, 2017, at 7:42 AM, Alexey Goncharuk  
> wrote:
> 
> +1, I see no other reasons to keep it.
> 
> 2017-04-05 13:59 GMT+03:00 Sergi Vladykin :
> 
>> +1
>> 
>> Lets drop them.
>> 
>> Sergi
>> 
>> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
>> dmitriy.govoruk...@gmail.com>
>> :
>> 
>>> Hi guys, i implemented proxy for IgniteCache in hibernate integration,
>> this
>>> proxy transformate cacheKey to our key wrapper, leaves only required
>>> field. I think we can remove identity resolve, it should not broke
>>> integration with hibernate. Any objections?
>>> 
>>> On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com> wrote:
>>> 
 I'm not saying there is no alternative solution. But let's implement it
>>> and
 prove that it works first, and remove resolvers only after that.
 
 -Val
 
 On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin <
>>> sergi.vlady...@gmail.com
> 
 wrote:
 
> Guys, nothing is impossible if you know a bit about reflection in
>> Java
>>> :)
> 
> We had a look at the CacheKey class and it is easily replaceable.
> 
> Sergi
> 
> 
> 
> 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan >> :
> 
>> On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>> 
>>> "Hibernate key" is the CacheKey class I was referring to. It's
 provided
>> by
>>> Hibernate, not by user and not by us. So I'm not sure it's
>> possible
 to
>>> replace it.
>>> 
>> 
>> If it is impossible to replace or get rid of the Hibernate key, is
>>> this
>> discussion valid at all?
>> 
> 
 
>>> 
>> 

Re: Adding ML to Ignite, IGNITE-4572

[Denis Magda]

These are some suggestions from Nikita that were sent to Alper privately that 
might be useful for other candidates:

Alper,
Here are some of the immediate tasks we'll be working on past 2.0 release (and 
you are 100% welcome to tackle them if you find them interesting):

(1) Linear regression algorithm on super-large distributed sparse dataset
(2) Logistic regression algorithm on super-large distributed sparse dataset

Thanks!
> On Apr 3, 2017, at 12:21 AM, anantbietec  wrote:
> 
> yeah thats good but GSOC application last till today only so any suggestion
> how to write the proposal or what need to be included in the proposal.
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Adding-ML-to-Ignite-IGNITE-4572-tp13936p16070.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: IGNITE - 4760 : working in hibernate module

[Denis Magda]

> How to reproduce situation when updates can be recorded to another region?

Don’t you just need to define multiple caches that will be mapped to Hibernate 
regions and initiate a transaction that updates several regions (caches) at 
once?

—
Denis

> On Apr 3, 2017, at 10:39 AM, Вадим Опольский  wrote:
> 
> Hello everyone!
> 
> I added some change to method threadLocalForCache  and added test
> testEntityCacheNonStrictFails.
> 
> How to reproduce situation when updates can be recorded to another region?
> 
> https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac507ed73872d62b2969a7411/modules/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateRegionFactory.java
> 
> https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac507ed73872d62b2969a7411/modules/hibernate/src/test/java/org/apache/ignite/cache/hibernate/HibernateL2CacheConfigurationSelfTest.java
> 
> PullRequest
> https://github.com/vadopolski/ignite/pull/4/files
> 
> Vadim
> 
> 
> 
> 2017-03-27 18:20 GMT+03:00 Denis Magda :
> 
>> Vadim,
>> 
>> What IDE do you use? My recommendation would be to set up everything let’s
>> say under IntellijIDEA or Eclipse and after that trying to compile from a
>> terminal.
>> 
>> This is how you can easily prepare the dev env in IntellijIDEA:
>> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup <
>> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup>
>> 
>> —
>> Denis
>> 
>>> On Mar 27, 2017, at 7:14 AM, Вадим Опольский 
>> wrote:
>>> 
>>> Valentin, OK.
>>> 
>>> To enabled it in my environment I done next:
>>> - built project with command - mvn clean package -DskipTests
>> -Prelease,lgpl
>>> - added folder hibernate to modules in project structure
>>> - added library to dependencies (without it import doesn't working)
>>> 
>>> After that I have a lot of error, for instance:
>>> - Class 'AccessStrategy' must either be declared abstract or implement
>> abstract method 'remove(SharedSessionContractImplementor, Object) in
>> 'RegionAccessStrategy'
>>> 
>>> generateCacheKey
>>> getCacheKeyId
>>> getRegion
>>> insert
>>> afterInsert
>>> update
>>> afterUpdate
>>> insert
>>> afterInsert
>>> update
>>> get
>>> putFromLoad
>>> lockItem
>>> unlockItem
>>> remove
>>> 
>>> Do anybody know the easier way to resolve this issue?
>>> 
>>> Also tried to reimport all maven projects and cleansed repository in .m2.
>>> Vadim Opolski
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 2017-03-25 2:42 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com >:
>>> Vadim,
>>> 
>>> ignite-hibernate module is a part of 'lgpl' profile. Apparently it's not
>>> enabled in your environment.
>>> 
>>> -Val
>>> 
>>> On Fri, Mar 24, 2017 at 4:38 PM, Вадим Опольский > >
>>> wrote:
>>> 
 Hello everybody,
 
 I want to resolve issue №4760
 https://issues.apache.org/jira/browse/IGNITE-4760 <
>> https://issues.apache.org/jira/browse/IGNITE-4760>
 
 To find solution I'm going to change method threadLocalForCache and to
>> add
 Junit test.
 
 Why folder hibernate is not a module ? Can I added it ?
 
 Vadim Opolski
 
>>> 
>> 
>> 

Presenting Apache Ignite in Miami, May 2017

[Denis Magda]

Igniters,

I’m presenting two talks related to Apache Ignite in May at ASF Apache Con and 
Apache BigData conferences. Latest news: https://ignite.apache.org/news.html 


Direct links:
https://apachecon2017.sched.com/event/9zot?iframe=no 

https://apachebigdata2017.sched.com/event/A01a?iframe=no

Please help to promote the talks using your social channels. 

BTW, does anyone go to the conferences? It’s a good chance to meet with each 
other in person.

—
Denis

[GitHub] ignite pull request #1744: Ignite 3477 master client offheap fix

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

Ignite 3477 master client offheap fix

DO NOT MERGE.

PR only to run tests on TC.

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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-3477-master-client-offheap-fix

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

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






---
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 #1743: ignite-4797: Added API for system allocated size ...

[kartiksomani]

GitHub user kartiksomani opened a pull request:

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

ignite-4797: Added API for system allocated size in CacheMetrics

Addressed comments made by Andrey Gura

https://issues.apache.org/jira/browse/IGNITE-4797


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

$ git pull https://github.com/kartiksomani/ignite ignite-4797

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

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


commit 4d02758bedc01ad9da2ada23b1ce3fbc62610f91
Author: Kartik Somani 
Date:   2017-04-05T16:32:40Z

ignite-4797: Added API for system allocated size in CacheMetrics




---
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-4921) Refactor segments array in PageMemoryNoStoreImpl

[Ivan Rakov (JIRA)]

Ivan Rakov created IGNITE-4921:
--

 Summary: Refactor segments array in PageMemoryNoStoreImpl
 Key: IGNITE-4921
 URL: https://issues.apache.org/jira/browse/IGNITE-4921
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Ivan Rakov
Assignee: Alexey Goncharuk


In current version of PageMemoryNoStoreImpl, offheap memory is split into equal 
segments. Quantity of segments is based on 
MemoryConfiguration#getConcurrencyLevel (or Runtime#availableProcessors, if 
previous is not set).
This approach is obsolete. In order to reduce code complexity, segments should 
be refactored into one memory region.



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

[jira] [Created] (IGNITE-4920) LocalDeploymentSpi resources cleanup on spi.register() might clean resources from other tasks using delegating classloader.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-4920:
-

 Summary: LocalDeploymentSpi resources cleanup on spi.register() 
might clean resources from other tasks using delegating classloader.
 Key: IGNITE-4920
 URL: https://issues.apache.org/jira/browse/IGNITE-4920
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.6
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov
 Fix For: 2.1


Culrpit is "if" condition in LocalDelpoymentSpi:

{noformat}
if (entry.getKey().equals(entry.getValue()) && isResourceExist(ldr, 
entry.getKey()) &&
!U.hasParent(clsLdrToIgnore, ldr) && 
ldrRsrcs.remove(ldr, clsLdrRsrcs)) {
...
}
{noformat}

and can be fixed by adding clsLdrRsrcs.containsKey(entry.getKey()):

{noformat}
if (entry.getKey().equals(entry.getValue()) && isResourceExist(ldr, 
entry.getKey()) &&
!U.hasParent(clsLdrToIgnore, ldr) && 
clsLdrRsrcs.containsKey(entry.getKey()) && ldrRsrcs.remove(ldr, clsLdrRsrcs)) {
...
}
{noformat}

Reproducer (might require multiple runs)

{noformat}
/** */
public class Main {
public static void main(String args[]) throws MalformedURLException, 
ClassNotFoundException {
System.setProperty("IGNITE_CACHE_REMOVED_ENTRIES_TTL", "1");

IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setPeerClassLoadingEnabled(true);

TcpDiscoverySpi spi = new TcpDiscoverySpi();
spi.setIpFinder(new TcpDiscoveryVmIpFinder(true));

cfg.setDiscoverySpi(spi);

final Ignite ignite = Ignition.start(cfg);

final ClassLoader moduleClsLdr = Main.class.getClassLoader();

final ClassLoader moduleCLImpl = new DelegateClassLoader(null, 
moduleClsLdr);

for (int i = 0; i < 100; i++)
try {
Class clazz = moduleCLImpl.loadClass("Main$CallFunction");

ignite.compute().call(

(IgniteCallable)clazz.getDeclaredConstructor(ClassLoader.class).newInstance(moduleCLImpl)
);
}
catch (Exception e) {
e.printStackTrace();
}

System.out.println("Done");
}

public static class CallFunction implements IgniteCallable, 
GridPeerDeployAware {
transient ClassLoader classLoader;

public CallFunction(ClassLoader cls) {
this.classLoader = cls;
}

public Object call() throws Exception {
return null;
}

public Class deployClass() {
return this.getClass();
}

public ClassLoader classLoader() {
return classLoader;
}
}

public static class DelegateClassLoader extends ClassLoader {
private ClassLoader delegateCL;

public DelegateClassLoader(ClassLoader parent, ClassLoader delegateCL) {
super(parent); // Parent doesn't matter.
this.delegateCL = delegateCL;
}

@Override
public URL getResource(String name) {
return delegateCL.getResource(name);
}

@Override
public Class loadClass(String name) throws ClassNotFoundException {
return delegateCL.loadClass(name);
}
}
}
{noformat}



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

[GitHub] ignite pull request #1742: Ignite-4919 Remove support BinaryIdentityResolver

[DmitriyGovorukhin]

GitHub user DmitriyGovorukhin opened a pull request:

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

Ignite-4919 Remove support BinaryIdentityResolver



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

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

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

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


commit 56162b39a9a86751ea0b791505db14f69348163b
Author: sboikov 
Date:   2017-01-09T14:17:04Z

IgniteCacheContinuousQueryNoUnsubscribeTest: fixed test to wait for stable 
topology.

commit 15956a8a6a26e37d99501fdb7e5af0b00efae506
Author: sboikov 
Date:   2017-01-09T14:32:49Z

Fix NPE in GridCachePartitionExchangeManager.createPartitionsFullMessage.

commit d63b3862a43a142f248ac96bc3fd1c02705172da
Author: Alexey Goncharuk 
Date:   2017-01-09T14:59:15Z

Merge branch 'ignite-gg-8.0.2.ea2' of 
https://github.com/gridgain/apache-ignite into ignite-gg-11414

commit 34db273ba628fbcadbe742d90035a44295ae1aad
Author: sboikov 
Date:   2017-01-09T15:05:25Z

IgniteTxCachePrimarySyncTest: fixed test to wait for stable topology.

commit c7f1cce266c30676ad8781072362161fc7a50718
Author: Dmitriy Govorukhin 
Date:   2017-01-09T15:37:44Z

ignite-gg-11414 simplify iterator wrapper for cursor

commit bb2ad161888b676bd8afc7d4783fe939332f7064
Author: Dmitriy Govorukhin 
Date:   2017-01-09T15:38:43Z

ignite-gg-11414 minor update

commit 6107ddb8e987eb381ffdc4a16f928d8fe89fe003
Author: Alexey Goncharuk 
Date:   2017-01-09T16:38:48Z

Merge remote-tracking branch 'community/ignite-gg-11414' into 
ignite-gg-11414

commit 2b6484a5bcb5520e66ad13fa54507390e58d78ff
Author: Alexey Goncharuk 
Date:   2017-01-09T17:04:26Z

Code style, minors.

commit 98366b134947e9fb962b7f89fad5f24fc3e7af58
Author: sboikov 
Date:   2017-01-10T08:06:43Z

Disabled tests for unsupported peek modes.

commit 3c99f9099518854ad997963ae8efd2fc6a2b2c3c
Author: sboikov 
Date:   2017-01-10T10:37:26Z

Fixed issue when stopping node invalidates tx (due to NodeStoppingException 
from IgniteCacheOffheapManagerImpl.update).

commit e82940cdede7001b2cf72a63731df29c9fc43bc2
Author: sboikov 
Date:   2017-01-10T10:45:09Z

Disabled failing test.

commit f5fd34ea5ac855cb3f6bb517e6199276ad4a3e3f
Author: sboikov 
Date:   2017-01-10T11:35:18Z

Disabled failing tests,
GridDhtPreloader: fixed race between GridCacheMapEntry unswap/evict/info.

commit bb425161958052726c30b43ab7c7c9fa2512975f
Author: sboikov 
Date:   2017-01-10T11:40:44Z

Disabled failing tests.

commit 9af39adbd353c2fbebf982f239c78f8e0aa9e77c
Author: Dmitriy Govorukhin 
Date:   2017-01-10T12:31:19Z

ignite-gg-11414 distribution join in one suit

commit e03a9805e5e7ea653f10fe1abc6f2bd981bec71d
Author: Dmitriy Govorukhin 
Date:   2017-01-10T12:38:42Z

Merge remote-tracking branch 'remotes/professional/ignite-gg-8.0.2.ea2' 
into ignite-gg-11414

commit 4fbc38893673fbf896c9d946a7ff1154aaa92a8b
Author: sboikov 
Date:   2017-01-10T12:52:30Z

GridDhtForceKeysFuture: now when rebalancing is disabled partition can be 
in OWNED state, fixed future logic.

commit 11a7e7d0bfd6ac0a4bd4b3cdda584bfa63d2d244
Author: sboikov 
Date:   2017-01-10T13:01:34Z

GridCacheEntryExtras: assert for expireTime instead of ttl.

commit 1e39325cd3a54da97476b0779244f062d333f582
Author: sboikov 
Date:   2017-01-10T13:06:42Z

Disabled failing tests.

commit 13f16dc105053553181a92bea001735fe14a5d07
Author: sboikov 
Date:   2017-01-10T13:12:43Z

CacheLoadingConcurrentGridStartSelfTest: enabled late affinity assignment.

commit 3f942af1beba1973e9e72304c5cb98d21072dd63
Author: sboikov 
Date:   2017-01-10T13:18:33Z

CacheLoadingConcurrentGridStartSelfTest: enabled late affinity assignment.

commit 403ac1f14849899f2f2a66e53965b5b1f08580dc
Author: sboikov 
Date:   2017-01-10T13:27:29Z

GridCacheAbstractMetricsSelfTest: fixed test for offheap mode.

commit 55ac6e71e68dc1ce66edeee146da0073d1bf10f9
Author: sboikov 
Date:   2017-01-10T13:59:17Z

Do not evict removed entries, otherwise removes can be lost.

commit e4b8e4bf681456ca5e63a494378118a4b6e392a4
Author: sboikov 
Date:   2017-01-10T14:17:06Z

Added license headers.

commit 2aca7c79711020859e016e20e7f7633b2189c752
Author: sboikov 
Date:   2017-01-10T14:35:31Z

JettyRestProcessorAbstractSelfTest: fixed test.

commit fec70d790b8f0a74707c5ebe2b0f199ddc7e85cb
Author: sboikov 
Date:   2017-01-10T14:38:42Z

Disabled failing tests.

commit 942076720499e7fbf4c4d950655a17f3ee8b7b83
Author: sboikov 
Date:   2017-01-10T14:39:26Z

Disabled failing tests.

commit 6c6cbd327d67c05278a3617a0cfc4b0f90e0bffc
Author: Dmitriy Govorukhin 
Date:   2017-01-11T08:23:33Z

ignite-gg-8.0.2.ea2 ClusterStateAbstractTest fix test

commit 9d38f6bba15223c6fd091

[GitHub] ignite pull request #1468: IGNITE-4511: Set QueryIndexType.SORTED by default...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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 #1257: IGNITE-4259: Geospatial functionality is broken i...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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 #1082: IGNITE-3925: Output process ID to the log during ...

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---
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-4919) Remove support BinaryIdentityResolver

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-4919:
--

 Summary: Remove support BinaryIdentityResolver
 Key: IGNITE-4919
 URL: https://issues.apache.org/jira/browse/IGNITE-4919
 Project: Ignite
  Issue Type: Task
  Components: binary
Reporter: Dmitriy Govorukhin
Assignee: Dmitriy Govorukhin
 Fix For: 2.0


We must get rid of BinaryIdentityResolver, because in new memory mode we must 
provide stable binary key representation. 
[discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Stable-binary-key-representation-td15904.html]



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

Re: ScanQuery With BinaryObject

[Andrey Mashenkov]

I've creted a ticket [1].

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

On Wed, Apr 5, 2017 at 4:42 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Looks like a bug. Can you create a ticket?
>
> -Val
>
> On Wed, Apr 5, 2017 at 2:01 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > wrote:
>
> > To reproduce
> > - start standalone server
> > - run test, it should work fine.
> > - run test with changed filter code, it will return same results.
> >
> >
> > On Wed, Apr 5, 2017 at 11:40 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> >> Can you provide the test?
> >>
> >> -Val
> >>
> >> On Wed, Apr 5, 2017 at 1:37 AM, Andrey Mashenkov <
> >> andrey.mashen...@gmail.com
> >> > wrote:
> >>
> >> > Hi Val,
> >> >
> >> > I run test with no filter class in server classpath. I've got an error
> >> > wiith peerClassLoading disabled, which is ok as server can't unmarshal
> >> > filter object.
> >> > But with peerClassLoading enabled, query works fine but looks like
> >> filter
> >> > class won't be updated on server.
> >> >
> >> > On Wed, Apr 5, 2017 at 11:14 AM, Valentin Kulichenko <
> >> > valentin.kuliche...@gmail.com> wrote:
> >> >
> >> > > Andrey,
> >> > >
> >> > > Marshaller cache does not store classes, only class names. So I'm
> not
> >> > sure
> >> > > what you mean by this.
> >> > >
> >> > > I looked at the code and it seems I was wrong - peer class loading
> >> does
> >> > > work for scan query filter, which is good. But as I mentioned
> before,
> >> if
> >> > > the class is available on local classpath, it will never be
> >> dynamically
> >> > > loaded, even if peer class loading is enabled. Therefore server will
> >> not
> >> > > know about any changes happening to the class definition on the
> >> client.
> >> > > This is correct behavior.
> >> > >
> >> > > -Val
> >> > >
> >> > > On Wed, Apr 5, 2017 at 12:01 AM, Andrey Mashenkov <
> >> > > andrey.mashen...@gmail.com> wrote:
> >> > >
> >> > > > Hi Val,
> >> > > >
> >> > > > Filter object serialized and send inside GridCacheQueryRequest,
> and
> >> > then
> >> > > it
> >> > > > is deserialized on server side and loaded by cache class loader.
> >> > > > Looks like filter class is cached in marshaller cache.
> >> > > >
> >> > > >
> >> > > > On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
> >> > > > valentin.kuliche...@gmail.com> wrote:
> >> > > >
> >> > > > > Andrey,
> >> > > > >
> >> > > > > To my knowledge, peer class loading is not supported for scan
> >> query
> >> > > > > filters, but I'm not sure though. Can you please check?
> >> > > > >
> >> > > > > Note that this actually doesn't matter if the class is available
> >> on
> >> > > > > server's local classpath. In this case it will be always used
> >> > > regardless
> >> > > > of
> >> > > > > any changes done on a client (i.e. will never be dynamically
> >> loaded).
> >> > > > This
> >> > > > > is true for any functionality, including Compute Grid.
> >> > > > >
> >> > > > > -Val
> >> > > > >
> >> > > > > On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
> >> > > > > andrey.mashen...@gmail.com> wrote:
> >> > > > >
> >> > > > > > Crossposted to dev:
> >> > > > > >
> >> > > > > > Guys,
> >> > > > > >
> >> > > > > > ScanQuery filter code (see IgniteBiPredicate implementation
> >> below)
> >> > > can
> >> > > > be
> >> > > > > > cached on server side
> >> > > > > > that can cause unexpected results.
> >> > > > > > The main point here is server node never restarts while client
> >> does
> >> > > it
> >> > > > > with
> >> > > > > > filter code changed.
> >> > > > > >
> >> > > > > > Is it ok?
> >> > > > > >
> >> > > > > > I try to add *serialVersionUID* and it was useless. The only
> >> class
> >> > > > > renaming
> >> > > > > > was helpful.
> >> > > > > >
> >> > > > > >
> >> > > > > > -- Forwarded message --
> >> > > > > > From: David Li 
> >> > > > > > Date: Mon, Apr 3, 2017 at 9:24 AM
> >> > > > > > Subject: Re: ScanQuery With BinaryObject
> >> > > > > > To: u...@ignite.apache.org
> >> > > > > >
> >> > > > > >
> >> > > > > > Sorry, please ignore the previous email, it was sent by
> mistake.
> >> > > > > >
> >> > > > > > 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip
> it.
> >> > > > > > 2. In terminal, I start an ignite instance by *bin/ignite.sh
> >> > > > > > examples/config/example-ignite.xml*
> >> > > > > > 3. I create a Java application, source code as below:
> >> > > > > >
> >> > > > > > public static void main(String[] args) {
> >> > > > > > String ORG_CACHE = "org_cache_remote";
> >> > > > > >* Ignition.setClientMode(true);*
> >> > > > > > Ignite ignite = Ignition.start("example-ignite.xml");
> >> > > > > > CacheConfiguration orgCacheCfg = new
> >> > > > > > CacheConfiguration<>(ORG_CACHE);
> >> > > > > > orgCacheCfg.setIndexedTypes(Long.class,
> >> Organization.class);
> >> > > > > > ignite.destroyCache(ORG_CACHE);
> >> > > > > > IgniteCache cache =
> ignite.createCache(
> >> > >

[GitHub] ignite pull request #1741: IGNITE-4914 distributing marshaller mappings for ...

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

IGNITE-4914 distributing marshaller mappings for multiple platforms fixed



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

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

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

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


commit 519e9d473db696452c169e87719cb74d5be17c9a
Author: Sergey Chugunov 
Date:   2017-04-05T13:31:24Z

IGNITE-4914 distributing marshaller mappings for multiple platforms was 
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-4918) ScanQuery filter class code is not updated on server once it has been changed on client.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4918:


 Summary: ScanQuery filter class code is not updated on server once 
it has been changed on client.
 Key: IGNITE-4918
 URL: https://issues.apache.org/jira/browse/IGNITE-4918
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.9
Reporter: Andrew Mashenkov






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

Re: Async listeners for IgniteFuture

[Taras Ledkov]

Hi, Dmitry.

Is make sense use custom named executors [1] in your API?
i.e. adds method passed executor name?

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


On 05.04.2017 12:15, Dmitry Karachentsev wrote:

Hello everyone!

I'm working on this ticket [1] and Vladimir made a review where he has 
concerns about implementation. I want to know community opinion about 
second one: where user callbacks should be processed by default?


For that purpose I used public pool for now, but this could lead to 
deadlocks, so what is the best decision here: use callback fork join 
pool, additional one, or maybe force user to provide his own Executor?


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

Thanks!

-Dmitry.



--
Taras Ledkov
Mail-To: tled...@gridgain.com

Re: ScanQuery With BinaryObject

[Valentin Kulichenko]

Looks like a bug. Can you create a ticket?

-Val

On Wed, Apr 5, 2017 at 2:01 AM, Andrey Mashenkov  wrote:

> To reproduce
> - start standalone server
> - run test, it should work fine.
> - run test with changed filter code, it will return same results.
>
>
> On Wed, Apr 5, 2017 at 11:40 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
>> Can you provide the test?
>>
>> -Val
>>
>> On Wed, Apr 5, 2017 at 1:37 AM, Andrey Mashenkov <
>> andrey.mashen...@gmail.com
>> > wrote:
>>
>> > Hi Val,
>> >
>> > I run test with no filter class in server classpath. I've got an error
>> > wiith peerClassLoading disabled, which is ok as server can't unmarshal
>> > filter object.
>> > But with peerClassLoading enabled, query works fine but looks like
>> filter
>> > class won't be updated on server.
>> >
>> > On Wed, Apr 5, 2017 at 11:14 AM, Valentin Kulichenko <
>> > valentin.kuliche...@gmail.com> wrote:
>> >
>> > > Andrey,
>> > >
>> > > Marshaller cache does not store classes, only class names. So I'm not
>> > sure
>> > > what you mean by this.
>> > >
>> > > I looked at the code and it seems I was wrong - peer class loading
>> does
>> > > work for scan query filter, which is good. But as I mentioned before,
>> if
>> > > the class is available on local classpath, it will never be
>> dynamically
>> > > loaded, even if peer class loading is enabled. Therefore server will
>> not
>> > > know about any changes happening to the class definition on the
>> client.
>> > > This is correct behavior.
>> > >
>> > > -Val
>> > >
>> > > On Wed, Apr 5, 2017 at 12:01 AM, Andrey Mashenkov <
>> > > andrey.mashen...@gmail.com> wrote:
>> > >
>> > > > Hi Val,
>> > > >
>> > > > Filter object serialized and send inside GridCacheQueryRequest, and
>> > then
>> > > it
>> > > > is deserialized on server side and loaded by cache class loader.
>> > > > Looks like filter class is cached in marshaller cache.
>> > > >
>> > > >
>> > > > On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
>> > > > valentin.kuliche...@gmail.com> wrote:
>> > > >
>> > > > > Andrey,
>> > > > >
>> > > > > To my knowledge, peer class loading is not supported for scan
>> query
>> > > > > filters, but I'm not sure though. Can you please check?
>> > > > >
>> > > > > Note that this actually doesn't matter if the class is available
>> on
>> > > > > server's local classpath. In this case it will be always used
>> > > regardless
>> > > > of
>> > > > > any changes done on a client (i.e. will never be dynamically
>> loaded).
>> > > > This
>> > > > > is true for any functionality, including Compute Grid.
>> > > > >
>> > > > > -Val
>> > > > >
>> > > > > On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
>> > > > > andrey.mashen...@gmail.com> wrote:
>> > > > >
>> > > > > > Crossposted to dev:
>> > > > > >
>> > > > > > Guys,
>> > > > > >
>> > > > > > ScanQuery filter code (see IgniteBiPredicate implementation
>> below)
>> > > can
>> > > > be
>> > > > > > cached on server side
>> > > > > > that can cause unexpected results.
>> > > > > > The main point here is server node never restarts while client
>> does
>> > > it
>> > > > > with
>> > > > > > filter code changed.
>> > > > > >
>> > > > > > Is it ok?
>> > > > > >
>> > > > > > I try to add *serialVersionUID* and it was useless. The only
>> class
>> > > > > renaming
>> > > > > > was helpful.
>> > > > > >
>> > > > > >
>> > > > > > -- Forwarded message --
>> > > > > > From: David Li 
>> > > > > > Date: Mon, Apr 3, 2017 at 9:24 AM
>> > > > > > Subject: Re: ScanQuery With BinaryObject
>> > > > > > To: u...@ignite.apache.org
>> > > > > >
>> > > > > >
>> > > > > > Sorry, please ignore the previous email, it was sent by mistake.
>> > > > > >
>> > > > > > 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip it.
>> > > > > > 2. In terminal, I start an ignite instance by *bin/ignite.sh
>> > > > > > examples/config/example-ignite.xml*
>> > > > > > 3. I create a Java application, source code as below:
>> > > > > >
>> > > > > > public static void main(String[] args) {
>> > > > > > String ORG_CACHE = "org_cache_remote";
>> > > > > >* Ignition.setClientMode(true);*
>> > > > > > Ignite ignite = Ignition.start("example-ignite.xml");
>> > > > > > CacheConfiguration orgCacheCfg = new
>> > > > > > CacheConfiguration<>(ORG_CACHE);
>> > > > > > orgCacheCfg.setIndexedTypes(Long.class,
>> Organization.class);
>> > > > > > ignite.destroyCache(ORG_CACHE);
>> > > > > > IgniteCache cache = ignite.createCache(
>> > > > > > orgCacheCfg);
>> > > > > > cache.put(1L, new Organization(1L, "org1", true, "jurong
>> east",
>> > > > > > ""));
>> > > > > > cache.put(2L, new Organization(2L, "org2", false, "orchard",
>> > > > > ""));
>> > > > > > cache.put(3L, new Organization(3L, "org3", true, "jurong
>> west",
>> > > > > > ""));
>> > > > > > cache.put(4L, new Organization(4L, "org4", false,
>> "woodlands",
>> > > > > > ""));
>> > > > > > cache.put(5L, new Organization(5L, "org5"

Re: issue with Hibernate 2L cache region factory ignite-1.8

[vadopolski]

Hello everybody!

Cameron write please. How did you recreated mistake that the wrong
regions/caches were being updated?

I tried to do it in HibernateL2CacheConfigurationSelfTest.java -
testEntityCacheNonStrictFails. 

After: 
e2forUpdate.setName("XXX"); 
session.update(e2forUpdate); 

Both regions for Entity1 and Entity2 get updates and assert fails:
assertEquals(1,
sessionFactory.getStatistics().getSecondLevelCacheStatistics(ENTITY1_NAME).getPutCount());
 





Cameron Braid wrote
> I have just discovered that the ignite hibernate layer 2 cache region
> factory does something weird with tracking changes - the wrong
> regions/caches were being updated  -  I would end up with cache entries
> for
> other regions in one region.
> 
> for example if I say loaded updated a product entity then updated a
> customer entity the product cache could contain the update to the
> customer.
> 
> It looks like someone didn't finish the implementation as there was a note
> in source : /** Map needed to provide the same transaction context for
> different regions. */
> 
> So I made the following two lines of change in
> modules/hibernate/src/main/java/org/apache/ignite/cache/hibernate/HibernateRegionFactory
> 
> Line 102 in 1.8 :
> 
> -private final ThreadLocal threadLoc = new ThreadLocal();
> +private ConcurrentMap threadLocMap = new
> ConcurrentHashMap<>();
> 
> Line 222 in 1.8 :
> 
>  ThreadLocal threadLocalForCache(String cacheName) {
> -return threadLoc;
> +return threadLocMap.computeIfAbsent(cacheName, (k)->new
> ThreadLocal());;
>  }
> 
> 
> Cameron





--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/issue-with-Hibernate-2L-cache-region-factory-ignite-1-8-tp14912p16170.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[GitHub] ignite pull request #1740: Ignite 1.8.6

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite 1.8.6



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

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

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

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


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

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

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

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

(cherry picked from commit f445e7b)

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

IGNITE-4299: Fixes for examples.

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

IGNITE-4305 marshalling fix in GridNearAtomicSingleUpdateInvokeRequest

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

IGNITE-4305 marshalling fix

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

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

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

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

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

Improved exception handling.

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

Updated classnames.properties for running nodes in IDE.

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

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

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

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

(cherry picked from commit 0b7c62d)

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

IGNITE-4347: Fixed NPE.

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

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

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

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

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

ignite-2545 Optimization for GridCompoundFuture's futures iteration

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

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

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

Improved exception handling for failed queries.

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

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

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

ignite-3685 - fixed

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

IGNITE-3770 GridLogThrottle.warn ignores the exception

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

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

commit 671a77a2d81cac401765dddf25f30fba4e4ab17f
Author: sboikov 
Date:   2016-12-08T09:56:46Z

ignite-4154 Fixed node version check for compression feature usage

commit 391f4be4c687a7f325aeec8b727c9c85ca003454
Author: agura 
Date:   2016-12-07T17:11:50Z

ignite-2358 toString() method for cache store implementations

commit bc977d3211906ef94e1f7d3f0f988efbed65034f
Author: Alexey Kuznetsov 
Date:   2016-12-09T09:11:31Z

IGNITE-4350 Reworked JdbcTypesDefaultTransformed logic. Improved improved 
error messages in CacheJdbcPojoStore.

commit b83ec8e57c7c48f2baa4780cf3b2e46df075

[GitHub] ignite pull request #1739: Ignite-1267-1

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite-1267-1

for test purpose only

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

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

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

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


commit e01aee0b1bbdb8ff5583728e539df165029f682d
Author: nikolay_tikhonov 
Date:   2017-03-31T17:19:52Z

Fixed SSL issue.

Signed-off-by: nikolay_tikhonov 

commit ead9f2a595b91821b1b16627dd8d752897c24c03
Author: dkarachentsev 
Date:   2017-04-03T11:46:54Z

Merge branch 'ignite-1.8.4-p1' into ignite-1.8.6

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 925ee11c2002729b1264148ee5db5700ded5a7b7
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:06:01Z

Fixed typo.
(cherry picked from commit 3b84f34)

commit ce4b078c1c97cae4136c318ae38b27a50fe383cc
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:14:56Z

master Updated version.
(cherry picked from commit 5469626)

commit 9deadbec00d10b94945986db0c7363213435c7e3
Author: Andrey V. Mashenkov 
Date:   2017-04-05T09:12:51Z

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

Re: Question: local cache on client nodes

[Sergey Chugunov]

In that case I suggest the following solution based on the same model of
allocating memory on node startup.

So, on client nodes if user provides configuration for MemoryPolicies, we
allocate all memory on node startup.
But if no MemoryPolicy configuration is provided on client node startup, no
default MemoryPolicy is allocated and any attempts to create a local cache
on client node will result in exception.

This solution allows users to have local caches on client nodes (with all
appropriate capacity planning; so we are talking about experienced users);
at the same time it allows starting lightweight client nodes with small
memory footprint.

Very simple yet powerful and easy to implement.

Thoughts?


On Thu, Mar 30, 2017 at 3:00 PM, Denis Magda  wrote:

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

[GitHub] ignite pull request #1738: IGNITE-4899 .NET: Review Dictionary usage in APIs

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-4899 .NET: Review Dictionary usage in APIs



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

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

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

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


commit 68f2417e452ccb4faf2bb4c9fc302a4f90dc3f8e
Author: Pavel Tupitsyn 
Date:   2017-04-05T12:04:40Z

PutAll refactored

commit 31812f03e503827b1f8b0ab3e79d5dc0dd784294
Author: Pavel Tupitsyn 
Date:   2017-04-05T12:17:43Z

Refactor GetAll & GetAllAsync

commit aefa134f4a826d64ae2d11eda6a42a877eb48874
Author: Pavel Tupitsyn 
Date:   2017-04-05T12:20:14Z

Fix example

commit 41d1c749383d728fa6d5c28a066a7a17e52abada
Author: Pavel Tupitsyn 
Date:   2017-04-05T12:30:38Z

wip InvokeAll

commit 8b58574337c633fae47211cf9f8dd98b402f2779
Author: Pavel Tupitsyn 
Date:   2017-04-05T12:32:05Z

InvokeAll done




---
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 #1737: IGNITE-4535

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-4535



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

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

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

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


commit 59c302c1b707c29a681fca398671863e69d22171
Author: Ilya Lantukh 
Date:   2017-03-14T13:29:15Z

ignite-4535 : WIP.

(cherry picked from commit 4dc8376)

commit abfbaf801f8a4de747e463a2ac7bcdb5cea61061
Author: Ilya Lantukh 
Date:   2017-03-16T11:44:24Z

ignite-4535 : fixed tests to distinguish onheap and offheap peeks.

(cherry picked from commit 925c7e4)

commit 51d27eb772a227ecbfd6a394c16bea89d945f94e
Author: Ilya Lantukh 
Date:   2017-03-16T12:55:22Z

ignite-4535 : Fixed test failures.

(cherry picked from commit 678bd1b)

commit 82fe3bfc3ac5a3997ea2c650cf6ee40753325a10
Author: Ilya Lantukh 
Date:   2017-03-16T14:53:30Z

ignite-4535 : Analyzed failing tests.

(cherry picked from commit 7c483a3)

commit 5ce33f3334c1692eed93a07af3eb962b44f7b8cb
Author: Ilya Lantukh 
Date:   2017-03-16T15:34:15Z

ignite-4535 : Fixed and uncommented eviction tests.

(cherry picked from commit ff4ec5e)

commit 8c60243aac12164918aedc829936a61db4e44d31
Author: Ilya Lantukh 
Date:   2017-03-20T12:49:27Z

ignite-4535 : Removed SWAP PeekMode, adjusted tests.

(cherry picked from commit 5ac245e)

commit edc8b7fb51786a405f5a26fe6b6b059ac7e3ed10
Author: Ilya Lantukh 
Date:   2017-03-20T13:49:41Z

ignite-4535 : Fixed calculation of entries count in heap.

(cherry picked from commit 9826ce4)

commit 51eee72c8fb594005a517c8db30578e84728e099
Author: Ilya Lantukh 
Date:   2017-03-20T15:15:42Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit 149b974)

commit b55640aafb8e4e9d701e606239a31384e133ea35
Author: Ilya Lantukh 
Date:   2017-03-20T15:29:57Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit 250597e)

commit 3e71edae117c435ee406c4fda6526c27d805db99
Author: Ilya Lantukh 
Date:   2017-03-20T16:12:36Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit 5e90523)

commit 5ec807a53a812c47a5a8b22f98d57b25cccf0240
Author: Ilya Lantukh 
Date:   2017-03-21T13:27:18Z

ignite-4535 : Removing CacheMemoryMode - WIP.

(cherry picked from commit b3e1bc3)

commit 7a49fa5d4be9970af93ef662abc84d0538638717
Author: Ilya Lantukh 
Date:   2017-03-30T13:10:26Z

ignite-4535 : Conflicts.

commit 4ea0316e7a2e04389e57efbfbbeaad77fa5bcb45
Author: Ilya Lantukh 
Date:   2017-03-21T13:48:51Z

ignite-4535 : Removing CacheMemoryMode - done.

(cherry picked from commit 6b7472c)

commit c89c563b573d57f5138ab61bd9a161a2d8c8866b
Author: Ilya Lantukh 
Date:   2017-03-21T13:52:43Z

ignite-4535 : Removed redundant test.

(cherry picked from commit 3cfea91)

commit 141064ed9e0c392ca0c5bb51bf848945bec1c1d1
Author: Ilya Lantukh 
Date:   2017-03-21T14:29:05Z

ignite-4535 : Fixed size calculation.

(cherry picked from commit 531a449)

commit b5ccfe365ff1a1f1ef949b7505f6058b772671c7
Author: Ilya Lantukh 
Date:   2017-03-21T14:42:06Z

ignite-4535 : Redesigned semantics of GridDhtLocalPartitions#size() and 
#publicSize() methods.

(cherry picked from commit dd3884d)

commit 0756bb890c26d74a51e72268811048c485502aee
Author: Ilya Lantukh 
Date:   2017-03-22T12:15:02Z

ignite-4535 : Fixed test.

(cherry picked from commit 1475ee3)

commit 952c0efd12d2b90b3b519a999ae0fd6935b84274
Author: Ilya Lantukh 
Date:   2017-03-24T11:30:00Z

ignite-4535 : Fixed DHT cache size calculation.

(cherry picked from commit 06c845c)

commit 06d853d124c9cfc1cea5e13867edfa78c89a3d74
Author: Ilya Lantukh 
Date:   2017-03-30T13:21:52Z

ignite-4535 : conflicts

commit 4ad8974c9f741ea33379ad4e323db9873cfda328
Author: Ilya Lantukh 
Date:   2017-03-30T13:31:03Z

ignite-4535 : Conflicts.

commit ecfc45e23bcbc5e440a74c594c21455bdd8b935e
Author: Ilya Lantukh 
Date:   2017-03-31T13:14:42Z

Removed properties specific for old OFFHEAP modes: offheapMaxMemory and 
sqlOnheapRowCacheSize.

commit 7d7b28377c0f53037e5207a18a109ad22c8954aa
Author: Ilya Lantukh 
Date:   2017-03-31T13:41:15Z

Removed getOrCreateEntry(...).

commit f2df0a7c7c11426bc83839cc903f10da18a0d677
Author: Ilya Lantukh 
Date:   2017-03-31T13:50:06Z

ignite-4535 : GridDhtLocalPartition - replaced delegation to map with 
inheritance.

commit 65d816f39a6985c2cc2104960ec1f41574e4e3a6
Author: Ilya Lantukh 
Date:   2017-03-31T14:20:27Z

ignite-4535 : Removed sync evicts.

commit 51b0d0079bab80fc78115d0db40c8569f41894de
Author

[GitHub] ignite pull request #1620: Ignite 4535

[ilantukh]

Github user ilantukh closed the pull request at:

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


---
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: Non-collocated distributed SQL Joins across caches over separate cluster groups

[christos]

I suggest we continue the conversation on the user list. My bad for pinging
the email to both channels.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Non-collocated-distributed-SQL-Joins-across-caches-over-separate-cluster-groups-tp16136p16163.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: one point optimisation

[ALEKSEY KUZNETSOV]

would like to add 1 phase optimisation isn't gonna work if write through is
enabled.

ср, 5 апр. 2017 г. в 15:23, Антон Чураев :

> Maybe it will be useful to update the documentation?
>
> 2017-04-05 15:15 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > Thank you for help!
> >
> > ср, 5 апр. 2017 г. в 15:14, Alexey Goncharuk  >:
> >
> > > This optimization does not work when near cache is enabled because we
> > need
> > > the same ordering on near nodes. You should see the expected number of
> > > messages with near cache disabled.
> > >
> > > 2017-04-05 15:09 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > yes
> > > >
> > > > ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > > >
> > > > > Do you have a near cache enabled?
> > > > >
> > > > > 2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > The test shows as follows:
> > > > > > assertMessageCount(GridNearTxPrepareRequest.class,
> 1);
> > > > > > assertMessageCount(GridDhtTxPrepareRequest.class, 1);
> > > > > > assertMessageCount(GridDhtTxPrepareResponse.class,
> 1);
> > > > > > assertMessageCount(GridNearTxPrepareResponse.class,
> > 1);
> > > > > > assertMessageCount(GridNearTxFinishRequest.class, 1);
> > > > > > assertMessageCount(GridDhtTxFinishRequest.class, 0);
> > > > > > assertMessageCount(GridNearTxFinishResponse.class,
> 1);
> > > > > >
> > > > > > ср, 5 апр. 2017 г. в 14:53, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > Aleksey,
> > > > > > >
> > > > > > > Can you elaborate on which of the extra messages you observe?
> > > > > > >
> > > > > > > --AG
> > > > > > >
> > > > > > > 2017-04-04 14:17 GMT+03:00 ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > > any thoughts on one phase commit realization ?
> > > > > > > >
> > > > > > > > пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com
> > > > > > > >:
> > > > > > > >
> > > > > > > > > I've attached test that prints messages exchange . Which
> > shows
> > > us
> > > > > > that
> > > > > > > > > there are more messages then you declared in article.
> > Perhaps,
> > > > > > > > > implementation has changed.
> > > > > > > > > I created it on base of IgniteOnePhaseCommitNearSelfTest
> > > > > > > > >
> > > > > > > > > пн, 3 апр. 2017 г. в 19:03, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >:
> > > > > > > > >
> > > > > > > > > Aleksey,
> > > > > > > > >
> > > > > > > > > The blog describes the 1-phase commit at a high level, but
> I
> > am
> > > > > still
> > > > > > > > > curious about the differences you found. Can you share them
> > > here?
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Mon, Apr 3, 2017 at 2:11 AM, ALEKSEY KUZNETSOV <
> > > > > > > > > alkuznetsov...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Regarding IgniteOnePhaseCommitNearSelfTest test ,
> ignite's
> > > one
> > > > > > phase
> > > > > > > > > > optimisation works not as you said.
> > > > > > > > > > I attached picture of message exchange. There are partial
> > > > prepare
> > > > > > > phase
> > > > > > > > > > exists, along with finish phase.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > пн, 3 апр. 2017 г. в 10:55, Christos Erotocritou <
> > > > > > > > chris...@gridgain.com
> > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > >> As far as I know a partition is always allocated to a
> > > specific
> > > > > > node
> > > > > > > > and
> > > > > > > > > >> does not span nodes. Ignite has default 1024 partitions
> on
> > > > start
> > > > > > > that
> > > > > > > > > are
> > > > > > > > > >> split equally across nodes.
> > > > > > > > > >>
> > > > > > > > > >> > On 3 Apr 2017, at 08:10, ALEKSEY KUZNETSOV <
> > > > > > > > alkuznetsov...@gmail.com>
> > > > > > > > > >> wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > in ur blog u texted belonging to the same partition is
> > > > > nessesary
> > > > > > > > for 1
> > > > > > > > > >> > phase commit. But its not guarantee belonging to the
> > same
> > > > > node.
> > > > > > > > > >> Partition
> > > > > > > > > >> > may span many nodes
> > > > > > > > > >> >
> > > > > > > > > >> > вс, 2 Апр 2017 г., 13:46 ALEKSEY KUZNETSOV <
> > > > > > > > alkuznetsov...@gmail.com
> > > > > > > > > >:
> > > > > > > > > >> >
> > > > > > > > > >> >> thank u !
> > > > > > > > > >> >>
> > > > > > > > > >> >> пт, 31 Мар 2017 г., 21:06 Denis Magda <
> > dma...@apache.org
> > > >:
> > > > > > > > > >> >>
> > > > > > > > > >> >> Here is a good blog post about 1phase commit impl in
> > > Ignite
> > > > > and
> > > > > > > its
> > > > > > > > > >> >> advantages:
> > > > > > > > > >> >>
> > > > > > > > > >> >> http://gridgain.blogspot.com/
> > > > 2014/09/one-phase-commit-fast-
> > > > > > > > > >> 

Fwd: IGNITE - 4760 : added test

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

Hello everybody!

Added test. Test fails after session.update(e2forUpdate). This update must
put into ENTITY2_NAME region, but it puts into ENTITY1_NAME and
ENTITY2_NAME regions.

https://github.com/vadopolski/ignite/pull/1

Is it true?

I have no idea how to change the method threadLocalForCache to support
NONSTRICT_READ_WRITE strategy. I tried to change it in accordance with
Cameroon Braid report.

Vadim Opolski


-- Forwarded message --
From: Вадим Опольский 
Date: 2017-04-03 17:39 GMT+03:00
Subject: Re: IGNITE - 4760 : working in hibernate module
To: dev@ignite.apache.org
Cc: Valentin Kulichenko , Semyon Boikov <
sboi...@gridgain.com>


Hello everyone!

I added some change to method threadLocalForCache  and added test
testEntityCacheNonStrictFails.

How to reproduce situation when updates can be recorded to another region?

https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac507ed73872d62
b2969a7411/modules/hibernate/src/main/java/org/apache/
ignite/cache/hibernate/HibernateRegionFactory.java

https://github.com/vadopolski/ignite/blob/5aa25f3830fef14ac507ed73872d62
b2969a7411/modules/hibernate/src/test/java/org/apache/
ignite/cache/hibernate/HibernateL2CacheConfigurationSelfTest.java

PullRequest
https://github.com/vadopolski/ignite/pull/4/files

Vadim



2017-03-27 18:20 GMT+03:00 Denis Magda :

> Vadim,
>
> What IDE do you use? My recommendation would be to set up everything let’s
> say under IntellijIDEA or Eclipse and after that trying to compile from a
> terminal.
>
> This is how you can easily prepare the dev env in IntellijIDEA:
> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup <
> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup>
>
> —
> Denis
>
> > On Mar 27, 2017, at 7:14 AM, Вадим Опольский 
> wrote:
> >
> > Valentin, OK.
> >
> > To enabled it in my environment I done next:
> > - built project with command - mvn clean package -DskipTests
> -Prelease,lgpl
> > - added folder hibernate to modules in project structure
> > - added library to dependencies (without it import doesn't working)
> >
> > After that I have a lot of error, for instance:
> > - Class 'AccessStrategy' must either be declared abstract or implement
> abstract method 'remove(SharedSessionContractImplementor, Object) in
> 'RegionAccessStrategy'
> >
> > generateCacheKey
> > getCacheKeyId
> > getRegion
> > insert
> > afterInsert
> > update
> > afterUpdate
> > insert
> > afterInsert
> > update
> > get
> > putFromLoad
> > lockItem
> > unlockItem
> > remove
> >
> > Do anybody know the easier way to resolve this issue?
> >
> > Also tried to reimport all maven projects and cleansed repository in .m2.
> > Vadim Opolski
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 2017-03-25 2:42 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com >:
> > Vadim,
> >
> > ignite-hibernate module is a part of 'lgpl' profile. Apparently it's not
> > enabled in your environment.
> >
> > -Val
> >
> > On Fri, Mar 24, 2017 at 4:38 PM, Вадим Опольский  >
> > wrote:
> >
> > > Hello everybody,
> > >
> > > I want to resolve issue №4760
> > > https://issues.apache.org/jira/browse/IGNITE-4760 <
> https://issues.apache.org/jira/browse/IGNITE-4760>
> > >
> > > To find solution I'm going to change method threadLocalForCache and to
> add
> > > Junit test.
> > >
> > > Why folder hibernate is not a module ? Can I added it ?
> > >
> > > Vadim Opolski
> > >
> >
>
>

Re: Non-collocated distributed SQL Joins across caches over separate cluster groups

[Andrey Mashenkov]

Sergi,

Does it means that "broken" FairAffinityFunction can lead to wrong SQL
query result?
As we know, using FairAF have no guarantee that same parititions of
different caches can belongs to different nodes in some cases.

On Wed, Apr 5, 2017 at 1:47 PM, Sergi Vladykin 
wrote:

> Hi,
>
> Moreover distributed joins can be executed only between caches with the
> same affinity (same partitions on the same nodes).
>
> Keep in mind that distributed join is already a "last resort" thing and you
> have to prefer collocated joins as much as possible, if you want to achieve
> good performance. Distributed join between different cluster groups will
> make things even worse.
>
> Sergi
>
> 2017-04-05 12:02 GMT+03:00 Christos Erotocritou :
>
> > Igniters,
> >
> > Is it correct to assume the following:
> >
> >- We have an Ignite cluster comprised of 2 cluster groups A & B that
> >have different caches deployed.
> >- We use an Ignite client to obtain API access to the whole cluster
> >and execute a join query that joins data across the 2 caches
> >
> > My understanding is that this is *not possible*, correct?
> >
> > Reading this article [1
> >  large-bank-process-geog-1>]
> > it seems that such cross-cluster-group behaviour is supported with the
> > transactions API and also advised.
> >
> > Any thoughts why the SQL API would not allow this and requires caches to
> > be located on all nodes when the JOIN query is executed?
> >
> > Cheers,
> > Christos
> >
>



-- 
Best regards,
Andrey V. Mashenkov

Re: one point optimisation

[Антон Чураев]

Maybe it will be useful to update the documentation?

2017-04-05 15:15 GMT+03:00 ALEKSEY KUZNETSOV :

> Thank you for help!
>
> ср, 5 апр. 2017 г. в 15:14, Alexey Goncharuk :
>
> > This optimization does not work when near cache is enabled because we
> need
> > the same ordering on near nodes. You should see the expected number of
> > messages with near cache disabled.
> >
> > 2017-04-05 15:09 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > yes
> > >
> > > ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> > >
> > > > Do you have a near cache enabled?
> > > >
> > > > 2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > >:
> > > >
> > > > > The test shows as follows:
> > > > > assertMessageCount(GridNearTxPrepareRequest.class, 1);
> > > > > assertMessageCount(GridDhtTxPrepareRequest.class, 1);
> > > > > assertMessageCount(GridDhtTxPrepareResponse.class, 1);
> > > > > assertMessageCount(GridNearTxPrepareResponse.class,
> 1);
> > > > > assertMessageCount(GridNearTxFinishRequest.class, 1);
> > > > > assertMessageCount(GridDhtTxFinishRequest.class, 0);
> > > > > assertMessageCount(GridNearTxFinishResponse.class, 1);
> > > > >
> > > > > ср, 5 апр. 2017 г. в 14:53, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > > >
> > > > > > Aleksey,
> > > > > >
> > > > > > Can you elaborate on which of the extra messages you observe?
> > > > > >
> > > > > > --AG
> > > > > >
> > > > > > 2017-04-04 14:17 GMT+03:00 ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com
> > > > >:
> > > > > >
> > > > > > > any thoughts on one phase commit realization ?
> > > > > > >
> > > > > > > пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV <
> > > > > alkuznetsov...@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > > I've attached test that prints messages exchange . Which
> shows
> > us
> > > > > that
> > > > > > > > there are more messages then you declared in article.
> Perhaps,
> > > > > > > > implementation has changed.
> > > > > > > > I created it on base of IgniteOnePhaseCommitNearSelfTest
> > > > > > > >
> > > > > > > > пн, 3 апр. 2017 г. в 19:03, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >:
> > > > > > > >
> > > > > > > > Aleksey,
> > > > > > > >
> > > > > > > > The blog describes the 1-phase commit at a high level, but I
> am
> > > > still
> > > > > > > > curious about the differences you found. Can you share them
> > here?
> > > > > > > >
> > > > > > > > D.
> > > > > > > >
> > > > > > > > On Mon, Apr 3, 2017 at 2:11 AM, ALEKSEY KUZNETSOV <
> > > > > > > > alkuznetsov...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Regarding IgniteOnePhaseCommitNearSelfTest test , ignite's
> > one
> > > > > phase
> > > > > > > > > optimisation works not as you said.
> > > > > > > > > I attached picture of message exchange. There are partial
> > > prepare
> > > > > > phase
> > > > > > > > > exists, along with finish phase.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > пн, 3 апр. 2017 г. в 10:55, Christos Erotocritou <
> > > > > > > chris...@gridgain.com
> > > > > > > > >:
> > > > > > > > >
> > > > > > > > >> As far as I know a partition is always allocated to a
> > specific
> > > > > node
> > > > > > > and
> > > > > > > > >> does not span nodes. Ignite has default 1024 partitions on
> > > start
> > > > > > that
> > > > > > > > are
> > > > > > > > >> split equally across nodes.
> > > > > > > > >>
> > > > > > > > >> > On 3 Apr 2017, at 08:10, ALEKSEY KUZNETSOV <
> > > > > > > alkuznetsov...@gmail.com>
> > > > > > > > >> wrote:
> > > > > > > > >> >
> > > > > > > > >> > in ur blog u texted belonging to the same partition is
> > > > nessesary
> > > > > > > for 1
> > > > > > > > >> > phase commit. But its not guarantee belonging to the
> same
> > > > node.
> > > > > > > > >> Partition
> > > > > > > > >> > may span many nodes
> > > > > > > > >> >
> > > > > > > > >> > вс, 2 Апр 2017 г., 13:46 ALEKSEY KUZNETSOV <
> > > > > > > alkuznetsov...@gmail.com
> > > > > > > > >:
> > > > > > > > >> >
> > > > > > > > >> >> thank u !
> > > > > > > > >> >>
> > > > > > > > >> >> пт, 31 Мар 2017 г., 21:06 Denis Magda <
> dma...@apache.org
> > >:
> > > > > > > > >> >>
> > > > > > > > >> >> Here is a good blog post about 1phase commit impl in
> > Ignite
> > > > and
> > > > > > its
> > > > > > > > >> >> advantages:
> > > > > > > > >> >>
> > > > > > > > >> >> http://gridgain.blogspot.com/
> > > 2014/09/one-phase-commit-fast-
> > > > > > > > >> transactions-for.html
> > > > > > > > >> >> <
> > > > > > > > >> >> http://gridgain.blogspot.com/
> > > 2014/09/one-phase-commit-fast-
> > > > > > > > >> transactions-for.html
> > > > > > > > >> >>>
> > > > > > > > >> >>
> > > > > > > > >> >> Took a reference to it from there:
> > > > > > > > >> >>
> > > > > > > > >> >>
> > https://apacheignite.readme.io/docs/transactions#section-
> > > > > > > > >> two-phase-commit-2pc
> 

Re: one point optimisation

[ALEKSEY KUZNETSOV]

Thank you for help!

ср, 5 апр. 2017 г. в 15:14, Alexey Goncharuk :

> This optimization does not work when near cache is enabled because we need
> the same ordering on near nodes. You should see the expected number of
> messages with near cache disabled.
>
> 2017-04-05 15:09 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > yes
> >
> > ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk  >:
> >
> > > Do you have a near cache enabled?
> > >
> > > 2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV  >:
> > >
> > > > The test shows as follows:
> > > > assertMessageCount(GridNearTxPrepareRequest.class, 1);
> > > > assertMessageCount(GridDhtTxPrepareRequest.class, 1);
> > > > assertMessageCount(GridDhtTxPrepareResponse.class, 1);
> > > > assertMessageCount(GridNearTxPrepareResponse.class, 1);
> > > > assertMessageCount(GridNearTxFinishRequest.class, 1);
> > > > assertMessageCount(GridDhtTxFinishRequest.class, 0);
> > > > assertMessageCount(GridNearTxFinishResponse.class, 1);
> > > >
> > > > ср, 5 апр. 2017 г. в 14:53, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > > >
> > > > > Aleksey,
> > > > >
> > > > > Can you elaborate on which of the extra messages you observe?
> > > > >
> > > > > --AG
> > > > >
> > > > > 2017-04-04 14:17 GMT+03:00 ALEKSEY KUZNETSOV <
> > alkuznetsov...@gmail.com
> > > >:
> > > > >
> > > > > > any thoughts on one phase commit realization ?
> > > > > >
> > > > > > пн, 3 апр. 2017 г. в 19:35, ALEKSEY KUZNETSOV <
> > > > alkuznetsov...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > I've attached test that prints messages exchange . Which shows
> us
> > > > that
> > > > > > > there are more messages then you declared in article. Perhaps,
> > > > > > > implementation has changed.
> > > > > > > I created it on base of IgniteOnePhaseCommitNearSelfTest
> > > > > > >
> > > > > > > пн, 3 апр. 2017 г. в 19:03, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >:
> > > > > > >
> > > > > > > Aleksey,
> > > > > > >
> > > > > > > The blog describes the 1-phase commit at a high level, but I am
> > > still
> > > > > > > curious about the differences you found. Can you share them
> here?
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Mon, Apr 3, 2017 at 2:11 AM, ALEKSEY KUZNETSOV <
> > > > > > > alkuznetsov...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Regarding IgniteOnePhaseCommitNearSelfTest test , ignite's
> one
> > > > phase
> > > > > > > > optimisation works not as you said.
> > > > > > > > I attached picture of message exchange. There are partial
> > prepare
> > > > > phase
> > > > > > > > exists, along with finish phase.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > пн, 3 апр. 2017 г. в 10:55, Christos Erotocritou <
> > > > > > chris...@gridgain.com
> > > > > > > >:
> > > > > > > >
> > > > > > > >> As far as I know a partition is always allocated to a
> specific
> > > > node
> > > > > > and
> > > > > > > >> does not span nodes. Ignite has default 1024 partitions on
> > start
> > > > > that
> > > > > > > are
> > > > > > > >> split equally across nodes.
> > > > > > > >>
> > > > > > > >> > On 3 Apr 2017, at 08:10, ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >> >
> > > > > > > >> > in ur blog u texted belonging to the same partition is
> > > nessesary
> > > > > > for 1
> > > > > > > >> > phase commit. But its not guarantee belonging to the same
> > > node.
> > > > > > > >> Partition
> > > > > > > >> > may span many nodes
> > > > > > > >> >
> > > > > > > >> > вс, 2 Апр 2017 г., 13:46 ALEKSEY KUZNETSOV <
> > > > > > alkuznetsov...@gmail.com
> > > > > > > >:
> > > > > > > >> >
> > > > > > > >> >> thank u !
> > > > > > > >> >>
> > > > > > > >> >> пт, 31 Мар 2017 г., 21:06 Denis Magda  >:
> > > > > > > >> >>
> > > > > > > >> >> Here is a good blog post about 1phase commit impl in
> Ignite
> > > and
> > > > > its
> > > > > > > >> >> advantages:
> > > > > > > >> >>
> > > > > > > >> >> http://gridgain.blogspot.com/
> > 2014/09/one-phase-commit-fast-
> > > > > > > >> transactions-for.html
> > > > > > > >> >> <
> > > > > > > >> >> http://gridgain.blogspot.com/
> > 2014/09/one-phase-commit-fast-
> > > > > > > >> transactions-for.html
> > > > > > > >> >>>
> > > > > > > >> >>
> > > > > > > >> >> Took a reference to it from there:
> > > > > > > >> >>
> > > > > > > >> >>
> https://apacheignite.readme.io/docs/transactions#section-
> > > > > > > >> two-phase-commit-2pc
> > > > > > > >> >> <
> > > > > > > >> >>
> https://apacheignite.readme.io/docs/transactions#section-
> > > > > > > >> two-phase-commit-2pc
> > > > > > > >> >>>
> > > > > > > >> >>
> > > > > > > >> >> —
> > > > > > > >> >> Denis
> > > > > > > >> >>
> > > > > > > >> >>> On Mar 31, 2017, at 12:27 PM, Dmitriy Setrakyan <
> > > > > > > >> dsetrak...@apache.org>
> > > > > > > >> >> wrote:
> > > > > > > >> >>>
> > > > > > > >> >>> On Fri, Mar 31, 2017 at 9:25 AM, ALEKSEY KUZNETS

Re: one point optimisation

[Alexey Goncharuk]

This optimization does not work when near cache is enabled because we need
the same ordering on near nodes. You should see the expected number of
messages with near cache disabled.

2017-04-05 15:09 GMT+03:00 ALEKSEY KUZNETSOV :

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

Re: one point optimisation

[ALEKSEY KUZNETSOV]

yes

ср, 5 апр. 2017 г. в 15:07, Alexey Goncharuk :

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

*Best Regards,*

*Kuznetsov Aleks

Re: one point optimisation

[Alexey Goncharuk]

Do you have a near cache enabled?

2017-04-05 15:00 GMT+03:00 ALEKSEY KUZNETSOV :

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

Re: one point optimisation

[ALEKSEY KUZNETSOV]

The test shows as follows:
assertMessageCount(GridNearTxPrepareRequest.class, 1);
assertMessageCount(GridDhtTxPrepareRequest.class, 1);
assertMessageCount(GridDhtTxPrepareResponse.class, 1);
assertMessageCount(GridNearTxPrepareResponse.class, 1);
assertMessageCount(GridNearTxFinishRequest.class, 1);
assertMessageCount(GridDhtTxFinishRequest.class, 0);
assertMessageCount(GridNearTxFinishResponse.class, 1);

ср, 5 апр. 2017 г. в 14:53, Alexey Goncharuk :

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

*Best Regards,*

*Kuznetsov Aleksey*

Re: one point optimisation

[Alexey Goncharuk]

Aleksey,

Can you elaborate on which of the extra messages you observe?

--AG

2017-04-04 14:17 GMT+03:00 ALEKSEY KUZNETSOV :

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

[GitHub] ignite pull request #1736: IGNITE-4917: BinaryObjectBuilder field value acce...

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4917: BinaryObjectBuilder field value access failed if its 
serialized with optimal marshaller

Fixed failure when accessing BinaryObjectBuilder field value serialized 
with OptimizedMarshaller.

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

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

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

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


commit 1fcf992b30d86ad0c34df82c7a6afb5c52ac6106
Author: Andrey V. Mashenkov 
Date:   2017-04-05T11:33:27Z

Fixed failure when accessing BinaryObjectBuilder field value serialized 
with OptimizedMarshaller .




---
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 #1735: Ignite-4917-1

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite-4917-1

for test purposes

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

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

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

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


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

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

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

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

(cherry picked from commit f445e7b)

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

IGNITE-4299: Fixes for examples.

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

IGNITE-4305 marshalling fix in GridNearAtomicSingleUpdateInvokeRequest

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

IGNITE-4305 marshalling fix

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

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

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

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

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

Improved exception handling.

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

Updated classnames.properties for running nodes in IDE.

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

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

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

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

(cherry picked from commit 0b7c62d)

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

IGNITE-4347: Fixed NPE.

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

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

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

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

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

ignite-2545 Optimization for GridCompoundFuture's futures iteration

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

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

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

Improved exception handling for failed queries.

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

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

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

ignite-3685 - fixed

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

IGNITE-3770 GridLogThrottle.warn ignores the exception

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

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

commit 671a77a2d81cac401765dddf25f30fba4e4ab17f
Author: sboikov 
Date:   2016-12-08T09:56:46Z

ignite-4154 Fixed node version check for compression feature usage

commit 391f4be4c687a7f325aeec8b727c9c85ca003454
Author: agura 
Date:   2016-12-07T17:11:50Z

ignite-2358 toString() method for cache store implementations

commit bc977d3211906ef94e1f7d3f0f988efbed65034f
Author: Alexey Kuznetsov 
Date:   2016-12-09T09:11:31Z

IGNITE-4350 Reworked JdbcTypesDefaultTransformed logic. Improved improved 
error messages in CacheJdbcPojoStore.

commit b83ec8e57c7c48f2b

Re: Stable binary key representation

[Alexey Goncharuk]

+1, I see no other reasons to keep it.

2017-04-05 13:59 GMT+03:00 Sergi Vladykin :

> +1
>
> Lets drop them.
>
> Sergi
>
> 2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com>
> :
>
> > Hi guys, i implemented proxy for IgniteCache in hibernate integration,
> this
> > proxy transformate cacheKey to our key wrapper, leaves only required
> > field. I think we can remove identity resolve, it should not broke
> > integration with hibernate. Any objections?
> >
> > On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > I'm not saying there is no alternative solution. But let's implement it
> > and
> > > prove that it works first, and remove resolvers only after that.
> > >
> > > -Val
> > >
> > > On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin <
> > sergi.vlady...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Guys, nothing is impossible if you know a bit about reflection in
> Java
> > :)
> > > >
> > > > We had a look at the CacheKey class and it is easily replaceable.
> > > >
> > > > Sergi
> > > >
> > > >
> > > >
> > > > 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan  >:
> > > >
> > > > > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> wrote:
> > > > >
> > > > > > "Hibernate key" is the CacheKey class I was referring to. It's
> > > provided
> > > > > by
> > > > > > Hibernate, not by user and not by us. So I'm not sure it's
> possible
> > > to
> > > > > > replace it.
> > > > > >
> > > > >
> > > > > If it is impossible to replace or get rid of the Hibernate key, is
> > this
> > > > > discussion valid at all?
> > > > >
> > > >
> > >
> >
>

[GitHub] ignite pull request #1734: IGNITE-4915 Remove deprecated methods at the publ...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-4915 Remove deprecated methods at the public API



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

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

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

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


commit 723bf2e2a1b0d5c52bb48d8a490189f6ac8f1d5d
Author: tledkov-gridgain 
Date:   2017-04-05T09:35:16Z

IGNITE-4915: remove IgniteCluster.mapKeysToNodes

commit f346a1eecf62323fe7bb6715548cd9dabf2c486a
Author: tledkov-gridgain 
Date:   2017-04-05T10:29:21Z

IGNITE-4915: remove IgniteCache.randomEntry

commit 61bfd5fa16b0002dc9ca3d141a496d7ca07872b7
Author: tledkov-gridgain 
Date:   2017-04-05T11:07:30Z

IGNITE-4915: remove deprecated properties from IGFS configuration

commit ee72fb8d267acae0cea94fa0c2cbc3c58f9a0130
Author: tledkov-gridgain 
Date:   2017-04-05T11:22:32Z

IGNITE-4915: remove deprecated methods from IgfsPath




---
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-4917) BinaryObjectBuilder field value access failed if its serialized with optimal marshaller

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4917:


 Summary: BinaryObjectBuilder field value access failed if its 
serialized with optimal marshaller
 Key: IGNITE-4917
 URL: https://issues.apache.org/jira/browse/IGNITE-4917
 Project: Ignite
  Issue Type: Bug
  Components: binary
Reporter: Andrew Mashenkov






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

Re: NearCache transaction qeustion

[ALEKSEY KUZNETSOV]

sorry, but what is sync/async policy ?

пт, 31 мар. 2017 г. в 19:26, Dmitriy Setrakyan :

> On Fri, Mar 31, 2017 at 6:29 AM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com
> > wrote:
>
> > Hi all!
> > Consider we have 4 nodes. Node1 contains key1, Node2 contains key1
> backup,
> > and Node3 near-contains (contains in near cache) key1.
> > Now we commit key1 value change like the following : Node4Cache.put(key1,
> > updatedValue);
> >
> > From my point of view Node1 receives prepare request and send
> > DhtTxPrepareRequest to Node2 and Node3.
> > processDhtTxPrepareRequest will be executed on Node3 and GridNearTxRemote
> > will be created by startNearRemoteTx().
> >
> > What is unclear is the role of GridNearTxRemote ?
> >
>
> From what I remember, this object is created to handle the near transaction
> (not the backup transaction). Near cache has to be updated in transactional
> fashion, but possibly with a different sync/async policy from primary node,
> so we need to handle the near transaction differently.
>
> D.
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #1733: IGNITE-4885 .NET: Disallow abstract and open gene...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-4885 .NET: Disallow abstract and open generic types in 
BinaryConfiguration



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

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

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

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


commit 3122c258fc7a7f3969e33f3c24dc3af568c13255
Author: Pavel Tupitsyn 
Date:   2017-04-05T10:00:50Z

IGNITE-4885 .NET: Meaningless exception on generic type in 
BinaryConfiguration

commit 7af83635c23d8a24e4763c226e922f2245bb8cf8
Author: Pavel Tupitsyn 
Date:   2017-04-05T10:28:20Z

wip

commit c96db8a12a6e40bff82cf75b568b601cfab5d263
Author: Pavel Tupitsyn 
Date:   2017-04-05T10:31:07Z

Fix exception propagation

commit 06dd3289cdce8a3fb6eeb77c727833dfa0ac3d4c
Author: Pavel Tupitsyn 
Date:   2017-04-05T10:34:15Z

wip

commit 270c881e8f6e7e175ea3a8c166e029231c1ccb00
Author: Pavel Tupitsyn 
Date:   2017-04-05T10:39:02Z

Add type validation

commit 29bb64949811ec474eac38a53f587d3a2d48f604
Author: Pavel Tupitsyn 
Date:   2017-04-05T10:52:35Z

Add check for abstract types

commit f79c138aceb9702ce746631f30cc363b9dc4dd30
Author: Pavel Tupitsyn 
Date:   2017-04-05T11:05:19Z

Fix tests




---
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: Stable binary key representation

[Sergi Vladykin]

+1

Lets drop them.

Sergi

2017-04-05 13:50 GMT+03:00 Dmitriy Govorukhin 
:

> Hi guys, i implemented proxy for IgniteCache in hibernate integration, this
> proxy transformate cacheKey to our key wrapper, leaves only required
> field. I think we can remove identity resolve, it should not broke
> integration with hibernate. Any objections?
>
> On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > I'm not saying there is no alternative solution. But let's implement it
> and
> > prove that it works first, and remove resolvers only after that.
> >
> > -Val
> >
> > On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin <
> sergi.vlady...@gmail.com
> > >
> > wrote:
> >
> > > Guys, nothing is impossible if you know a bit about reflection in Java
> :)
> > >
> > > We had a look at the CacheKey class and it is easily replaceable.
> > >
> > > Sergi
> > >
> > >
> > >
> > > 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > "Hibernate key" is the CacheKey class I was referring to. It's
> > provided
> > > > by
> > > > > Hibernate, not by user and not by us. So I'm not sure it's possible
> > to
> > > > > replace it.
> > > > >
> > > >
> > > > If it is impossible to replace or get rid of the Hibernate key, is
> this
> > > > discussion valid at all?
> > > >
> > >
> >
>

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

[Dmitriy Setrakyan]

On Wed, Apr 5, 2017 at 2:52 AM, Ilya Lantukh  wrote:

> Dmitry,
>
> 1. Setting an eviction policy should not be a mechanism to enable the
> > on-heap cache. We already have eviction policies off-heap as well, and
> they
> > don't enable anything. On top of that, the eviction policy should not be
> a
> > requirement for the on-heap cache. User should still be able to enable
> the
> > on-heap cache, even if it grows indefinitely without evictions. We should
> > have a more intuitive flag here.
>
>
> It doesn't make any sence to me to enable on-heap cache without evictions:
> it will result in having all data both in on-heap and off-heap memory. If
> we want to support such use case, we should implement a separate on-heap
> only mode with page memory disabled.
>

I agree that this would cause a double memory consumption, but yet again,
we don't have a pure on-heap cache yet. Until we do, we should not require
an eviction policy present for the on-heap caches.

Re: Stable binary key representation

[Dmitriy Govorukhin]

Hi guys, i implemented proxy for IgniteCache in hibernate integration, this
proxy transformate cacheKey to our key wrapper, leaves only required
field. I think we can remove identity resolve, it should not broke
integration with hibernate. Any objections?

On Wed, Mar 29, 2017 at 11:07 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> I'm not saying there is no alternative solution. But let's implement it and
> prove that it works first, and remove resolvers only after that.
>
> -Val
>
> On Wed, Mar 29, 2017 at 12:18 PM, Sergi Vladykin  >
> wrote:
>
> > Guys, nothing is impossible if you know a bit about reflection in Java :)
> >
> > We had a look at the CacheKey class and it is easily replaceable.
> >
> > Sergi
> >
> >
> >
> > 2017-03-29 21:49 GMT+03:00 Dmitriy Setrakyan :
> >
> > > On Wed, Mar 29, 2017 at 11:43 AM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > "Hibernate key" is the CacheKey class I was referring to. It's
> provided
> > > by
> > > > Hibernate, not by user and not by us. So I'm not sure it's possible
> to
> > > > replace it.
> > > >
> > >
> > > If it is impossible to replace or get rid of the Hibernate key, is this
> > > discussion valid at all?
> > >
> >
>

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

[Sergi Vladykin]

I think having pure on-heap cache is good idea.

Sergi

2017-04-05 12:52 GMT+03:00 Ilya Lantukh :

> Dmitry,
>
> 1. Setting an eviction policy should not be a mechanism to enable the
> > on-heap cache. We already have eviction policies off-heap as well, and
> they
> > don't enable anything. On top of that, the eviction policy should not be
> a
> > requirement for the on-heap cache. User should still be able to enable
> the
> > on-heap cache, even if it grows indefinitely without evictions. We should
> > have a more intuitive flag here.
>
>
> It doesn't make any sence to me to enable on-heap cache without evictions:
> it will result in having all data both in on-heap and off-heap memory. If
> we want to support such use case, we should implement a separate on-heap
> only mode with page memory disabled.
>
>
> On Tue, Apr 4, 2017 at 7:15 PM, Dmitriy Setrakyan 
> wrote:
>
> > Ilya, I looked at the Semyon's comments in the ticket, and I think I
> agree
> > with him on all counts.
> >
> > 1. Setting an eviction policy should not be a mechanism to enable the
> > on-heap cache. We already have eviction policies off-heap as well, and
> they
> > don't enable anything. On top of that, the eviction policy should not be
> a
> > requirement for the on-heap cache. User should still be able to enable
> the
> > on-heap cache, even if it grows indefinitely without evictions. We should
> > have a more intuitive flag here.
> >
> > 2. As far as the tests go, they should examine all the tests and adapt
> them
> > to the new behavior. I think we should have a replica of all off-heap
> tests
> > to test the scenario with on-heap caches.
> >
> > D.
> >
> > On Tue, Apr 4, 2017 at 8:12 AM, Ilya Lantukh 
> > wrote:
> >
> > > Hi Igniters,
> > >
> > > Since review of IGNITE-4535
> > >  implementation
> > caused
> > > some misunderstandings, I'd like to open a discussion here and see if
> > > everyone agrees with the chosen approach or can suggest a better one.
> > >
> > > We are going to re-use existing EvictionPolicy mechanics to decide when
> > > entry is going to be evicted from on-heap cache. If evictionPolicy ==
> > null,
> > > we assume that there is no on-heap cache. One of suggested alternatives
> > was
> > > to have a separate boolean parameter that will enable on-heap cache.
> > >
> > > Another questionable decision was to remove tests for memory mode
> > > variations. For example, we had GridCacheContinuousQueryAtomic
> SelfTest,
> > > GridCacheContinuousQueryAtomicOffheapTieredSelfTest and
> > > GridCacheContinuousQueryAtomicOffheapValuesSelfTest that were testing
> > the
> > > same functionallity for ONHEAP_TIERED, OFFHEAP_TIERED and
> OFFHEAP_VALUES
> > > modes, respectively. Since those memory modes were removed, only
> > > GridCacheContinuousQueryAtomicSelfTest was left and it now runs in
> > > off-heap
> > > mode without on-heap cache. One of suggestions was to add a new
> subclass
> > to
> > > this test (and all other tests) that will run the same test case with
> > > on-heap cache enabled. In my opinion, functionallity that is specific
> for
> > > on-heap cache should be tested in completely separate tests (which we
> > > already have), and there is no need to run generic tests with every
> > > possible configuration.
> > >
> > > What do you think?
> > >
> > > --
> > > Best regards,
> > > Ilya
> > >
> >
>
>
>
> --
> Best regards,
> Ilya
>

Re: Non-collocated distributed SQL Joins across caches over separate cluster groups

[Sergi Vladykin]

Hi,

Moreover distributed joins can be executed only between caches with the
same affinity (same partitions on the same nodes).

Keep in mind that distributed join is already a "last resort" thing and you
have to prefer collocated joins as much as possible, if you want to achieve
good performance. Distributed join between different cluster groups will
make things even worse.

Sergi

2017-04-05 12:02 GMT+03:00 Christos Erotocritou :

> Igniters,
>
> Is it correct to assume the following:
>
>- We have an Ignite cluster comprised of 2 cluster groups A & B that
>have different caches deployed.
>- We use an Ignite client to obtain API access to the whole cluster
>and execute a join query that joins data across the 2 caches
>
> My understanding is that this is *not possible*, correct?
>
> Reading this article [1
> ]
> it seems that such cross-cluster-group behaviour is supported with the
> transactions API and also advised.
>
> Any thoughts why the SQL API would not allow this and requires caches to
> be located on all nodes when the JOIN query is executed?
>
> Cheers,
> Christos
>

[jira] [Created] (IGNITE-4916) Hibernate support improvement

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-4916:


 Summary: Hibernate support improvement
 Key: IGNITE-4916
 URL: https://issues.apache.org/jira/browse/IGNITE-4916
 Project: Ignite
  Issue Type: Task
  Components: Hibernate L2 cache
Reporter: Andrew Mashenkov
 Fix For: 2.1






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

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

[Ilya Lantukh]

Dmitry,

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


It doesn't make any sence to me to enable on-heap cache without evictions:
it will result in having all data both in on-heap and off-heap memory. If
we want to support such use case, we should implement a separate on-heap
only mode with page memory disabled.


On Tue, Apr 4, 2017 at 7:15 PM, Dmitriy Setrakyan 
wrote:

> Ilya, I looked at the Semyon's comments in the ticket, and I think I agree
> with him on all counts.
>
> 1. Setting an eviction policy should not be a mechanism to enable the
> on-heap cache. We already have eviction policies off-heap as well, and they
> don't enable anything. On top of that, the eviction policy should not be a
> requirement for the on-heap cache. User should still be able to enable the
> on-heap cache, even if it grows indefinitely without evictions. We should
> have a more intuitive flag here.
>
> 2. As far as the tests go, they should examine all the tests and adapt them
> to the new behavior. I think we should have a replica of all off-heap tests
> to test the scenario with on-heap caches.
>
> D.
>
> On Tue, Apr 4, 2017 at 8:12 AM, Ilya Lantukh 
> wrote:
>
> > Hi Igniters,
> >
> > Since review of IGNITE-4535
> >  implementation
> caused
> > some misunderstandings, I'd like to open a discussion here and see if
> > everyone agrees with the chosen approach or can suggest a better one.
> >
> > We are going to re-use existing EvictionPolicy mechanics to decide when
> > entry is going to be evicted from on-heap cache. If evictionPolicy ==
> null,
> > we assume that there is no on-heap cache. One of suggested alternatives
> was
> > to have a separate boolean parameter that will enable on-heap cache.
> >
> > Another questionable decision was to remove tests for memory mode
> > variations. For example, we had GridCacheContinuousQueryAtomicSelfTest,
> > GridCacheContinuousQueryAtomicOffheapTieredSelfTest and
> > GridCacheContinuousQueryAtomicOffheapValuesSelfTest that were testing
> the
> > same functionallity for ONHEAP_TIERED, OFFHEAP_TIERED and OFFHEAP_VALUES
> > modes, respectively. Since those memory modes were removed, only
> > GridCacheContinuousQueryAtomicSelfTest was left and it now runs in
> > off-heap
> > mode without on-heap cache. One of suggestions was to add a new subclass
> to
> > this test (and all other tests) that will run the same test case with
> > on-heap cache enabled. In my opinion, functionallity that is specific for
> > on-heap cache should be tested in completely separate tests (which we
> > already have), and there is no need to run generic tests with every
> > possible configuration.
> >
> > What do you think?
> >
> > --
> > Best regards,
> > Ilya
> >
>



-- 
Best regards,
Ilya

[jira] [Created] (IGNITE-4915) Remove deprecated methods at the public API

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-4915:


 Summary: Remove deprecated methods at the public API
 Key: IGNITE-4915
 URL: https://issues.apache.org/jira/browse/IGNITE-4915
 Project: Ignite
  Issue Type: Sub-task
  Components: general
Affects Versions: 1.9
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.0






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

Async listeners for IgniteFuture

[Dmitry Karachentsev]

Hello everyone!

I'm working on this ticket [1] and Vladimir made a review where he has 
concerns about implementation. I want to know community opinion about 
second one: where user callbacks should be processed by default?


For that purpose I used public pool for now, but this could lead to 
deadlocks, so what is the best decision here: use callback fork join 
pool, additional one, or maybe force user to provide his own Executor?


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

Thanks!

-Dmitry.

Non-collocated distributed SQL Joins across caches over separate cluster groups

[Christos Erotocritou]

Igniters,

Is it correct to assume the following:
We have an Ignite cluster comprised of 2 cluster groups A & B that have 
different caches deployed. 
We use an Ignite client to obtain API access to the whole cluster and execute a 
join query that joins data across the 2 caches 
My understanding is that this is not possible, correct? 

Reading this article [1 
]
 it seems that such cross-cluster-group behaviour is supported with the 
transactions API and also advised.

Any thoughts why the SQL API would not allow this and requires caches to be 
located on all nodes when the JOIN query is executed?

Cheers,
Christos

Re: ScanQuery With BinaryObject

[Andrey Mashenkov]

To reproduce
- start standalone server
- run test, it should work fine.
- run test with changed filter code, it will return same results.


On Wed, Apr 5, 2017 at 11:40 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Can you provide the test?
>
> -Val
>
> On Wed, Apr 5, 2017 at 1:37 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com
> > wrote:
>
> > Hi Val,
> >
> > I run test with no filter class in server classpath. I've got an error
> > wiith peerClassLoading disabled, which is ok as server can't unmarshal
> > filter object.
> > But with peerClassLoading enabled, query works fine but looks like filter
> > class won't be updated on server.
> >
> > On Wed, Apr 5, 2017 at 11:14 AM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Andrey,
> > >
> > > Marshaller cache does not store classes, only class names. So I'm not
> > sure
> > > what you mean by this.
> > >
> > > I looked at the code and it seems I was wrong - peer class loading does
> > > work for scan query filter, which is good. But as I mentioned before,
> if
> > > the class is available on local classpath, it will never be dynamically
> > > loaded, even if peer class loading is enabled. Therefore server will
> not
> > > know about any changes happening to the class definition on the client.
> > > This is correct behavior.
> > >
> > > -Val
> > >
> > > On Wed, Apr 5, 2017 at 12:01 AM, Andrey Mashenkov <
> > > andrey.mashen...@gmail.com> wrote:
> > >
> > > > Hi Val,
> > > >
> > > > Filter object serialized and send inside GridCacheQueryRequest, and
> > then
> > > it
> > > > is deserialized on server side and loaded by cache class loader.
> > > > Looks like filter class is cached in marshaller cache.
> > > >
> > > >
> > > > On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> wrote:
> > > >
> > > > > Andrey,
> > > > >
> > > > > To my knowledge, peer class loading is not supported for scan query
> > > > > filters, but I'm not sure though. Can you please check?
> > > > >
> > > > > Note that this actually doesn't matter if the class is available on
> > > > > server's local classpath. In this case it will be always used
> > > regardless
> > > > of
> > > > > any changes done on a client (i.e. will never be dynamically
> loaded).
> > > > This
> > > > > is true for any functionality, including Compute Grid.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
> > > > > andrey.mashen...@gmail.com> wrote:
> > > > >
> > > > > > Crossposted to dev:
> > > > > >
> > > > > > Guys,
> > > > > >
> > > > > > ScanQuery filter code (see IgniteBiPredicate implementation
> below)
> > > can
> > > > be
> > > > > > cached on server side
> > > > > > that can cause unexpected results.
> > > > > > The main point here is server node never restarts while client
> does
> > > it
> > > > > with
> > > > > > filter code changed.
> > > > > >
> > > > > > Is it ok?
> > > > > >
> > > > > > I try to add *serialVersionUID* and it was useless. The only
> class
> > > > > renaming
> > > > > > was helpful.
> > > > > >
> > > > > >
> > > > > > -- Forwarded message --
> > > > > > From: David Li 
> > > > > > Date: Mon, Apr 3, 2017 at 9:24 AM
> > > > > > Subject: Re: ScanQuery With BinaryObject
> > > > > > To: u...@ignite.apache.org
> > > > > >
> > > > > >
> > > > > > Sorry, please ignore the previous email, it was sent by mistake.
> > > > > >
> > > > > > 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip it.
> > > > > > 2. In terminal, I start an ignite instance by *bin/ignite.sh
> > > > > > examples/config/example-ignite.xml*
> > > > > > 3. I create a Java application, source code as below:
> > > > > >
> > > > > > public static void main(String[] args) {
> > > > > > String ORG_CACHE = "org_cache_remote";
> > > > > >* Ignition.setClientMode(true);*
> > > > > > Ignite ignite = Ignition.start("example-ignite.xml");
> > > > > > CacheConfiguration orgCacheCfg = new
> > > > > > CacheConfiguration<>(ORG_CACHE);
> > > > > > orgCacheCfg.setIndexedTypes(Long.class, Organization.class);
> > > > > > ignite.destroyCache(ORG_CACHE);
> > > > > > IgniteCache cache = ignite.createCache(
> > > > > > orgCacheCfg);
> > > > > > cache.put(1L, new Organization(1L, "org1", true, "jurong
> east",
> > > > > > ""));
> > > > > > cache.put(2L, new Organization(2L, "org2", false, "orchard",
> > > > > ""));
> > > > > > cache.put(3L, new Organization(3L, "org3", true, "jurong
> west",
> > > > > > ""));
> > > > > > cache.put(4L, new Organization(4L, "org4", false,
> "woodlands",
> > > > > > ""));
> > > > > > cache.put(5L, new Organization(5L, "org5", false, "changi",
> > > > ""));
> > > > > > // cache.put(6L, new Organization(6L, "org6", true, "jurong
> > > > island",
> > > > > > ""));
> > > > > >
> > > > > > IgniteCache binaryCache =
> > > > cache.withKeepBinary();
> > > > > >
> > > > > > List> re

[GitHub] ignite pull request #1667: IGNITE-4839 Remove CacheTypeMetadata

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-4914) Dynamic type registration hangs for platformId > 0 on node restart

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-4914:
--

 Summary: Dynamic type registration hangs for platformId > 0 on 
node restart
 Key: IGNITE-4914
 URL: https://issues.apache.org/jira/browse/IGNITE-4914
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.0
Reporter: Pavel Tupitsyn
 Fix For: 2.0


{{MarshallerContextImpl.registerClassName}} hangs when called after node 
restart:

* Start two nodes, A and B
* Call {{registerClassName}} with {{platformId = 1}} and any class name from 
node B
* Stop node B
* Start node B again
* Call {{registerClassName}} with {{platformId = 1}} and any class name from 
node B

The last call hangs.



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

Re: ScanQuery With BinaryObject

[Valentin Kulichenko]

Can you provide the test?

-Val

On Wed, Apr 5, 2017 at 1:37 AM, Andrey Mashenkov  wrote:

> Hi Val,
>
> I run test with no filter class in server classpath. I've got an error
> wiith peerClassLoading disabled, which is ok as server can't unmarshal
> filter object.
> But with peerClassLoading enabled, query works fine but looks like filter
> class won't be updated on server.
>
> On Wed, Apr 5, 2017 at 11:14 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Andrey,
> >
> > Marshaller cache does not store classes, only class names. So I'm not
> sure
> > what you mean by this.
> >
> > I looked at the code and it seems I was wrong - peer class loading does
> > work for scan query filter, which is good. But as I mentioned before, if
> > the class is available on local classpath, it will never be dynamically
> > loaded, even if peer class loading is enabled. Therefore server will not
> > know about any changes happening to the class definition on the client.
> > This is correct behavior.
> >
> > -Val
> >
> > On Wed, Apr 5, 2017 at 12:01 AM, Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> > > Hi Val,
> > >
> > > Filter object serialized and send inside GridCacheQueryRequest, and
> then
> > it
> > > is deserialized on server side and loaded by cache class loader.
> > > Looks like filter class is cached in marshaller cache.
> > >
> > >
> > > On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Andrey,
> > > >
> > > > To my knowledge, peer class loading is not supported for scan query
> > > > filters, but I'm not sure though. Can you please check?
> > > >
> > > > Note that this actually doesn't matter if the class is available on
> > > > server's local classpath. In this case it will be always used
> > regardless
> > > of
> > > > any changes done on a client (i.e. will never be dynamically loaded).
> > > This
> > > > is true for any functionality, including Compute Grid.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
> > > > andrey.mashen...@gmail.com> wrote:
> > > >
> > > > > Crossposted to dev:
> > > > >
> > > > > Guys,
> > > > >
> > > > > ScanQuery filter code (see IgniteBiPredicate implementation below)
> > can
> > > be
> > > > > cached on server side
> > > > > that can cause unexpected results.
> > > > > The main point here is server node never restarts while client does
> > it
> > > > with
> > > > > filter code changed.
> > > > >
> > > > > Is it ok?
> > > > >
> > > > > I try to add *serialVersionUID* and it was useless. The only class
> > > > renaming
> > > > > was helpful.
> > > > >
> > > > >
> > > > > -- Forwarded message --
> > > > > From: David Li 
> > > > > Date: Mon, Apr 3, 2017 at 9:24 AM
> > > > > Subject: Re: ScanQuery With BinaryObject
> > > > > To: u...@ignite.apache.org
> > > > >
> > > > >
> > > > > Sorry, please ignore the previous email, it was sent by mistake.
> > > > >
> > > > > 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip it.
> > > > > 2. In terminal, I start an ignite instance by *bin/ignite.sh
> > > > > examples/config/example-ignite.xml*
> > > > > 3. I create a Java application, source code as below:
> > > > >
> > > > > public static void main(String[] args) {
> > > > > String ORG_CACHE = "org_cache_remote";
> > > > >* Ignition.setClientMode(true);*
> > > > > Ignite ignite = Ignition.start("example-ignite.xml");
> > > > > CacheConfiguration orgCacheCfg = new
> > > > > CacheConfiguration<>(ORG_CACHE);
> > > > > orgCacheCfg.setIndexedTypes(Long.class, Organization.class);
> > > > > ignite.destroyCache(ORG_CACHE);
> > > > > IgniteCache cache = ignite.createCache(
> > > > > orgCacheCfg);
> > > > > cache.put(1L, new Organization(1L, "org1", true, "jurong east",
> > > > > ""));
> > > > > cache.put(2L, new Organization(2L, "org2", false, "orchard",
> > > > ""));
> > > > > cache.put(3L, new Organization(3L, "org3", true, "jurong west",
> > > > > ""));
> > > > > cache.put(4L, new Organization(4L, "org4", false, "woodlands",
> > > > > ""));
> > > > > cache.put(5L, new Organization(5L, "org5", false, "changi",
> > > ""));
> > > > > // cache.put(6L, new Organization(6L, "org6", true, "jurong
> > > island",
> > > > > ""));
> > > > >
> > > > > IgniteCache binaryCache =
> > > cache.withKeepBinary();
> > > > >
> > > > > List> result;
> > > > >
> > > > > System.out.println("Scan by address");
> > > > > ScanQuery scanAddress = new ScanQuery<>(
> > > > > new IgniteBiPredicate() {
> > > > > @Override
> > > > > public boolean apply(Long aLong, BinaryObject
> > > binaryObject) {
> > > > > *// first time filter by jurong, got two entries,
> > org1
> > > > and
> > > > > org3*
> > > > > *// second time filter by changi, got two entries,
> > org1
> > > > and
> > > > > org3*
> > > > > *   

Re: ScanQuery With BinaryObject

[Andrey Mashenkov]

Hi Val,

I run test with no filter class in server classpath. I've got an error
wiith peerClassLoading disabled, which is ok as server can't unmarshal
filter object.
But with peerClassLoading enabled, query works fine but looks like filter
class won't be updated on server.

On Wed, Apr 5, 2017 at 11:14 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Andrey,
>
> Marshaller cache does not store classes, only class names. So I'm not sure
> what you mean by this.
>
> I looked at the code and it seems I was wrong - peer class loading does
> work for scan query filter, which is good. But as I mentioned before, if
> the class is available on local classpath, it will never be dynamically
> loaded, even if peer class loading is enabled. Therefore server will not
> know about any changes happening to the class definition on the client.
> This is correct behavior.
>
> -Val
>
> On Wed, Apr 5, 2017 at 12:01 AM, Andrey Mashenkov <
> andrey.mashen...@gmail.com> wrote:
>
> > Hi Val,
> >
> > Filter object serialized and send inside GridCacheQueryRequest, and then
> it
> > is deserialized on server side and loaded by cache class loader.
> > Looks like filter class is cached in marshaller cache.
> >
> >
> > On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Andrey,
> > >
> > > To my knowledge, peer class loading is not supported for scan query
> > > filters, but I'm not sure though. Can you please check?
> > >
> > > Note that this actually doesn't matter if the class is available on
> > > server's local classpath. In this case it will be always used
> regardless
> > of
> > > any changes done on a client (i.e. will never be dynamically loaded).
> > This
> > > is true for any functionality, including Compute Grid.
> > >
> > > -Val
> > >
> > > On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
> > > andrey.mashen...@gmail.com> wrote:
> > >
> > > > Crossposted to dev:
> > > >
> > > > Guys,
> > > >
> > > > ScanQuery filter code (see IgniteBiPredicate implementation below)
> can
> > be
> > > > cached on server side
> > > > that can cause unexpected results.
> > > > The main point here is server node never restarts while client does
> it
> > > with
> > > > filter code changed.
> > > >
> > > > Is it ok?
> > > >
> > > > I try to add *serialVersionUID* and it was useless. The only class
> > > renaming
> > > > was helpful.
> > > >
> > > >
> > > > -- Forwarded message --
> > > > From: David Li 
> > > > Date: Mon, Apr 3, 2017 at 9:24 AM
> > > > Subject: Re: ScanQuery With BinaryObject
> > > > To: u...@ignite.apache.org
> > > >
> > > >
> > > > Sorry, please ignore the previous email, it was sent by mistake.
> > > >
> > > > 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip it.
> > > > 2. In terminal, I start an ignite instance by *bin/ignite.sh
> > > > examples/config/example-ignite.xml*
> > > > 3. I create a Java application, source code as below:
> > > >
> > > > public static void main(String[] args) {
> > > > String ORG_CACHE = "org_cache_remote";
> > > >* Ignition.setClientMode(true);*
> > > > Ignite ignite = Ignition.start("example-ignite.xml");
> > > > CacheConfiguration orgCacheCfg = new
> > > > CacheConfiguration<>(ORG_CACHE);
> > > > orgCacheCfg.setIndexedTypes(Long.class, Organization.class);
> > > > ignite.destroyCache(ORG_CACHE);
> > > > IgniteCache cache = ignite.createCache(
> > > > orgCacheCfg);
> > > > cache.put(1L, new Organization(1L, "org1", true, "jurong east",
> > > > ""));
> > > > cache.put(2L, new Organization(2L, "org2", false, "orchard",
> > > ""));
> > > > cache.put(3L, new Organization(3L, "org3", true, "jurong west",
> > > > ""));
> > > > cache.put(4L, new Organization(4L, "org4", false, "woodlands",
> > > > ""));
> > > > cache.put(5L, new Organization(5L, "org5", false, "changi",
> > ""));
> > > > // cache.put(6L, new Organization(6L, "org6", true, "jurong
> > island",
> > > > ""));
> > > >
> > > > IgniteCache binaryCache =
> > cache.withKeepBinary();
> > > >
> > > > List> result;
> > > >
> > > > System.out.println("Scan by address");
> > > > ScanQuery scanAddress = new ScanQuery<>(
> > > > new IgniteBiPredicate() {
> > > > @Override
> > > > public boolean apply(Long aLong, BinaryObject
> > binaryObject) {
> > > > *// first time filter by jurong, got two entries,
> org1
> > > and
> > > > org3*
> > > > *// second time filter by changi, got two entries,
> org1
> > > and
> > > > org3*
> > > > *// third time filter by changi as well, uncomment
> > org6,
> > > > got three entries, org1, org3 and org6*
> > > > *return
> > > > binaryObject.field("address").startsWith("jurong");*
> > > > }
> > > > }
> > > > );
> > > > result = binaryCache.query(scanAddress).getAll();
> > > > System.out.println("result: "

Re: ScanQuery With BinaryObject

[Valentin Kulichenko]

Andrey,

Marshaller cache does not store classes, only class names. So I'm not sure
what you mean by this.

I looked at the code and it seems I was wrong - peer class loading does
work for scan query filter, which is good. But as I mentioned before, if
the class is available on local classpath, it will never be dynamically
loaded, even if peer class loading is enabled. Therefore server will not
know about any changes happening to the class definition on the client.
This is correct behavior.

-Val

On Wed, Apr 5, 2017 at 12:01 AM, Andrey Mashenkov <
andrey.mashen...@gmail.com> wrote:

> Hi Val,
>
> Filter object serialized and send inside GridCacheQueryRequest, and then it
> is deserialized on server side and loaded by cache class loader.
> Looks like filter class is cached in marshaller cache.
>
>
> On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Andrey,
> >
> > To my knowledge, peer class loading is not supported for scan query
> > filters, but I'm not sure though. Can you please check?
> >
> > Note that this actually doesn't matter if the class is available on
> > server's local classpath. In this case it will be always used regardless
> of
> > any changes done on a client (i.e. will never be dynamically loaded).
> This
> > is true for any functionality, including Compute Grid.
> >
> > -Val
> >
> > On Mon, Apr 3, 2017 at 10:19 AM, Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> > > Crossposted to dev:
> > >
> > > Guys,
> > >
> > > ScanQuery filter code (see IgniteBiPredicate implementation below) can
> be
> > > cached on server side
> > > that can cause unexpected results.
> > > The main point here is server node never restarts while client does it
> > with
> > > filter code changed.
> > >
> > > Is it ok?
> > >
> > > I try to add *serialVersionUID* and it was useless. The only class
> > renaming
> > > was helpful.
> > >
> > >
> > > -- Forwarded message --
> > > From: David Li 
> > > Date: Mon, Apr 3, 2017 at 9:24 AM
> > > Subject: Re: ScanQuery With BinaryObject
> > > To: u...@ignite.apache.org
> > >
> > >
> > > Sorry, please ignore the previous email, it was sent by mistake.
> > >
> > > 1. I download apache-ignite-fabric-1.9.0-bin.zip, and unzip it.
> > > 2. In terminal, I start an ignite instance by *bin/ignite.sh
> > > examples/config/example-ignite.xml*
> > > 3. I create a Java application, source code as below:
> > >
> > > public static void main(String[] args) {
> > > String ORG_CACHE = "org_cache_remote";
> > >* Ignition.setClientMode(true);*
> > > Ignite ignite = Ignition.start("example-ignite.xml");
> > > CacheConfiguration orgCacheCfg = new
> > > CacheConfiguration<>(ORG_CACHE);
> > > orgCacheCfg.setIndexedTypes(Long.class, Organization.class);
> > > ignite.destroyCache(ORG_CACHE);
> > > IgniteCache cache = ignite.createCache(
> > > orgCacheCfg);
> > > cache.put(1L, new Organization(1L, "org1", true, "jurong east",
> > > ""));
> > > cache.put(2L, new Organization(2L, "org2", false, "orchard",
> > ""));
> > > cache.put(3L, new Organization(3L, "org3", true, "jurong west",
> > > ""));
> > > cache.put(4L, new Organization(4L, "org4", false, "woodlands",
> > > ""));
> > > cache.put(5L, new Organization(5L, "org5", false, "changi",
> ""));
> > > // cache.put(6L, new Organization(6L, "org6", true, "jurong
> island",
> > > ""));
> > >
> > > IgniteCache binaryCache =
> cache.withKeepBinary();
> > >
> > > List> result;
> > >
> > > System.out.println("Scan by address");
> > > ScanQuery scanAddress = new ScanQuery<>(
> > > new IgniteBiPredicate() {
> > > @Override
> > > public boolean apply(Long aLong, BinaryObject
> binaryObject) {
> > > *// first time filter by jurong, got two entries, org1
> > and
> > > org3*
> > > *// second time filter by changi, got two entries, org1
> > and
> > > org3*
> > > *// third time filter by changi as well, uncomment
> org6,
> > > got three entries, org1, org3 and org6*
> > > *return
> > > binaryObject.field("address").startsWith("jurong");*
> > > }
> > > }
> > > );
> > > result = binaryCache.query(scanAddress).getAll();
> > > System.out.println("result: " + result.size());
> > > for (Cache.Entry entry : result) {
> > > System.out.println(entry.getValue().deserialize().toString());
> > > }
> > >
> > > ignite.close();
> > > }
> > >
> > > Here what I want to do is start a client node, connect to the server
> node
> > > started in step 2. Then I create a cache, put some data inside,
> > > then try to run a scan query to find entries by its address.
> > > The problem is when I run this program first time, it will return two
> > > entries, their addresses are started with "jurong", which is correct.
> > > When I run the program again, with changed value, eg. "c

IGNITE-2313 - ready for review

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

Hello, please review.

PR: https://github.com/apache/ignite/pull/1709/files
JIRA: https://issues.apache.org/jira/browse/IGNITE-2313
CI:
http://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests_RatJavadoc&branch_IgniteTests=pull%2F1709%2Fhead&tab=buildTypeStatusDiv

[jira] [Created] (IGNITE-4913) Update yardstick properties files

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-4913:


 Summary: Update yardstick properties files
 Key: IGNITE-4913
 URL: https://issues.apache.org/jira/browse/IGNITE-4913
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.9
Reporter: Ilya Suntsov
 Fix For: 2.0


Need to add *ver* parameter in all properties files from yardstick/config.
Example:
{noformat}
#Ignite version
ver="RELEASE-"

CONFIGS="\
-cfg ${SCRIPT_DIR}/../config/ignite-multicast-config.xml -nn ${nodesNum} -b 
${b} -w ${w} -d ${d} -t ${t} -sm ${sm} -dn IgnitePutBenchmark -sn IgniteNode 
-ds ${ver}atomic-put-${b}-backup,\
...
{noformat}



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

[GitHub] ignite pull request #1732: IGNITE-4856 .NET: StopAll on AppDomain unload

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-4856 .NET: StopAll on AppDomain unload



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

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

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

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


commit c3431e901678ea1520bfc647b935e7d425b839d4
Author: Igor Sapego 
Date:   2017-04-04T16:07:49Z

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

commit 0ef9046373846b7f79ced81468ff461172c44995
Author: Pavel Tupitsyn 
Date:   2017-04-05T08:00:20Z

IGNITE-4856 .NET: StopAll on AppDomain unload




---
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-4912) Fix testDeployCalledAfterCacheStart and testDeployCalledBeforeCacheStart tests

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4912:
---

 Summary: Fix testDeployCalledAfterCacheStart and 
testDeployCalledBeforeCacheStart tests
 Key: IGNITE-4912
 URL: https://issues.apache.org/jira/browse/IGNITE-4912
 Project: Ignite
  Issue Type: Sub-task
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev


IgniteServiceDynamicCachesSelfTest.testDeployCalledAfterCacheStart
IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart



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

[jira] [Created] (IGNITE-4911) Fix tests #1

[Dmitry Karachentsev (JIRA)]

Dmitry Karachentsev created IGNITE-4911:
---

 Summary: Fix tests #1
 Key: IGNITE-4911
 URL: https://issues.apache.org/jira/browse/IGNITE-4911
 Project: Ignite
  Issue Type: Bug
  Components: cache, general
Reporter: Dmitry Karachentsev
Assignee: Dmitry Karachentsev


Test that constantly failing:
IgniteServiceDynamicCachesSelfTest.testDeployCalledAfterCacheStart
IgniteServiceDynamicCachesSelfTest.testDeployCalledBeforeCacheStart

IgniteCachePeekModesAbstractTest.testNonLocalPartitionSize

GridCacheDeploymentOffHeapValuesSelfTest.testDeployment

GridCacheAtomicPrimaryWriteOrderNearRemoveFailureTest.testPutAndRemove
TcpDiscoveryNodeAttributesUpdateOnReconnectTest.testReconnect



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

Re: ScanQuery With BinaryObject

[Andrey Mashenkov]

Hi Val,

Filter object serialized and send inside GridCacheQueryRequest, and then it
is deserialized on server side and loaded by cache class loader.
Looks like filter class is cached in marshaller cache.


On Tue, Apr 4, 2017 at 4:43 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

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



-- 
Best regards,
Andrey V. Mashenkov